1771 ASB Fault after a Power Outage?

[jasil]

L81 series processor, DHRIOE 1756 card, communicating to some old PLC 5 IO.

Site wide power outage after power up everything is okay except 1 error this ASB module fault:

16#0312

I have heard this could be rack related like a bad card in a slot, bad PSU, noise, all other RIO adapters are fine just this one is not.

Just picking brains until I go in I have never seen an ASB fail before.

LED STATUS: Active Blinking GREEN & Adapter Fault Blinking RED in unison at the same time.

 

[Ken Roach]

I think you've finally seen your first real in-the-field Adapter Fault.

Ask the onsite guys if the top green "ACTIVE" indicator and the middle red "ADAPTER FAULT" are alternating, or in unison.

Alternating means a backplane restart fault, which would be consistent with the power cycle. Usually an ASB can restart the backplane itself (that's totally normal) but you can also set a DIP switch to make the restart require a contact closure. That DIP switch could have failed, or there might really be a rack restart button.

Those indicators blinking in unison mean that the starting rack number is invalid or incorrect (I've never seen that in the field, I'm reading from the Troubleshooting section of the Quick Reference, page 137):

https://literature.rockwellautomation.com/idc/groups/literature/documents/qr/1785-qr001_-en-p.pdf

Disassembling the chassis and blowing everything out with compressed air is a good start.

Also look at the PLC-5 I/O configuration and examine the equipment that comes before this in the Rack number sequence. If something's failed on that device, maybe that generated a RIO address overlap or conflict.

 

[jasil]

They are blinking in unison in sync with each other.

Thanks Ken.

We will see how it goes

 

[Ken Roach]

Interesting !

Let's take a look at what the reference has to say when Active and Adapter Fault are blinking in unison, and the I/O Rack indicator is off:

Incorrect starting I/O group number error in starting I/O group number or I/O
rack address

Check switch settings. Refer to table 3.B to verify acceptable beginning I/O group number; set switches correctly

I think the "table 3.B" they're referring to is actually from a different 1771-ASB user manual, but the same information is on Page 100 of the Quick Reference, where it shows that SW1 switches 7 and 8 designate the beginning I/O group represented by this adapter.

I would blow the switches out with compressed air, maybe spray with some isopropyl. Note the switch positions carefully, then use anything but a graphite pencil to rock the DIP switches back and forth to see if you can make a better connection.

My thinking is that if there's corrosion or damage to the DIP switch, then the wrong "starting group" of this I/O adapter chassis would cause the adapter to overlap the subsequent adapter's address space, or it would conflict with this being the last device in the "rack" address space.

 

[Ken Roach]

Also: "back in the day" when I routinely did PLC-5 work, my troubleshooting process would include connecting the adapter to PLC-5 controller on our workbench, download an empty program with an empty RIO scanlist, and use the "Auto Detect" feature on RIO to determine what the PLC-5 thought the 1771-ASB was configured to represent with rack/start/size info. If that didn't match the DIP switch settings we could focus on those.

Unfortunately, to my knowledge the 1756-DHRIO never implemented that feature for the RIO channel.

 

[jasil]

1. If I remove the other RIO networks (power them off) wouldn't that eliminate the overlap issue?

2. I powered off all of the other RIO devices, so they showed up as not communicating with the DHRIOE card.

NO change, swapped the card with 3 others no change, swapped the PSU no change, tried a new cable for giggles no change.

I'm about to change the rack because I'm stuck!

 

[Ken Roach]

I genuinely don't know if the 1771-ASB can tell if there's a poll that goes out to an overlapping subsequent Rack numbered adapter.

You could test that by installing a test program in the ControlLogix that scans *only* this one 1771-ASB.

But I tend to agree with your conclusion: this module has reached the end of its service life and has failed with an unusual mis-diagnostic.