1756-DHRIO connectivity & setup

[gromit 4]

I have two SLC5/05 PLCs connected together on an Ethernet switch. PLC#1…192.168.0.151…ch0 is DH-485 Node 1 PLC#2…192.168.0.152 1756-ENET…192.168.0.150 The Ethernet switch is connected to a 1756-ENET module in a 1756-A4/B chassis that also contains a 1756-DHRIO. Channel B of the 1756-DHRIO module is connected to a ‘DH+ to Modbus’ converter which is connected to a Siemens DCS. I do not understand how to configure the ‘DH+ to Modbus’ converter access the data in both PLCs through the 1756-DHRIO. I believe it distinguishes the PLCs by their node address, but PLC#1 has ch0 addressed as Node1, but since PLC2 ch0 is configured as DF1 it does not have a node address. This link has been in place for nearly 10 years, but since the DCS is being updated, it is replacing the ‘DH+ to Profibus’ converter with a ‘DH+ to Modbus’ converter. Please see attached pics for better insight. Also, when I connect to the channel B of the 1756-DHRIO module with the 1785-U2DHP DH+ cable/converter it appears as a KE/KF/KF2 in RSlinx RSWho, and I am not able to see the PLCs through this connection. Thanks. Edited 22 Apr 2015 by gromit

[gromit 4]

What I believe is happening is as follows: PLC#1 is moving N37:0-10 to DHRIO node5 address N7:0-10 PLC#2 is moving N7:14-17 to DHRIO node5 address N7:11-14 PLC#1 is moving N38:0-38 to DHRIO node5 address N7:15-54 PLC#2 is moving N18:0-25 to DHRIO node5 address N7:55-81 Sooo, the EQUUSTEK DL3500 DH+ to Modbus converter should reference Node address 5 and registers N7:0-N7:81. I'm still not sure why channel B of the 1756-DHRIO module with the 1785-U2DHP DH+ cable/converter appears as a KE/KF/KF2 in RSlinx RSWho, Thanks.

[Ken Roach 194]

I read through the post a few times and I think I understand the questions now. Are these RSWho screenshots taken with the existing DH+/Profibus device in place, or with the new Equustek DL3500 in place ? Your RSWho should show three devices under the 1784-U2DHP; the RSLinx station (node 7), the 1756-DHRIO station, and the Equustek DL-3500. And the browse through the backplane should show more than just the 1756-DHRIO Channel A and Channel B. It should show the RSLinx station and the DL-3500 as well. Since the DL-3500 is functionally built to behave like a KE/KF/KF2 network bridge, my guess is that the Equustek is the thing you're seeing at Node 0. The DH+ addresses and the DH+ data speed for the 1756-DHRIO are set via rotary switches. What is your node number for the 1756-DHRIO on Channel A and on Channel B ? It needs to be different than the node numbers used for the DL-3500 and the 1784-U2DHP/RSLinx station. And remember that everything needs to be configured for the same DH+ data rate. It can't hurt to have proper terminating resistors in place as well, even with a short cable. I'm going to take a few minutes to look through the DL-3500 DH+/Modbus application notes. I don't have any direct DL-3500 experience because we never used them at Rockwell Automation for various technical and legal patent-related reasons. I will mention that you have to be extremely vigilant when reading Equustek documentation because they are notorious for copy-paste editing errors.

[Ken Roach 194]

Quick questions: My guess is that the DCS will be a Modbus RTU Master, and that the DL-3500 will be a Modbus RTU Slave. Is this correct ? Was the DH+/Profibus device also an Equustek device ? If not, what was it ?

[Ken Roach 194]

My brief reading of the DH-3500 Modbus RTU Slave to DH+ application note suggests that you're going to need a ControlLogix CPU to act as the middleman for this data. This will make the new system more similar to the way that the old system appears to have worked. Here's why: The DL-3500 does not itself serve as the target of DH+ messages. The old Profibus unit probably did, and emulated PLC-5 data tables. Was it an SST X-Link ? The 1756-DHRIO does have a DH+ routing table that allows messages that arrive at its DH+ port to be routed to other devices on a Rockwell CIP network, including devices on Ethernet and on ControlNet and on other DH+ networks. But in order to use that routing table, the DH+ message needs to be a "DH+ Remote Message". It needs to have three different addresses in message: the address of the "local bridge" on DH+, the address of the "remote target" and the "Link ID" of the remote network. Ordinary DH+ messages aren't Remote Messages. They are "DH+ Local Messages" and all they have is the local DH+ network target node address. When the 1756-DHRIO receives a DH+ local message, it doesn't use the routing table. Instead, it looks at its Default Slot number and sends the message to one of the slots in the backplane (the default is Slot 0), expecting there to be a ControlLogix CPU in that slot to answer the message by emulating PLC/SLC data tables. If you have any ControlLogix CPU in the chassis, it can fulfill this role. Even an obsolete 1756-L1 or 1756-L55 will do the job if you're on a budget.

[gromit 4]

Wow Ken. . . very good information. Please find my responses to your questions in bold red font. I read through the post a few times and I think I understand the questions now. Are these RSWho screenshots taken with the existing DH+/Profibus device in place, or with the new Equustek DL3500 in place ? With the Equustek DL3500 Your RSWho should show three devices under the 1784-U2DHP; the RSLinx station (node 7), the 1756-DHRIO station, and the Equustek DL-3500. Sorry, is the RSLinx station my laptop??? And the browse through the backplane should show more than just the 1756-DHRIO Channel A and Channel B. It should show the RSLinx station and the DL-3500 as well. Wow… Since the DL-3500 is functionally built to behave like a KE/KF/KF2 network bridge, my guess is that the Equustek is the thing you're seeing at Node 0. OK The DH+ addresses and the DH+ data speed for the 1756-DHRIO are set via rotary switches. What is your node number for the 1756-DHRIO on Channel A and on Channel B ? It needs to be different than the node numbers used for the DL-3500 and the 1784-U2DHP/RSLinx station. Channel A is Node 1 Channel B is Node 2 And remember that everything needs to be configured for the same DH+ data rate. It can't hurt to have proper terminating resistors in place as well, even with a short cable. The old DH+/Profibus device had a terminating resistor, as well as the DHRIO chB, but the resistor at the Equustek DL3500 is not currently in place. Is it needed on both ends? I'm going to take a few minutes to look through the DL-3500 DH+/Modbus application notes. I don't have any direct DL-3500 experience because we never used them at Rockwell Automation for various technical and legal patent-related reasons. I will mention that you have to be extremely vigilant when reading Equustek documentation because they are notorious for copy-paste editing errors. Understood. New question…The MSG instructions identify the DHRIO module, Node5 and N7:0-81, but the DHRIO chB is address 2, sooo, what Node address should the Equustek DL3500 reference? Quick questions: My guess is that the DCS will be a Modbus RTU Master, and that the DL-3500 will be a Modbus RTU Slave. Is this correct ? Yes sir. Was the DH+/Profibus device also an Equustek device ? If not, what was it ? No sir. . . not sure why??? My brief reading of the DH-3500 Modbus RTU Slave to DH+ application note suggests that you're going to need a ControlLogix CPU to act as the middleman for this data. This will make the new system more similar to the way that the old system appears to have worked. Wow, could it otherwise be done by using something else rather than the Equustek DL3500, instead of having to procure a new ControlLogix processor??? Here's why: The DL-3500 does not itself serve as the target of DH+ messages. The old Profibus unit probably did, and emulated PLC-5 data tables. Was it an SST X-Link ? Yes sir. The 1756-DHRIO does have a DH+ routing table that allows messages that arrive at its DH+ port to be routed to other devices on a Rockwell CIP network, including devices on Ethernet and on ControlNet and on other DH+ networks. Since both SLC5/05s are tied to an ethernet switch, can we abandon the DHRIO device and bring it into the DCS via TCP/IP? But in order to use that routing table, the DH+ message needs to be a "DH+ Remote Message". It needs to have three different addresses in message: the address of the "local bridge" on DH+, the address of the "remote target" and the "Link ID" of the remote network. Ordinary DH+ messages aren't Remote Messages. They are "DH+ Local Messages" and all they have is the local DH+ network target node address. When the 1756-DHRIO receives a DH+ local message, it doesn't use the routing table. Instead, it looks at its Default Slot number and sends the message to one of the slots in the backplane (the default is Slot 0), expecting there to be a ControlLogix CPU in that slot to answer the message by emulating PLC/SLC data tables. If you have any ControlLogix CPU in the chassis, it can fulfill this role. Even an obsolete 1756-L1 or 1756-L55 will do the job if you're on a budget. Wow, could it otherwise be done by using something else rather than the Equustek DL3500, instead of having to procure a new ControlLogix processor??? Thanks for the very detailed response.

[Ken Roach 194]

The way your old system worked was that the SST X-Link emulated a PLC-5 controller on the DH+ network at Node 5. The SLC-5/05 controllers actively sent data to the X-Link using MSG instructions. The SLC-5/05's firmware allows them to send a message over Ethernet, through a ControlLogix backplane to a 1756-DHRIO and have the DHRIO handle sending that message (and the reply) on DH+. The proposed system works differently. The Equustek DL3500 accepts Modbus messages, converts them to DH+ protocol with similarly structured addresses, and forwards them on DH+ as DH+ Local Messages. They cannot pass through the 1756-DHRIO/1756-ENET bridge because they do not contain the appropriate DH+ Remote Link Addressing information. If you want to try using the ControlLogix method, you'll have to focus on getting the DH+ network functioning correctly, which means being able to "see" the DL3500, the 1756-DHRIO port, and the 1784-U2DHP/RSLinx all on the network. Your laptop, the 1784-U2DHP, and RSLinx software all show up as the "RSLinx" station. The DL-3500 is (evidently) the "KE/KF/KF2" device at Node 0. Data Highway Plus runs either at 57600 bits per second or 230400 bits per second. Very old 1756-DHRIO modules did not have the ability to run at the higher data rate, so I suggest setting everything to 57.6 kb/s. DH+ networks need two terminating resistors, one at each end. These should be 150 ohms for the 57.6 kb/s data rate. The 1756-DHRIO channels are electrically isolated from one another (unless you wire them both together !), so terminating resistors are separate on those two networks.

[Ken Roach 194]

As for "other methods", I don't know your Siemens DCS capabilities. If it supports the old Rockwell Automation "CSPv4" protocol on Ethernet, or the new Rockwell Automation EtherNet/IP protocol with support for SLC-5/05 controllers, you could connect directly to these SLC-5/05 controllers over Ethernet. If they're welded to the idea of using Modbus RTU protocol, one solution might be to install a Digi One IAP device, which can perform that sort of translation. A very good (and very technical) description of how the Digi One IAP does that is here : Polling Rockwell PLCs as Modbus Slaves

[gromit 4]

Thanks Ken. The way your old system worked was that the SST X-Link emulated a PLC-5 controller on the DH+ network at Node 5. Understood. The SLC-5/05 controllers actively sent data to the X-Link using MSG instructions. The SLC-5/05's firmware allows them to send a message over Ethernet, through a ControlLogix backplane to a 1756-DHRIO and have the DHRIO handle sending that message (and the reply) on DH+. Understood. The proposed system works differently. The Equustek DL3500 accepts Modbus messages, converts them to DH+ protocol with similarly structured addresses, and forwards them on DH+ as DH+ Local Messages. They cannot pass through the 1756-DHRIO/1756-ENET bridge because they do not contain the appropriate DH+ Remote Link Addressing information. Understood. If you want to try using the ControlLogix method, you'll have to focus on getting the DH+ network functioning correctly, which means being able to "see" the DL3500, the 1756-DHRIO port, and the 1784-U2DHP/RSLinx all on the network. Understood, but the 1784-U2DHP cable was only briefly used via RSLinx with my laptop. Now using the Ethernet RSLinx driver with my laptop. Your laptop, the 1784-U2DHP, and RSLinx software all show up as the "RSLinx" station. Understood, but the 1784-U2DHP cable was only briefly used via RSLinx with my laptop. Now using the Ethernet RSLinx driver with my laptop. The DL-3500 is (evidently) the "KE/KF/KF2" device at Node 0. Well, once the EQUUSTEK DL-3500 module was set up properly, the "KE/KF/KF2" device appeared as Node 5. Unfortunately the EQUUSTEK DL-3500 would fault when it was set up as node 5 in order to receive the DH+ data. Data Highway Plus runs either at 57600 bits per second or 230400 bits per second. Very old 1756-DHRIO modules did not have the ability to run at the higher data rate, so I suggest setting everything to 57.6 kb/s. Understood, but the original SST X-Link was configured as 230kBaud, which has us scratching our heads. DH+ networks need two terminating resistors, one at each end. These should be 150 ohms for the 57.6 kb/s data rate. Understood. The 1756-DHRIO channels are electrically isolated from one another (unless you wire them both together !), so terminating resistors are separate on those two networks. Understood. ___________________________________________________________________________________________________________________________________________________________________________________________________- As for "other methods", I don't know your Siemens DCS capabilities. If it supports the old Rockwell Automation "CSPv4" protocol on Ethernet, or the new Rockwell Automation EtherNet/IP protocol with support for SLC-5/05 controllers, you could connect directly to these SLC-5/05 controllers over Ethernet. OK. If they're welded to the idea of using Modbus RTU protocol, one solution might be to install a Digi One IAP device, which can perform that sort of translation. A very good (and very technical) description of how the Digi One IAP does that is here : Polling Rockwell PLCs as Modbus Slaves Awesome…I like the Digi One IAP option. So can I assume that the Digi One IAP effectively provides the same functionality and features that the SST X-Link previously provided? THANKS for the detailed responses to this very challenging matter!!!

[Ken Roach 194]

The Digi One IAP would work more like the way the EquusTek DL3500 works. It takes an incoming Modbus RTU message, converts the Modbus registers to SLC-500 registers and the protocol from Modbus to A-B PCCC, then sends it on to the SLC-5/05 over Ethernet. You don't send MSG instructions to it from the SLC-5/05 controllers like you were doing with the X-Link. The attached PPT might make a little sense on what I'm describing with the Digi One IAP. Are you in the planning stages or is this stuff already bought and installed ? SLC to DCS.pdf Edited 24 Apr 2015 by Ken Roach

[gromit 4]

Thanks Ken...please find my response to your comments and questions in bold red font. The Digi One IAP would work more like the way the EquusTek DL3500 works. Based on the PPT, will the DigiOne IAP replace the EQUUSTEK, the 1756-ENET, and the 1756-DHRIO module? It takes an incoming Modbus RTU message, converts the Modbus registers to SLC-500 registers and the protocol from Modbus to A-B PCCC, then sends it on to the SLC-5/05 over Ethernet. You don't send MSG instructions to it from the SLC-5/05 controllers like you were doing with the X-Link. Sooo, will the DigiOne IAP replace the EQUUSTEK, the 1756-ENET, and the 1756-DHRIO module …and will it be able to reach into both SLC5/05s via Ethernet and place the respective N7 registers into a single modbus table? …and can it be done without adding any logic to the two existing SLC5/05s. If so, how can this not be the best option? The attached PPT might make a little sense on what I'm describing with the Digi One IAP. Very nice PPT. Are you in the planning stages or is this stuff already bought and installed ? The new DCS was just installed and the link was scheduled to be tested this week but it became clear that something was missing.

[Ken Roach 194]

I usually use one Digi One IAP per PLC controller, so I don't know for sure if a single Digi One IAP can serve both SLC-5/05 controllers. The Digi One IAP would replace all three intermediate devices: the 1756-ENBT, the 1756-DHRIO, and the DL-3500. According to the address translator spreadsheet from Digi: PLC#1's N37:0 through N37:15 will be represented by Modbus addresses 409251 through 409261. PLC#1's N38:0 through N38:38 will be represented by Modbus addresses 409501 through 409539. PLC#2's N7:14 through N7:17 will be represented by Modbus addresses 400015 through 400018. PLC#2's N18:0 through N18:25 will be represented by Modbus addresses 404501 through 404526. That spreadsheet that translates A-B data tables to Modbus data tables is available from Digi from their Digi One IAP support webpage: http://www.digi.com/support/productdetail?pid=1910&type=documentation

[gromit 4]

Thanks Ken...please find my response to your comments and questions in bold red font. I usually use one Digi One IAP per PLC controller, so I don't know for sure if a single Digi One IAP can serve both SLC-5/05 controllers. I couldn’t find anything that confirmed that one DigiOne IAP could serve two SLC5/05s, but I left a voicemail for DigiOne at 877.912.3444. The Digi One IAP would replace all three intermediate devices: the 1756-ENBT, the 1756-DHRIO, and the DL-3500. That is a big benefit that I was hoping for. According to the address translator spreadsheet from Digi: PLC#1's N37:0 through N37:15 will be represented by Modbus addresses 409251 through 409261.yes PLC#1's N38:0 through N38:38 will be represented by Modbus addresses 409501 through 409539. yes PLC#2's N7:14 through N7:17 will be represented by Modbus addresses 400015 through 400018. Oops When I used the [Modbus = (file number * 250) + element number + 1] equation I get MB address 401765-401768 for N7:14-N7:17 PLC#2's N18:0 through N18:25 will be represented by Modbus addresses 404501 through 404526. yes That spreadsheet that translates A-B data tables to Modbus data tables is available from Digi from their Digi One IAP support webpage: http://www.digi.com/...e=documentation Yes sir…the link I found the info at is http://ftp1.digi.com/support/documentation/90000647_B.pdf. If the DigiOne IAP cannot serve both SLC5/05s, what would be the best option?

[Ken Roach 194]

Thanks for the correction on N7:14-17; The spreadsheet itself treats a default of N7:0 as 40001, but what it means is that you can read "Data File 0" as though it was N7. Your manual calculation looks correct. It makes sense that a Digi One IAP could have multiple target SLCs treated like multiple target Modbus slaves, but I don't know how your DCS addresses Modbus slaves. Best to get your answer direct from Digi.

[gromit 4]

Thanks Ken...please find my response to your comments and questions in bold red font. Thanks for the correction on N7:14-17; The spreadsheet itself treats a default of N7:0 as 40001, but what it means is that you can read "Data File 0" as though it was N7. Your manual calculation looks correct. Super. It makes sense that a Digi One IAP could have multiple target SLCs treated like multiple target Modbus slaves, but I don't know how your DCS addresses Modbus slaves. Best to get your answer direct from Digi. Great. I left Digi a voice message and an email message from their Digi website, but still haven’t received a reply. I am hopeful that they will confirm that the DigiOne IAP could serve multiple SLC5/05s. Thanks.

[gromit 4]

Ken, I just received the Digi reply this morning. Looking through the links, it appears that one DigiOne IAP can serve two SLC5/05s, but I have yet to figure out the configuration to achieve that. I am at a different site today, but hope to find time to review the documentation thoroughly later today or tomorrow. “The DOIAP can convert Allen Bradly protocols to Modbus. It is done in the DOIAP using a one to one mapping within the DOIAP. You will find the convertion information using Digi’s protocol bridging calculator (Master polling device is rockwell protocol. Slave (polled) device is using the modbus protocol). Digi document number 90000652_a.xls. As well as appliction note 9000643_a found on our support site. Application note: http://ftp1.digi.com/support/documentation/90000643_a.pdf Protocol bridging calculator. http://www.digi.com/support/productdetail?pid=1910 take a look at these documents. It will show you how configure the device for you desired setup. Kind Regards, John R Digi Tech Support”

[gromit 4]

After speaking with Digi tech support, they claim that it will indeed achieve the networking scheme that is needed. Therefore, the DigiOne IAP module was purchased today, and I/we will proceed with setting it up upon receipt. Thanks for your direction and support.

[gromit 4]

The DigiOne IAP has not yet been received, but we acquired an Equustek EQ-DCM gateway device which was very easy to configure. It took less than an hour to setup and test. My guess is that the DigiOne IAP device would work just as well, and we will test it in the lab once we receive it. I was looking for an interface module to standardize with, and was really hoping that the DigiOne IAP would fit the bill, but may have missed the opportunity since startup schedules dictated an expedient solution. I was kinda torn when the EQ-DCM proved to be so simple and effective. . . although not sure of the cost. Thanks again for your assistance and very detailed response(s).