Hi!

I've encountered an unexplainable issue where I move any value to a static integer in an FB, the ENO goes false

Take a look at the attached image.

On the left is the default "idle" state. On the right the "C.acknowledge" bit is triggered, causing the two second off-delay timer to move a value to the acknowledgement integer "#ACK" (which will be seen by WinCC to acknowledge alarms on the object). After two seconds, the logic returns and moves 0 to the INT.

The issue only happens if I include the last MOVE block to reset the integer back to 0 whenever the timer resets. If I don't, the value can be moved to the integer with ENO still true, but the value won't of course go back to 0.

I've resolved this by adding a "--| |----(SAVE)" at the end that is always true, but I'm just wondering what is going on here?

Piotr.M

what is in FB53?

check for ---(SAVE) instructions - last (SAVE) drives ENO bit

NOTE: SAVE is used  by LAD when system translates to STL

best to look in FB53 in STL view and check for last usage of SAVE.

FB53 doesn't have any SAVE instructions originally.

I've added a printout PDF of FB53, the (SAVE) function at the end was added after I noticed the issue, and it resolved it. The MOVE instruction that causes the issue is in Network 15.

I'm just wondering what might cause the ENO to go low, I've never encountered this before.