View Single Post
Old February 12th, 2018, 01:03 PM   #8
Tpetie3509
Member
United States

Tpetie3509 is offline
 
Join Date: Apr 2017
Location: Washington
Posts: 23
Quote:
Originally Posted by OkiePC View Post
All the data in all Allen Bradley PLCs is retentive. Nothing will be lost.

For comms checking...normally, the first element of my MSG is a "Heartbeat". It is just a number that increments or a copy of the free running clock...think of it as a random number. In each slave, I will watch for this value to change.

If it doesn't change for 1 to 10 minutes (depends on situation) I will set an alarm and take appropriate action. In the master PLC I will receive a heartbeat for each slave, so that if it doesn't change, I know that PLC is not running or not communicating. So in the main PLC I will have a comms timeout alarm rung for each slave RTU. I will map those timer accumulators to tags for each slave called "data age" or something to that effect. In the HMI tooltip, where available, I will explain it as the number of seconds since the last successful read took place.

Note that a PLC can communicate just fine when it is simply faulted, so using a heartbeat rather than just relying on MSG error bits proves that not only is the RTU communicating, but it is in RUN mode.
I fully understand this portion and thank you for that. I'm not sure I understand some of the control you have set up for your messaging.

I have mine set up so that it increments to the next message with the previous done or error bit. I can also see how adding an "enable/disable bit to each station would be beneficial.

What is the purpose of the FLL instruction if you are using a message instruction anyways?

Also, is the poll time timer just a timer that starts with the message.en bit and stops with the message.dn bit, then reporting that time back before resetting during the next poll?

Thanks,

Todd
  Reply With Quote