Search results

PROFIBUS GSD files are device-specific, so when replacing a device with another that is not the same model, you will need to make changes to the DCS system using the new device's GSD file. Also make sure the new device's address is set to the same address as the device you are replacing (and...

You need to include more details to get appropriate help, but here are some general things to confirm. Wiring You should use a 3 wires to connect the two devices together (preferrably RS-485 rated cabling, 1.5 twisted pair conductors - the .5 is for the 3rd wire for common-mode reference)...

It appears from the PCB pictures from the previous links that the RS-485 circuitry on the Sunamp is not isolated, therefore, I would connect to "GND" on J8 of the Sunamp for the ground connection. RS-485 grounding is a much larger topic to cover here, but suffice it to say, yes it may work when...

Just in case there was confusion on this, you should connect ground in addition to A and B to make sure a common reference for the RS-485 signals is established. Your RS-485 converter should have a ground (it may be called signal reference, common, ref, etc.) and this should be connected to the...

Also, note that there is no industry-agreed-upon standard for the polarity of 'A' and 'B' for RS-485, so assuming you're using those thru holes, you may need to try swapping your A and B wires and perform your tests again. Having the polarity swapped does no harm, but communication won't work.

I assume during your tests you connected an RS-485 adapter from a computer to the A and B thru holes on the Sunamp? Did you connect ground? If the device did support Modbus, it should at least reply with an exception response when the baud rate, parity, and address are correct, even if you are...

What makes you believe the device uses the Modbus protocol? Does Sunamp state that it supports Modbus? Based on a quick Google search, it seems like someone has successfully interfaced to a Sunamp heat battery using only the TX and Ground pins (which means it's not Modbus because Modbus...

If you're looking for a device to convert between ControlLogix (Ethernet/IP protocol) and this ASCII protocol, take a look at ICC's ETH-1000 gateway. Its Generic Serial driver supports nearly any ASCII protocol and would have no problem with this protocol used by the Honeywell equipment. Details...

To improve your chances of getting responses, I recommend that you start a new thread for this issue and provide as much details as you can, including which device is the client (master), which is the server (slave), and how you have the client (master) configured for Modbus communications...

They're probably about the same price as the Moxa, but you could take a look at Advantech's ADAM I/O modules: https://www.advantech.com/products/iot-ethernet-i-o-modules-adam-6000-6200/sub_gf-5197

I believe this is the common "off by one" addressing issue when using Modbus. Both the IEM3150 and ModScan use 1-based addressing, however, I'm guessing Node-RED uses 0-based addressing. Try using 3059 in Node-RED instead of 3060. For additional details on Modbus register numbering, refer to...

You're entitled to believe what you wish, but all I have done is presented you with the facts. Please remember, I am donating my valuable time to this forum and providing free engineering consultation to you for your product. I am not here to argue about semantics of serial or Ethernet...

The concept of an Address is at the protocol level (Modbus RTU). The physical layer that the protocol is running on (USB, TTL, RS-232, RS-485, radio, etc.) has no concept of an address. Yes, there are physical layers that are inherently point-to-point (USB, TTL, RS-232) or multi-drop (RS-485)...

Yes, the concept of broadcast only exists with serial line and Modbus RTU. However, I assume when you mention USB, this would be a USB Virtual COM port, so it is emulating a serial connection and using Modbus RTU. Therefore, it's possible that a a Modbus master connected to your product via USB...

Modbus RTU slave address 0 is reserved for broadcasts. If a slave receives a message targeted at address 0, it should process it, but not respond (since you don't want all slaves responding at the same time, causing bus contention). A master can send a write command to slave address 0 and all...

I'm glad you got it working. On a side note, I don't think you need the "ModbusTCP Poll" checkbox checked. Unfortunately, the manual is very poorly written and extremely vague on what the setting does, stating only ModbusTCP Poll: Function for Modbus Polling. Also, for what it's worth, there...

The Local Port Number of the USR is still set to 1 according to your screenshot. You need to change this to 502.

Those screenshots seem to indicate you still have the USR-N540 misconfigured. Did you set the Local Port setting to 502? Did you power cycle the USR-N540 after making changes? It's unlikely to be a firewall issues, since your computer is trying to make the connection (outgoing firewall rules...

I recommend that you read section 3.5 in the manual you linked. That explains how to properly setup the USR-N540 for Modbus RTU to Modbus TCP conversion. You need to select "ModbusTCP" in the ModbusTCP setting right below TCP Server style instead of "None". You also want the USR to be a TCP...

For RS-485 connections, you connect plus to plus, minus to minus, and ground (0V, ref, com) to ground (0V, ref, com). For your particular equipment, connect as follows USR T+ (A) <-> IEM D1/+ USR T- (B) <-> IEM D0/- USR GND <-> IEM 0V Make sure to configure the USR device for RS-485 mode...