E300 and PF525 lost ethernet connection device tag data frozen at last state

[p8p8]

When E300 powered off, the ethernet device tag data stayed at last know state, for example, fault bit is still Off, ready bit is still ON, status bit is still On.
We have many E300 , only some of them act this way.
Some PF drive also act this way.
The good E300 fault bit will be ON , Ready bit will be OFF.
Has anybody seen the same issues before? What could be the the cause? How to fix it?
Thanks

 

[Ken Roach]

That is normal behavior for A-B networked devices, so that you can tell what the last I/O state was before the connection failure.

Some devices have built-in communication failure tags (like POINT I/O for the Rack Optimized connection), but it's an ordinary practice to use Get System Variable (GSV) instructions, or even an I/O fault recovery routine, to monitor and trap connection failures.

There is a useful "Information and Status Programming Manual" for module and network status features:

https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm015_-en-p.pdf

 

[Ken Roach]

>only some of them act this way.

They all act the same. The difference is the state that the motor was in when the communications connection was broken.

 

[JeremyM]

^ that.

I’m wondering if there’s value in zeroing the IO data on a connection loss for lack of certainty in the actual state of the endpoint device.

 

[Ken Roach]

In the DCS world, the quality of the signal is always built into the I/O subsystem and accounted for in the process control logic.

But even a sophisticated PLC like the Logix family just has an Input data tag that gets produced cyclically by the IO device. If you've got a device where all zeroes is a normal and valid condition, then you can't use all-zeroes as the fault state.

I would prefer that every I/O connection had a Status tag object, but they don't.

Produced/Consumed Tags got that added as an option years ago, and you can check the Slot_Status bit array <> -1 for POINT or FLEX easily, but for other things you have to roll your own.

When I'm feeling fancy I use the "Fault if connection fails at runtime" and use the Fault routine as an interrupt to gather exact timestamps, and feed the last condition of the device feedback into an alarm or event object so I know the context of the connection failure.

 

[p8p8]

In the DCS world, the quality of the signal is always built into the I/O subsystem and accounted for in the process control logic.

But even a sophisticated PLC like the Logix family just has an Input data tag that gets produced cyclically by the IO device. If you've got a device where all zeroes is a normal and valid condition, then you can't use all-zeroes as the fault state.

I would prefer that every I/O connection had a Status tag object, but they don't.

Produced/Consumed Tags got that added as an option years ago, and you can check the Slot_Status bit array <> -1 for POINT or FLEX easily, but for other things you have to roll your own.

When I'm feeling fancy I use the "Fault if connection fails at runtime" and use the Fault routine as an interrupt to gather exact timestamps, and feed the last condition of the device feedback into an alarm or event object so I know the context of the connection failure.

I was actually going to this "E300:I.Fault" tag; I noticed all bits of this tag would be "1"s if E300 powered off.
so if "E300:I.Fault" is not zero, the status feedback should be off. Before I do that, wanted to ask you guys to see if there is better way to do it.

 

[p8p8]

That is normal behavior for A-B networked devices, so that you can tell what the last I/O state was before the connection failure.

Some devices have built-in communication failure tags (like POINT I/O for the Rack Optimized connection), but it's an ordinary practice to use Get System Variable (GSV) instructions, or even an I/O fault recovery routine, to monitor and trap connection failures.

There is a useful "Information and Status Programming Manual" for module and network status features:

https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm015_-en-p.pdf

Thank you very much for reply.
I was wondering using E300/E1 Plus/E3 AOI, it that would solve this issue?
Or I should use this ethernet device tag "E300:I.Fault", it does show status changes if lose communication or powered off.

 

[p8p8]

In the DCS world, the quality of the signal is always built into the I/O subsystem and accounted for in the process control logic.

But even a sophisticated PLC like the Logix family just has an Input data tag that gets produced cyclically by the IO device. If you've got a device where all zeroes is a normal and valid condition, then you can't use all-zeroes as the fault state.

I would prefer that every I/O connection had a Status tag object, but they don't.

Produced/Consumed Tags got that added as an option years ago, and you can check the Slot_Status bit array <> -1 for POINT or FLEX easily, but for other things you have to roll your own.

When I'm feeling fancy I use the "Fault if connection fails at runtime" and use the Fault routine as an interrupt to gather exact timestamps, and feed the last condition of the device feedback into an alarm or event object so I know the context of the connection failure.

Other instrument such flow meter has communication fault tag, BOOL data type.
The E300:I.Fault tag is a DINT tag, I have no idea what each bit represents.
When the E300 is powered off, all bit is "1".

 

[JeremyM]

That ConnectionFault DINT is 0x00000000 normally and 0xFFFFFFFF when the connection is lost. Stratix switches have it as well.