PLC5 bit fails to register

Jcooli09 · Apr 21, 2021

I am running a PLC5 and FactoryTalk 8.2 to control equipment at my facility. The HMI is a legacy system upgraded a couple of times which started out as a ControlView project well before I started with the company.

We have experienced a problem a couple of times where a 'System Stop' button shuts down some of the equipment, but leaves some of it running. The button is setup to set a bit to 1 when pressed, and set the bit to 0 when released.

What I've found is that when this happens the equipment that shuts down properly is controlled by XIC instructions, and the equipment that doesn't shut down is controlled by XIO instructions. That confused me.

I added a line at the top of the affected ladder which counts up when the bit goes high, and another that counts up when the bit goes low. I added a third line at the bottom of the ladder which also counts up when the bit goes low. I verified that the all three counters were reset to 0.

I pushed the button 300 times, and I found that the two counters at the top of the ladder (one for bit high, one for bit low) are equal, but the counter at the bottom of the ladder counting low bits counted 1 fewer changes of state. I tried another 700 times and it didn't happen again.

I don't really understand how this can happen, so I'm not sure how to correct it. My plan at this point is to change the button to a momentary button, and use it to latch a new bit which controls everything and gets unlatched when all the equipment is shut down.

Anyone have any thoughts they'd be willing to share?

Ken Moore · Apr 21, 2021

On older, slower processors, the behavior you observed was quite common. Latching a bit with the HMI and unlatching with the PLC was standard (best) practice.

I am guessing that the System Stop is not active long enough for the last counter to always see it. Perhaps on some frequency the scan time is slightly longer.

drbitboy · Apr 21, 2021

Jcooli09 said:
...

I don't really understand how this can happen, so I'm not sure how to correct it. My plan at this point is to change the button to a momentary button, and use it to latch a new bit which controls everything and gets unlatched when all the equipment is shut down.

Anyone have any thoughts they'd be willing to share?

Yes, that is the solution: the HMI writes the 1; the PLC is responsible for writing the 0 when everything is done. This is called Set&Forget (i.e. from the point of view of the HMI).

My theory is that the write of the 0 gets lost because E/IP (or whatever is used) increases reliability by sending duplicate commands, so it sends several packets telling the PLC to write a 1, then several telling it to write a 0. Since ethernet can have collisions and is non-deterministic, one of the "write a 1" packets gets there after all the "write a 0" packets, which leaves the bit in the 1 state. I know it sounds silly given the timings involved, but that theory does seem to fit the data.

Steve Bailey · Apr 21, 2021

My theory is that the write of the 0 gets lost because E/IP (or whatever is used) increases reliability by sending duplicate commands

I fail to see how that increases reliability. For a momentary button the important thing is that the HMI send the same number of 1s and 0s and that the last transaction be a zero. It seems to me that sending multiples only increases the chances that one of them will get missed. And what if the ladder logic program uses a one-shot triggered by the HMI signal?

Many years ago I tested a PanelMate HMI to see what happens when a momentary button object got touched. It wrote a 1 when I touched the button and wrote a 0 when I took my finger off the button.

drbitboy · Apr 21, 2021

Steve Bailey said:
I fail to see how that increases reliability. The important thing is that the HMI send the same number of 1s and 0s. It seems to me that sending multiples only increases the chances that one of them will get missed.

If it sends exactly the same (UDP?) packet several times for any one command and the recipient has some infrastructure to ignore duplicates, then it is more likely that that at least one command will be received.

drbitboy · Apr 21, 2021

Steve Bailey said:
Many years ago I tested a PanelMate HMI to see what happens when a momentary button object got touched. It wrote a 1 when I touched the button and wrote a 0 when I took my finger off the button.

How many times was that test run? OP saw 1 failure in 1000.

Corsair · Apr 21, 2021

Communications Update

Most PLC manufacturers don't specify where in the scan cycle communications hits the data table. I suspect that it is impossible to always do it between scans with most situations. My guess is that a written value goes to a register whenever it comes in without being buffered until between scans.

The correct way to do it is to copy the HMI bit to an internal image address one time at the top of the scan (early in the program). If that bit is on then kill the HMI bit on the next rung. The action is then done based on the image bit. It can only change at one place in the scan cycle.

The PLC class outline at CorsairHMI.com talks about asynchronous process data exchanges. In this case the two asynchronous processes are HMI communications and PLC scan. There are a lot more data exchanges like this in the PLC world. They require special care. Intermittent operation that appears to fail at rare random intervals is almost always an indication of an asynchronous process data exchange problem.

drbitboy · Apr 21, 2021

Corsair said:
The correct way to do it is to copy the HMI bit to an internal image address one time at the top of the scan (early in the program). If that bit is on then kill the HMI bit on the next rung. The action is then done based on the image bit. It can only change at one place in the scan cycle.

So you are saying summat like this,

Code:

  HMI_written_bit        local_bit
-------] [------------------( )------

    local_bit         HMI_written_bit
-------] [------------------(U)--------

or maybe even this,

Code:

  HMI_written_bit        local_bit
-------] [---------+--------( )------
                   |
                   |  HMI_written_bit
                   +--------(U)--------

but not this?

Code:

  HMI_written_bit       local_bit
--------] [----------------( )------

  HMI_written_bit    HMI_written_bit
--------] [----------------(U)--------

Steve Bailey · Apr 21, 2021

How many times was that test run? OP saw 1 failure in 1000.

I wasn't running the test to see how often it failed. I simply wanted to know how it worked. It was even a bit more involved than what I related. The protocol involved used addresses (I said it was many years ago) and the smallest unit of data it could pass was one byte. To write a 1 to a single bit the HMI had to first read the byte containing the bit from the PLC, then set the bit in the byte it read before writing the result back to the PLC. So for a momentary button there were a total of four transactions, two on touch of the button, first read the byte from the PLC, then write the modified byte back. Then two more transactions on the button release, read the byte, write the modified byte back.

OkiePC · Apr 21, 2021

Steve Bailey said:
I wasn't running the test to see how often it failed. I simply wanted to know how it worked. It was even a bit more involved than what I related. The protocol involved used addresses (I said it was many years ago) and the smallest unit of data it could pass was one byte. To write a 1 to a single bit the HMI had to first read the byte containing the bit from the PLC, then set the bit in the byte it read before writing the result back to the PLC. So for a momentary button there were a total of four transactions, two on touch of the button, first read the byte from the PLC, then write the modified byte back. Then two more transactions on the button release, read the byte, write the modified byte back.

The A/B DF1 protocol allows for a masked write where the driver (if using that feature) doesn't have to perform the read in advance just to diddle one bit within a word. This isn't really relevant to the heart of the issue though.

What the OP describes and the prescribed solutions are common. He may have pressed the button for 500ms, and the PLC scan time might be 28ms, but the actual time between the "write a 1" and "write a 0" might end up 17ms apart in real life, so the PLC might actually experience two changes of state of that bit within a single PLC scan.

ASF · Apr 21, 2021

A couple of threads on this sort of issue:
http://www.plctalk.net/qanda/showthread.php?t=108032
http://www.plctalk.net/qanda/showthread.php?t=100797

TL;DR, drbitboys's second example in post #8 is best practice for all HMI pushbuttons to avoid several different types of problems.

Bit_Bucket_07 · Apr 21, 2021

Corsair said:
Most PLC manufacturers don't specify where in the scan cycle communications hits the data table. I suspect that it is impossible to always do it between scans with most situations. My guess is that a written value goes to a register whenever it comes in without being buffered until between scans.

That's definitely the case with the PLC-5. Reads and writes to the HMI may update in the middle of solving the program sweep.

Corsair said:
The correct way to do it is to copy the HMI bit to an internal image address one time at the top of the scan (early in the program). If that bit is on then kill the HMI bit on the next rung. The action is then done based on the image bit. It can only change at one place in the scan cycle.

I've done that on the word level for HMI reads, to make sure that a numerical value that can be changed by the program during the sweep will only display it's end of sweep value on the HMI.

One option for the pushbutton writes from the HMI is to clear the entire buffer unconditionally at the end of the sweep, rather than using individual bit resets, although that requires intentionally assigning pushbutton bits within an array.

Corsair said:
The PLC class outline at CorsairHMI.com talks about asynchronous process data exchanges. In this case the two asynchronous processes are HMI communications and PLC scan. There are a lot more data exchanges like this in the PLC world. They require special care. Intermittent operation that appears to fail at rare random intervals is almost always an indication of an asynchronous process data exchange problem.

I've seen the stuck pushbutton syndrome most often where network traffic is high relative to the inherent speed of the network, I've also seen it aggravated by operators who want to "make sure" the darn button works by clicking it 10 times instead of one, as fast as their mouse button can click.

Corsair · Apr 21, 2021

drbitboy's first two examples are excellent. The problem with the third is with the extremely rare case where the HMI comms hits between the two rungs.

The issue of whether the HMI can do masked bit writes or if it has to do read-modify-write needs to be taken into account. If it has to do read-modify-write then it is especially important to not use other bits in that word for other purposes like internal control relays. The extreme safest bet for HMI RMW is to only put one HMI tag in each register. That wastes a lot of bits. Better PLC register protocols use AND-OR masked writes.

As I said before, watch out for the ControlLogix PLC/SLC emulation protocol (PCCC) on this one. I don't think it supports masked bit writes unless things have changed with newer firmware.

PLC5 bit fails to register

Jcooli09

Member

Ken Moore

Lifetime Supporting Member

drbitboy

Lifetime Supporting Member

Steve Bailey

Lifetime Supporting Member + Moderator

drbitboy

Lifetime Supporting Member

drbitboy

Lifetime Supporting Member

Corsair

Lifetime Supporting Member

drbitboy

Lifetime Supporting Member

Steve Bailey

Lifetime Supporting Member + Moderator

OkiePC

Lifetime Supporting Member

ASF

Lifetime Supporting Member

Bit_Bucket_07

Member

Corsair

Lifetime Supporting Member

Similar Topics