Is Codesys broken wrt the Left-to-Right, Top-to-Bottom convention for Ladder in some cases?

[drbitboy]

Finded also this. Can it make differences?
"CODESYS connects the highest output with the highest input of the neighboring function blocks."

https://help.codesys.com/api-content/2/codesys/3.5.12.0/en/_cds_pragma_attribute_dataflow/

That is interesting, but its context seems to apply to user-defined function blocks in FBD.

What this thread is focused on is which branch, after a branch/rung split in LD, is executed first.

 

[Lare]

Not sure, but why user defined FB would differ from inbuild blocks (FC, FB and other blocks)?

 

[drbitboy]

Not sure, but why user defined FB would differ from inbuild blocks (FC, FB and other blocks)?

I could be wrong, but I suspect that users cannot add pragmas, such as that {attribute 'dataflow'} statement, to built-in blocks.

 

[dwoodlock]

See the Codesys LD program below; I would expect Rungs 2 and 3 to produce functionally identical results, but they do not.

Does anyone have any comments on this? Or perhaps it has been covered in another post?

After much delay.....

I tested this today and this is what I got, which is what I would have expected.

Using RPI zero W and codesys for RPI SL

 

[dwoodlock]

I edited so that its setup the same way as Dr.Bitboy's was, and the result is the same for both networks.

 

[drbitboy]

I edited so that its setup the same way as Dr.Bitboy's was, and the result is the same for both networks.

Thank you.

So the behavior is manufacturer/hardware dependent?

That's just peachy.

 

[dwoodlock]

Are you using simulation? Or a piece of hardware?

Result shouldn’t differ, just curious.

 

[drbitboy]

Are you using simulation? Or a piece of hardware?

Result shouldn’t differ, just curious.

simulation.

 

[dwoodlock]

I changed mine to simulation as well for science, and again I get the same result.

 

[drbitboy]

I changed mine to simulation as well for science, and again I get the same result.

Wow. what OS?

I'll have to go back and re-check mine.

 

[dwoodlock]

Windows 11x64

 

[AlfredoQuintero]

Brian, dwoodlock, I am curious, did you use Ladder Diagram or Ladder Logic Diagram for this Program Organization Unit?
There are differences between them, and I have not had the time to look into the differences. It seems dwoodlock and Brian are not using the same kind of POU.

 

[chelton]

Alfredo I see the same results as @dwoodlock and layout looks identical. Both appear to be LD as LD2 has EN/ENO input/output when you add a block. However, i can't position my blocks how @drbitboy has shown in his example.

 

[dwoodlock]

@AlfredoQuintero I actually tried it both ways and got the same result.

I initially started using standard ladder, and then changed to ladder diagram. Ladder diagram messes up the layout. I have seen this in older versions of Codesys too where a move instruction isn’t automatically moved to the right side of the ring, but remains in the middle.

It appears @drbitboy used ladder diagram.

side note the ladder diagram just looks like ladder in TIA to me, and takes up more space which is aggravating on a laptop. I found that I could right click on the program in my project tree and convert it to “new ladder”.

 

[parky]

I do not know that platform, however, in Mitsubishi the use of FBD/LAD versus LAD only the code is different, the reason is to make FBD compatible with the Ladder, (backward compatible with earlier IDE's & plc models), for example:
In FBD using the ENO to link it to another function i.e. two functions in series looks ok in FBD but if raw code is uploaded to the ladder editor it comes back like this:
In FBD A M0 A M1 [MOVE D2,D3] [MOV D4, D5]
In Ladder
A M0 A M1 OUT M8091
A M8091 [MOVE D2, D3]
A M8091 [MOVE D4,D5]
The reason in the old convention is that after an out or move instruction it must be tied to the "common" rail
So in many IDE's you cannot have out coils or certain functions in series (only in parallel what the compiler does is creat a temporary variable that is used as two ladder blocks
maybe it is something like this is happening. I know that the order of operation is correct in Mitsubishi but perhaps there is a bug in the compiler that for some reason it swaps the order. not the same as I would have expected i.e. using temps as I have seen in certain layouts of FBD but gives you an idea As you can see in effect the two ladders that actually are the same as it uses the ENO of the Function to drive one move which is just the same as using the result on M0 however, it uses M0 twice, the second is essentially the same thing but notice how it uses M0 three times, so as expected, maybe there is an error in the compilation of the different formats.