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

[drbitboy]

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?

 

[Lare]

Probably this
"The execution order in POUs is uniquely determined in text-based and network-based editors. In the CFC editor, however, you can position the elements freely, so the execution order is initially not unique."

Loading…

help.codesys.com

 

[bernie_carlton]

Is there a way to view a statement list version of the program. That may show interpretation differences.

 

[Lare]

Is there a way to view a statement list version of the program. That may show interpretation differences.

It is one possiblity. How noticed earlier that reset command with r_trig behaves differently depending if trigger is used on ladder or CFC and if used inside function block or not.

 

[drbitboy]

Probably this
"The execution order in POUs is uniquely determined in text-based and network-based editors. In the CFC editor, however, you can position the elements freely, so the execution order is initially not unique."

Loading…

help.codesys.com

That says to me that the execution order determined by Codesys is unambiguously broken, because this is LD not CFC, and LD (Ladder) is a network-based editor, and in LD the top branch of two parallel branches must execute first, and that is obviously not happening here.

Is there a way to view a statement list version of the program. That may show interpretation differences.

We don't need that: the lower branch of Rung 3 must have been executed before the upper branch of Rung 3 by the logic here, otherwise savehound2 could never equal fox.

 

[Lare]

That says to me that the execution order determined by Codesys is unambiguously broken, because this is LD not CFC, and LD (Ladder) is a network-based editor, and in LD the top branch of two parallel branches must execute first, and that is obviously not happening here.

We don't need that: the lower branch of Rung 3 must have been executed before the upper branch of Rung 3 by the logic here, otherwise savehound2 could never equal fox.

On same link that posted earlier
"The elements are sorted from top to bottom and left to right."

Is codesys program execution order from top to bottom then right or from left to right then bottom?
As now it seem that it is like on old modicons on 70s and 80s.

 

[dwoodlock]

I agree it is odd. Curious what the result would be if you put the two move instructions in series instead of branched.

 

[drbitboy]

On same link that posted earlier
"The elements are sorted from top to bottom and left to right."

Is codesys program execution order from top to bottom then right or from left to right then bottom?
As now it seem that it is like on old modicons on 70s and 80s.

That statement, "The elements are sorted from top to bottom and left to right," at that link, when read in context, only applies to CFC (Continuous Function Chart), not to LD.

The interesting bit relevant to LD from that quote is "The execution order in POUs is uniquely determined in text-based and network-based editors," which may be true, but for Codesys LD, a network-based editor, "Top-to-Bottom and Left-to-Right" is not how the "The execution order in POUs is uniquely determined..."

Ergo, Codesys behavior in this area is broken, or at least that is what I am trying to confirm.

 

[drbitboy]

I agree it is odd. Curious what the result would be if you put the two move instructions in series instead of branched.

It will execute correctly i.e. left-to-right; but this is only a minimal test case to demonstrate the problem.

In the actual case where I ran into this the upper branch had an XIC/NO contact that needed to run first because the logic after the contact affected the logic on the lower branch, so executing the lower branch first produced unexpected, and I believe incorrect, behavior.

There were workarounds:

• I swapped the upper and lower branches, so that contact-driven lower branch executed before the upper branch, and the logic worked as I intended (if not how it read)
• Joining the ends of the two branches made the upper branch's logic execute before the lower rung's logic, although if either rung ended with a coil then joining them was not possible.

 

[dwoodlock]

Don’t recall running into this issue before, but I’ll run some test cases today and see what I get. What version are you using?

 

[modiconguy]

CODESYS Group

content.helpme-codesys.com

"branches which are executed in succession from top to bottom"

I like that the Control Expert ladder editor is explicit about the execution order of functions. Sadly they don't label function blocks the same way, so if you wanted to use the value of a timer for example you have to test that.

 

[drbitboy]

Don’t recall running into this issue before, but I’ll run some test cases today and see what I get. What version are you using?

• CODESYS V3.5 SP19 Patch 6, downloaded a few days ago
• Window 10 "Enterprise Evaluation" Build 19041.vb_release.191206-1406 in a guest VM in VirtualBox
• Host OS is Linux Mint, which is a variant of Ubuntu, I think.

Thanks!

 

[dwoodlock]

• CODESYS V3.5 SP19 Patch 6, downloaded a few days ago
• Window 10 "Enterprise Evaluation" Build 19041.vb_release.191206-1406 in a guest VM in VirtualBox
• Host OS is Linux Mint, which is a variant of Ubuntu, I think.

Thanks!

Interesting @ Linux Mint, been contemplating making the jump.

 

[drbitboy]

CODESYS Group

content.helpme-codesys.com

"branches which are executed in succession from top to bottom"

Thanks for finding that!

It is disappointing (because either it is wrong or there is a bug in Codesys); I was hoping there would be an explanation regarding execution order of Closed vs. Unclosed branches.

 

[Lare]

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/