Sticky buttons Panelview 600 & Wonder Ware

Hello again. For years we have been using WonderWare for our HMI
interfaces. Starting about a year ago we started experiencing the
sticky button issue. Where a momentary WW screen button is pressed
a 1 is written to the plc data table in the plc. When the button is released the 0
never makes it. Unlatch outputs had to be placed in the programs to release the bits when the expected action had completed. Now We are seeing
this issue on a totally different system that uses Panelview 600's.
Anyone have some insights into this?

Dude, the button has been pushed to many time in the same spot, move it to another area on the screen.

I have experienced "sticky button" malfunctions in a number of HMI platforms. I've only ever confirmed a real bug in early PanelView Plus drivers (v4 and earlier), which would sometimes never attempt to send the "0".

In other systems, we chalked it up to high HMI traffic or error-laden network links.

That's one reason I really liked the old PanelView Standard I/O connection over EtherNet/IP, because it was a true cyclic I/O connection. Red Lion has that in their EtherNet/IP slave driver too, and the PV5000 has a modern incarnation of it as well.

In practice, I use momentary buttons the way they are designed, and only implement button timeouts or one-shots in logic if I experience malfunctions.

I was at a remote customer site last year where I had implemented one-shots in logic, and watched the operator press a particular button five times quickly every time she needed the machine function. I asked why (and had to rely on a translator): "oh, that's just necessary". They'd decided that this machine just needed a lot of button presses, instead of investigating the network or software.

When I opened the HMI transaction log, I found a large number of "Tag unavailable errors" and discovered that a few years ago, my former boss had deleted a set of what he thought were unused tags in the PLC. He missed the fact that they were still in a background data log, so the HMI drivers would occasionally reset/re-optimize, and that sometimes coincided with the button presses.

I forgot to mention theses Panelviews are on Controlnet and there is an occasional error
message that pops up. and it says: 634 Read Timeout, Node = 1

That's an important factor; thank you for the update !

Error code 634 suggests that these are PanelView Standard terminals, not PanelView Plus. And it indicates a Write error, which is consistent with the "stuck button" phenomenon, because the terminal has failed to send a "0" to the controller.

To investigate this, it makes sense to examine the ControlNet network media conditions by looking at the network status counters for each node, and to examine the CPU usage and buffer utilization on whatever controller these terminals are talking to.

The PanelView is very likely showing you symptoms of a network problem, not symptoms of a firmware or touchscreen problem.

It's unusual to see the "sticky button" issue in an application with a single PLC and a single HMI, but as a process network expands, it becomes almost inevitable for the problem to show up from time to time. I know many programmers who unconditionally reset momentary pushbutton bits in the PLC as part of their standard motor logic. I've also attacked the problem by placing a small indicator light on pushbuttons, so the operator can see when the bit is on. Simply clicking the button again will clear it up.

Ken, I too have encountered operators who think that clicking a button 10 times is much better than simply clicking it once. It's difficult to talk some of them out of that habit.

Ken, I too have encountered operators who think that clicking a button 10 times is much better than simply clicking it once. It's difficult to talk some of them out of that habit

Click to expand...

It's the same mindset that says pressing the elevator call button many times, harder each time, makes the elevator arrive at your floor faster.

In their defense, these operators had learned the habit because the network was flaky.

The flaky network led to us implementing timed-out unlatching logic for the pushbutton objects that were unreliable.

Because the operators could easily adopt "push a bunch of times" but the HMI communication drivers were written to "send 0 just once, even if there's an error", hammering the button became the habit.

In the system I'm thinking of, I joined the team four years after the machine was built. And it's in a site that it wouldn't take much for me to believe in wartime ghosts or gremlin infestations. We had to suspend an installation for a week once when they dug up an unexploded bomb under the parking lot.

I am an extremely good communications and automation troubleshooter, and even I couldn't sort out all the problems on that machine.

Thanks for the feedback!