Booleans getting "stuck" on?

[BE 13]

Hi All,

Bit of a weird one. I wrote a program several years ago (was the first PLC code I wrote, so it is kinda all over the place) that runs a nut sorting facility. There is 1 NX102 PLC, with 3x NA5 HMI's.

In a nutshell (pun intended), each process has a screen with Start, Pause & Process Complete buttons. Each of these buttons are momentary & trigger a bool in the PLC to perform the relevant function. I have a situation where on some of the touch screens the bool gets 'stuck' in a true state, even when the button is released. Initially, this created a problem, as the operators couldn't 'restart' the process if the pause button was stuck etc.

I have made a work around by just putting some code in to reset the relevant bits if they stay 'true' for more than 5 seconds. I also put counters in the code to see how often this behaviour occurs. These counters indicate that it happens rarely, once a day (on average) at the absolute most.

This isn't really an issue, as the reset code is working fine, but I just wanted to post something to see if anyone else had ever seen similar behaviour, and if so, did you ever work out what caused it? I suspect either interference or packet drops in the network connections between the PLC and HMI's, however cause it happens so rarely and randomly, it isn't something I have spent much time on. I also don't have physical access to the site easily.

Any thoughts or ideas would be great, but as I said, it isn't a problem I 'have to' fix, as the workaround code is handing the problem fine. Its more of a curiosity thing to be honest 

[IO_Rack 181]

10 hours ago, BE said:

In a nutshell (pun intended)

We had this issue years ago. I would have to think it's an issue with the NA5. At the time I put an unlatch instruction for all the push buttons after triggering a one shot. This won't work for any momentary actions you require obviously. It may have been an issue with an earlier firmware because I haven't seen the problem in quite a while.

I also remember this being a known issue in an earlier version of Wonderware Intouch. 

[pturmel 157]

This is a fundamental and unavoidable consequence of the use of query-response protocols, particularly over TCP/IP.  While not terribly common, I have seen this in every HMI technology (all brands) I've used in my 35 years of experience.  The only exception is when a device is using a true I/O protocol that repeatedly sends data buffers, such that any missed packet is quickly succeeded by a fresh one.

Some recommended, in-depth discussion of these phenomena:

https://forum.inductiveautomation.com/t/momentary-pushbutton-latching-on/5373

This related topic features a poor guy in utter denial:

https://forum.inductiveautomation.com/t/very-concerning-read-write-issues-important-information-for-all-users/18583

 

[BobLfoot 301]

4 hours ago, pturmel said:

This related topic features a poor guy in utter denial:

https://forum.inductiveautomation.com/t/very-concerning-read-write-issues-important-information-for-all-users/18583

 

Not just The Nile @pturmel  he's bought all of Egypt and Ethiopia.  LOL

[panic mode 246]

it is scary to think how many things out there are created by someone not understanding process or architecture of system they worked on. 

[BE 13]

Thanks everyone. Good to know that its not just me .

 

Will check out the links @pturmel posted later on when I have a bit of spare time. Thanks for the feedback

[BE 13]

So, having had a look at the links, and reviewed the button options in Sysmac Studio, I thought I might ask the opinion of those with far more experience than I about possible best practise.

As mentioned previously and in the links, the momentary buttons getting "stuck" occasionally is an unavoidable issue due to the communications protocols. Reset logic has been suggested to 'fix' the problem, but if the momentary buttons need reset logic, would it just be better practise be to use the "Set Button" in Sysmac Studio, and then code the PLC to reset the relevant bit once the PLC has done what it needs to do? Obviously this would not work for buttons used for jogging or similar, but the reality is that if the operation of those buttons is critical (ie. they MUST stop when released), they should be hardwired to physical I/O anyway.

Again, just chasing peoples thoughts or opinions. My own experience in PLC's is miniscule compared to many others on this forum 

[pturmel 157]

On an HMI with a naive PLC driver, set-from-HMI reset-in-PLC can be a reasonable approach.  The HMI operation does need to be "fire-and-forget".  I've found that using an 8-bit integer as a trigger (w/ change detection in the PLC) is even more reliable, as there's no "reset" at all.  It also plays nicer with non-naive OPC or SCADA drivers.  Such drivers tend to have race conditions if variables are commonly/quickly written from two directions.

For HMIs with scripting, the incrementing trigger can reliably mimic a momentary by scripting the increment repeatedly, quickly, while the button is pressed.  The PLC would then use a TOF with the change detection with a duration about 1.5x the increment pace.  Any breakage in comms or HMI and incrementing stops.

[BE 13]

Ahh. Well that might give me some motivation to learn the Visual Basic side of the Omron NA series HMI's, to have a play with that and further my skill set. 

I had thought that using a "Set Variable" event for when a button is pressed might work (based on a free running integer from the PLC), but as it turns out, the 'Set Variable' is only a one-shot, based on the quick simulation I did .

[panic mode 246]

you can have bunch of HMI buttons, each setting different bit in some memory area. at the end of PLC scan you can let PLC reset the entire area. for the rest of your PLC code, each of the bits will be seen as one shot. that will work rather nicely for plenty of cases and it is very efficient (no timers, very simple logic, no way to stay stuck etc.). if for some reason write message was missed, user would see no response and simply repeat pressing the same button. 

but while simple, this does not work in all cases. an example is where you want to use button to jog axis (and releasing button is suppose to stop the jog). in that case one can resort to some alternative to make it robust. one simple way to get around this is to have HMI cyclically write entire block of memory. this way even if one message is missed and thus desired change is not seen by PLC, the very next message will overwrite the entire block and correct the situation. this is pretty much of how fieldbus data transfer works so all received signals seem to be continuous and instantaneous. this is also quick to implement when one is making custom HMI (a PC application using own driver or implementing just two functions of some SDK - read one memory block and write another...).

but this is not how most HMIs work since it is limiting (all write requests need to be in one block). but typical controller may have many different memory areas (timer, counters, inputs, outputs, memory bits, data registers, retentive memory locations etc) they would normally send commands as individual writes to each individual location. so number, size and type of write messages would always differ.

therefore one may dig into the bag of tricks and do something fancy depending on particular platform capabilities.

and as you have already stated - if something is really critical, it should be handled as such and use more reliable solution. for example robots are making use of enabling switch (a safety device) allowing user to stop any motion command even if jog button was to fail.