Control.com - Nerds in Control

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
LinuxPLC@linuxplc.org
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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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
LinuxPLC@linuxplc.org
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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

> 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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Curt:

While I am sure my last post will not earn me any points for tactfulness, your dismissal of Hugh Jack's excellent code based on programming language really yanked my chain I am sorry to say.

Curt Wuollet wrote:

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

Went over to the NT side??? Don't you mean "went over to the dark side"? :-)

I have the opportunity to do some development work on a soft plc, and it happens that it must run on NT. I do plan on releasing the source under a BSD License or GPL though. Most of the code *will* be portable and if it turns out well I will port it to Linux as time permits. That I am developing it for a MS product is what gives you heartburn I suspect...

There are __many__ people using NT that we cannot ignore. Consider this: If a open source soft plc project on NT attracts people because of its
openness and there is also an equivalent effort in Linux, then there is an opportunity to
'convert' people to your beloved Linux OS.

Let me state now that I am definitely not a fan of Bill Gates or Microsoft. I began using Linux in 1997 because of my dissatisfaction with Windows. I have very positive experiences with W2K though, and I have begun to rethink my position on MS and Windows. With W2K and Linux I have the best of both worlds and it doesn't require me to exclude either OS. I am very impressed with the Linux kernel (have you ever actually sat down and gone through it?), but
IMHO, I think that the X Window system and many of the apps still leave a lot to be desired. Of
course, X Window and the apps are not really _Linux_ are they?

I am turned off by both Windows and Linux zealots and their all-or-nothing views. I use software as a tool to get a job done and as long as it works, I am happy.

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

Where did I mention good or evil in my last post? You are the one that seems to want
to make your OS choice and the open source movement an issue of morality and ethics...

Just re-read your response to my message a while back when I said that I was going to concentrate on NT right now. I believe you used the words "moral" and "ethical"...

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

All one has to do is read your past messages in the Automation List concerning open source vs proprietary or your feelings towards Microsoft to come to that conclusion. Somehow you feel that open source is more ethical and that proprietary
is evil. MS users are just mindless lemmings or clueless and your choice in an OS is somehow enlightened and "right"...

I applaud those who release their software projects as open source, but I do not condemn or think less of those who keep their products proprietary.

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

And no more unpleasant than many of the open source/ Linux advocates that can't get over the fact that the world does not bend to their idealistic wishes.

Their endless criticism and rhetoric does as much to turn off people to the idea of open source projects as it does to open peoples minds to the open source idea.

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

Not everyone has a deep seated disdain for proprietary solutions as you seem to have though...

Do you seriously think that Allen Bradley, Siemens, or whomever is going to give up and wither away just because there is an open source alternative available? Many companies like the support that they get from these proprietary
vendors and they are willing to pay the price that comes with sticking to a proprietary solution. I personally don't like having to pay big bucks for a fieldbus card when ethernet would be a much less expensive solution, but what I
personally think doesn't really matter when it comes right down to it. I can give my customers options (which would include an open source solution) but they will ultimately make the decision and I will smile and accept it. That is if I do want to keep them as a customer...

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

I think that if you continue to reject the efforts of people willing to contribute
to this project (such as Hugh Jack) then I don't think you will need worry about it. You will be the only one left here...


Regards,
Phil

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Hi Phil,

Welcome back!

What I am trying to do is get as many as 3 people working on the same machine. This is a microcosm of the automation industry. Half a dozen people working on half a dozen approaches. If we had half a dozen people working on the same approach we would have amazing results, even if it's only coded in crude old C. That Phil, is what the project is about and if you look at my "bigotry" in that light, I am guilty as charged. If you want to compete, let's see who can write the most code on the project or who can write the best code on the project. But, if what you want to do is build a different project, it's not helping this one. I have patiently waited for a concensus. We simply get more approaches. What is first and foremost is that I find people who want to forgo competition and apply their energies in the same direction for the common good. No mystery No BS, that has been my consistant agenda. Microsoft is irrelevent to
the Linux PLC project, I haven't brought it up.

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Phil (to Curt, in a longer conversation):
> Somehow you feel that open source is more ethical and that proprietary is
> evil.

Otherwise known as the RMS position.

(RMS = Richard M. Stallman)

I don't have a URL handy, but I expect you can find his writings from http://www.gnu.org


There are sound business reasons to use Open Source (see also ESR), and reasons related to lock-in and accountability and so forth. But, in its origins, Free Software was motivated by morality.

For some people, one of the main attractions of Free Software is this basis in ethics. For others this is not as important as the practical advantages of Open Source, but still we should not forget our origins, and we should not denigrate people for whom ethics are the determining factor.

In other words, RMS and ESR are both right.


G-d, now I've painted myself as some kind of zealot.

Jiri
--
Jiri Baum <jiri@baum.com.au>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Jiri,

-On RMS-

You can find his writings at: http://www.gnu.org/philosophy/philosophy.html
and yes I have read them.

I find his insistence that software is some kind of moral issue quite bazaar and that brings me to:

-ESR-

From ESR's "The Cathedral and the Bazaar":

<quote>
-----------
Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software ``hoarding'' is morally wrong
(assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.
-----------
<end quote>

I find that ESR's writings are more palatable. You can read his writings
at: http://www.tuxedo.org/~esr/writings/index.html

The "Cathedral and the Bazaar" and "Homesteading the Noosphere" are interesting reads...

-On your comments-

I don't think we should denigrate people for their decision to write proprietary software either though... Like I said in an earlier post - I applaud those who release their code as open source, but I don't think any less of those who make the choice to offer a closed source solution. To say one is evil and the other is good is complete nonsense, IMHO. I am a scientist, not an artist... but some programmers think that they are...

Regards,

Phil

---------------------------------------------------------------------- ------
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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I agree with Mark on this. We can have different modules, programmed in different languages and still make the whole thing work. The code can also be used by anyone on any platform. This effort needs a variety of opinions. Please don't leave us Phil.

If it still matters, my opinion is that C++ is a better language for this project, but that C is also valid if the code is designed using the
principles of encapsulation. I have seen many C projects that suffered because of a lack of scalability (something that is natural to C++). The benefit of C, as Curt has correctly identified, is that it is more universally known. Although, I don't think that should be a reason to preclude C++.

As far as issues with which operating system to support, I would hope that the design would keep all operating system dependant code in one localized place, so it can be replaced as needed. I understand that this is the LinuxPLC, but why limit the capabilities? This is one of the many reasons a good design makes a better product.

Please don't take any of my comments as a sign of aggression. I am only giving my personal opinion.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Hi,

One item that came up was the conversion between IL with brackets, and without. Here is a simple example.

before: AND( LD a LD b OR LD c ) ST d

would become

after: LD a LD b OR LD c AND ST d

Does anybody know of an example that would not convert?

Hugh


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

E = (A&B)|(C&D)
LD A
LD B
AND
LD C
LD D
AND
OR
ST E

E = (A|B)&(C|D)
LD A
LD B
OR
LD C
LD D
OR
AND
ST D

Both require a 3 term stack, and I have never seen/heard of a stack based computing device with a stack this small.


Debian GNU User
Simon Martin
Project Manager
Isys
mailto: smartin@isys.cl


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

simon,

carry this to an extreme, and we can build it under gForth...

robm

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Or postscript ...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

> From: M. Robert Martin

> carry this to an extreme, and we can build it under gForth...

Actually, that would probably work quite well for a prototype if anyone understands gForth enough to hook in the IO. Of more interest is the gForth
engine. It is a *very* fast threaded code interpreter implemented in gcc (note that I did not say Ansi C because it depends on some gcc-specific features for its speed). See
http://www.complang.tuwien.ac.at/papers/ertl93.ps.gz for details of how it works.

Clearly, the first PuffinPLC engine doesn't need to be this fast but it would be very nice to have this kind of performance later. Here are some
thoughts on how to design a logic engine to make this as easy as possible:

1. Choose a simple stack oriented object code. Make it 32-bit aligned for two reasons:
a. Support direct and indirect threading on 32 bit machines later on.
b. Many modern processors charge a heft penalty for unaligned accesses.

2. Express the opcode as a vector of instructions and operands. Think machine instructions here. Think simple, fast execution.

3. Maybe add some non-executable "opcodes" for holding information needed to support uncompiling and debugging as in typical PLCs. This trick, sometimes called "bytecode annotation", is little used but may be particularly useful in this project. The cost of these annotation opcodes is paid in code size and maybe cache misses (because of code size) -- we can almost certainly afford it.

4. Define the IO interface very carefully. Fortunately this is very easy in the current model where IO task(s) do most of this automagically through shared memory.

5. Write a simple user space interpreter for the virtual machine defined above. I'm not going to get into the C vs. C++ argument here, but I'd very
strongly suggest making the main interpreter loop look like the following:

while(1) {
opcode = *ip++;
switch (opcode) {
...
}
}

This (a.k.a. token threaded code) will be reasonably fast and easy to do. Upgrading to gforth style indirect threaded code (direct threaded loses on iX86) will probably gain a factor 2-4+ but be more work and less portable.

6. Write one or more compilers to this virtual machine (VM). I could care less what the compilers are written in or how fast they are (unless they're unbearably slow).

7. Write a programming environment or few for the compiler.

8. Convert the VM to the gforth model, make it work in the RT kernel, etc. This is fun, interesting and a waste of resources until we have a lot more done.

Issues with this approach:

1. Decompilation and debugging. This is going to be work and I've sort of swept in under the rug by suggesting annotations without defining them. The only alternative I immediately see is a VM more specifically tailored to ladder logic. This seems harder and more complex to me, possibly because I've never written one. I'd be thrilled if someone has the experience and desire to take this approach.

2. Ladder specific optimizations such as determining that none of the controlling inputs of a rung have changed (are on?) and that the entire rung can therefore be skipped. My problems with this are much the same as the
previous issue. Again, I suspect that annotations can help and can be added later (yeah, I said they weren't executed -- I lied :-).

3. I've completely ignored the VM's memory model and what to do with it. This isn't so much an issue and a TBD.

I hope that this helps point one possible direction. In summary, I think that Hugh's code could be a big step forward, but that the execution engine portion should be broken off, simplified and sped up.

Dan Pierson, <dan@control.com>

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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: smartin@isys.cl


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Hirrr...

Why don't use the post (or pre) fixed polonese notation, appling the classical approach as compilers does to order mathematical expressions ?

Cristiano

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc