PLC Fault Caused by 1769 Module

[Bullzi]

Hello Everyone,
I have a customer location that has a 1769-L33ER Processor. There are 2 remote RIO cabinets that use Point I/O Ethernet adapters and 1 that RIO that uses the 1769-ANETR.

Today I got a call that the PLC was down. I got into the network and found the PLC was faulted. The Fault was caused by the processor was not able to communicate to the Slot 1 module (1769-IF4) in the 1769-ANETR RIO. I cleared the fault and everything went on like normal.

That got me wondering about what could have caused that fault. What is the methodology a processor uses to determines a fault like this? Is there a certain number of retires? Certain amount of time that it will wait for a response? Does the RPI have any affect on that? Could I have the RPI set too tight? I have them set to the standard times that come up when you add the module. Given the RIO racks are on fiber 1000' from the processor maybe the communications delay is causing some issues? Any thoughts on this?

If you have any idea I would love to hear them. Thanks to everyone!!

 

[mort81]

Yes RPI could be the cause depending on other devices on that same network. I've seen large drive networks where the only way to setup the RPI's was to use prime numbers for the rates and "phase" the communications.

 

[James Mcquade]

first off, what is RPI?

secondly, this is for powering up.
every now and then a module tahes longer to power up than is should. thus the plc processor cannot see the module. this has been occuring fo 20+ years. what i do is to set the fault over ride at power up status bit. this gives the modules some more time to boot before the cpu faults.

regards,
james

 

[mort81]

Requested Packet Interval

You can find out about it in the help files for the module's you are working with. Here is a link to a remote I/O card:

http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1756-um534_-en-p.pdf

Page 27 - 29 should give you a general idea for how RPI works.

 

[jdbrandt]

Hello Everyone,
I have a customer location that has a 1769-L33ER Processor. There are 2 remote RIO cabinets that use Point I/O Ethernet adapters and 1 that RIO that uses the 1769-ANETR.

Today I got a call that the PLC was down. I got into the network and found the PLC was faulted. The Fault was caused by the processor was not able to communicate to the Slot 1 module (1769-IF4) in the 1769-ANETR RIO. I cleared the fault and everything went on like normal.

That got me wondering about what could have caused that fault. What is the methodology a processor uses to determines a fault like this? Is there a certain number of retires? Certain amount of time that it will wait for a response? Does the RPI have any affect on that? Could I have the RPI set too tight? I have them set to the standard times that come up when you add the module. Given the RIO racks are on fiber 1000' from the processor maybe the communications delay is causing some issues? Any thoughts on this?

If you have any idea I would love to hear them. Thanks to everyone!!

You didn't mention the firmware level, and that is a really big deal with a 1769-L33ER.
Having gone through some difficulties with this product recently, I would encourage you to read ALL THE WAY THROUGH, the Release Notes on this product...it will shed light on this issue.
I do not have the document number, but the title is:
Release Notes
CompactLogix 5370 L3 Controller, 2Mb Memory, w/Supercap Backup, up to 16 1769 I/O expansion modules, 32 EtherNet/IP and 120 TCP Version 20.011 - 21.011
Catalog Number 1769-L33ER (series A)

 

[Bullzi]

The Rev. level is 21.011.