Siemens S7/TIA v18: Trying to increment a tag by 1 when a button's pressed...

[JesperMP]

By the way, my experience with HMIs writing both the 1 on the button press as well as the 0 on the button release is that it is far less reliable. I don't know why, it almost seems as if sometimes the write of the 1 on the press gets lost, then the write of the 0 on the release gets sent (which changes nothing because the 1 was lost), and then the HMI notices that the 1 packet was not acknowledged so it sends it again, and if that second 1 is not lost then the bit value is left as a 1 even though the button has been released. Set and forget is more reliable: at least if the 1 packet is lost the user has only to press the button again and nothing gets out of sequence.

Also my experience, learned the hard way.

 

[parky]

lol, haven't we all been there

 

[drbitboy]

On second thought, I wonder if the explanation is simpler, e.g. instead of @JesperMP's

IF bit_from_hmi THEN
     /* do summat */

     bit_from_hmi := FALSE;

END_IF;

what if I did the ladder equivalent of this:

IF bit_from_hmi THEN
    /* do summat */
END_IF;

bit_from_hmi := FALSE;

thinking it would not matter where the reset to a value of 0 occurs?

Assuming that any communication task might be asynchronous and higher priority than the continuous program scan task, consider the following scenario:

1. The value of bit_from_hmi is 0 when the IF bit_from_hmi THEN statement is evaluated,
2. So execution jumps to the END_IF statement,
3. Then, before executing the next statement, an HMI communication task fires in response to an HMI button press, interrupting the program scan and writing a 1 to bit_from_hmi,
4. After that interrupt returns control to the program scan, the next statement immediately overwrites bits_from_hmi's value of 1 with a 0,
5. So on this and all following scan cycles, the PLC never sees the button press.

 

[plvlce]

On second thought, I wonder if the explanation is simpler...

I would expect this scenario to be possible. In a long program the chance of the value being updated at that exact spot in the program is very small, but as we all know that just means it will wait until a critically important moment to happen instead of showing up in testing.

It is for this exact reason when programming HMI buttons I generally OTU them on the same rung I check them. If I need to use the button press in multiple locations in the program I have it trigger a separate bit and use that instead.

 

[JesperMP]

Nit-picking here. Yes there can be some situations that can make a difference if you write the reset explicitly or not.
Some HMIs writes to the PLC memory while the PLC runs its program scan.
That means that it can write the set bit just between END_IF and the bit_from_hmi := FALSE.
Then the counter wont increase. It will be very rare, but can happen.
What speaks for an explicit reset of the HMI bit, is that if the do_something bit is somewhat complex, there could be a program issue that causes the end of the IF to be never executed.

So, if it is more important that the hmi bit doesnt 'hang', then place the reset outside the IF THEN.
If it is more important that the no of button presses matches the no of actions taken, then place the reset inside the IF THEN.

 

[tvey]

One technique I've used in the past to minimize 'clean up' is to maintain a single array of '_hmi_request' bits in the PLC.

On the last scan of the PLC program, just XOR the whole _hmi_request array with itself to clear all bits in the array.

In a synchronous scan environment, this guarantees you one full scan to check and action any requests before the request bit is cleared.

-Trevor

 

[Shellmer]

^ this.
By the way, my experience with HMIs writing both the 1 on the button press as well as the 0 on the button release is that it is far less reliable. I don't know why, it almost seems as if sometimes the write of the 1 on the press gets lost, then the write of the 0 on the release gets sent (which changes nothing because the 1 was lost), and then the HMI notices that the 1 packet was not acknowledged so it sends it again, and if that second 1 is not lost then the bit value is left as a 1 even though the button has been released. Set and forget is more reliable: at least if the 1 packet is lost the user has only to press the button again and nothing gets out of sequence.

One big problem with the "Set bit while key pressed" on siemens hmi is that if the operator closes/switch to another screen while still maintaining the button pressed, sometimes the bit will continue set.

I've found this issue on various ocassions and had to reset the bit myself again through the plc program.

So best solution is to reset the bit after the operation is processed in PLC side, this will also work even using the "Set bit while key pressed".

Siemens have some tricky "bugs" like this, something that I also suggest to everyone while working with siemens HMI is to force a full compilation of the HMI screens before loading them again... it has happened various times that icons, faceplates, buttons or any other element can dissapear completelly from the screen or not work correctly if not done that way.
It seems when compiling only the changes it just "forgets" some elements... last time it happened I had to return to the factory to load the screen again because the reference change button from the machine just dissapeared... forcing a full compilation and loading the screen again solved the issue, so I got used to do this and I had not more surprises since then.

 

[I_Automation]

I have encountered situations where a HMI momentary PB got stuck ON and never released, even pressing it again doesn't release it.



For all of my HMI PB's I use momentary buttons AND in the PLC have an OTU after the XIC and OSR for each just as plvice does above.


If the HMI PB output is going to be used in more than one rung of the program I have the OSR part trigger a OTE that will only be on the one scan and that bit will be on until the next scan of that OSR.