H
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
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