1756-DHRIO that can't be replaced

tsmith35

Lifetime Supporting Member
Join Date
Jun 2008
Location
USA
Posts
46
Well, it looks like I've run into another goody. We have a CLX rack running an L55 (v11.28) processor. It has a 1756-DHRIO v5.4 module in slot 4, and the module is configured with DH+ @57.6k on Channel A and RIO (going to some RIO-enabled scales) on Channel B. Channel A talks to eight 5/04s. The module routing table link IDs were all on factory defaults ("0" aka "Link Undefined"). This has been the setup for years, and worked fine until just recently.

The DHRIO module failed with a CNFG FALT following a planned shutdown. Attempts to read the routing table failed with a "module returned unexpected information" error. After a couple failed attempts to revive it, I decided to replace it with another identical DHRIO.

Despite carefully setting up the rotary switches (Ch. A address is set to "10" and Ch. B address is set to "01") and setting up the routing identical to the old module, the processor (and RSLinx) refused to see any nodes through DH+. I tried yet another module (v5.3 this time), but no-go. Finally, I borrowed a 1756-DHRIO/E v7.2 and met up with the same problem.

With time running short for startup, I reinstalled the old DHRIO and repeatedly attempted to write to the routing table (along with a few rack power cycles). Finally, despite several repeats of the "unexpected information" error, the CNFG FALT went away and the module began working normally. I can't read the routing table, though, and I don't trust the old module to keep running.

Since that time, I've had the opportunity to try again, but still no-go. I'm sure that I must be missing something, but I don't know what. CLX can see the new modules and has keying set properly for whatever module I am trying at the time (and I've also tried disable keying and exact keying, except for the DHRIO/E), but the only DHRIO that works is the old one.

Any help is welcomed. I'm running out of ideas... thanks.
 
Have you checked the link ID on the SLC5/04 as from memory I believe the Factory default link ID is number = 2

PLC5 default = 0

The DH+ RIO maybe default = 0

Just a wild guess
Does the DH+ RIO card need a power recycle to accept new settings
 
Last edited:
Well, the passthrough Link ID on all of our SLC 5/04 processors is set to 2, the default, but the node numbers are set properly. I don't think the passthrough Link ID has anything to do with the DHRIO routing table link IDs, but I could be wrong.

As for the power cycle, I couldn't say for sure. I was writing the routing table, then power-cycling the modules we tried individually and as part of power-cycling the rack. Nothing seemed to allow the new DHRIO modules to see the nodes on DH+.
 
Sounds like you have firmware and / Or Software compatability issues.

I would check and flash the firmware on the controller, DHRIO card and check nd update your version of linx. IIRC V11 firmware for the controller is pretty old.

Check the firmware in all you 5/04 units also. I would think they would benefit from being all the same if they are not the most recent rev.

I think flashing your controller,DHRIO and making sure your linx is up to date will solve your issues.
 
Rockwell doesn't know either

Well, I presented this issue to Rockwell tech support, and they had no idea what was causing the issue with missing nodes under the DH+ tree. So... I'll wait until I can get a chunk of planned downtime and work on finding a solution. My gut feeling is that I may need to interrupt and restore communication for each 5/04 individually, then power cycle the 1756-DHRIO. We'll see. Thank you to those of you who took time to try and help.
 
Okay, here's what I found as a solution to the problem: the MSG logic in the PLC was incorrectly written. It attempted to unnecessarily seal in each MSG instruction. In addition, the two rungs immediately below each MSG instruction rung cleared the DN and ER bits, causing each MSG instruction to immediately re-enable on the next scan.

After fixing the MSG implementation and removing the rungs used to clear the DN and ER bits, messaging was only active when called vs. running constantly.

Interestingly, this took care of my inability to replace the flaky DHRIO module successfully. I am only guessing, but it appears the constant MSG bombardment was preventing any replacement DHRIO module from seeing all of the nodes on the DH+ network.

The MSG instruction information was found starting on page 156 of the Logix5000 Controllers General Instructions Reference Manual.
 
Thanks for sharing the info - a good lesson for anyone programming messages in PLC instruction code.

MESSAGES TAKE TIME - longer than most PLC scans.

MESSAGES are usually queued - don't fill the queue.
 

Similar Topics

We have a remove PLC rack that is being used to collect data from older equipment via a 1756-DHRIO module. This module occasionally faults out...
Replies
1
Views
391
I am trying to send some datas from PLC-5 to control logix plc through 1756-DHRIO. When I go online to PLC-5, Message instruction gives error &...
Replies
15
Views
3,298
:banghead: Remote I/O The occasional times i have had to deal with blue hose/PLC5 I/O addressing it always wrecks my head. Now i am working on...
Replies
9
Views
3,245
Called to a site and am neck deep currently ;) running, but issues. Phase 2 completion has been running for almost 2 years no issues. Controller...
Replies
3
Views
1,615
Hello all. I have a job to add a 1794-IE8 Card in slot 5 on an existing Flex IO Rack which uses a 1794-ASB communications module, which...
Replies
8
Views
2,956
Back
Top Bottom