Ladder parser or compiler

C

Thread Starter

Curt Wuollet

Hi all

Does anyone have a ladder parser or compiler yet. Or any language tools? While delayed on I/O temporarily, I thought I'd spend some time lashing up a simple solver to go with the map display. For now the mapping will be in a header file equating a IO symbol with an array index. or some such.

I have the OK to get an Optilogic ethernet rack, but haven't had time to order one. Heartland Engineering ( my day job) is going to make it available to the cause

Regards

cww


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

I have been working on an X-windows ladder programming tool, and slowly refining the logic engine.

One item became clear to me, if the logic engine must deal with all of the 'compiler' issues,
such as variables, and delayed operations, the performance will be severely degraded. So what I did was went to a 'precompile' phase when the ladder logic is loaded initially, and as much interpretation as possible is done at that time. But, I decided to stick to an Instruction List without parentheses. This doesn't create a problem
for ladder diagrams, but for instruction list programs they will need to be compiled to
replace the unassigned variables with addresses, and reorder instructions to eliminate
parentheses.

Hope this helps.

Hugh

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

Curt Wuollet

Hi Hugh

I'm not sure whether that helps or not. Right now we don't have an interpreter for IL of any form. This could be of more use to me than the logic engine was.

It's a matter of some delicacy and I don't at all want to discourage you, but c++ doesn't help me in particular. I looked through the code and got an idea what it does, but I would have to learn c++ to deal with it. I will certainly yield to the list's democratic judgement on this point but I think C has been established as the language of choice. It seems that C is universally used for systems programming and is known by a larger number of our potential programmers. Since not much code is hitting the repository as it is, I don't want to exclude any more of them. For the core of the machine at least, I would like to see C.

At this stage of the game, approachable Bonehead C (tm.) might be best. In what I have done so far, I have strived to keep it as lucid and easily
understood as possible in hopes that more can contribute. It's not even a religious issue
at this point, I'm not seeing much indication that people are reading what's put up. The reason I say that this could be more useful is that tools are more modular and could be written in most any language if the output format is what
we need. Where I'm at is considering a flex (GNU Lex clone) driven tool that takes a text representation of RLL and outputs a C file that could be included in a solver engine at compile time. It's pretty inelegant, but it's what I can do at the moment to get something running. If you are translating visual ladder diagrams to an intermediate language (perhaps IL), that would be preferable to most. What I would need then is an interpreter or compiler (that was still a matter of some debate) for the intermediate language. I don't know IL well enough to know if it could expressive enough to be that intermediate language.

It sounds as if IL is an input to your translator, do you have the target defined well enough for someone (hopefully not me) to write an interpreter?

Regards

Curt Wuollet,
Wide Open Technologies.


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

Phil Covington

To Hugh Jack:

First let me say that I have looked at your code for the logic engine and I think that the OO approach that you have taken is very understandable and straight forward. Your code is certainly much more substantial that anything that has been contributed to the list thus far. Upon opening your source code in an editor, and seeing it was written in C++, I was filled with despair as I began counting down the time until it would be rejected __here__ on this list... Please don't let anyone's opinion of your language
of choice discourage you in your coding efforts - I believe that you are coding your logic engine for use as an educational tool... It is an
excellent effort...

It seems that the OS bigotry on the part of the instigator of this project manifests itself as Programming Language bigotry also (as if C is terribly different than C++ anyhow). Quite discouraging...


To Curt Wuollet:

Curt, somehow I expected it would be you to be the first to reject Hugh Jack's code because it was written in C++. Thanks for not disappointing me! You say that you don't want to exclude C coders, but you seem to easily dismiss C++ ( and other language) coders. Hugh has freely offered his code as contribution to this effort and you turn your nose up at it! All that I can say is please take your pipe-dream LinuxPLC project and shove it up your RMS worshiping, proprietary-world-is-against-me, open-source-elitist rump!
Don't you know that beggars can't be choosers? Looks like you'll be coding this one all by yourself...

I don't want anymore to do with this silliness here... Jiri, please remove me from the Maintainers List.


To other's on this list:

Please forgive my strong words...

Regards,

Phil Covington


My new .sig
----------------------------------------------------------------------------
-----------------
PMS - (Premenstrual Stallman)
Function: noun : a varying group of symptoms manifested by RMS and his lemmings when their
open source utopian world is threatened that may include emotional instability, irritability, insomnia, fatigue, anxiety, depression, headache,
edema, abdominal pain, and hissy fits.
----------------------------------------------------------------------------
----------------

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

Curt Wuollet

Hi all

So much for the olive branch........ Still hate to see you go, Phil. As I said when you went over to the NT side, I'm not out to exclude anyone. It's got to be a community effort. I agree that it's a good approach and well crafted. And it's more than anyone has contributed to date And as I also said, it's for the listers to decide and I will yield to democracy. I'm not going to debate good and evil with you Phil.

I do feel quite strongly that we need to include as many people as possible in a community project. I also believe that to keep it from being exploited, we need the GPL. I also believe that Linux and the free GNU tools make it possible for anyone from a poor student to a company president to participate and deploy the result on an equal basis with equal ownership.
I'm not sure how you construe that as elitist, that remark actually hurt.

I am a Linux bigot, that has a lot to do with the principles above and a deep appreciation for the countless developers who literally give their
lifes work so that I can afford to run a world class OS with world class tools, I owe much of what I know and how I make my living to people
who share knowlege and information freely. This project is an attempt to meet that standard and pass on the only advantage that I have been
given. If that sounds silly and idealistic and makes this a pipedream, so be it. RMS and I don't see eye to eye either, but, I respect his point of
view. This is perhaps the most adverse, commercialized environment to attempt a community effort in and I expected some unpleasantness.

If there is to be no community around it and the principles don't mean anything, it would be simpler and faster to pass the hat and pay some
CS mercenaries to do it. Then how they did it could be kept secret and sold for what the market would bear. It would run on proprietary and
expensive hardware and use yet another proprietary fieldbus etc. and nothing would change. I started to code the thing all by myself, but I thought and still think it would be better and mean a lot more if it were a community project. If I have become an obstacle to that, it's I who should leave. Listers, it's your_ community and _your_ project, what do you think?

Regards,

Curt Wuollet,
Wide Open Technologies.


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

Just some points;

> It's a matter of some delicacy and I don't at all want to discourage you, but c++
> doesn't help me in particular. I looked through the code and got an idea what it
> does, but I would have to learn c++ to deal with it. I will certainly yield to the
> list's democratic judgment on this point but I think C has been established as
> the language of choice. It seems that C is universally used for systems

1. Keep in mind, this is Linux. Open source projects are fun. They will happen. Disagreement is welcome. Parallel efforts are a great idea that
helped make Linux stronger. It is usually better to have many alternative architectures to pick apart and compare. This project has already yielded usable results - Modicon and AB drivers and an shared memory module. I would hate to see anybody "shut down" because the project seems to be rigidly directed.

2. To lay this out in clear terms: C++ is an extension of C that makes it more useable for large projects. But, just because some parts of a
project are written in C++ doesn't mean that anybody else's effort needs to change. At the high interface level I intended to write wrappers so that it would fit any language, and possibly be available as a linkable library. Note: even the C++ compiler turns it back into C.

3. Programs do not need to be one large contiguous chunk. Smaller chunks that run as stand alone executable has long been the unix/Linux way.

> the moment to get something running. If you are translating visual ladder
> diagrams to an intermediate language (perhaps IL), that would be preferable
> to most. What I would need then is an interpreter or compiler (that was still
> a matter of some debate) for the intermediate language. I don't know IL well
> enough to know if it could expressive enough to be that intermediate language.
>
> It sounds as if IL is an input to your translator, do you have the target defined
> well enough for someone (hopefully not me) to write an interpreter?


4. My logic engine is emulating the standard model of the PLC which does execute mnemonic instructions that are more basic than IL. Even ST, SFC and FBD programs are converted to mnemonics. The structures of the languages are simple opcode-operand lists using a stack. So, the logic engine uses these mnemonics, and is effectively the interpreter. The targets are well established. If you want some examples, just run some of your PLC programming software, enter some ladder, and then display the mnemonics.


> So much for the olive branch........ Still hate to see you go, Phil. As I said
> when you went over to the NT side, I'm not out to exclude anyone. It's
> got to be a community effort. I agree that it's a good approach and well
> crafted. And it's more than anyone has contributed to date And as I also
> said, it's for the listers to decide and I will yield to democracy. I'm not
> going to debate good and evil with you Phil.


5. Phil's entire perspective on the role of NT is important. I am not a big fan of Bill - I have been swearing at his stuff since 1981 - before
that the Pet was OK. But, well written code should easily port to any OS. I have even been writing the X-interface so that there is an easy to separate layer to put on a Windows front end. I would like to talk to somebody who might want to write a Windows equivalent to what I have
(Phil?).

Hugh

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

Johan Bengtsson

Curt: C is as I see it neccesary for all the common functions and interfaces, the individual engines and drivers can be coded in anything as long as it can interface to C (does anybody use a computer language that can't). Someone will
probably write a logic engine eventually in C. Whay is a C++ logic engine not useful to you anyway as long as you can use it you don't really have to understand every part of it or a, I wrong? By the way, you learning (to understand) C++ would not hurt you, would it?

Hugh: It is not always possible to remove pharanteses and keep do the same work unless you store temporary values in some other way, I have not looked at your code yet and really don't know if you have solved it fully or not, nevertheless I take it you are on a good way. Keep ut the good work.

Phil: Don't leave because of that.

/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> Where I'm at is considering a flex (GNU Lex clone) driven tool that takes
> a text representation of RLL and outputs a C file that could be included
> in a solver engine at compile time.

I already have that - 138-lines of Perl plus a 19-line sample C header.

It doesn't do the brackets thing, but apart from that it could handle pretty much anything. It even does #line directives, so you get source-level debugging with any debugger (well, you can step through the program, anyway).

Note that this is pre- a lot of stuff on the list - some of the things are completely different in linuxPLC as it is planned now (no separate `input'
and `output' spaces, for one thing).

For example, given:
=== cut ===
### test program ###
# 4.1.00

LD X001
AND Y002
LD X002
ANI Y001
ANB
OUT Y001
SET R5
RST Y002

###
=== cut ===

It will output

=== cut ===
# 1 "./sll2c.pl:preamble"

/************************************************************
* DO NOT EDIT - This file is automatically generated by ./sll2c.pl *
************************************************************/

/* sll.h needs to contain definitions of the load_ and out_ functions */
#include "sll.h"

#define stk_depth 8 /* stack depth - eight is normal */

/* should probably use `n&7' instead of `n%8' but never mind for now */

/* a couple of shortcuts */
#define acc stack[top] /* accumulator == top of stack */
#define next stack[(top + 1) % stk_depth] /* one beyond top of stack */
#define push top = (top + 1) % stk_depth
#define pop top = (top + stk_depth - 1) % stk_depth

void SLL_go() {
unsigned char top=0; /* top of stack */
char stack[stk_depth];
char master=1; /* for the MCS instruction */

/************************************** test.sll */
# 1 "test.sll"
/*** test program ***/
/* 4.1.00 */

# 4 "test.sll"
push; acc = master && SLL_load_X(1); /* LD X001 */
# 5 "test.sll"
acc = acc && SLL_load_Y(2); /* AND Y002 */

# 6 "test.sll"
push; acc = master && SLL_load_X(2); /* LD X002 */
# 7 "test.sll"
acc = acc && !SLL_load_Y(1); /* ANI Y001 */

# 8 "test.sll"
pop; acc = acc && next; /* ANB */
# 9 "test.sll"
SLL_out_Y(1,acc); /* OUT Y001 */
# 10 "test.sll"
if (acc) SLL_out_R(5,1); /* SET R5 */
# 11 "test.sll"
if (acc) SLL_out_Y(2,0); /* RST Y002 */
/* ### */
/************************************** [end] */
# 1 "./sll2c.pl:epilogue"

}

=== cut ===


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Scott Cornwall

Gee Phil, that was almost as emotional a response as Curts.

Maybe we should try and educate Curt on the pros and cons of each approach.

This project would benefit from an OO approach as different implementations want to use different modules, re-use and inherit code, etc, etc.

Let me see, the benefits of C over C++ are... um, err, hmmm, I need to think about that ! I know, people don't like to let go of their favourite language of the past (C or Ladder).

Scott Cornwall


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

Johan Bengtsson

Both or one of these examples is hard to code in most PLC:s IL without parantheses, this is heavily depending on the definition of the IL language however.
E=(A&B)|(C&D);
E=(A|B)&(C|D);
If the IL language have some kind of operator precedence it is possible to code one of them, sometimes it may be possible to do both (at least if you have a command like "invert current
result") Some PLC:s don't have any operator precedence at all.

In particular the following IEC61131-3 program
LD A
AND B
OR C
AND D
ST E
means:
E=((A&B)|C)&D;


It seems to me like you have a completely stack oriented IL definition, that type will NEVER need any kind of paranteses.

/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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

Hang around! Don't let the more vocal guys (guy?) get rid of you. We've already lost Stan Brown and who knows who else.

to Curt and the rest:

To make this work we need input from _anyone_ willing to contribute. I don't care if you want to call an output a Q or an O. My version
will call it what I want (or what my customers insist on<smile>).

The benefit of the open source is that I can do exactly that. (Stan are you still lurking?)

In the same manner I can use the C++ version, or if it really bugs me too much I could code my own in SNOBOL-3. In the meantime we'd at least have the C++ version for testing and for others to use.

The same holds true for platform issues. Lets write this stuff with a posix type interface and release the reference versions as running under Linux. If someone else wants to cobble up a
MickeySoft version, let them.

To be even more extreme if someone develops a component that runs under NT and wants to contribute it, I'd suggest we look at it. If it makes a major contribution someone will convert it to our chosen reference platform.

LETS STOP CRITIZING EVERYONE AND GET SOME WORK DONE!

Mark

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

I guess the questions would be if it looks like what Hugh's doing and how I can use it. Maybe Hugh, you and folks can work on an intermediate language spec? For now , I was gonna output C that I could compile in. An interpreter would be better., but that's the whole solver in this case. I'll probably continue for now, I know my first pass will be "throwaway" code. I hope it's replaced before I'm done :^)

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hugh Jack wrote:

> 1. Keep in mind, this is Linux. Open source projects are fun. They will
> happen. Disagreement is welcome. Parallel efforts are a great idea that
> helped make Linux stronger. It is usually better to have many
> alternative architectures to pick apart and compare. This project has
> already yielded usable results - Modicon and AB drivers and an shared
> memory module. I would hate to see anybody "shut down" because the
> project seems to be rigidly directed.

No disagreement there.

> 2. To lay this out in clear terms: C++ is an extension of C that makes
> it more useable for large projects. But, just because some parts of a
> project are written in C++ doesn't mean that anybody else's effort needs
> to change. At the high interface level I intended to write wrappers so
> that it would fit any language, and possibly be available as a linkable
> library. Note: even the C++ compiler turns it back into C.

Yes I'm aware that it's simply C with extensions. Read the pre processor output and see if you would want to work with it. I'm not trying to start a religious war on the advantages of C++ Where I have a problem is with complexity and our target audience. The whole point (in my mind) is to produce code that people can hack on and play around with as well as use. C++ adds complexity in itself, but, that's only part of the problem. When I look at our target audience, or even our rogues gallery of developers :^) I see a lot more procedural language experience than OO. If it's done in Bonehead C(tm.) you and Jiri can still use it and poke around. I might put in the effort to overcome the barrier and yes, I'd be better for it. I just don't feel you should have to learn another language _and_ another methodology to be involved. It's much, much, harder to get people to play than it is to discourage them. If this were a CS list and the audience were mostly PC developers and recent grads it would be different.

> 3. Programs do not need to be one large contiguous chunk. Smaller chunks
> that run as stand alone executable has long been the unix/Linux way.
>
> > the moment to get something running. If you are translating visual
> ladder
> > diagrams to an intermediate language (perhaps IL), that would be
> preferable
> > to most. What I would need then is an interpreter or compiler (that
> was still
> > a matter of some debate) for the intermediate language. I don't know
> IL well
> > enough to know if it could expressive enough to be that intermediate
> language.
> >
> > It sounds as if IL is an input to your translator, do you have the target defined
> > well enough for someone (hopefully not me) to write an interpreter?
>
> 4. My logic engine is emulating the standard model of the PLC which does
> execute mnemonic instructions that are more basic than IL. Even ST, SFC
> and FBD programs are converted to mnemonics. The structures of the
> languages are simple opcode-operand lists using a stack. So, the logic
> engine uses these mnemonics, and is effectively the interpreter. The
> targets are well established. If you want some examples, just run some
> of your PLC programming software, enter some ladder, and then display
> the mnemonics.

That's what I was saying. We should be able to use your tool with the mnemonics as our intermediate language and compile or interpret it with your engine, another engine, or a compiler to native language if we so desire. I'm much less concerned with interchangable, modular parts of the system than I am with the core parts. X programming will never be simple, less people would likely want to play with that. I could see a use for tcl/tk in the scada parts where people would like something like VB to customise things. I simply think that average implimentor should
have a chance to understand and conceivably change things if they want to. I would take your suggestion, but I don't own any proprietary PLC software. I can't be accused of copyright violation.


> 5. Phil's entire perspective on the role of NT is important. I am not a
> big fan of Bill - I have been swearing at his stuff since 1981 - before
> that the Pet was OK. But, well written code should easily port to any
> OS. I have even been writing the X-interface so that there is an easy to
> separate layer to put on a Windows front end. I would like to talk to
> somebody who might want to write a Windows equivalent to what I have
> (Phil?).

As I said, Phil still has a place here if he wants to, I don't have any use for MS stuff, but, I've tried to be goal oriented for the purposes of this project and our "open" is really Open, you can port to whatever you want to. The project has to accept only code without legal problems. If we can't give it to anyone, freely, it's probably a liability. That's my concern there. And I surely don't want to argue with you, my remarks were strictly to answer Phil's charges.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
What you are generating is postfix notation. As far as computing is concerned, postfix is a complete notation without parentheses, there are no exceptions (See Knuth et al). The big problem is going backwards, i.e. Having no parenthesis means that the decision tree you have to build to
reverse the compilation is quite intricate (not impossible though as the semantics of the original statement are complete). The reverse compilation may be necessary for monitoring, depending on the amount of debug information that is placed in the compiled code.


Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]


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

For the example you gave,
E=(A&B)|(C&D);
Stuff between the brackets is done first, so when converting from '&'
and '|' the operators are moved to after the two arguments.
e = ( a & b ) | ( c & d )
e = ( LD a LD b AND) | (LD c LD d AND)
e = LD a LD b AND LD c LD d AND OR
LD a LD b AND LD c LD d AND OR ST e

For the second one,
E=(A|B)&(C|D);
e = (a | b) & (c | d)
e = (LD a LD b OR) & (LD c LD d OR)
e = LD a LD b OR LD c LD d OR AND
LD a LD b OR LD c LD d OR AND ST e

In these cases the normal operator precedence seems to work.

Hugh

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

Phil Covington

> 5. Phil's entire perspective on the role of NT is important. I am not a
> big fan of Bill - I have been swearing at his stuff since 1981 - before
> that the Pet was OK. But, well written code should easily port to any
> OS. I have even been writing the X-interface so that there is an easy to
> separate layer to put on a Windows front end. I would like to talk to
> somebody who might want to write a Windows equivalent to what I have (Phil?).


Hugh,

I was able to compile and test your code under NT and Linux. Under NT (with VC++) I only had to change the name of one #include file...

There should be no problem with a Windows port of your project and I am interested.

BTW, have you talked to Ron Gage about his notes for a PLC5 work-a-like project?

Regards,

Phil Covington

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