The Linux PLC Project

M

Michael Griffin

I am curious as to what the actual target for this project is. There has been some mention of an MMI system. Is this project primarily directed towards process industry applications, or what is it exactly? I think this is important to define precisely, otherwise different people will see what they want to see and you will end up with arguements as to what the original
objective was. Whatever it is, I don't think it can be all things to all people.
Maybe the first thing that should be done is a bit of "market research" to see what is that the potential contributors want out of it at
the end. Before discussion of this project dissappears off list, perhaps this could be defined more clearly.
I would also suggest that if discussion does eventually move to a separate forum, then this list should receive regular updates on
developments. This will help sustain interest from non-participants which may help later on in gaining acceptance of the finished system. It will also help in providing additional recruits to work on it later on as new people join this list and learn about this project.

There has been some mention in other letters about that this project would be nice because the end product would be "cheap". I think it would be a mistake to tout "cheapness" as one of the virtues. I don't think this project will be accepted in the market unless enough people can figure out how to make money out of it after it is done. They may not be able to charge for the actual software, but they need to be able to make a reasonable living out of installing, configuring, customising, commissioning, etc. This
is where the real cost of most complex systems is anyway. We should make sure we don't attach a "cheap" label to this system or we may create
unreasonable cost expectations or unjustified quality concerns among end customers.

A lot of people talk about the need for standards in this business. Its nice to see someone out to actually create a defacto open standard - because that's exactly what the end result would be.

**********************
Michael Griffin
London, Ont. Canada
[email protected]
 
Two thoughts:

1) The cost of the equipment is not the only cost. Controls engineers are not programmers and need tech support. A "free" product does not come with such support.

2) Just because a thing does not have a price tag does not mean it is free. This thread is contemplating many staff-years of effort to design, develop, and test a Linux PLC. Without support, a highly paid engineer will be required to get it compiled and running in any particular installation.
How many staff-days does it take to swamp the purchase price of a supported product?

It seems that the time is worth more than the money.
 
C

Curt Wuollet

Hi, All

Status on the project is as follows:

Ken Crater has graciously offered to set up a mailing list for the project and possibly a code repository. I have been asking folks to sit
tight until that happens. Best guess another week or so. To those who are anxious (and who isn't?:^)), I see no harm in using this list in the meantime. The first order of business is to define the interfaces necessary at this time. I am actually beginning to work on the Modbus/TCP scanner. I am getting paid to write part of this for my day job and am contributing the balance, with the express provision that it be GPL'd . I have done some research and have made some decisions on how that might be done. I wanted to get something out for people to look at before the holidays, but my I/O hasn't all arrived yet. I have outlined the approach I was taking, and haven't read any discussion on that. There has been a great deal of discussion on goals, features and the like and that's great. As far as specifics, here is what I've got so far. The actual memory structures have changed a couple of times already but as soon as I'm convinced and have confirmed them with the documentation, I'll post what I've got.

I/O will be modular with a shared memory pool (not shmxxx()) interface. The memory used will be outside the area under management by Linux. On a box with 16 mb of ram, we give the kernel 15 mb. We then have a 1mb. area that is readily accessable from both kernel space and user space. This way, loadable drivers, RTLinux and regular programs can access it with low overhead and no restrictions. For now, the drivers will do byte swapping, type translation, etc. to present data to the PLC process in consistant native types. Each "driver" will have it's own struct with members for digital inputs, digital output, analog input and analog output.. I envision the PLC starting a scan by altering a flag in the map. A daemon of some sort will notice the change and traverse a list of actions to read inputs belonging to the various drivers.into the map. Upon completion the daemon will set a flag to let the PLC know it can start solving. When the logic is solved, the PLC will write to the map, set a flag and the daemon will traverse a list of actions to set the outputs. The first driver, the Modbus/TCP driver, will be a user process as this allows easy use of sockets to communicate to the I/O. Later drivers for cards will probably be loadable device drivers as they will probably need to run in kernel space for dma and
interrupt access.

That's what I've figured out so far, none of it is cast in concrete yet. I'll get the structs I'm
using for the Modbus/TCP driver up as soon as I can. In the meantime let's think about the PLC process, How to handle user logic, online editing, and the like.
I'm all ears.

Curt Wuollet,
Wide Open Technologies.
 
Curt,
I hereby voluteer myself as a coder for this project. I can not manage much time but every little helps. I have been wanting to write a
SCADA for Linux for some time now and your project sounds great.


Dave West
E-Mail: [email protected]
Semiras Projects Ltd.
PGP public key available on request.
 
C

Curt Wuollet

Hi Dave,

Great! Watch this list for developments and we're working on getting a dedicated list together. I'm curious, what do you think the best tools/libraries would be
for HMI/SCADA development? Glade? Tcl/Tk? ncurses?

Regards

Curt Wuollet
 
OK, we want speed and stability above all others. In my experience these are both inversly proportional to the memory footprint so code size needs to be kept small. I see a group of C programs/modules communicating via sockets with simple text based protocols. For example almost all PLC's can be connected to a computer via a serial link. We write host programms to sit on the TTY and translate a standard set of text commands from a socket into the native PLC protocol and send it on to the PLC. For cards in the computer we do similar but we also write a driver to make the card look a little like a TTY. This way you generate a standard high level
communications protocol that can be tested using Telnet and all higher level programms can use.

Then we produce code to emulate a PLC runtime enviroment. It runs a compiled logic programme to control any remote I/O or I/O built into the
computer.

Then you come on to user interfaces for writing and compiling the logic programme. Some people will want to write ladder logic others will want to use something a little more verbose like a scripting language. For scripting languages there are plenty of text editors to generate the source and then all we need is a compiler to create the logic programme. For ladder and other visual representation we need some sort of graphical
display. Ncurses is portable and relatively nice on overhead but very soon people will want to display what is going on using "lamps" and change
machine operation using "buttons", this takes us into the world of GUI's such as X or Windows so ncurses becomes something of a waste of effort
except for, say a cheap HMI, but if you've got the computer you may as well have the pretty pictures (we can always drive some one elses cheap
HMI remotely).

For the pretty graphics we want a portable enviroment/language so we are into TCL/TK or one of the C librarys that allows cross platform
development for X or WIN. I think we should stick to TCL/TK as almost all of the libraries are for X/WIN but someone will want to use OS2 or Be or
something even stranger and it's more likely that someone will port Tcl/Tk than someone writing a library for all GUI's.

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, the ovehead is far too great. C++ is marvelous for re-using objects within a single programme. It's probably the perfect language for
a GUI that is to have lots of buttons or scroll bars or windows or whatever but is it portable, I think not (will a C++ prog for WIN run on X
without modification or an abstraction layer). As for the small "driver" programmes, what do they re-use different I/o cards, PLC's etc require
different data structures and procedures. The drivers will implement a subset of the total protocol so there is little if any reusability that is not better done using a simple C library.

I'm not saying we have to use any one language or tool set. Others from different backgrounds and experience may well have better ideas but please
remember that some of the best coders are poor and will not want to pay more than $20 for the tools to assist this project. Keep it cheap and
simple.

Just my 2p worth.

Dave West
E-Mail: [email protected]
Semiras Projects Ltd.
PGP public key available on request.
 
A

Anthony Kerstens

Why? Why not. Everybody needs a hobby of one sort or another. Some hobbies can actually turn out to become profitable ventures.

Anthony Kerstens P.Eng.
 
T
I'm willing to install and use and evaluate/troubleshoot such a LINUX PLC is one ever gets prototyped and ready for some real testing.

Ted Lechman
Rome Cable Corporation
Rome, New York 13440
(315) 335-8464
 
M

Michel A. Levesque

Hi all,

I've been following this thread and it seems to me that there are a few missing thoughts here:

1. If you want to do an HMI then do an HMI and keep the programming/control aspect out of this.
Keep both aspects (HMI and control) seperate from each other. This modularizes everything into nice manageable components.

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 ?

3. Keeping point 2 in mind, the communication cards needed to talk on these
various buses are from various manufacturers...would they be supported?
...what about updates? The solution here is NOT self-evident. We would need some input/support/contribution from various manufacturers. Or we fork out the bucks needed to buy a copy of these "open" specs and put our noses to the grinding wheel.

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. It's CSMA/CD architecture was never designed for control. It might work fine
now with relatively few I/O's but think of the future where we could potentially have 100k I/O and we would want these all on the same subnet...good luck.

5. As far as the GUI of the programming language...since we are starting fresh here, let's drop the ladder language. Anyone who has worked with function block programming can attest to its strengths...We can have very modular code for each block (actually anyone could make his/her own),
All we need is a universal parameter passing convention and each block is on it's own and may the better block win.

6. In the beginning of this diatribe I mentioned that the HMI should be separate. I would think that everyone would want to keep the HMI on a seperate machine altogether. Having the HMI on a seperate machine would allow us to use Ethernet for communication (versus using it for control of I/O).
This would again modularize the development effort. One could then implement server based HMI or standalone HMI. Again may the better system win.

All this thread has mentioned so far is the possibility of doing this project...I am all for it, but keep in mind that this will not be a bed of roses. Some serious work must be done here if this is to become viable. Never forget who this would be up against (Siemens, Rockwell, Mitsubishi, etc.). These boys will probably not take this project seriously in the beginning. But if they wake up, the project would become much more interesting very quickly.


Michel A. Levesque, ing.
Directeur Bureau Montreal
AIA Inc.
[email protected]
 
J

Jack Gallagher

I have a few questions on this subject:

1. Is there a defined list of people that wish to participate?
2. Is there a defined list of how each person would like to participate?
3. Do we have the scope of the project defined?
4. Is there a single person that is the lead for this project?
5. Am I asking too many questions too early?

********************************************
Jack Gallagher
SES CO Inc.
3 Vision Drive
Natick, MA 01760
Phone: (508) 650-9147
Fax: (508) 650-9310
e-mail: [email protected]
 
K
I'm not sure what is to be gained by this, given the wide variety of languages and libraries available. I use Perl/Tk quite a bit, mainly because I know Perl better than Tcl, but the end result is the same. Others might prefer Python
or C, REBOL or who knows what else (Visual BASIC for Linux??).

To me, the main consideration would be the interfaces presented by the plc or other components of a system. If the interface (i.e. a protocol) is adequately defined, then it doesn't matter what is used to connect to it; to some extent a simple telnet client might be useful to do some queries or commands. If something like
a Modbus interface is defined, then a Linux PLC could be usable from existing HMI systems without additional effort.

--
Ken Irving
Trident Software
[email protected]
 
S

Simon Martin

No problems in a GUI or OOUI front end, it is actually desirable. I can envision a few monitor windows open, a programming window, various processes running on the PLC. Just let the PLC machine run the PLC, let a GUI machine run the interfaces, keep them apart. I have done this and it works very well, even using a serial link. The production machine is kept as simple as possible. Perturbations to the system are kept to a minimum. The front end system can crash and burn, but production carries on. Use a double homed server and your home and away. All IO comms are kept away from monitor, etc. trafic. See it as 2 vital, but separate parts of the system. Whenever possible I try to apply the KISS principal, which usually turns out to be divide and conquer.

Rant mode off.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]
 
K
Mike Griffin brings up some important points about the project, which I think deserve exploration...

>I am curious as to what the actual target for this project is.<

Coming from the machine control (discrete manufacturing) sector, I bring that prejudice to the project. I would hope that the resultant code base be appropriate for discrete manufacturing projects, meaning a reasonable degree of performance and (dare I say <g>) determinism. I could certainly envision, though, a "Linux PLC" that could, with appropriate choice of hardware, be used in process, batch, and discrete sectors successfully, if not universally. It's a tool, and the flexibility of the tool will determine its breadth of application.

>I would also suggest that if discussion does eventually move to a separate forum, then this list should receive regular updates on developments.<

I agree wholeheartedly, and hope to link the effort closely to the existing Automation List community. One reason we are moving quickly to build a host site for the project is to maintain the connection with the user community. For the success of the project, I believe this is more important that a close connection with the "open source" community.

>I think it would be a mistake to tout "cheapness" as one of the virtues.<

Again I agree. What must be understood (and well communicated) are the risk factors involved -- in using proprietary systems! I was recently asked to comment on the project by an editor at ISA Online (yes, word is already spreading :). The resultant article may be seen at:
http://www.isa.org/journals/ic/news/1,1771,785,00.html

Regards to all,
Ken Crater, President
Control.com Inc.
[email protected]
 
Here's my three cents on this subject.

The key to success of this project or any other project of this magnitude is a good design. Remember Linux just didn't happen by someone writing a bunch of code, it was based on Unix, which was designed initially by grad students
at MIT and Bell Labs.

The success of large projects lay in their specification and design. I've been developing HMI products commercially for 8 years and programming since I was 12 (I have 20+ years programming experience :) I've seen how ugly
software can become when it is not well thought out. :(

My recommendations are

A) Develop a Specification saying what it is you are going to do. Is it PC-Control, HMI both, neither.

B) Design the interfaces between the components.

C) Build prototypes to test design strategies

(e.g. Shared memory is much faster than TCP/IP)

From a language perspective, I would not underestimate the usefullness of C++ for this project. Component interfaces (aka COM on Windows) are very important for producing modern modular plug-and-play components, such as a
generic device communications interface. Certainly if you are planning on building a modern HMI with a graphics display supporting rotation, scaling, etc - you'll end up reinventing C++ in C in order to get the job done. You need classes for rectangles, ellipses, lines, etc. You'll also reinvent virtual functions. At some point you'll want to draw an object on the screen, you'll either call the virtual draw method on the object (C++ solution) or switch on the type of object and call the appropriate C drawing routine. In this case C++ is faster than the switch code, simpler to
understand and much more maintainable.

BTW. I read on the newswire yesterday that VA Linux has signed up to host development projects such as this on there web-site. Apparently they have a bunch of tools in-place to help manage the distributed development.

Pete
 
K
Progress report from here (Control.com)...

1. There is a new domain name "LinuxPLC.org", which we're now waiting to propagate to the toplevel domain name servers. This will point to the host site for the project.

2. A site for the development community is being installed, using the services of Zope (an open source product). This will allow online playing
with code, commentary, etc.

3. We've established a maillist, linuxplc, which is set up using Mailman under Linux (yes, they're both open source products <grin>). This will
converge with the domain name tomorrow, and will then be ready for subscribers. We'll send out a message when it's ready.

4. Although perhaps premature, a CVS (source code repository) is in the works. We're basically waiting for something to put in it (hint).

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

Things are happening quickly!
Regards to all,
Ken Crater, President
Control.com Inc.
[email protected]
 
D
Sorry for not responding to your earlier post, I was on vacation for a couple of weeks.

> I/O will be modular with a shared memory pool (not shmxxx()) interface. The memory used will be outside the area under management by Linux. On a box with 16 mb of ram, we give the kernel 15 mb. We then have a 1mb. area that is readily accessable from both kernel space and user space. This way, loadable drivers, RTLinux and regular programs can access it with low overhead and no restrictions.<

This sounds like a good start. Proposals that avoid drivers and put everything in user processes are probably fine for some applications
but wouldn't meet time and determinism requirements of others.

>For now, the drivers will do byte swapping, type
translation, etc. to present data to the PLC process in consistant native types. Each "driver" will have it's own struct with members for digital inputs, digital output, analog input and analog output..<

It sounds like getting a minimal set of these structs defined is one of the most important first areas to agree (dare I say "standardize")
on. It would be bad if applications became unnecessarily driver dependent.

>I envision the PLC starting a scan by altering a
flag in the map. A daemon of some sort will notice the change and traverse a list of actions to read inputs belonging to the various
drivers.into the map. Upon completion the daemon will set a flag to let the PLC know it can start
solving. When the logic is solved, the PLC will write to the map, set a flag and the daemon will traverse a list of actions to set the outputs.<

This is the area that concerns me the most. I see a need to separate the low level application flow of control structure ("flow model" from now on) from the other primitives provided by the PLC.

<Digression on flow models -- feel free to skip :)>

A flow model is a vital attribute of application specific higher order languages. It is one of the primary reasons that programs in these
languages can be very simple *IF* they follow the flow model of the language. The downside, is that the complexity of the application program
increases very rapidly if it tries to deviate at all from the language's flow model.

RPG is a perfect, if ancient, example of a highly productive language with a very strong flow model. RLL is also a very pure flow model. Visual Basic is a modern language that gets many of it's strengths and weaknesses from a complex flow model (forms and events). Languages such as C and Java don't have a flow model, this gives them great flexibility at the cost of greater
size and complexity for programs that would have benefited from a flow model.

</Digression>

You seem to be coming from a traditional PLC viewpoint where the flow model is:

input scan -->
solve (RLL) logic -->
output scan -->
repeat

Other automation languages have different flow models. For example, Quickstep's is more like:

start step -->
set outputs -->
process instructions (may include):
I/O access
task execution (start and synchronize)
computation
motion control I/O
transfer to new step
-->
repeat process instructions (if didn't transfer to new step)

It would be good for this project to support multiple flow models. It would also be good to provide canned implementations of common flow models as building blocks for higher level language implementations. Some languages
would use these; RLL is probably a good example. Other languages would need to roll their own; Quickstep is definitely an example.

This means to me that the eventual API of this project wants to be layered. Here's a hand wave at a start:

<application code or language execution engine>
optional flow model
I/O access
drivers

I'm assuming that the API for each layer is in C because that's the Linux way. I'm also assuming that executing applications will eventually be
divided into two types:

1. Directly compiled applications written in C/C++/Fortran, etc.

2. Applications written in a specialized language that is handled by a runtime engine of some kind. It's convenient to think of this as a bytecode interpreter, but that's far from the limit of possibilities.

Note that specialized automation languages could be of either type. What matters in this message is the view from below.

>The first driver, the Modbus/TCP driver, will be a user process as this allows easy use of sockets to communicate to the I/O. Later drivers for cards will probably be loadable device drivers as they will probably need to run in kernel space for dma and interrupt access.<

Sounds good. From my viewpoint, it's important to get something running that people can start to play with and extend or try to replace with a
better idea.

> That's what I've figured out so far, none of it is cast in concrete yet. I'll get the structs I'm
using for the Modbus/TCP driver up as soon as I can. In the meantime let's think about the PLC process, How to handle user logic, online editing, and the like.<

Hope this helps somewhat. Please feel free to take potshots everyone!

Dan Pierson
Control.com
 
L
I think I'd expand this and say any "direct" window interface is bad & will end up being a source of kludges & quick fixes. I assume the PLC would go the way of a VB-style interpreter if we allow such simple access by windows. Plus we don't want to create a mammoth code set which defies simple understanding. The PLC should be a simple, closed system which allows effective performance prediction on a preformed psuedo-code program.

Better to have the PLC run blind and rely on something like Modbus/TCP to move data to the window task running as a more traditional HMI/OPS or IEC1131 programmer. If someone wants a "production machine" based HMI, no problem as TCP/IP happily allows a machine to talk to itself. Those who desire separate machines can have the same level of functionality by remote
Modbus/TCP access. As mentioned above, the HMI could them be any commercial tool also.

If users want some form of status output from the PLC, I'd just have it support telnet to create a view-only trace and/or status dumps. The user
should not be able to tweak registers or program code by it.
 
C

Curt Wuollet

That's exactly the whole point, the project is free for all, If you build a machine with it, you can still charge for that but, you must provide the source you got for free. Why would that be
a problem? Services are a much larger part of any project. I suggest you read the GNU Public License for details @www.gnu.org

Curt Wuollet
Wide Open Technologies
 
B
I don't think that anyone would expect to give away the systems that are developed using free software. The idea is that the operating environment and development tools should be free for anyone to use and/or modify.

There are certain issues with the GPL that come up, but anyone who uses free software should be educated as to what free software really means.

Bill Sturm
Applied Grinding Technologies
 
Top