Re: Ladder Parser or Compiler, and more....

H

Thread Starter

Hugh Jack

Hi,

I have been struggling with some of the different models. And, to solve the problem I have implemented all of the basic instructions in the
logic engine. So far I have stuck to a stack oriented model, pushing and pulling as needed. With my temporary op-code structure (not all in
0.0.1) the following statements would all be interpreted the same way. 'ANB' and 'ORB' pull two values from the stack, operate and push. 'AND'
and 'OR' pull one value and compare to the operand and push. The last is Allen Bradley stuff that makes conversion back to ladder much easier.

e = ( a | b ) & ( c | d );
LD a OR b LD c OR d ANB ST e
LD a LD b ANB LD c LD d ANB ORB ST e
SOR BST XIC a NXB XIC b BND BST XIC c NXB XIC d BND OTE e EOR

In both of the IEC 61131 IL type opcodes the 'ANB' and 'ORB' operations are needed to replace the parentheses. In the Allen bradley notation the
'SOR' pushes a true on the stack, 'BST' duplicates the item at the top of the stack, 'XIC' is like an 'AND' with the top of the stack, 'NXB' swaps the two items on the top of the stack, 'BND' is an 'OR' on the two items on the top of the stack. 'OTE' will set the output based on the top of the stack, and 'EOR' pops the stack.

It is my feeling that all of the IEC 61131-3 languages should be compiled to a set of stack oriented, platform neutral commands, including IL. All of the other options add many kludgy methods for delayed instruction stacks, and guessing where the logic branches. There
are still some issues of reverse compiling, but these are less difficult with a completely stack oriented approach like the last code.

Hugh

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Ralph G. McDonald

Hi Hugh:

I believe that you are on the right track. As an old PLC programmer ( 5TI; AB 2, 5, & SLC;GE Series 6, etc) and having done controls in forth as well as assembler, I think that your compiling to a machine independent stack orientated code is the best current approach. You may want to consider using a null or no operation code "NOP" as a marker for rungs ( 1st case ) and branches ( 2nd case ) to aid in reverse compiling:

e = ( a | b ) & ( c | d );
f = ( a | c ) & e
NOP LD a LD b ANB LD c LD d ANB ORB ST e NOP LD a LD c ANB LDc ORB ST f NOP
NOP NOP LD a LD b ANB NOP LD c LD d ANB NOP ORB ST e NOP NOP LD a LD c ANB NOP LDc ORB ST f NOP
This would incur a very minor increase in logic solving speed and could be left out via a compiler switch in a truly speed sensitive case. If the AB notation is copywrited you may not want to use it in the core language but only as an optional compiler module in case of objections by Rockwell, Inc.
Keep up the good work:
Ralph

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Hi,

Thanks for the feedback. What I have done in the current implementation is to add some mnemonics to the basic set that directly support ladder
logic. The logic engine will switch modes when a 'rung' is encountered, and behave somewhat differently. In particular, the outputs don't
consume the value at the top of the stack. When the rung begins, a TRUE is pushed on the stack, and the value on the stack is popped off at the
end of the rung. In some cases these operators are redundant, but they make the ladder coding unambiguous. The operators for ladder are listed
below (you might recognize them).

SOR - marks the start of a rung of ladder logic (push a TRUE on the stack)
EOR - marks the end of a rung of ladder logic (pull a value off the stack)
BST - marks the start of a ladder logic branch (pushes a copy of the top of the stack on the stack)
NXB - indicates that the logic should move to the start of the next branch (exchange the values on the stack)
BND - indicates that the branch has ended (OR the two values on the stack)

BTW, I also included a NOP (for old times sake) but it has no function. I have not noticed any AB copyrights on their formats or instructions, but if this is the case, it can be changed in minutes.

Hugh


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top