PLC5-80E faults, loses program, related to ethernet

[Kent Hostetler]

Three times now I have had my PLC5-80E have a major fault with program loss while doing things with the connected ethernet network.

First time, in 2003, I don't think it was a coincidence that this happened at the same time I installed RSLinx and began to configure it. The ethernet LED was blinking code "7", which AB said means "overflow trap vector instruction" to Allen Bradley's internal technicians. No in fo beyond that - AB said replace PLC if it happens again (was in service 24 months).

Never had a problem until last two faults in the last month. Both happened while powering on or off a new CompactLogix processor in another panel.


Some info:

• Ethernet is run with fiber, with Hirschmann fiber hubs to convert to cat5
• 1st fault happened while configuring RsLinx on my laptop 6 years ago. Code was 7.
• 2nd and 3rd faults happened last month when I was powering down a control panel that's using a CompactLogic processor. Code both times were 69 (seems like a 69, or 6 and 9, or 9 and 6, or 96. Anyway, a 6 and nine were flashing as 6>short pause>9>longer pause>repeat. AB tech connect discussion - AB said there is no code 69.
• Not 100% sure if fault occurred while powing down or up the CompactLogix, but almost certain it occurs when powering down.
• Two messages exist b/w the PLCs
• Network between them is PLC5>cat5>into Hirschmann fiber hub cat5 port > out of another cat5 port on hub > Belden EthernetIP cable > CompactLogix ethernet port.

Any thoughts? What can cause a major fault in a PLC5-80E when a CompactLogix plc is powered down?...or when "something" happens with comms on the enet channel?

 

[Ken Roach]

Definitely pursue extracting a Fault Log out of the PLC-5 controller. This will tell A-B technical support more than the flashing LED will.

Does the CompactLogix perform any produced/consumed Tag exchange or Ethernet I/O on this network ? If so, have you installed and configured managed switches to constrain the multicast traffic ?

Does the CompactLogix send or receive any unscheduled Messages to or from the PLC-5E controller ?

 

[Kent Hostetler]

Does the CompactLogix perform any produced/consumed Tag exchange or Ethernet I/O on this network ? If so, have you installed and configured managed switches to constrain the multicast traffic ?

Does the CompactLogix send or receive any unscheduled Messages to or from the PLC-5E controller ?

The CompactLogix -L32E does not exchange produced/consumed tags or Ethernet I/O, but the following data is exchanged:

• MSG instruction initiated by CompactLogix, PLC5 Typed Read of the PLC5-80E, 10 elements, CompactLogix tag properties have them as a Base type tags, data type REAL, message scheduled every 3 seconds. (Should these be "consumed" type?)
• MSG instruction initiated by PLC5-80E, PLC5 Typed Read of the CompactLogix, 10 elements, CompactLogix tag properties have them as a Base type tags, data type REAL, message scheduled every 1 seconds or so. (Should these be "produced" type?)

No managed or unmanaged switch present. Both PLCs are connected to the same Hirschmann RH1-TP/FL rail hub. This rail hub is one of 8 on the network ring. The ring is fiber, each hub connects a PLC5 to the network via RJ45 jack. This hub also connects the HMI to the network, and connects the network to the corporate network via a Cisco managed switch.

Kent

 

[Eddie Willers]

At least the hubs will make it easy to see what sort of traffic might be getting placed on the network.

Old PLC-5E controllers would "throttle back" or take themselves off the Ethernet network when they detected high traffic volumes, but actual faults were rare.

I'd go after this two ways: get the PLC-5 memory dump utility and send the crash log to A-B tech support, and connect Wireshark to the hub and capture the traffic on this network segment when the CompactLogix is powered up or down.

There isn't anything about powering up or down a CompactLogix that would send out a message or traffic the PLC-5 can't handle.

 

[JesperMP]

This has been mentioned several times in older threads.
PLC5E CPUs can fault under circumstances involving "ethernet storms".

Ken, you mention Hirschmann "fiber hubs", and they are really hubs and not switches ? If that is the case, the PLC5E will see all the traffic that the CompactLogix generates. This can be the same as an "ethernet storm" to the PLC5E.

I think that in this thread is said that a later firmware than C/E should make the PLC5E CPU resistant to ethernet storms:
http://www.plctalk.com/qanda/showpost.php?p=309318&postcount=8
So, you can investigate what firmware version the PLC5-80E CPU is.

 

[Kent Hostetler]

What utility is used to extract the fault log? I have the "fault dump utility" from the AB site, but the online description says it's for Logix processors (I had to use it on a ControlLogix).

Kent

 

[Kent Hostetler]

PLC was running f/w revision E.2. I guess we forgot to upgrade this one.

Had my support guy install the comm chip and took it to K.3.

I will try to make it happen again since we took it to K3.