K_Ohjus

Still no need for any triggers. Use click event of a button to set bit and reset after on PLC.

Did I miss something? 
Did @rfriedman say he is using a button on an HMI?

K_Ohjus

 

I probably missed something.

I thought that @rfriedman is going to use push buttons on HMI and still positive edge triggers on PLC.

I base this of comments about operator feel, so most likely a button on HMI. So I only commented that there is no need for triggers on PLC, whether the action is on positive - or negative edge.

Your recommendation for not using a positive/negative edge when using a button on an HMI is a sound one. It is also a good suggestion to use the Set Bit function and have the PLC reset the bit tag.

Though I am not sure why you suggest the "click event" of the HMI button, unless that was not meant literally. Or perhaps it is a suggestion to suit a mouse operated WinCC session. I use the "release key" event on the Basic Panels.
 

My point?.. For my own education: Which situation is "click event" best used for? Is this event on the release of the mouse button / touch?

K_Ohjus

I was wrong about click event. It is actually on negative edge. So that would not work.

But with press event or even with setWhileKeyPressed would.

I do not trust the "setWhileKeyPressed" event. Ironically it is something I used regularly on the OP5 / OP7 / OP3. I have found by experimentation^** that it is a compound event: pressKey (rising edge) and releaseKey (falling edge) combined.

Assume setWhileKeyPressed controls a PLC tag.
When the user presses the button down the bit is set, as expected.
The bit tag remains on however when..
(a) the screen page changes (by PLC command), or
(b) the communication is lost, or
(c) HMI download is invoked.

** = This leaves margin of error

Your findings mirror my own from over a decade ago with MP177's.

I ended up changing all buttons and screens to:

Push Event, typical buttons: DO NOTHING
Release Event: typical buttons: in PLC logic, IF HMI_BUTTON_PRESSED, [TAKE ACTION], RESET HMI_BUTTON_PRESSED

All screens configured to reset all buttons to OFF when leaving screens. 

Each "HMI screen" / button handler has IF "First Scan" OR "HMI JUST WENT OFFLINE" handling that resets HMI buttons. Handles possibly previously SET HMI buttons should one of the above mentioned edge cases happens.

I tried adding it to local HMI scripts that run when the HMI detects "HMI JUST CAME ONLINE" - which happens ~2-3 seconds after the HMI is actually online and the "HMI JUST CAME ONLINE" is still FALSE.

It makes for some mandatory PLC Network and Block comments to explain why the short delay establishing that status bit.  After well over a decade of using it, it's hidden a few FBs deep in PLC old legacy logic that we consider "just works", so nobody bothers looking at it.

If I forget about it - after not working on an HMI project for > 1 year, during commissioning testing where I perform those 3 edge case tests on each new screen / button / object - change screens restart PLC with button pressed, download while button pressed, I quickly remember the pattern requirements, go copy an existing button, move over the visible attributes, etc. and always works fine for the rest of that HMI project with my freshly renewed memory... 

qwazee

K_Ohjus

I was wrong about click event. It is actually on negative edge. So that would not work.

But with press event or even with setWhileKeyPressed would.

I do not trust the "setWhileKeyPressed" event. Ironically it is something I used regularly on the OP5 / OP7 / OP3. I have found by experimentation^** that it is a compound event: pressKey (rising edge) and releaseKey (falling edge) combined.

Assume setWhileKeyPressed controls a PLC tag.
When the user presses the button down the bit is set, as expected.
The bit tag remains on however when..
(a) the screen page changes (by PLC command), or
(b) the communication is lost, or
(c) HMI download is invoked.

** = This leaves margin of error