I am trying to wire a Digi One RealPort between a Rosemont 1420 modbus wireless hub and the ethernet network to pick up the modbus signal on a Rockwell control logix plc. I have hooked the Modbus A and B to the terminal 3-6+ on and the 4-7- on B. I come to this conclusion after extensive studying of both manufacturer’s supplied documents. This is not working. I have ten hours invested here and need some help.
The Digi One Realport IA is a pretty old product (that’s not the problem, other than I’ve never seen a physical example of that model).
I can only comment on how the newer Digi One IA or IAP work.
Since the Digi’s ground is isolated/floating, you MIGHT require a signal-ground connection from pin 5 of the Digi to whatever Rosemount 1420 treats as ground. This is because (and you can read the EIA-485 spec if you doubt me) a 2-wire RS-485 needs some form of “return path” either directly by wire or indirectly through shared power grounds. Since the Digi isolates the DC supply, there is NO shared power ground.
Also for 2-wire RS-485 to work, one of the two devices must have a “line bias” enabled, or there will be too much noise when neither device is transmitting. On the Digi, line bias is only on when DIP # 4 (the terminator) is ON. So although termination won’t be required on a short cable, the line bias is critical on any length. If the Rosemount 1420 supplies line-bias, then the DIP #4 on the digi can be on or off.
As for the A/B, unfortunately the EIA-485 standard defines these as logically not voltage, so one can never out guess if A means + or -.
I normally find B = + (so screw 3 to B) and A = - (do screw 4 to A), which is backwards from how you are trying. On the Digi One IAP, one doesn’t need to link 3&6 or 4&7, so I’d guess on the older Digi One Realport IA you also don’t need to. It is only the Txd+ and Txd- which are active during RS-485 2-wire mode - the Rxd+/Rxd- will be tri-stated.
Are you enabling a Modbus/TCP to Modbus/RTU bridge within the Digi product? If so it fixes up any timing issues introduced by Ethernet encap. Modbus/RTU can be very fussy about tiny time-gaps, so if you are just using Digi Realport driver on Windows or raw TCP/IP encap of Modbus/RTU, it is possible timing gaps are causing message discard at either end.
OK Thanks for getting the wiring straight. Now The discovery program sees my digi IA. But, when I try to configure I cannot get the browser window to communicate. I had to hook the ethernet port to the pc with an ethernet crossover cable to get discovery to work. I also tried to communicate through the command prompt with no luck.
The discovery tool only works if you turn the Windows firewall off, because the tool sends out Class D multicast, and the products return Class C unicasts (which might include an IP of 0.0.0.0 or from a remote subnet) will be blocked by default as unexpected.
I have heard of people not being able to use cross-cables & forced to use switches (for example some notebook Broadcom chips don’t auto-negotiate cleanly on a cross-cable), but I’ve never heard of someone being forced to use a cross cable.
It sounds like you are having hardware issues - make sure you have at least a 12vdc 500mA power supply. 12vdc 200mA (as example) is only enough to kind of make the Digi work, but it has problems when you actually try to log in to the product. Also, RS-485 can draw up to 50-65mA of extra power (compared to a few mA for RS-232), so that is another variable when you connect external RS-485 devices.
You may want to try a different web browser to get into the Digi unit. There are issues with IE that do not allow you web access into the Digi if you are on older firmware. A firmware upgrade fixes this issue, but due to the age of your product, there may not be a firmware upgrade available. This is something you would have to check on once you get into the device and see what firmware version your device is running. Try using something like Firefox and see if you are now able to get into the web interface that way.
Thanks for the support. I had to do a reality check and go back to the basics. First I changed the programming pc’s IP address to the same subnet as what the DigiRealPort came with from the factory. This enabled me to connect through the devices built in web address and change the IP Adress to my choice. Then I changed the pc back and communicated to the DigiRealPort to finish the incoming serial 485 setup. I am still communicating through the ethernet crossover cable. When I get the programming done I will try to connect over the lab’s ethernet network.
Right now I am researching what layer 1, 2, and seven parameters the 1420 will send over the 485 to the DigiRealPort.
I need an eds file to communicate with rslinx
An old Digi One IA Realport won’t work with RSLinx because it didn’t support ODVA Class 3 connected messaging. The newer Digi One IAP does support this form of messaging.
Actually, you don’t need an EDS because how RSLinx talks to PLC like MicroLogix, SL5, ControlLogix is NOT defined in the EDS. The DOIAP contains no ODVA/CIP objects - which is what the EDS describes.
Adding the EDS makes a nice DOIAP ‘icon’ show up instead of the yellow question-mark - but it won’t help or hurt RSLinx communications.
The EDS file is located here:
http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=433
If your RSLinx to PLC is not working, try turning OFF support for AB/Ethernet (or old CSPv4) on the DOIAP. Only enable the newer Ethernet/IP. RSLinx can talk to a DOIAP attached to the serial port of a MicroLogix, PLC5 or SLC5.
But you cannot use RSLinx via Ethernet/IP to talk to a DOIAP to CompactLogix or ControlLogix serial port. This is because a special not-really-DF1 protocol is used and RSLinx won’t understand to create it.
To make this work (RSLinx -> Ethernet -> DOIAP -> C*Logix DF1 port), use Digi RealPort driver to create a new ‘serial port’ like COM4 on your computer linked to the DOIAP. This way RSLinx understands to use this special serial protocol. Other products like the 1761-NET-ENI include support for this other serial protocol, but the DOIAP does not.
Actually, what version of firmware are you using?