Where we are (long)

C

Curt Wuollet

Hi All

I have looked at all the responses both public and private to the questions I posed and the general state of things. As is usual with
a request of this type, I have been left with more questions than answers: I will start with my statements and then, sigh, some more questions.

First, Hugh's Java PLC. I agree with Hugh that there is room for multiple approaches to fielding a Linux Automation Product. The first time I tried to explain this I got singed around the edges but, as I am relatively fire resistant and flames are nothing new for someone who seeks to change the status quo, I will persist.
This Linux PLC has different goals and purposes, not the least of which is to use Free Software tools and to be totally free to distribute. While there are rumors about Java being Open Sourced
it is not at this time. The efficiency tradeoffs with higher level languages are also a problem as another goal is for the core to be as small and fast as possible. There are also realtime and small machine considerations that, added to the fact that C is "the" systems programming language on Linux, make C the choice for this project. It is my sincere hope that at least one opproach reaches commodity status in the automation market. I truly admire Hugh's solitary accomplishment, but that brings us (conveniently) to the next issue, the one that concerns me most of all.

A major goal of this and other Open Source projects is to use the abilities of a group of people to make better software that better
serves the common need than can be produced by an entity purely for profit. I have argued endlessly to make choices that keep the prospective developer base as broad and democratic as possible. I want this to be a volksplc in concept and execution so that it would be routinely and continuously augmented and improved by the user base, with those improvements available to all via the GPL requirements.
I am a strong proponent of project ownership where each and every individual feels they are a part and can be proud of the group
accomplishment. This ideal has been extremely difficult to inspire in this group and may perhaps never be realized due to both the
diversity and uniqueness of the members.

The most significant remarks have been that the project has become too complex for the majority of people to follow and discouraged many who might otherwise contribute. I happen to be in the group that is so challanged. I have agonized over this for more time than I should admit to and have found no easy solution. We certainly can not fault Jiri amd Mario for their contribution,
to the contrary, they have kept the project alive when _no one_ else, my self included, has been contributing. That we can't work together at that level is certainly not their intent or fault either.

I started this project believing that I was fully capable of making a Linux PLC and I have not been shaken from that view yet. I wanted to harness the talent and skill of others in achieving that goal faster. What I could do myself would be
much less sophisticated than what is in the works from Jiri and Mario and crude by comparison. But, done entirely in Bonehead C (tm.) as I do no other, it would be more easily understood and argued about. More people could participate and
it would more closely approach the volksplc. It would have to be incrementally and repeatedly revised and rewritten to add needed features as they are discovered.

Jiri and Mario (and others I'm sure) are schooled and skilled to design for the final version and code once or at least many less times than I would as my approach was to use the skills of
the average hacker in the group, that is to say, a couple of notches better or worse than my own skills.

The compromise informally proposed is that the CS guys write the "hard stuff" and provide comprehensible API's for the others to write to. This is certainly plausible under the circumstances. The main problem is that it has been and will be a while before it can be done. Many have lost interest in the meantime.

I accepted Jiri's offer of help in good faith with reservations about just this problem. Thus, I take all responsibility for the waning of interest. It must be said we were on the prongs of a similar but different dilemma at the time, I couldn't get anyone to help me code in my fashion either.

When I asked the original questions in this thread, I had been thinking about OSS development in general. What we have is a microcosm of the "Cathedral and the Bazaar". This is quite by
accident as the "high priests" had no intention of being such. Indeed, it is the rarity of Linux programming skills and experience _in this group_ that elevate them to their lofty and unintended position.

Many times I have adamantly refused or at least argued against proposals that would include more skilled CS types at the expense of the "silent majority" of folks who have a little C experience
on a different platform perhaps or who are very willing but need help or coaching on their skills to contribute. This has turned off some high power people who think I am an idiot to insist on
simple and archaic tools and traditional values and inclusiveness. While I don't regret these choices, perhaps I am an idiot for not finding a way to include these high power folks.

I keep up with handgun Metallic Silhouette shooting. I don't compete anymore because there are no facilities close and I am too pressed for time and money. But I can compete (badly) if I
want to because they have a class for hackers with a production gun and other classes for exotic hardware and the good shooters. You'll see where I'm going with this in a minute.

I propose the same structure for our endeavor:

A "Hunter's Gun" division where I continue the thread of development I started with explanation and progress based on understanding with anyone welcome. The goal will be a light weight embedded class PLC compatible wherever possible.

An "Unlimited Class" Where anything goes to interest those who want C++, OOM, (object oriented mentality) and whatever they can successfully argue will get the job done with the proviso of course, that it run on Linux and be GPL compatible. I would ask those who I offended before to give it another look.

Some may see this as "Solomon's solution" that is suggest splitting the baby and see who cares the most or forking. I see this as addressing two applications areas optimally.

What do you think?
Does anyone else have a better solution?

Regards
cww

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

P

PhilC

> First, Hugh's Java PLC. I agree with Hugh that there is room for
> multiple approaches to fielding a Linux Automation Product. The
> first time I tried to explain this I got singed around the edges
> but, as I am relatively fire resistant and flames are nothing new
> for someone who seeks to change the status quo, I will persist.
> This Linux PLC has different goals and purposes, not the least
> of which is to use Free Software tools and to be totally free to
> distribute. While there are rumors about Java being Open Sourced
> it is not at this time.

When in the Hell did Hugh's LPC become the "Java PLC"? I doubt you have even bothered to look at the LPC's code. Yes, there is a Java client front
end, but the LPC is written in C++. There is also a telnet client. Look at Hugh's code, you will find excellent ideas that could be used in the Linux PLC. Don't worry its not fancy C++, but just Bonehead C++ ( not trying to imply that Hugh writes Boneheaded code though). An if you have bothered to look at the source code, you would see that it is released under the GPL, so
your assertion that the LPC is not free is total BS.

I think that the SMM and I/O work that has been done in the Linux PLC could be merged with Hugh's code. There is no reason why the I/O and other lower level stuff can't be written in C and the higher level stuff in C++. There is no need to abandon either project if this is done, but both projects could benefit from collaboration.

The idea that the Linux PLC must be written in only C because of the possibility that it may run on embedded hardware is a *bogus* argument also.
Take a look at Automation Direct's ( actually Host engineering's) WinPLC. It is a processor that sits on the DL205 rack and runs Windows CE. Some people actually write control programs in C++ or VB (!!!!!!!!!!!!!!!) with this thing! Or you can run Think and Do's soft PLC on it. My point is that the operating system will be embedded Linux running on the embedded hardware
and with flash memory being so inexpensive now, there is no reason why Hugh's C++ (gasp) LPC or any other program written in non-C couldn't fit and run on it. Insisting that the Linux PLC will be only written in C because C is the only thing that you understand is 'kinda self centered.

I have never understood those who only know one programming language and no other. If you have had any formal training, understand data structures and general programming techniques, the transition to another language isrelatively painless. It is very limiting to be stuck in only one language.

Phil

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

C

Curt Wuollet

Hi Phil

1. Isn't that more or less what I was proposing? It's a philosophical difference. None the less, I am holding out an olive branch. It is not a gauntlet. It is specifically so that you and folks like you can take it where you will. Dono Nobis Pacem. I am trying very hard to work with _all_ the people who want to contribute. That is entirely difficult enough, I don't have time to worry about other projects. Hugh seems to understand this and we can exchange back and forth freely as it is.

2. That does nothing to lower complexity which is my stated goal and we disagree about systems programming. You can code time critical code
in whatever you want, I use C on a platform written in C. I have programmed professionally in at least 6 other languages. I don't view it as self serving if I try to find the one shared by the most prospective contributors which is also good for systems programming. Linux is written in C for the same reasons. I am not excluding you.
You and Hugh and many other coders can _all_ work in C. I _will_ make what I do as accessable and inclusive as possible. I want users to be able to understand, run, fix and improve the system.

3. You can wedge a whole W98 system on an embedded platform if cost is not an object. But on the processors that are inexpensive and
operate without a fan through the industrial temperature range, small is beautiful and you can never be too fast. I am looking for a retail price that undersells a microPLC with vastly superior capability and an embeddable engine that can be configured as an IO rack economically.

Regards

cww

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

M

Mario J. R. de Sousa

PhilC wrote:

>
> I think that the SMM and I/O work that has been done in the Linux PLC could
> be merged with Hugh's code.

Quite right. I actually copied the plc5 emulator code to my local copy of the linuxplc cvs tree and am trying to make them compatible. I had a look through the code, and it doesn't seem that impossible, especially seing that Hugh made all accesses to the LPC memory go through a variable type class. We just have to change this class to access the linuxplc memory. Some other changes to the controller may aso be required.

I tried to link Hugh's C++ code with our linuxplc.a library and failed on my first try. It's not something I've done before, and I have been busy writing the parsing code to the simpler synch configuration syntax, so I'll look through the man pages later and figure out how to do it, unless someone else can help (Phil, have you got a clue on how to go about doing it?).

Hugh, sorry about not asking you about using your code, I intended to get a working version privately, and only then ask you before making it public. Might just as well ask you now, do you mind if we use your source code?

> There is no reason why the I/O and other lower
> level stuff can't be written in C and the higher level stuff in C++.

Please note that this is exactly what I proposed in my email trying to introduce the linuxplc to the newcommers. It seems it made its way to the FAQ, so you can see it there too.

> There
> is no need to abandon either project if this is done, but both projects
> could benefit from collaboration.

I completely agree. I sure hope Hugh agrees too.

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

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

J

Jiri Baum

Mario de Sousa:
> I tried to link Hugh's C++ code with our linuxplc.a library and failed on
> my first try.

I think what you have to do is put an
extern "C" { ... };
around the C declarations. That's because internally C++ uses some hairy Hungarian notation, so you have to tell it that it's not there.

It might be enough to replace

#include <plc.h>

with

extern "C" {
#include <plc.h>
}

but realistically you'd want to make a new header file which declares a point object and some friend functions, so that you can use points like
this:

{
Point foo("foo"), bar("bar"), baz("baz");

baz = foo & bar;
}

(You'd probably want to put all those functions in the .h file, too, so that they can be inlined.)

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

J

Jiri Baum

> Mario de Sousa:
> > I tried to link Hugh's C++ code with our linuxplc.a library and failed
> > on my first try.

Jiri Baum:
> I think what you have to do is put an
> extern "C" { ... };
> around the C declarations.

With thanks to Harald Albrecht, this is now in the plc.h file (and also plc_setup.h). So with any luck it'll work now as expected from C++, with no further magic required.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

H

Hugh Jack

Hi,

If anybody wants to use my code, feel free. If you are trying to patch in the SMM, it is best to do it through the 'io.cpp' file. But, beware,
I do need to revisit the IO scanner because what is there now is enough to make it functional, not versatile. Please let me know what you get and I will patch it into my releases.

I am glad the discussion of the project direction is continuing. Here are some points that I think are worth considering.

1. It is time for the Puffin PLC to do a release. I see the basic elements forming up - the FAQ, some demos, etc. Why not set a target of a few weeks from now, and work towards it?

2. The SMM architecture of the Puffin PLC would allow any variety of languages to be used without impacting other modules. The best advice to
increase development would be to release a tarball that has a simple API so that others can write independent applications and drivers. I would be very interested in including it as part of the LPC project.

3. I remember when I found the Puffin project in March, and 'lurked' (tm) for a few days. The idea of a Linux PLC was very attractive to me, and I wanted to help the project. I spent a week and put together the logic engine, and offered it to the group. The response I got made it easier for me to just continue it elsewhere. I have seen the same response to many others since then regarding topics such as Perl, Eiffel, OLE, Windows, Java, XML, IEC 61131, etc. The appropriate response in an open source project is 'why don't you try it', not 'I don't agree, but you can do it anyway'. People in open source projects want to be challenged, not managed.

4. I have found that a common argument used to dissuade others has been that something was agreed to earlier, and the discussion is over. This is not acceptable in a group project. Neither are references to old discussion items. The group needs to put together a clear description of the project with technical details and directions. See Mark Hutton's Java PLC spec for an example. Note that it is also possible to have multiple versions of the same project, with a clean division between goals.

5. The current leadership has been very effective at generating publicity and interest in the project. And, I think it would be effective if it continued. But, in an open source project the people with strong technical opinions, should be technically strong and productive. For example, have a look through the CVS tree.

Hope this helps,

Hugh

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

C

Curt Wuollet

Hi All

(setting aside smoking remains of what appears to be an ....Olive Branch?)

You're welcome!

It's difficult for some people to compromise on principles. I take it from the last few posts that the top end folks agree?

Regards

cww

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

D

Dan L. Pierson

Curt Wuollet <[email protected]> writes:

Hi Curt, I've take the liberty of reordering some of your message to make my comments clearer. I hope this is OK with you.

First, an apology of sorts. Both we at Control.com, Inc. and me personally do intend to make useful technical contributions to this
project aside of the logistical support we're currently providing. Unfortunately we've been much to swamped setting up and funding a new
company to do technical work this year. Since I believe that open source projects work best with an initial code base and don't need a lot of disruption from non-contributors, I've kept pretty quiet so far. I intend to keep pretty quiet most of the time until we have some code to toss into the pot, but I'll make an exception today

> Some may see this as "Solomon's solution" that is suggest
> splitting the baby and see who cares the most or forking.
> I see this as adressing two applications areas optimally.

I don't see this as a problem because we have always seen the Puffin project as a sort of umbrella over a number of different subprojects.
It'd be nice if one project produced working code before a split into multiples, but frankly that looks like what will happen: IMHO the Jiri - Mario - Hugh branch looks likely to produce the first useable code fairly soon.

One reason that we believe in multiple subprojects is that different models of automation programming lead to different requirements. While Ken and I have both spent our automation careers in state languages (Ken invented Quickstep and I designed and led the
implementation of the last 2 major versions), we both realize that a Linux based PLC that doesn't support ladder logic and at least a subset of IEC1131 won't succeed. We also believe that the low level implementation requirements of state languages and ladder logic are not fully compatible. Thus one subproject can't satisfy everyone. It is important to share as much as possible. However, contrary to some conventional CS wisdom, the best way to get there may not be to start out by insisting on one perfect shared design.

> Many times I have adamantly refused or at least argued against
> proposals that would include more skilled CS types at the expense
> of the "silent majority" of folks who have a little C experience
> on a different platform perhaps or who are very willing but need
> help or coaching on their skills to contribute. This has turned
> off some high power people who think I am an idiot to insist on
> simple and archaic tools and traditional values and inclusiveness.
> While I don't regret these choices, perhaps I am an idiot for not
> finding a way to include these high power folks.

Unfortunately for you, I have to count as another "CS type" (I'll let you decide how skilled I am after I contribute some code). The
problem is that what we practical CS types try to do is make things simpler. It may not seem like it at first, and the internal implementation may not be trivial, but the alternative is frequently
much worse. I've spent a fair amount of time hacking and porting GNU Emacs and have also done some porting of GCC and Perl. All of these
are C programs. None of them is simple. I'll go so far as to say that no highly portable, large C program is simple. Yes, this means that if the LinuxPLC becomes successful it will not be simple. No matter what language it's written in. How do we deal with that? Here are several ways:

1. Try not to introduce too much complexity too soon.

2. Package complexity in reusable hunks with well defined API's (what Jiri and Mario have been doing).

3. Break up the project into multiple subprojects. For example, there's no reason why the PLC engine and the HMI have to be in the
same project or even execute on the same machine (obviously there's also no reason why there should be only one HMI, but that's a different topic). I'd even argue that the programming tools and PLC engine should _eventually_ be different subprojects, especially if it
gets the point of (several) programming IDE(s).

4. Use the right tool for the right job. C is appropriate for some subprojects. C++ is appropriate for others. Python or Java might be
best for yet others. There are lots of tradeoffs. Speed and size for embedded hardware is one and using interpreted or threaded code where size is more important than speed is a well established technique for fitting less speed critical code into less space in that environment.
Program readability and maintainability is more important for other subprojects where C might not be the best choice.

> I started this project believing that I was fully capable of
> making a Linux PLC and I have not been shaken from that view
> yet. I wanted to harness the talent and skill of others in
> achieving that goal faster. What I could do myself would be
> much less sophisticated than what is in the works from Jiri
> and Mario and crude by comparison. But, done entirely in
> Bonehead C (tm.) as I do no other, it would be more easily
> understood and argued about. More people could participate and
> it would more closely approach the volksplc. It would have to
> be incrementally and repeatedly revised and rewritten to add
> needed features as they are discovered.

I don't fully understand this. Probably because I still don't know what you mean by Bonehead C (tm.). While there are some corners of C
such as bit fields in structures that can cause a lot of problems, I don't have a picture of what subset you have in mind that will support the development of a _portable_ Linux volksplc that will continue to be comprehensible and maintainable as it grows. Yes, I consider portability vital. There are too many embedded processors out there and the tradeoffs change too rapidly to make settling on any one processor architecture acceptible in the long term. Right now Tri-M's PC104 wrapping of the Mach-Z in a single board controller wrapper looks really sweet for the low end (http://www.tri-m.com/products/tri-m_engineering/iccmachz.html),
but what will be the hot low end product next year? What do you move to if a P-133 equivalent isn't fast enough? An ARM maybe?

Dan Pierson

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

C

Curt Wuollet

Hi Dan

You're right, we don't hear from you often (enough)

"Dan L. Pierson" wrote:
...
> First, an apology of sorts. Both we at Control.com, Inc. and me
> personally do intend to make useful technical contributions to this
> project aside of the logistical support we're currently providing.
> Unfortunately we've been much to swamped setting up and funding a new
> company to do technical work this year. Since I believe that open
> source projects work best with an initial code base and don't need a
> lot of disruption from non-contributors, I've kept pretty quiet so
> far. I intend to keep pretty quiet most of the time until we have
> some code to toss into the pot, but I'll make an exception today
>
> > Some may see this as "Solomon's solution" that is suggest
> > splitting the baby and see who cares the most or forking.
> > I see this as adressing two applications areas optimally.
>
> I don't see this as a problem because we have always seen the Puffin
> project as a sort of umbrella over a number of different subprojects.
> It'd be nice if one project produced working code before a split into
> multiples, but frankly that looks like what will happen: IMHO the Jiri
> - Mario - Hugh branch looks likely to produce the first useable code
> fairly soon.

That's why I thought compromise advisable. Don't get me wrong. I'm all for a lplc as soon as possible. I would like one that many more folks
could contribute to but, in the end I need a lplc. I don't _have_ to be able to understand how the hell to write a driver to it, we'll have more drivers if I can.

> One reason that we believe in multiple subprojects is that different
> models of automation programming lead to different requirements.
> While Ken and I have both spent our automation careers in state
> languages (Ken invented Quickstep and I designed and led the
> implementation of the last 2 major versions), we both realize that a
> Linux based PLC that doesn't support ladder logic and at least a
> subset of IEC1131 won't succeed. We also believe that the low level
> implementation requirements of state languages and ladder logic are
> not fully compatible. Thus one subproject can't satisfy everyone. It
> is important to share as much as possible. However, contrary to some
> conventional CS wisdom, the best way to get there may not be to start
> out by insisting on one perfect shared design.

I am not a fan of any of the common PLC languages, I would like to see quickstep or I may use the libraries with C for my purposes. IL or ST would be the conventional choices I'd use most. BUT, it's really up to the users.

> > Many times I have adamantly refused or at least argued against
> > proposals that would include more skilled CS types at the expense
> > of the "silent majority" of folks who have a little C experience
> > on a different platform perhaps or who are very willing but need
> > help or coaching on their skills to contribute. This has turned
> > off some high power people who think I am an idiot to insist on
> > simple and archaic tools and traditional values and inclusiveness.
> > While I don't regret these choices, perhaps I am an idiot for not
> > finding a way to include these high power folks.
>
> Unfortunately for you, I have to count as another "CS type" (I'll let
> you decide how skilled I am after I contribute some code). The
> problem is that what we practical CS types try to do is make things
> simpler. It may not seem like it at first, and the internal
> implementation may not be trivial, but the alternative is frequently
> much worse. I've spent a fair amount of time hacking and porting GNU
> Emacs and have also done some porting of GCC and Perl. All of these
> are C programs. None of them is simple. I'll go so far as to say
> that no highly portable, large C program is simple. Yes, this means
> that if the LinuxPLC becomes successful it will not be simple. No
> matter what language it's written in. How do we deal with that?
> Here are several ways:
>
> 1. Try not to introduce too much complexity too soon.
>
> 2. Package complexity in reusable hunks with well defined API's (what
> Jiri and Mario have been doing).
>
> 3. Break up the project into multiple subprojects. For example,
> there's no reason why the PLC engine and the HMI have to be in the
> same project or even execute on the same machine (obviously there's
> also no reason why there should be only one HMI, but that's a
> different topic). I'd even argue that the programming tools and PLC
> engine should _eventually_ be different subprojects, especially if it
> gets the point of (several) programming IDE(s).
>
> 4. Use the right tool for the right job. C is appropriate for some
> subprojects. C++ is appropriate for others. Python or Java might be
> best for yet others. There are lots of tradeoffs. Speed and size for
> embedded hardware is one and using interpreted or threaded code where
> size is more important than speed is a well established technique for
> fitting less speed critical code into less space in that environment.
> Program readability and maintainability is more important for other
> subprojects where C might not be the best choice.

For size _and_ speed we use compiled C. For tools, GUI's and stuff not in the main execution loop there are many options. Drivers and stuff that operates in kernel space (realtime) is almost certainly going to be in C or the kernel folks will ignore it.

> > I started this project believing that I was fully capable of
> > making a Linux PLC and I have not been shaken from that view
> > yet. I wanted to harness the talent and skill of others in
> > achieving that goal faster. What I could do myself would be
> > much less sophisticated than what is in the works from Jiri
> > and Mario and crude by comparison. But, done entirely in
> > Bonehead C (tm.) as I do no other, it would be more easily
> > understood and argued about. More people could participate and
> > it would more closely approach the volksplc. It would have to
> > be incrementally and repeatedly revised and rewritten to add
> > needed features as they are discovered.
>
> I don't fully understand this. Yes :^)

> Probably because I still don't know
> what you mean by Bonehead C (tm.). While there are some corners of C
> such as bit fields in structures that can cause a lot of problems, I
> don't have a picture of what subset you have in mind that will
> support the development of a _portable_ Linux volksplc that will
> continue to be comprehensible and maintainable as it grows.

It's as much a style issue as a complexity issue. Things like Hungarian Naming, obfusticated structure, code commenting and documentation. Current commercial practice is for code to be hidden away. We are writing code that is meant to be read, understood, and shared. Look at my code and compare it to what's in the archive. I write code this way because I have to explain it to people. And the gcc output from obvious code is equal to or better than extremely terse, dense
code. Portability beyond Linux/POSIX is simply not an issue for me. Anything else except perhaps QNX or ***BSD will unacceptably degrade reliability. We will probably never have all the drivers we want for X86. I would rather have a
highly optimized design for one platform than a can of worms that "fits all".

Just what other platforms are we equipped to support? Most of our lurkers don't even have a Linux box.........yet :^)

We are competing against serious embedded people with dedicated hardware and hand optimized code with critical portions written in assembler. If it turns out too small and too fast, I'll be happy to apologize :^)

> Yes, I
> consider portability vital. There are too many embedded processors
> out there and the tradeoffs change too rapidly to make settling on any
> one processor architecture acceptible in the long term.

I think embedded Linux is the safest bet. There's no way we can plan for whatever processor someone may port Linux to. It already supports more
than anything else. At the embedded level things do get hardware specific. For example uCLinux runs on a Dragonball without a MMU. My memory
scheme will work there. About all you can count on for system support is gcc and a (shrunken) stdc. A lplc that runs there should run anywhere. The converse is not very likely. If you want portability we probably already have changes to make. Porting to a bigger system should be easier.

> Right now
> Tri-M's PC104 wrapping of the Mach-Z in a single board controller
> wrapper looks really sweet for the low end

If you're small and tight enough, that's the high end:^) As you know, I have been trying to get something going with the Mach-Z for a DIN rail mount "lplc home". Seriously though, that's much more horsepower than at least 99.9% of all the PLC's in use. There's no substitute for efficiency. A decent lplc should do well on an old 486 without a GUI and be untouchable on that
hardware. I guess we just come from different worlds

That's why I suggested perhaps an embedded version. I have an interest there and no one is addressing all the other folks who want a piece of the action.

> (http://www.tri-m.com/products/tri-m_engineering/iccmachz.html), but
> what will be the hot low end product next year? What do you move to
> if a P-133 equivalent isn't fast enough? An ARM maybe?

I'd profile and optimize my code :^)

I'm not picking on you, Dan, these are things I wanted to get out on the table so people can understand my rationale. From some of the comments, I know some people are looking at this from a PC only perspective and as application
coding. I think small footprint hardware directly competing with PLC's is the bigger "market". Not only are there more opportunities, there's no viable competition...yet. There's some entrenched vendors with deep pockets and Microsoft backing in the PC game. Wince is not a threat in embedded. Being good in both markets is a good position to be in.

regards
cww

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

D

David Wilson

Hello gang,

Just thought I would drop in and put in the my 2 cents worth. First some background. Up until the last year I spent 17 years working in the maintenance department for an auto manufacturer.
The crew that I was in did a good deal of the programming for the devices on the floor, and in some cases that meant re designing equipment after
it was installed. I counted something close to 17 different PLC types that we had to deal with on the floor. That did not include any of the robots and a number of control systems. Previous to that I did computer system repair and worked in the broadcast business. For the last 8 years I have been running Linux on several machines.

That said, I can see a number of ways that Linux would be applicable to traditional plc applications.

I think that it is important that the old ladder logic interface be considered as at least part of the interface for those that have to trouble shoot the systems. That does not mean that I am particularly partial to any vendor's interface.

It seems to me that it should be possible to put together an interface that could allow the use of ladder logic with a web based interface. Beside that, It looks to me like embedded perl C and PHP could all be leading candidates for processes that require a fast response.

The question in my mind is how far do we want the average user / technician to have to go in order to debug applications? Most will not have the expertise or the time to debug complex source code
in a system on a production floor.

I have been lurking on the list for a few weeks. I may be able to contribute a bit from time to time. I look forward to seeing some results from the group. If there is any interest, I can think of a few projects that I think have a good bit of potential cost savings for industrial operations.

Dave
--
David R. Wilson
World Wide Network Services
Nashville, Tennessee USA
[email protected]

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

H

Harald Albrecht

> I think that it is important that the old ladder logic interface be
> considered as at least part of the interface for those that have to
> trouble shoot the systems. That does not mean that I am particularly
> partial to any vendor's interface.

For me as a lurker it is always interesting to see the "cultural" differences between North America and Europe, as well as between manufacturing and process industries. In the hope of not oversimplifying things and with a side-swipe, there's a big community which would surely buy the book "ladder diagrams considered harmful". Especially in european process industry you won't find that much LDs anymore, as controlling batches is a pain in the ass. While the function block technique is surely not the one-and-all solution and only really useful for signal-oriented processing and control, it has its merrits. However, I know that LD is very alive especially in North America and in the manufacturing industries around the world (so please do not flame me).

As previously mentioned on the list, please separate all the concerns. From what I've seen and as far as I understand (which is probably not very "far" at all), there's currently some cristalization kernel, the shared memory manager. It is the main "data store" for the process signal image.

Then there are several kinds of "user applications" using the smm.
First, the usual suspects, aka "drivers". They are responsible for communicating the signals to/from the process image to actuators and from sensors. Drivers for Profibus (sorry, I'm still a European), FF, WorldFIP, etc comes to mind. At the same time, the silent horror of engineering all those "drivers" and the mapping of
sensor/actuator data on the wires to places in the smm also comes to mind. The LinuxPLC surely will need quite some work in this place, otherwise it ends up as just another SoftPLC with an even larger bunch of drivers to engineer. While I personally enjoy hacking Linux and industrial DCS customers will definitely not

But back to track; other applications are software working on the signals, transforming input signals into output signals, watching for
alarms, distributing them, etc. This is where "modules" like a ladder diagram interpreter/compiler comes in. Or a structured text interpreter, or... These are all separate modules, thus separate projects around the central process image.

Thinking of distributed systems, communication with other systems, be it 3964, Profibus, TCP/IP-based protocols, will also be important modules, which need to be integrated into LD, ST, ...
interpreters.

> It seems to me that it should be possible to put together an interface
> that could allow the use of ladder logic with a web based interface.
> Beside that, It looks to me like embedded perl C and PHP could all
> be leading candidates for processes that require a fast response.

The Web is only a presentation layer. Please, first define the interfaces for the modules. E.g., how are LDs engineered, how do I add another sensor without getting nuts, etc... Only then comes the web presentation layer, with for instance PHP scripts using these interfaces to retrieve data and for engineering.

just my e0,02, even less worth than $.02. Harald -- Harald Albrecht Chair of Process Control Engineering RWTH Aachen University of Technology Turmstrasse 46, D-52064 Aachen, Germany Tel.: +49 241 80-7703, Fax: +49 241 8888-238 _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc D Dan Pierson Curt Wuollet <[email protected]> writes: > Hi Dan > > You're right, we don't hear from you often (enough) Thanks > "Dan L. Pierson" wrote: > > > Curt Wuollet <[email protected]> writes: > > > For size _and_ speed we use compiled C. For tools, GUI's and stuff not > in the main execution loop there are many options. Drivers and stuff that > operates in kernel space (realtime) is almost certainly going to be in C > or the kernel folks will ignore it. First, I agree that hand written kernel space code will be GCC (i.e. not just C). That's a Linux essential. What I don't agree with is the assumption that hand written C is always the winner in size _and_ speed. For example, older PC versions of a certain major word processor compiled less used portions of the code to p-code because the size of the p-code plus interpreter was enough less than the directly compiled C to be a win. In the real time context, I believe that a kernel mode byte code interpreter for compiled automation programs may be both practical and useful. It would also be highly controversial and might not be worth the development effort, but the idea intrigues me (if I/we ever did it, it would _definitely_ be a later stage effort). The goal would be to make it possible and acceptably safe for less expert people to write highly time critical code such as direct servo control. &lt;digression> The reason that a kernel mode byte code interpreter is realistic is that I'm talking about an interpreter for a highly structured and restricted automation language where the interpreter prevents the byte code from doing too many evil things. &lt;/digression> We agree that different constraints apply to tools, GUIs etc. > It's as much a style issue as a complexity issue. Things like > Hungarian Naming, obfusticated structure, code commenting and > documentation. Current commercial practice is for code to be hidden > away. We are writing code that is meant to be read, understood, and > shared. Look at my code and compare it to what's in the archive. I > write code this way because I have to explain it to people. And the > gcc output from obvious code is equal to or better than extremely > terse, dense code. I'll have to download and look at some of your code. Personally I detest Hungarian Naming, believe in readable (and frequently long) variable names and strict indentation conventions (which probably differ from yours ) and readable code structure. I should write more comments, but believe that the most valuable comments are ones that explain why the code is a certain way (e.g. what design decisions were made), not repeat what you can get by reading the code. IMHO, speed comes primarily from good algorithms, secondarily from well written code, and almost not at all from source level terseness and density. Write readable code with decent but understandable algorithms, then make it work, then profile it and optimize _where_ _necessary_ is my approach. >Portability beyond Linux/POSIX is simply not an > issue for me. Anything else except perhaps QNX or ***BSD will > unacceptably degrade reliability. We will probably never have all > the drivers we want for X86. I would rather have a highly optimized > design for one platform than a can of worms that "fits all". I am talking about processor portability, not OS portability. For the purpose of this discussion I am willing to believe that the LinuxPLC will never run on another OS (actually, it will be ported if it's successful, but that's the porter's problem). > We are competing against serious embedded people with dedicated > hardware and hand optimized code with critical portions written in > assembler. If it turns out too small and too fast, I'll be happy to > apologize :^) It is possible that critical portions of the LinuxPLC code will eventually be hand optimized in assembler. Not soon and almost certainly not by me, but it may well happen. This is what I mean by large portable C programs not being simple. When you start including the code structures necessary to support such portability (macros, conditional compilation, multiple levels of include files and architecture specific code directories, etc.) things cease being simple no matter what language you use. Look at the Linux kernel's use of assembler for a good example. Sometimes the tool set of a different language can make things simpler without significant efficiency loss. Sometimes. > I'm not picking on you, Dan, these are things I wanted to get out on > the table so people can understand my rationale. From some of the > comments, I know some people are looking at this from a PC only > perspective and as application coding. I think small footprint > hardware directly competing with PLC's is the bigger "market". Not > only are there more opportunities, there's no viable > competition...yet. There's some entrenched vendors with deep > pockets and Microsoft backing in the PC game. Wince is not a threat > in embedded. Being good in both markets is a good position to be > in. Actually, we at Control.com are interested in the complete range of controller sizes. One of the attractions of a Linux based set of projects is that it can potentially scale over a very wide range -- say from a small hardened device that reads a couple of IO points and reports them over a network through a high end controller for a fast and elaborate machine to a whole factory control network that ties into the IT mainframes for "real time" data reporting. This implies a wide range of supported hardware. I believe the very small embedded controller is an essential piece of the puzzle, it's just that there are many more pieces needed to make open control a success. By open I mean open both in the sense of the openness of PC hardware today vs. computers in the 1970s and in the sense of open source control software. Not feeling picked on at all , Dan Pierson _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc C Curt Wuollet "Dan L. Pierson" wrote: > <clip> > First, I agree that hand written kernel space code will be GCC > (i.e. not just C). That's a Linux essential. What I don't agree with > is the assumption that hand written C is always the winner in size > _and_ speed. For example, older PC versions of a certain major word > processor compiled less used portions of the code to p-code because > the size of the p-code plus interpreter was enough less than the > directly compiled C to be a win. In the real time context, I believe > that a kernel mode byte code interpreter for compiled automation > programs may be both practical and useful. It would also be > highly controversial and might not be worth the development effort, > but the idea intrigues me (if I/we ever did it, it would _definitely_ > be a later stage effort). The goal would be to make it possible and > acceptably safe for less expert people to write highly time critical > code such as direct servo control. Of the tools open to us right now I think C through the newer compilers would be hard to beat even with assembler unless a person paid a lot of attention to exactly which processor they were running on. I am intrigued by your p-code engine idea especially for realtime. It should be possible to know the cost of each code and schedule them in "packets" that would fit in the scheduler interval hmm..... I/O would be interesting. What would the interpreter buy you? > <digression> > The reason that a kernel mode byte code interpreter is realistic is > that I'm talking about an interpreter for a highly structured and > restricted automation language where the interpreter prevents the > byte code from doing too many evil things. > </digression> > > We agree that different constraints apply to tools, GUIs etc. > > > It's as much a style issue as a complexity issue. Things like > > Hungarian Naming, obfusticated structure, code commenting and > > documentation. Current commercial practice is for code to be hidden > > away. We are writing code that is meant to be read, understood, and > > shared. Look at my code and compare it to what's in the archive. I > > write code this way because I have to explain it to people. And the > > gcc output from obvious code is equal to or better than extremely > > terse, dense code. > > I'll have to download and look at some of your code. Personally I > detest Hungarian Naming, believe in readable (and frequently long) > variable names and strict indentation conventions (which probably > differ from yours ) and readable code structure. I should write > more comments, but believe that the most valuable comments are ones > that explain why the code is a certain way (e.g. what design decisions > were made), not repeat what you can get by reading the code. > > IMHO, speed comes primarily from good algorithms, secondarily from > well written code, and almost not at all from source level terseness > and density. Write readable code with decent but understandable > algorithms, then make it work, then profile it and optimize _where_ > _necessary_ is my approach. My point was, speed is a toss-up and up to the compiler. How you write your code makes a much larger difference to us poor humans. If it's very difficult for me to follow, it could be reasonably argued that a lot of other folks might have a problem and we're back to the cathedral. > > Portability beyond Linux/POSIX is simply not an > > issue for me. Anything else except perhaps QNX or ***BSD will > > unacceptably degrade reliability. We will probably never have all > > the drivers we want for X86. I would rather have a highly optimized > > design for one platform than a can of worms that "fits all". > > I am talking about processor portability, not OS portability. For the > purpose of this discussion I am willing to believe that the LinuxPLC > will never run on another OS (actually, it will be ported if it's > successful, but that's the porter's problem). > > We are competing against serious embedded people with dedicated > > hardware and hand optimized code with critical portions written in > > assembler. If it turns out too small and too fast, I'll be happy to > > apologize :^) > > It is possible that critical portions of the LinuxPLC code will > eventually be hand optimized in assembler. Not soon and almost > certainly not by me, but it may well happen. This is what I mean by > large portable C programs not being simple. When you start including > the code structures necessary to support such portability (macros, > conditional compilation, multiple levels of include files and > architecture specific code directories, etc.) things cease being > simple no matter what language you use. Look at the Linux kernel's > use of assembler for a good example. Sometimes the tool set of a > different language can make things simpler without significant > efficiency loss. Sometimes. We could do it all in Forth :^) I would hope that by paying attention to size and speed that we never get squeezed enough to resort to assembler > > I'm not picking on you, Dan, these are things I wanted to get out on > > the table so people can understand my rationale. From some of the > > comments, I know some people are looking at this from a PC only > > perspective and as application coding. I think small footprint > > hardware directly competing with PLC's is the bigger "market". Not > > only are there more opportunities, there's no viable > > competition...yet. There's some entrenched vendors with deep > > pockets and Microsoft backing in the PC game. Wince is not a threat > > in embedded. Being good in both markets is a good position to be > > in. > > Actually, we at Control.com are interested in the complete range of > controller sizes. One of the attractions of a Linux based set of > projects is that it can potentially scale over a very wide range -- > say from a small hardened device that reads a couple of IO points and > reports them over a network through a high end controller for a fast > and elaborate machine to a whole factory control network that ties > into the IT mainframes for "real time" data reporting. This implies a > wide range of supported hardware. I believe the very small embedded > controller is an essential piece of the puzzle, it's just that there > are many more pieces needed to make open control a success. By open I > mean open both in the sense of the openness of PC hardware today > vs. computers in the 1970s and in the sense of open source control > software. I don't disagree there at all except to say that 100 mips should be able to do a _lot_ of PLC work. With much more than that in one place the problem is IO bandwidth. You know my definition of open. > Not feeling picked on at all , Dan, I'm curious just what you guys have in mind (control,com) You throw in a couple of pearls from time to time, but I'm not seeing the string. cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc M Marc-olivier > For me as a lurker it is always interesting to see the "cultural" > differences between North America and Europe, as well as And don't forget the french touch with the GRAPHCET ! I use german program an french program and we see the difference : most of german develop in LST and use lot of BYTE or WORD for set a BIT. like L 16#01 T MB0 Terrible for the non programmer! (I remember you i'm not a C C++ programmer but i use LD, STL in siemens PLC, i know siemens BUS ) PuffinBUS for which application ? Most of actuals I/O interface use profibus dp,pa EIB and ASinterface, Modbus, device net, canbus, interbus ans some one use rs232. I don't see others bus in industrials I/O For communication between PLC/PC the profibus FMS are great and for PLC/PLC there FDL/FMS. > The Web is only a presentation layer. Please, first define the > interfaces for the modules. E.g., how are LDs engineered, how do I > add another sensor without getting nuts, etc... Only then comes > the web presentation layer, with for instance PHP scripts using > these interfaces to retrieve data and for engineering. Yes i agree soo much I hope i can help you a day ( but just with SIEMENS bus ) Best regard =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#= Marc-Olivier THOMAS Service automatisme et informatique industrielle ELEC API tel : 03.87.31.71.61 fax : 03.87.31.71.69 Email : [email protected] Site internet : http://www.etn.fr =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#= _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc D Dan L. Pierson Curt Wuollet <[email protected]> writes: > Dan, I'm curious just what you guys have in mind (control,com) You > throw in a couple of pearls from time to time, but I'm not seeing > the string OK. The following is either a commercial or spilling the beans. Please quit reading now if either offends you Actually we've been pretty open about the string We eventually intend to make much of our money selling and supporting open control hardware. That is, packaged systems made up of components from various vendors with a single source of support. Think of how you buy a PC today... We founded this company because we believe that we have a chance to help the automation community move from nearly total control by a small number of vendors to a more open, fertile marketplace that will do a much better job of satisfying the needs of automation implementors and users. Obviously, to sell open control hardware systems, we need software that can make them useful. We think that open source, Linux based software has a very important role to play here. We expect the automation community to tell us what type of systems and software they want us to provide. That's why we're as open as we can be about this plan. That's why the Open Control Lab will be open and ask the community what systems and components to test and how to test them. Our business success will be measured by how well we provide the products and services the open control community wants, not how well we brainwash you into buying what we chose to sell. Dan Pierson _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc H Harald Albrecht > > For me as a lurker it is always interesting to see the "cultural" > > differences between North America and Europe, as well as > And don't forget the french touch with the GRAPHCET ! > I use german program an french program and we see the difference : most of > german developpe in LST and use lot of BYTE or WORD for set a BIT. So much for putting my foot in it... how could I only forget to mention the french ;-) > like > L 16#01 > T MB0 > Terrible for the non programmer! > (I remember you i 'm not a C C++ programmer but i use LD, STL in siemens > PLC, i know siemens BUS ) Having been exposed to ST and PLCs too early in my life, I'm now a vivid fan of process control systems. But then, who cares. > PuffinBUS for which application ? Process industry. However, *all* fieldbusses in toto only have less than ten percent of the total sensor and actuator market for process industries. That's the situation, and it is radically different from the manufacturing industry. One reason is, that for instance flow meters, like magneto resistive or curioles cost$5000 and more, so the cost for the fieldbus bus coupler isn't that important. You don't want to use AS, CAN, or interbus for a beast like this. And such sensors are not simple bit senders, they emit a lot of information and have lots of parameters, for instance the zero point,
linearization, etc. And in the future they might even have archives, storing trend information for several minutes. Then, don't forget maintenance, where is much more one can do with "smart
sensors". Ade CAN, ade AS, ade interbus (my apologies to the really good guys at Phoenix Contact; I don't want to flame you). They all are not designed with acyclic communication in mind.

> Most of actuals I/O interface use profibus dp,pa EIB and ASinterface,
> Modbus, device net, canbus, interbus ans some one use rs232. I don't see
> others bus in industrials I/O
> For communication between PLC/PC the profibus FMS are great and for PLC/PLC
> there FDL/FMS.

New installations I've seen in process industry during the last years seem to settle on this design -- and these are not "those" 30 sensors installations, I'm talking about 3,000 up to 30,000, which are common for the process industry. The pattern is: Profibus from the control processors (roughly PLC's but with all the higher functionality like alarming, where PLC's are rather bad at) to the Remote I/Os. However, these Remote I/Os are still within the room where the DCS is located. From the Remote I/Os then to the field, using classical 4-20mA wireing with HART protocol on top.

If you search really hard, you can actually find a few installations with fieldbusses in the field. Remote I/Os, or better Intelligent I/Os,
seem to be the next wave. By intelligent I mean, that such beasts will run closed loops, do the alarming, archiving, etc. Cheaper than a traditional PLC, but much more versatile.

My unworthy e0.02

Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238

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

J

Jiri Baum

Curt Wuollet:
> The most significant remarks have been that the project has become too
> complex for the majority of people to follow and discouraged many who
> might otherwise contribute.
...
> The compromise informally proposed is that the CS guys write the "hard
> stuff" and provide comprehensible API's for the others to write to. This
> is certainly plausible under the circumstances. The main problem is that
> it has been and will be a while before it can be done. Many have lost
> interest in the meantime.

Actually, the basic comprehensible API'' has been available and basically stable since May-July (May is the date of my announcement, July is the date at the bottom of doc/smm/tutorial.txt).

There have been additions since then, some of which actually impacted on existing code, but they've been rare and in general we tried to go through the whole CVS tree and put them in ourselves. (This may not have been done with the synch library yet, but things will run without it.)

At times I/we have made various efforts to alert people to its existence, from the original announcement, files in doc/smm, to the recent post on "the plc_set() function", with varying levels of success

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

J

Jiri Baum

Harald Albrecht:
> From what I've seen and as far as I understand (which is probably not
> very "far" at all), there's currently some cristalization kernel, the
> shared memory manager. It is the main "data store" for the process signal
> image.

> Then there are several kinds of "user applications" using the smm.
> First, the usual suspects, aka "drivers".
...
> But back to track; other applications are software working on the
> signals, transforming input signals into output signals, watching for
> alarms, distributing them, etc.
...

Exactly.

> This is where "modules" like a ladder diagram interpreter/compiler comes
> in. Or a structured text interpreter, or... These are all separate
> modules, thus separate projects around the central process image.

Yup.

(The user can also write a program directly in C, if necessary, bypassing all the interpreters and things. For special applications.)

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

J

Jiri Baum

Hugh Jack:
> 3. I remember when I found the Puffin project in March, and 'lurked' (tm)
> for a few days. The idea of a Linux PLC was very attractive to me, and I
> wanted to help the project. I spent a week and put together the logic
> engine, and offered it to the group. The response I got made it easier
> for me to just continue it elsewhere.

Oops... (Though, as you see, it wasn't forgotten and when the time was right Mario went to pull it back in.)

> I have seen the same response to many others since then regarding topics
> such as Perl, Eiffel, OLE, Windows, Java, XML, IEC 61131, etc. The
> appropriate response in an open source project is 'why don't you try it',
> not 'I don't agree, but you can do it anyway'.

Hmm, in practical terms those two are probably closer together than they seem, but I see your point.

Basically all the posts you read are personal opinions; I don't agree' often translates as I don't have the time/enthusiasm to code that'.

Perl would be nice, but I've never coded a C-to-Perl interface before.
IEC 61131 is now in progress.

You posted once about a GUI front-end. I'm afraid I haven't got around to looking at it, but if you would port it it would be cool to actually have
something graphical, rather than just grand visions. Sticking working code in the CVS does wonders for consensus

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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