POU Output Variables Touched When POU Doesn't Execute

We are moving from Allen-Bradley to Beckhoff and have discovered a construct that behaves in unexpected ways.

If we use the built-in MOVE block to the right of a FALSE N.O. contact, that MOVE is not executed, the output variable is untouched, and the ENO pin is FALSE. This works exactly as expected and is illustrated in Example 3 (attached).

However, if we wrap the MOVE within a FUNCTION or PROGRAM POU, the Output variable of the POU is disturbed even when the EN pin is FALSE. For a FUNCTION POU (Example 1) the output variable will be set to zero. For a PROGRAM POU (Example 2) the output variable will be set to the last output value when the EN pin was TRUE. Also, the ENO pin will be TRUE when the EN pin is FALSE.

We have situations were we want to run certain POUs conditionally, and only update the output variable(s) when THE EN pin is TRUE. The logic inside those POUs is more substantial than just a MOVE, but we use a MOVE to illustrate this issue.

As of right now our logic won't work properly because even when the EN pin is FALSE, output variables are modified.

We are looking at IEC 61131-3 but don't see where this situation is explicitly covered, but are still studying the reference we have (Heinz & Tiegelkamp), Springer.

Any thoughts on this?

When reviewing the examples be sure to note variable values in the data table above the code. The values shown alongside the variables in the LD seem to be truncated by TwinCAT.

Example 3 is the gold standard. If we could get either of the other two Examples to work the same way, then we would be back in business.

Your comments on this are appreciated!

Thank you!


View attachment POU_Output_Variables_Example_1.pdf

View attachment POU_Output_Variables_Example_2.pdf

View attachment POU_Output_Variables_Example_3.pdf

twincat is compatible with 61131, however you will need to stay within the scope:
move is a function so treated that return var is same as input.
you are using an integer as return that is incorrect.
another thing is using the same var as output double, that is bad practice there is even a check for it called multiple write access to an output.

another thing is the way ladder is working with function blocks, you will have to give every function block another name in the declaration.
The values you see on the screen are not updated every line (same as outputs which are done at every loop of the PLC, so the real value can be different. It is not fault, but as you are doubling and not within scope the values are not correct.

So untangle your program and stay with 61131.
It is lesson 7 not use an output double.
for this i use SELect to be sure i am seeing correct.

I could change all these examples to use INTegers exclusively, but the problem will still be evident.

Look at the definition of MOVE_FUNC: Input is moved to Output, both types are REAL. MOVE_FUNC is type INT, but the value of the function is not used. Note how it works correctly when the contact is TRUE. If your assertions were correct, that would not be the case.

I am showing two POU types: FUNCTION and PROGRAM. I am not showing FUNCTION BLOCK. No instantiation required or possible.

Every line uses a unique variable fOut1, fOut2, etc. At the end of the program scan the values shown in the data table above the LD will correctly indicate the final values.

All the rungs with the TRUE contact work correctly. Only Example 3 works correctly when the contact is FALSE. Compare all three examples side-by-side and you will see the issue better.

Again, look at the values shown in the data table, not those within the LD.

This is a very subtle issue that requires an exceptionally high experience level to understand. Thanks for trying. Your help is appreciated.

!!!Disclaimer: I don't know anything about twincat, but I've used CoDeSys a few times, just enough to be dangerous.

In CoDeSys (Wago v2.3) you don't define the EN bit, you might call a "Box with EN" when calling a function or function block.

In example 1, I think what is going on is that you are actually always calling these functions, sometimes with the input variable EN true, sometimes with it false. After the function runs it's logic it assigns its outputs variables, in your example 1 it appears to be using some un-initialized memory that happens to be 0 in each "instance" (have you run it with your "false"bit true, then switched it back false to see if it retains it's value, or keeps writing fOut2 after you manually change fOut2). CoDeSys 2.3 won't allow additional outputs in a Function so I'm having a little trouble duplicating your test, or really understanding how a function would work without assigning the main variable.

Example 2 is clearer to me, a Program is more like a Function Block in that it has it's own Data, you just can't have multiple instances of Data like a Function Block, so the first time you call the program, its internal data gets set then assigned to variable fOut1 back in your main program, you then call the same program without enabling the internal logic that changes the internal values, so the same value is assigned to fOut2, etc.

Notice in Example3 when you call the MOVE instruction the EN part inside the box is blue. I think the crux of the problem here is that your are somehow actually calling these functions and programs when you think that you aren't because you have disabled a user defined EN bit. I'm not sure how it works in Twincat and the CoDeSys version I have won't seem to allow me to compile most of the things you're trying.

Are there two different types of "box" instructions one with EN, and one without that you can pick when laying out rungs/calling functions?

I could be way off, good luck.

I can not reproduce your program, so please export it (to XML) and i will try to import it.
I remade a piece of your program:
see screenshots
as you can see a function needs a return value with same name as function is.
A function can have only ONE value returned, in V2.3 (Ladder)it could only be a BOOL, in V3 it can be anything. Do not misuse the EN and ENO as you did. so i made them other names.

If as you say try to use 61131 stick to the convention, misuse is possible as you did, however as you can see i can make a coil anything i like see rung 3 and 4
You are doing same.

Now for your real problem:
when you use the MOVE it will Move a var from one to another.
however the output of a function you made can be anything, because you move a Varinput to a internal variable in the function (normally it is zero or the result of the function) and use that to output.

Solution is to use VAR_IN_OUT that way it will keep the value it was.

Please use only one output per line in ladder (you may parallel an output however it is impossible to give it another value in ladder.(impossible to put contact in second line)
Use an output name only once.
Put one function or block per line.
Use correct returns in the functions.

Use the appropriate language for a task,
I hate the function MOVE, as it is not a MOVE but a copy, for this i use SELect. and yes i am aware Ladder is restricted and old habits stay very long.

This 61131 exists for long time so if something strange happens it will be for SURE your problem, not an error in the language.

please keep it simple.