The Linux PLC Project

C

Thread Starter

Curt Wuollet

Hi All

We have seen another attempt at standardization derailed by proprietary interests on the fieldbus front, I have several types of automation equipment, none of which will interoperate, and the various "Open" initiatives all involve Microsoft and Microsoft only. The major vendors
seem to go out of their way to prevent interoperability and the market is years behind the state of the art , because the state of the art is "Customer Driven".

What this industry needs is a truly open alternative, designed with open architecture, open protocols and "what is good for the customer" in mind. From the research I have done, all the pieces are in place to build a solution for the community, controlled by the community and owned by the community. I am seeking volunteers who are interested in giving some of their expertise and talent to make this possible. Worst case, it would be a great free educational package to teach Automation basics. How good it could become is virtually unlimited.

It goes without saying that everyone, whether they contribute or not would have access to the result. I'm sure there is enough talent reading
these words to build an excellent system or suite of products.

Here's an outline on how it could be done:

The system would be PC based and aimed at generic hardware. The Operating System would be Linux. If real time performance becomes necessary, it would incorporate either the RTLinux system or the KURT
system for hard or soft realtime respectively. The I/O would be either PCI I/O cards or MODBUS/TCP for remote I/O. The reference software
implementation would be a state language or possibly ladder logic PLC with SCADA, HMI, etc., etc. added as people want them. The first
pieces to be coded would be modules that map I/O to a common shared memory map. This would abstract the differences between remote and
attached I/O allowing a PLC to be built that will work with new modules interchangebly. It will be coded in C for speed and to expand the programmer pool.

Q&A

Why?: Because we can. The comments I have read on the list indicate a desire to do things better. Call it a hobby, Make a tool you can give to your local high school. Because it'd be fun.

Why Linux: It's free, all the tools are there and they're free. And the huge amount of stuff that comes with it would save a lot of reinventing wheels. And there are no license fees or royalties. And most, important, the
GPL would keep it open and free to all.

Why Modbus/TCP: It works on commodity ethernet hardware and the spec and example code are free. It is supported by at least two I/O systems,
Opto22 and Modicon Momentum with bridges to others. TCP/IP will take over eventually. It's truly open,cheap, fast, and already there.

What is needed:

I have committed to doing the I/O and PLC myself. I will gladly accept help on any of it or give parts to others to do. Whatever you're
interested in doing is welcome. I am not a professional coder so, the best code wins. Code and ideas are welcome. Someone with disk space
and bandwidth would be helpful as I live in a rural area and can't get a fast connection. Someone with experience in Flex and Bison to help or code. I/O hardware is needed now (Opto 22 EIEIO, or Modicon Momentum with an Ethernet adapter.). All are welcome to contribute.


Curt Wuollet, Owner, Wide Open Technologies.
 
K
> Curt Wuollet said...
>What this industry needs is a truly open alternative, designed with
>open architecture, open protocols and "what is good for the customer" in
>mind.

YES! Control.com would be glad to provide the venue and discussion
resources to carry on such a project. The model is already there in the
Open Source community. If there's interest, we'd set up the necessary
discussion group(s), FTP area, bug tracking and CVS source control area.

Anyone else interested in pursuing such a project??

Regards,
Ken Crater, President
Control.com Inc.
[email protected]
 
K
I'm interested, but I don't understand what the scope of the project
is, e.g., a PLC running Linux, using Linux to interface to PLCs, an
HMI running on Linux, etc.

I've done some work toward a "PLC server" running on Linux, with the
goal of providing an interface to different types of controllers, and
can connect, logon, and do simple queries to a (very) small number of
them. The technical problems are not great, but I can see the need for
a specified protocol to really make such a thing work.

--
Ken Irving
Trident Software
[email protected]
 
L
I think that would be ideal - especially if it can start including diverse protocol drivers.

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
 
R

Ranjan Acharya

What about keeping the initiative in line with the original concepts for IEC 61131-3 -- SFCs, Function Blocks, Statement Language, Instruction List, Ladder Logic and so on.

You could start with just the SFCs (allowing embedded statement language and ladder for example) and then add other 1131-3 elements such as function blocks. Perhaps stuff currently outside 1131-3 such as flowcharts could be
added at a later date too (a great list topic -- SFCs versus flowcharts!).

This would also be a GREAT teaching tool a "Pascal" of PLC programming keeping to all the rules and also not being proprietary.

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]
 
Greetings,
I will throw this into the mix.
You may have heard of Apyx. Developed by MicroCraft. Anyway to make a long story short. Right now it is gathering dust. Just too small to get it to market after customer was bought out.

The software does work. I will get the site back up soon so you can take a look.
The kernel is fairly pure C++ which should port reasonably to Linux but right now on Windows NT.
The Front End is MFC. The hooks are in place to work with most HMI.
Has a Visual C development environment with a Visual Basic like scripting language.
It has all the IO goodies: Discrete, Analog, Motion, etc.
Opto 22, DeviceNet, MEI, Galil ...
Should be able to add PLC easily.

More bucks invested than I want to admit but am trying to figure out something to do with it. Try to sell it? Open source? Ideas, concepts, buyers, investors, partners welcome. How does this fit with what you are looking into?

RB Taylor, President
MicroCraft
 
L
By the way, win-tech.com's ModSim32 is a dynamite little Modbus/TCP slave simulator, and ModScan32 is a dynamite little Modbus/TCP master
simulator. They allow you to do a lot of easy testing without real hardware.

Not to steal win-tech's bread, but I'd suggest creating similar X-Windows tools is another great Open Source project. Maybe someone at win-tech would be willing to port their tools over in exchange for having their company name there & promoting sales of their related products. If this Linux PLC succeeds such tools will exist as well.

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
 
S

Simon Martin

Sounds interesting Ken,

I might be interested. I currently develop software on a few Unix flavours (Linux included), Win32, and proprietary hardware. Most of my expertise is in the Motion Control area, so I don't know how useful I'd be. I'd also have to look at the overall design objectives and see how interesting I find it.

Long live GLP, FSF, etc.

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

Murry Shohat

Dear Curt --

Speaking on behalf of the emerging Embedded Linux forum, which is covered in some detail at http://www.linuxdevices.com/, we would be pleased to collaborate with you for the goals you've articulated. Let me suggest you contact Rick Lehrbaum using the "Contact Us" button at the web site.

Murry Shohat
 
J

John Margaglione

Sounds like an interesting idea. I've been working under Linux for a little over a year now, and it is a stable and versatile platform. But how can we truly writen "open" software to one OS? Isn't that just as bad as writing Windows-only software? Perhaps there is a way to code this beast using truly cross-platform methods. I know Java is slow on the user interface, but it is
plenty fast for the types of things we are talking about here. It is also far easier to program than C. I did a little prototype of a soft-plc memory system using Java and CORBA a while back. I don't remember any performance
characteristics, but I didn't really optimize for speed anyway. It was pretty fast, though. If speed is really a major issue, perhaps coding of the base libraries could be done in C and provide Java wrappers to make non-speed critical processes a little easier.

Anyway, before I analyze this thing to death, do you have any requirements, design specs, etc.? I would be happy to help in the coding of any part,
assuming that I have relevant coding experience for the particular piece. Right now I am concentrating on web development, but I have 8 years' experience coding in C/C++/Java/Pascal/databases/what-have-you.

Let's talk.

John Margaglione
Senior Software Engineer
Omron STG
[email protected]
 
C
Hi Ken etal.

Good question, I guess in being concise I glossed over that. The project could cover all of those. What I would ultimately like to have is like the typical PC control product only 100% open. It
would have an integrated PLC with HMI and some SCADA. I would like it to handle both local and remote I/O. The remote I/O would most logically be done with Ethernet using ModbusTCP. It would
support programming in IEC 1131 languages. Due to the excellent connectivity inherent in Linux it would communicate with almost any manufacturing host system for statistical control and reporting. There are no technical barriers for any of this with Linux. The building blocks are there. In fact, this would be easier with Linux than any platform I could think of due to the existing feature set.

How close we can come to that is determined by how many volunteers we have and how much time. The first step, which I am doing for my day job anyway, is the I/O subsystem. I intend to write
a Modbus scanner that will communicate with Ethernet I/O and map it to a shared memory structure. Digital I/O will map to structure elements, "Registers" much like a PLC. Next would be a scanner to map PCI I/O in an identical fashion for consistancy. That way the PLC process would simply attach to the shared memory and read and write to these "registers". Once this is
established, someone needs to work out a PLC process to read input "registers" , interpret user logic, and write to output "registers",
hopefully at a high rate of speed. After this works with test logic, we need programming tools to parse, tokenize and translate user statements into a logic list to be executed between input and
output scans. No magic, that's what a PLC does.

At this point we would have a usable "soft PLC". Any number of add ons would come next. HMI in say, Python or Java, additional field busses, SCADA, IEC languages, anything that someone wants
to add. If you want it and can do it, Go for it! That's what it is about. If you have an idea, here's a vehicle to test it on. I can't do this
alone in a reasonable amount of time but, several C people with PLC experience could certainly have something running by summer. And anyone with a spare PC could use it.

Hope this clears it up.

Regards,

cww
 
M
---- the state of the art , because the state of the art
is "Customer Driven".------

Most customers don't give a damn if the solution is state of the art, they are only concerned with reliability, availability and profitability.
Maintainability improves availability. Most state of the art solutions are 'Developer Driven', because the engineer wants to do what is interesting and what is new is interesting.


-----From the research I have done, all the pieces are in place to build a solution for the community, controlled by the community and owned by the community. I am seeking volunteers who are interested in giving some of their expertise and talent to make this possible. Worst case, it would be a great free educational package to teach Automation basics. How good it could become is virtually unlimited.-----

Good idea, in fact, I'd been thinking along the same lines, though I would probably never have had the guts to initiate this. I have also been
interested in the idea of community collaboration, distributed project management, virtual companies/project teams. Basically, how do engineers come together on the internet to create project teams for specific projects?


---The system would be PC based and aimed at generic hardware. The Operating System would be Linux.---

Can it be truly open if it is limited to a PC/Linux paltform?


---The reference software implementation would be a state language or possibly ladder logic PLC
with SCADA, HMI, etc., etc. added as people want them. ---

Any open PLC should be based on the ideas of PLCOpen and the IEC 1131 standard. Additional, languages and features should be added around a
standard core. If this is not done we would be just setting our selves up as a competing standard, that's if we could agree amongst ourselves.

--- The first pieces to be coded would be modules that map I/O to a common shared memory map. This would abstract the differences between remote and attached I/O allowing a PLC to be built that will work with new modules
interchangebly. It will be coded in C for speed and to expand the programmer pool.---

This calls for an object oriented approach. C++ would be the better language to choose, but it is worth considering Java also. Despite its apparent lack of speed, a Java based core system could be devised that wasn't based on a particular platform (PC/Linux). Java also has other, emerging technologies which would facilite this kind of a project, and leverage the kind of links
to existing enterprised software that would be required (JavaBeans, InfoBus, Jini,JDBC etc.).

As with all software development coding should be left until later on in the project. We need a clear specification (what do we want the system(s) to do, how will it all interface, what is the architecture) and project plan (how will contributors interact, how will the work be integrated), we have to be sure that everybody is using the same sized Lego.


----Why Linux: It's free, all the tools are there and they're free. And the huge amount of stuff that comes with it would save a lot of reinventing wheels. And there are no license fees or royalties. And most, important, the
GPL would keep it open and free to all. ---

I definitely agree that Linux should be used as the development platform and that the GPL would be required.

---Why Modbus/TCP: It works on commodity ethernet hardware and the spec and example code are free. It is supported by at least two I/O systems, Opto22 and Modicon Momentum with bridges to others. TCP/IP will take over eventually. It's truly open,cheap, fast, and already there.---

Agreed, but why limit our selves. DF1 would be very easy to implement, Hostlink (Omron) is also very simple. DeviceNet, FIP and Profibus would have to be done also. Why? Because not doing so limits interoperability.

----I have committed to doing the I/O and PLC myself. I will gladly accept help on any of it or give parts to others to do. Whatever you're
interested in doing is welcome. I am not a professional coder so, the best code wins. Code and ideas are welcome. Someone with disk space
and bandwidth would be helpful as I live in a rural area and can't get a fast connection. Someone with experience in Flex and Bison to help or code. I/O hardware is needed now (Opto 22 EIEIO, or Modicon Momentum with an Ethernet adapter.). All are welcome to contribute.---

'nuff said.
 
C
Hi Lynn,

We'll be happy to include anything you can write :^) or if you supply the spendy protocol docs, maybe someone else will take a shot at it. I'm not hearing from many coders though. Maybe I'll have to post to some of the Linux lists.

Regards,

Curt Wuollet
 
A

Aalhad & Ashok Saraf

We made our PLC based on 8088 CPU and ISA Bus so we can give I/O cards to use with this PLC . We even have code in Assembly to implement the PLC
interpreter with Step type command language in PC. It works very well. We have made ladder diagram generator from STEP5 instructions for documentation.
I am very much interested in putting RT Linux on standard hardware and will be glad to share the ideas and code if we can build truely open automation hardware platform for all .
Ashok Saraf
Syslab Automation Pvt. Ltd.
98A/15B H.I.E. Pune 411 013
India tel 91-20-6872634
 
J

Johan Bengtsson

Written in C (or C++) and with the OS specific parts isolated it would be quite portabe at the source code level - sounds like enough

I would say, keep it to C (or perhaps C++)

/Johan Bengtsson

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

My comments in line

<snip>
>---- the state of the art , because the state of the art is "Customer Driven".------
>
>Most customers don't give a damn if the solution is state of the art, they
>are only concerned with reliability, availability and profiatbility.
>Maintainability improves availability. Most state of the art solutions are
>'Developer Driven', because the engineer wants to do what is interesting and
>what is new is interesting.

True to a point. I developed some software that no customer had asked for, but I could see was obviously needed to improve the
performance/efficiency of some equipment. The original requirement was identified by me working with the customer on his site, to solve his problems. I have found that the products that arise from this approach are flyers, more often than pure research products.

>-----From the research I have done, all the pieces are in place to build
>a solution for the community, controlled by the community and owned by
>the community. I am seeking volunteers who are interested in giving some
>of their expertise and talent to make this possible. Worst
>case, it would be a great free educational package to teach Automation
>basics. How good it could become is virtually unlimited.-----
>
>Good idea, in fact, I'd been thinking along the same lines, though I would
>probably never have had the guts to initiate this. I have also been
>interested in the idea of community collaboration, distributed project
>management, virtual companies/project teams. Basically, how do engineers
>come together on the internet to create project teams for specific projects?

Engineers come together via e-mail and a good version control system. I telecommute from Chile to the UK every day, and have done so
for the past 5 years.

>---The system would be PC based and aimed at generic hardware. The
>Operating System would be Linux.---
>
>Can it be truly open if it is limited to a PC/Linux paltform?

Linux runs on PC, SPARC, AIX, Mac, Alpha, so we are not tied to a platform.

>---The reference software
>implementation would be a state language or possibly ladder logic PLC
>with SCADA, HMI, etc., etc. added as people want them. ---
>
>Any open PLC should be based on the ideas of PLCOpen and the IEC 1131
>standard. Additional, languages and features should be added around a
>standard core. If this is not done we would be just setting our selves up as
>a competing standard, that's if we could agree amongst ourselves.

Very wise

>--- The first
>pieces to be coded would be modules that map I/O to a common shared
>memory map. This would abstract the differences between remote and
>attached I/O allowing a PLC to be built that will work with new modules
>interchangebly. It will be coded in C for speed and to expand the
>programmer pool.---
>
>This calls for an object oriented approach. C++ would be the better language
>to choose, but it is worth considering Java also. Despite its apparent lack
>of speed, a Java based core system could be devised that wasn't based on a
>particular platform (PC/Linux). Java also has other, emerging technologies
>which would facilite this kind of a project, and leverage the kind of links
>to existing enterprised software that would be required (JavaBeans,
>InfoBus, Jini,JDBC etc.).
>
>As with all software development coding should be left until later on in the
>project. We need a clear specification (what do we want the system(s) to do,
>how will it all interface, what is the architecture) and project plan (how
>will contributors interact, how will the work be integrated), we have to be
>sure that everybody is using the same sized Lego.

I agree with the design first code later approach, but I'm not sure that Java is the right tool to use. OK there is a new release of the realtime Java spec, but I don't know how it addresses the problem issues such as garbage collection, etc.
<snip>

Debian GNU User
Simon Martin
Project Manager
Isys
 
> John Margaglione [SMTP:[email protected]] said...
>Sounds like an interesting idea. I've been working under Linux for a little over a year now, and it is a stable and versatile platform. But how can we truly writen "open" software to one OS? Isn't that just as bad as writing Windows-only software?<

I agree, which is why I subsequently used the term "Open Source Controller". First of all, while writing to a reference platform such as Linux is an advisable strategy, I don't see any reason why the code should be limited to use on that platform.

Secondly, while I guess I would assume that ladder logic (the traditional PLC language) would be one of the languages supported, a more modular
approach that would allow the accommodation of a variety of languages would provide a more general (and usable) "product". The term "PLC" seems to
imply ladder logic, hence the choice of the broader term "Controller". I guess that's arguable, though.

Terminology aside, what I would envision is a framework supporting different languages and different I/O devices, with clearly defined hooks allowing these extensions to be contributed by various individuals or companies. And, I am assuming that we *are* talking about a software-based portable controller here, not merely a communications interface between Linux and an
external controller.

Comments?
Ken Crater, President
Control.com Inc.
[email protected]
 
I would be interested in helping out where I can, I think an open source control software project is a great idea. I have done a fair amount of C
programming for industrial PC based control, and I am familiar with Linux, DOS, and Windows NT.

A project like this would prevent much duplication of code, why should a hundred different companies all write their own Data Highway or Modbus drivers when they could contribute to writing part of them and have a vast
pool of drivers available as a result.

Several things need to be considered:

1. We need to decide on a format for the I/O drivers. My initial thought is that they should be device drivers which would be loaded as modules into the kernel. If they use a standard interface, the rest of the software could be more operating system independant.

2. It is very important that the system be modular. I would like see many individual programs running together and accessing the I/O and using inter-process communication. If we are careful, the modules could be classified as either hardware dependant or hardware independant. The hardware independant modules should be source code portable among many
operating systems.

3. A portable graphics library needs to be determined. I assume that many of the programs would run under X or WIN32. It would far easier to use a library that supports both. Maybe GTk+, or ...

Bill Sturm
 
Unfortunately my employer will not allow releasing any source code - even if I do it on my own time. Of course, Mr. Boz says there are ways
around this if the code is not noticeably related to my day job! (Non-Dickens fans; Boz was his "pen name" for early writings.)

But we've heard from a few - and there must be dozens if not hundreds - of small HMI systems which are commercially of little value. If the code from some of these were molded & ported it would offer a lot of fodder to chew on. For example, I'd bet hundreds of new Modbus drivers are written every year.

Regards;
- Lynn
 
M
<snip>
>>Most customers don't give a damn if the solution is state of the art, they are only concerned with reliability, availability and profitability. Maintainability improves availability. Most state of the art solutions are
'Developer Driven', because the engineer wants to do what is interesting and what is new is interesting.<<

> True to a point. I developed some software that no customer had asked for, but I could see was obviously needed to improve the performance/efficiency of some equipment. The original requirement was identified by me
working with the customer on his site, to solve his problems. I have found that the products that arise from this approach are flyers, more often than pure research products.<

True, but there is still a sizable chunk of state of the art solutions, that are state of the art because the designer wanted to do it a particular way. State of the Art solutions looking for any old problem.

A good ENGINEER finds appropriate solutions, and they are not allways (or even often) state of the art. (But this is a different discussion :).

<snip>
>Linux runs on PC, SPARC, AIX, Mac, Alpha, so we are not tied to a platform.<

So Linux isn't a platform?

I don't disagree that Linux is the right platform to start on, but do we really want to cut our selves off from all those MS slaves?

<snip>
> I agree with the design first code later approach, but I'm not sure that Java is the right tool to use. OK there is a new release of the realtime Java spec, but I don't know how it addresses the problem issues such as garbage collection, etc.<

I'm not sure that Java is the right tool for the job either, but I believe it MUST be considered. I also think it would be useful in prototyping the
actual controllers/command interpreters. The front ends, ladder/program editors, documentation databases, HMIs etc. can be written in any language really, just so long as all the interfaces are compliant.

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
 
Top