The Linux PLC Project

Hello,

Michel A. Levesque, ing., wrote:
> 2. If you want to control machines then keep in mind that almost all plants have invested a great deal of money in I/O hardware. So I/O drivers would be a key issue. So which "open standard" will this project adhere to: DeviceNet ?, Modbus ?, Profibus ?, ControlNet?, Fieldbus ?<

Ideally all of the above, simultaneously on the one computer :)

In practice, whichever is easiest to implement first ("easiest" includes considerations such as whichever of them happen to be available/useful to the people doing the coding...), then the others as possible.

> 4. Some manufacturers are coming out with Ethernet I/O. The communication card is inexpensive, but I would NOT put my control system on Ethernet.<

Well, that's a bit out of the scope of the project. Put a warning in the docs is about all we can do about it. Maybe watch /proc/net/dev and warn if collisions become frequent (shocking as that sounds).

> 5. As far as the GUI of the programming language...since we are starting fresh here, let's drop the ladder language.<

Why? It can just be one of the options... if the base API is in C (it really has to be, anyway), then we can have any number of languages. If
(when) the project supports more than one kind of bus, we can even have a "grab these from bus A and show them to bus B like this" language...

Anyway, ladder language is very simple if you stick with the text version (LD X001 / AND X002 / ...). A couple of days back I wrote a simple
interpreter in an afternoon, just to see if it really was that easy... (I'll upload it if there's an exp(erimental) directory in the CVS.)

> 6. In the beginning of this diatribe I mentionned that the HMI should be seperate. I would think that everyone would want to keep the
HMI on a seperate machine altogether.

Yes, though that'd really be the implementer's decision, if it's done properly. The module should be designed to work either way.

(One of the usage modes should be as an HMI box, anyway, in which case you want the HMI module and the industrial bus interface on the same machine.)


Jiri
--
Jiri Baum <[email protected]>
 
M
Simon

I don't see where you differ. I agree entirely.

I already have most of the design for a virtual PLC, that I have been modelling for Java, a personal project only. This PLC is intended to have a very similar achitecture to the one you lay out (though I intend to communicate, atleast initially, with something a lot simpler than HTTP,
straight ASCII over TCP/IP (perhaps a simplified HTTP)).

Connection is via Sockets.

The PLC acts as a server, allowing multiple concurrent client connections via one or more TCP ports. The interface will allow for connection using simple text commands such as GET, SET, LOAD, RUN, QUIT, etc. and will allow for commands to be given or files to be download via a simple terminal (e.g. winterm or hyperterm), or even Telnet.

The PLC takes straight text files of a sub-set of IEC 1131-3 compliant Instruction List (IL).

I have no I/O driver methodology yet, and the first prototype will not support online editing, and maybe not function blocks (this last depends on the time available).

As I have said before, this is a project that I have been planning for a while; I am currently using it as a training project to learn UML and to
help me consolidate my Java knowledge prior to taking the Certification exam.

I will make the code available to any interested parties once I have something worth seeing (or atleast working).

Regards
Mark Hutton
Software Engineer
Vogal Software Services
Regent House, Welbeck Way, Peterborough. UK PE2 7WH
Tel: +44 (0)1733 370789 Fax: +44 (0)733 370701
[email protected]
 
K
New Maillist: [email protected]

The maillist is now set up, and you can subscribe via either of the following routes:

1. Go to the website http://linuxplc.org/mailman/listinfo/linuxplc and use the form there to subscribe.
-or-
2. Send email to [email protected] with the content of the message the single word "subscribe".

The web address may also be used to control your subscription options.

This is an unmoderated list, which should allow the discussion to move more quickly. I'm hoping that we'll move most of the discussion to the new list, so it can be divided into threads with their own subject lines. I think this will make it easier to make progress on individual topics relating to the project.

Ken Crater
Control.com Inc.
[email protected]
 
M
Not wanting to p**s on anyones fire, or to give the impression that I don't fully agree with the usefulness of this project, but I have a number of
comments re-open source.

Dave Geer wrote:
>> I don't quite understand this thread. Why re-invent this product when there are already commercial products that do this?<<

Jiri Baum replied:
>This has several advantages; here's four off the top of my head...<

>- No single-supplier lock-in: with a commercial package, if you want a new feature or a bug-fix you have to wait for the supplier to provide it. If you have the source code, and the right to change it, anyone can do it.<

In most cases I have enough problems with the application code, of each project without having to get in and hack or even tweak system code. If
I had to do this, at all, I would shortly become unprofitable to my employers and would be seeking employment elsewhere.

The 'cost' of the software itself only becomes an issue if commercial and open source products have like for like stability and reliability.

>- Quality: open-source software tends to be high-quality.<

Come on now. There are thousands, perhaps hundreds of thousands of crap open source programs out there. Open source does not necessarily lend itself to quality, any more than a poorly run commercial development does.

>- Philosophy: some people believe that commercial licences are unethical. Also known as the RMS argument(**). <

That doesn't necessarily mean that the open source licences are the natural replacement. Hell, why have a GPL, why not have no license at all.


Another point:

It is well accepted amongst the Linux community that Linux is an Experts product, it is for people who like and have the time to, play with a system and find out how it works.

Linux is becoming more user friendly, or should I say beginner friendly, as new administration tools and wizards are added. Most of these are based on commercial tools available for other OS's, and many are due to the involvement of commercial organisations in the Linux project (Red Hat, Corel, Caldera). Because these items are added by enthusiasts, many in their spare time initial development was slow, much slower than is possible for a commercial house to move.

Linux development is moving rapidly now because, in the last eight or ten years it has picked up many thousands of enthusiasts and has the now
achieved a phenominal momentum, one that the commercial houses (even Microsoft ?) cannot hope to match.

This little project will have to start from a stand still, and it could take an extremely long time to become practical. This is not to say that we shouldn't make the attempt, I am entusiastic about the project. It will be useful, even if only from the learning perspective.

A final note:
I haven't seen any reference yet to the existing relevant Linux projects e.g. Linux Lab, which is an existing project to provide 'data aquisition and process control'. I don't have the references with me, so I will post them later.

Good Hunting! Happy New Millenium!

Regards
Mark Hutton
Software Engineer
Vogal Software Services
Regent House, Welbeck Way, Peterborough. UK PE2 7WH
Tel: +44 (0)1733 370789 Fax: +44 (0)733 370701
[email protected]
 
B

Brian T. Smith

Ken:

Happy New Year and good luck with the Linux PLC Project.

Yes I would think there is a need to define a set of hardware reference platforms.
This would help reduce the project workload and hopefully ensure success by selecting hardware with good potential that is also considered standard in the industry. It was suggested in an earlier post that a specification should be created for this activity. This is a good suggestion for the same reasons I mention above. A general spec may be all that is needed. A detailed spec may be too difficult and cause unnecessary delays in getting the project going (I sense an enthusiasm that should not be dampened by documentation).

You may consider including the short term and long term specifications and intended hardware reference platforms. That could show where the project could go beyond the initial testing and relieve any concerns about hardware that is not initially listed for testing.


Brian T. Smith, CET, email: [email protected]
Nova Chemicals(Canada)Ltd., Sarnia, ON. Canada.
(519)332-1212 x7920, Fax:(519)339-7301.
Opinions expressed are those of the author and not necessarily those of NOVA
Chemicals.
Personal home page: http://www.xcelco.on.ca/~btsmith/
 
G
>... I see a group of C programs/modules...

>... Notice throughout this I have not mentioned C++. No doubt I will flamed to a crisp for heresey but it is my oppinion that C++ has no place in this project...

I don't want to feed a flame war either but I have one feeling about the C vs C++ discussion.

A small subset of the arguments that came up during the Gnome vs KDE wars that have occured in the last year centered around the C vs C++ problem. Gnome and GTK use C for all APIs and KDE uses C++. This means that all KDE applications must be written in C++, you can't chose your favorite language.

The reason the Gnome and GTK folks chose C over C++ is it's ability to provide a frame work for many other languages. Therefore Gnome and GTK have bindings for many languages.

If we force our interfaces to be in C++, then we force all application developers that interface with our platform components to use C++.

That's just food for thought, I really have no opinion, since I know either language...
 
R

Ranjan Acharya

Sorry to be cheeky, but does Redhat actually make any money?

> Look what happens to Linux, the product itself is free, but it is still quite possible to make money out of it. Look at, for example redhat, they make money in exactly this way - the product is good and free, but people need help initially and are willing to pay for it. They also know
that if the help they get isn't good enough they can get the help from someone else - still about the same product.<

In lieu of any alternative Linux is certainly the best choice of OS. However the proposed system must follow standards such as ISO 860.1 and EN
6-1131.3 / IEC 1131.3 in both action and spirit.

I absolutely agree with other postings that the actual real-time production machine (PLC) must not contain any rubbish such as the HMI and especially SCADA. The pressure from the cost-cutting side of any project is tremendous
especially if they think that they can get away with putting the MMI/HMI and PLC functionality all in one box. HOWEVER, that being said, for really small machines the HMI and PLC should be able to reside in one box. I currently work for a Systems Integrator where the one-box solution is not looked upon with any affection, but I used to work for an OEM and the cost pressures on an OEM are tremendous. A small machine does not necessarily require two boxes (granted you can go to people such as ZWorld or IEE for a small display [or even use push-buttons if no displays of statistics and animation are required]).

The thoughts of sharing one box also always brings up the issue of keeping control and factory-floor / plant / works intranets on separate buses. I have seen instances of some control (not I/O but intra-PLC communications)
being placed on the same Ethernet as the one used in the front office, luckily switches are being used.

RJ

Ranjan Acharya 905-634-0844 x 238 (V)
Team Leader - Systems Group 905-634-9548 (F)
Grantek Control Systems http://www.grantek.com/
[email protected]
[email protected]
 
A

Anthony Kerstens

It makes sense to focus on one platform first for the sake of orderly development. I don't think Linux started out with the complete gamut of
video cards :).

On the other hand, unlike video cards, there is no lowest common denominator that all I/O systems could communicate with. For example, all PC video cards that I know of support 80x25 text mode. All newer video cards also support 640x480 graphics.

A line will have to be drawn, and in all likelihood it will be something new and on the cutting edge.

Anthony Kerstens P.Eng.
 
M
>5. A discussion is under way with our Intellectual Property counsel about licensing approaches. There are some real issues here, that require real legal advice. For instance, the standard GPL might (*might*) be interpreted
as requiring user programs (i.e., the program for running your machinery) to be given away. Obviously, this is not the intent, and would inhibit the use of the system. We'll need a license which insures free distribution of the
controller code, but provides the user community with the necessary assurances to support its use. There's a lot of discussion about such
issues on the net, but legal advice obtained on the net is worth about what you pay for it <grin>.<


This is like saying that because you give away the JVM (yes, I know it is not necessarily GPL'd (but what about the Linux one?)), you must give away the Java written to run on it.

Define the product. In this case the product is the virtual machine (PLC), not the code that runs on it.

Point taken however.
 
Jiri Baum:
> >- No single-supplier lock-in: with a commercial package, if you want a
> >new feature or a bug-fix you have to wait for the supplier to provide
> >it. If you have the source code, and the right to change it, anyone can
> >do it.

Mark Hutton:
> In most cases I have enough problems with the application code, of each
> project without having to get in and hack or even tweak system code.

Oops, my bad.

I didn't intend to imply that mucking around inside the PLC code would be the standard modus operandi, just as it isn't in the closed-software case. But there are two advantages of being able to: 1) you can, if there's a show-stopper bug, and 2) any number of companies can offer support and you can shop around for price/quality.

> Another point:

> It is well accepted amongst the Linux community that Linux is an Experts
> product, it is for people who like and have the time to, play with a
> system and find out how it works.

Hmm, if you have a non-expert automating your plant, there's your first problem.

Sorry to sound so elitist, but if people don't understand the capabilities and limitations of the systems they are using - whether open or closed - it can only lead to mistakes and bugs.

Then again, even NASA gets bitten by priority inversion...

> A final note:
> I haven't seen any reference yet to the existing relevant Linux projects
> e.g. Linux Lab, which is an existing project to provide 'data aquisition and
> process control'. I don't have the references with me, so I will post them
> later.

http://www.llp.fu-berlin.de/

The GNU Scientific Library also looks interesting.
http://sourceware.cygnus.com/gsl


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...
 
M
I agree entirely, and have been advocating good project management since I began posting.

This is (as far as I know) the first (positive) post in agreement.

I also agree entirely with your comments about C++. Object Orientation has a lot to offer this project.

Back (a long time ago) when I used to do a bit of C, I used to spend a lot of my time creating C++ functionality (unknowingly at the time).

I still haven't given up on Java, despite the potential performance issues, especially not for prototyping. A new realtime Java specification was issued recently, if any one is interested I'll hunt out the link for that.
 
M
As promised here are a few (existing) Linux resources that you may find useful/interesting, that relate to this project.

First the Linux Lab project. This project has drivers for PC I/O cards, Siemens and Schnieder comms. plus lots of other goodies.

http://www.llp.fu-berlin.de

The following are three (competing?) real time Linux projects.

KURT (KU Real Time project) http://hegel.ittc.ukans.edu/projects/kurt/
RTLinux http://luz.cs.nmt.edu/~rtlinux/
REDLinux http://ece.uci.edu

The following link is to the LesTif project which is a small fast Motif implementation (HMI?)

http://www.lesstif.org

The final link I have is for a project developing IEEE1394 drivers for Linux.

http://www.edu.uni-ku.ac.at/~epiker/ieee1394.html


I haven't visited all of these sites, I found them and others at
http://www.linux.org/projects/software


Regards
Mark Hutton
Software Engineer
Vogal Software Services
Regent House, Welbeck Way, Peterborough. UK PE2 7WH
Tel: +44 (0)1733 370789 Fax: +44 (0)733 370701
[email protected]
 
R

Ralph Mackiewicz

> 5. A discussion is under way with our Intellectual Property counsel about licensing approaches. There are some real issues here, that require real legal advice. For instance, the standard GPL might (*might*) be interpreted as requiring user programs (i.e., the program for running your machinery) to be given away. Obviously, this is not the intent, and would inhibit the use of the system. We'll need a license which insures free distribution of the controller code, but provides the user community with the necessary assurances to support its use.<

Why wouldn't this be the intent? Why is it important for the system software to be "free" (as defined by the Free Software Foundation)
but user programs need proprietary protections? What's the difference between someone developing a driver or other utility/enhancement to the Linux PLC (which would supposedly by implication be required to be licensed under GPL) and someone developing a control program to run a process? They both will supposedly make use of LinuxPLC APIs.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
S
>It seems to me like the project could have a number of separate scopes (in no particular order):
>
> 3a. a Linux PLC, with I/O and executable application programming
> 3b. a Linux MMI (or multiple) to interface the Linux (and other) PLCs
> 3c. a PLC server, to present a common interface to different (existing) PLCs
> 3d. a gateway, to interface different (existing) fieldbusses to a common protocol
> 3e. ?
>

You left out the PLC programing software peice of the puzzle, both for the LinuxPLC, and for existing PLC's. There is absolutely no reason I should have to retain a windoze partition just to run PLC programing software.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
 
L

Lynn August Linse

What about this as a general framework:

I. Control Code - create a "sharable" memory space for the control code. Those who want it to run blind will lose a bit of performance but those who want a RT window open to allow on-line editing of logic can do so. If the code can be formatted as lists of lists, then different blocks of code can be flagged as requiring different processors - ladder logic ... Ok, SFC ..
Ok, Forth ... Ok, Fortran ... Ok, etc. This is a user driven tool and if we retain a 32-bit tag, we could end up with millions of unique control
processors. Maybe some PhD student will create a killer auto-tuning PID processor! Those who don't want on-line editing/HMI can use an FTP tool
someone writes which just rewrites the entire code space, or a Modbus/TCP server which addresses this code memory as extended registers, or as a MMS VD. All it takes is some one to code it

II. Control Data - create a 2nd "shareable" memory space for general control scratch memory. Access to this memory must be sensitive to possible timing coordination with the running code. Perhaps this code is also wrapped as lists of nested lists and access to any sub-section is controlled by some form of header. Some code-processors will want a "update-date, run-code"
cycle; others will not care. Drivers pulling in data for the controller & the various control processors would use this memory.

III. Global scratch data - create an optional 3rd "shareable" memory for general access by remote hosts. The control code should explicitly do block
copies to move data between Control data and Global data, but access to the global data has NO relation to the control operation. This space could also be used for sharing data between remote hosts/protocols. As I mentioned before, allowing this space to be used to coordinate between Siemens, Modicon, Allen-Bradley, GE and other proprietary TCP/IP protocols could be a
big "value-added" to our work.

Really, there is NO reason to pick "one" protocol or "one" HMI method or "one" programming design.

If Curt wants to code Modbus/TCP and Bill wants to code MSS and X chooses ControlNet/CIP and Y chooses FF-HSE, then we all gain more options.

If A wants a RT/on-line interactive programming window, let A code it

If B wants ladder and C wants Flow blocks, let them all code each as each see fit.

We just need to create the wrappers & structure which allow these tools to interoperate - or at least be swappable. We are not making a "Control Tool for Dummies" here. As others have mentioned, I see the largest application being 1) VAR machine makers who tweak the code into an embedded tool, 2) students who can use it to test new control theories, and 3) Custom integrators who specialize in very detailed, niche market systems.

Best Regards;

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected] www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132
 
I'd take a look at using XML. The OPC Foundation is defining XML data types to layer on top of the OPC Data Access specification. This protocol is
internet ready and will end up being supported by most commercial HMI vendors.

Pete
 
Java is an interesting solution for PC based Control and should not be ruled out. An approach I've seen by commercial PC based control vendors is to compile the ladder diagrams, SFC's etc into Jave Byte Code. The byte code can then be executed on any target that has a JVM. This gives greater cross-platform portability to NT, CE, JINI and other to be determined platforms.

Compilation of the ladder diagrams to at least byte code is needed for performance. Interpreters are generally slow. The byte code could probably be further optimized by one of the tools that creates native java (e.g. platform specific machine code.) However, the task of creating efficient, reliable compilers is not a job for the faint of heart.

The way I see it the PLC project really has several components:

1) Langauge Editors (sfc,ladder, etc), can be added as needed
2) Language to Neutral Form converter - converts the language specific description to a neutral form.
3) Neutral Form to Target converter - coverts the neutral form to target (Exe, Java Byte Code, etc)
4) Target Execution Enviroment (for exe, JBC, etc)
5) Device specific interface modules for execution environment.

Pete
 
M
I also still believe that the widest possible range of protocols, both standard, open and proprietry should (eventually) be supported or
supportable.

I am forever telling suppliers that until their product supports the protocol that my customers have installed in their factories, I cannot
support that product.

The project not only needs interfaces to commercially produced hardware, it also needs interfaces to commercially written drivers and application software.

Of course we don't want to run, before we can walk; Modbus/TCP is an ideal starting point.
 
D
> Jiri Baum:
> I didn't intend to imply that mucking around inside the PLC code would be the standard modus operandi, just as it isn't in the closed-software case. But there are two advantages of being able to: 1) you can, if there's a show-stopper bug,
and 2) any number of companies can offer support and you can shop around for price/quality.<

I'll offer a third advantage. On the office side of our network, we run a custom document management database. We have the source code for software interface, so I can make changes if I have the time and desire. This comes in handy for the non-show-stopper annoyances that can be fixed quickly with a phone call to our consultant, who can talk me through line-by-line edits to the code. Small "upgrades" and bug fixes can be designed, tested and implemented in a
matter of days (with only a few minutes of my time), which tends to make everyone happy.

By the way, I think this requires a good relationship between the customer (me) and the consultant that writes the code, and I think that the open source code facilitates this relationship. We communicate monthly, if not weekly, about system performance and future upgrades. Because of the frequent communication,
my consultant becomes increasingly familiar with our system, service improves, and the relationship grows.

- David
 
> Java is an interesting solution for PC based Control and should not be ruled out. An approach I've seen by commercial PC based control vendors is to compile the ladder diagrams, SFC's etc into Jave Byte Code. The byte code can then be executed on any target that has a JVM. This gives greater cross-platform portability to NT, CE, JINI and other to be determined platforms.<

By all means pursue this.

You are welcome to contribute Java code to the LinuxPLC. It won't likely be considered for the core, but others may find it useful. There is also the possibility of using Java as an intelligent way to allow web access to the
LinuxPLC - kind of an intermediary.

Best Regards
- Lynn Linse
 
Top