CoDeSys 2.3 Ladder - In Line Comparison Operators

Using CoDeSys 2.3 for the first time. I've not been able to use in line comparison operators successfully in Ladder - and haven't found any examples of it anywhere in the user manuals or otherwise. I'd just like to confirm that it is impossible.

Say I want to drive a coil if two pairs of DINTs are equal, so in Ladder, what I would do in say RsLogix (one rung no branches):



--- EQU(DINT1, DINT2) --- EQU(DINT3,DINT4) --- OTE(bCoil)



instead, I have to



--- EQU(DINT1,DINT2) --- OTE(bScratch1)

--- EQU(DINT3,DINT4) --- OTE(bScratch2)

--- XIC(bScratch1) --- XIC(bScratch2) --- OTE(bCoil)



or something similar (three rungs).

Is this the best I can do?

Best way I could figure to make it clean would be write your own function in ST. Really just 1 line of code.

I know, probably not what you want to do. However, the real strength of 61131 is when you use each language for what it is good for and combine things that way.

The most visual way to do this would be in function block diagram (FBD).

This breaks a few rules, but it is the closest I have been able to come to it. I put it some fixed numbers just to test it. You will need to modify the input variable types of the function block to match the variable types that you want to compare. They should technically be functions (not function blocks), but the ladder editor won't let you insert functions this way.

Why use Ladder? Try FB it makes much neater code that I find much easier to fault find

Why use Ladder? Try FB it makes much neater code that I find much easier to fault find

Click to expand...

Customer spec. They are changing controllers and want old programs converted.

Archie:
Thanks, this is the way to go I think.

I know you mentioned CoDeSys V2 but if you have an option for V3 Then you can do this in ladder:



In fact, in V3, the editor for Function Block, Ladder and Instruction list is really only one editor and you can select which view you want to see.

Archie said:

This breaks a few rules, but it is the closest I have been able to come to it.

Click to expand...

To explain why this "breaks some rules"....

1) The function instance declaration of "dummy" is used on more than one instance of the function block. 99% of the time this will cause problems. The reason it does not in this case is because the function block has no internal variables that would retain their values from one scan to the next.

2) This function block should really be a function because it will always have the same output value when the same input values are given and it only has one output value. These are the rules of when to use a lighter weight function versus function block.

same as archie but in ladder

archie,
how do you make these nice screen grabs?

shooter said:

archie,
how do you make these nice screen grabs?

Click to expand...

I do an Alt-PrntScrn, then paste into Paint and save as a PNG

shooter

When I use "enable" or "EN" in a custom function/function block, I try to be careful because it is easy to cause confusion on what to expect for the output.

This is an example showing the EQ function inserted as a Box with EN along side a custom function block with an enable input. If the following sequence occurs, most users coming from other PLC systems can be caught off guard:

- FreezeOutputs=False and MySignal=0
- This results in OUT1=True and OUT2=True
- Now FreezeOutputs goes to True
- OUT1 stays True, OUT2 goes to False
- Then MySignal changes to a 1
- OUT1 continues to be True and OUT2 remains False




For most people new to CodeSys, this is an unexpected result. So to keep things consistent, when I use Enable/EN in a custom function, I make sure it acts the same as an EN on a Box with EN