The Linux PLC Project

C

Curt Wuollet

Hi Bill and all

The initial I/O scheme that I am doing will be Modbus/TCP and can be implimented in user space and run without root permissions. Almost anything else except serial protos will need access to irqs and ports. You can usually relinquish root permissions. You will need kernel mode drivers
in some cases, but, they can be minimal like Bill sez. Another approach I like is to do the direct
hardware access under RTLinux. Actually, I like the idea of good old Ethernet for all I/O for reasons below and cost. Modbus/TCP is the
closest thing to an open fieldbus protocol I've found so far, everything else I would have to join something or buy somthing and the hardware is vastly overpriced. Unfortunately, not too
many I/O vendors support Modbus/TCP and the only other Ethernet standard that I've seen, ControlNet seems to be run by the same set of control freaks that run ODVA. Modicon may loosely control Modbus/TCP but they are trying a lot harder than anyone else by publishing it for free with example code. I don't see any licensing or
intellectual property problems with it.

Curt Wuollet
Wide Open Technologies

The opinions expressed ARE the opinions of the company, it's the only benefit I get.
 
M

Michael Griffin

One-off machines are probably best controlled by a commonly available conventional PLC or something similar. High volume standard machines can justify a lot of time spent on writing software in 'C' or some other computer language. Not all machines are one-off products or high
volume standard models though.

There is a certain market for machines which a company may build in batches of a few dozen a year. These machines may be broadly similar but
with individual customization (e.g. coil winders and other similar equipment).

I am aware of several companies which have developed their own proprietary "soft-logic" systems for use only in the machines they build.
The soft-logic system allowed them to quickly and easily customise the program for each machine as they built it. It was not however, something the
end customer would normally modify themselves after delivery; indeed the customer may not even have been aware of how it was programmed. For the
manufacturer, the number of machines built was large enough to justify the engineering effort involved in closely tailoring their control system to their application.

I imagine that companies like these would be interested in a product which they didn't have to develop by themselves, but which at the same time
didn't leave them totally dependant on a third party. If they can support their own proprietary "soft-logic" system, then surely they could just as easily support one available as GPL.

Another possibility would be for a smaller control system *hardware* vendor to package their control system hardware complete with a
preconfigured and preinstalled "Linux PLC" ready to use right out of the box. To the end user, this would be similar to buying a conventional PLC. The hardware vendor could then provide whatever customer support was required since this would be directly connected with their hardware sales.

The attraction for the hardware vendor is that they would be supplying a higher margin service with their hardware rather than just bare
commodity hardware. A company whose advantage was innovative hardware or good distribution would not have to support a corresponding level of
software development or involve a third party (with the associated business risks) in order to offer a complete system. It would also allow smaller hardware vendors to compete more effectively with the large ones as the software system used would have more customer familiarity than if they had developed a purely proprietary one.

The attraction for the customer is that they would have better support than they would get if they were expected to put together a typical
"soft-logic + Windows NT + bad network driver" system themselves.

I think the above two examples show that the "customer support" issue should not prevent the success of this project. It may not be something which would interest everyone, but I think there is a place for it.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
 
I hope that this project is successfull and I agree with the general nature of Jiri's reasons for the benefit of free software, but I question whether this market will support free software. For an operating system or a standard
application that is going to be used by thousands if not milliions of people, then you can get enough leverage behind the software development effort to make it work. For this market it is questionable that you will get enough interested
people to support the type of robustness that people want. This does not discount the ability of the people offering their help. It is simple economics.

If you aren't getting paid to work on the software then you are doing it in your own time. Unless you are rich and you need no other job then this is a limited amount of time.

Back to what some other people said - what about the systems on the market that does this sort of thing - people are not going to use this system simply because it is free.

Good luck and I hope you succeed.
 
K
In a previous message in this thread I mentioned that Linux could be considered a reference platform for this project. I'd like to expand on the concept a bit.

Certainly, portability would be a goal of the project, especially since different application areas will have (possibly dramatically) differing
platform requirements. However, for the project to progress in an orderly manner, I believe it would be useful to have one or more reference
*hardware* platforms as well as a reference OS. These could be an accumulation of board-level products from various manufacturers, potentially
including specific models of I/O interface hardware. Or it could be something else.

I don't think we want to get into the business of "preferring" one brand over another, but there is a countervailing interest in making sure that, as
the code evolves, it will at least work in *some* specified environments. I believe such a move would help lend order to the process and build
confidence in the resultant code.

So, the first question I have to ask is: Do you think there is a need, and the possibility, of agreeing upon one or more hardware reference platforms?

If consensus on this question is in the affirmative, I've got a few more questions about specifics. BTW, I should mention that my own company does not manufacture any candidate systems, so I don't have any ulterior motive
except to make the project successful. However, we would be willing to acquire (or perhaps they would be donated <grin>) reference systems to act
as a test bed for the project.

Ken Crater, President
Control.com Inc.
[email protected]
 
S

Simon Martin

Hi Dave,

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

I concur and would add keep the HMI, programming, editing, monitoring software off of the production machine.

<snip>
>Notice throughout this I have not mentioned C++. No doubt I will flamed to a crisp for heresy but it is my opinion 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.<

Ok, the flames start. There is very little overhead associated with using C++. Most of the constructs that C++ is famous for is actually resolved at compile/link time, such as overloading, inheritance, etc. This means that we get the functionality without paying the price. For example the typical statement cout << "hello". Inside the stream class there is an overload for the operator "<<". The compiler just picks up the correct function call, sets the parameters and Bob's your uncle!! Easy (no offence Stroustrup). I have programmed extensively in C and C++ (amongst others) on a variety of platforms (mostly AIX, Linux and Windows, but I have also worked on VMS, SCO Unix, and a little bit of Mac a lot time ago). If you don't mind using a console app then it easier to port Unix to/from Win32 than it is to port Win32 to/from Win16/DOS or DOS (Win16/DOS to Win32 is fairly easy, Win32 to Win16/32 can be a
challenge). If you want to use X then you can use cygwin. The cygwin libraries are GPL'ed. As far as C++ is concerned, how about egcs (replaced g++). This runs on Unix and Win32 as well. And it's free (please see the FSF about the definition of free).

<snip>

So long

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

David Nimmons

> 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".
>
I think this is a great idea. In fact I have been searching for something like this among the free/open source projects. I would like to contribute. I have some C and assembly language programming experience ( been awhile though ). Here are some thoughts.

1. Go for the whole ball of wax. Machine control, process control, HMI, etc....I believe the support will come to cover all the bases.

2. A key enabler would be a universal, web based HMI with drivers for all existing DCS's, plc's, etc. This would allow integrating into existing systems with the goal of eliminating the expensive proprietory HMI's available for the different platforms and providing a single interface to all your systems from a inexpensive web browser based thin client.

3. I believe JINI might be perfect as fieldbus protocol for interfacing to smart instrument

4. You should look at hosting your site at SourceForge. This is the new site that VA Linux has setup to host open source projects. They have a really nice setup, providing all the tools you need to run a project like this. In addition it will put you in front of a whole lot more eyeballs.
 
C

Curt Wuollet

Hi Dave and all;
Sounds like we're on the same page, I have a memory interface between I/O and the "PLC" portion I'm working on. I agree on C, bonehead C whenever possible so any bonehead like me can work on or modify it. The KISS principle will make
it a much more approachable system, and useful to more people. Lynn was getting at this also.

Curt Wuollet
Wide Open Technologies
 
S

Simon Martin

Hi Michel,

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

This is what I have been advocating. They are two different things. Keep them that way.

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

Why not all. I understand that the code for DeviceNet slave is free, but a DeviceNet master is not, so there may be some legal issues involved here.

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

Hopefully suppliers could be found, or bribed with use o the finished product, or something worked out in a different way. See the USB on Linux effort, all the USB stuff was donated (including an analyzer if I remember correctly)

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

Why all on the same subnet? Ok Ethernet is CSMA/CD, but if you keep bus use below 60% utilization then you should run into real problems. Logic could be built in that recognizes a unit, estimates is maximum IO throughput and says "No I can't access it" and warn the user. Alarms can be put on maximum bus utilization, etc. If we use standard TCP/IP, then we should be able to handle at least 8 ethernet cards so we can really spread the load.

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

Why limit ourselves. I envisage a PLC enginge chugging through rules, resolving the logic. The programming software can be whatever you want, as long as it resolves to boolean logic at some point. If programmer A likes ladder, let him have it, it programmer B likes function block, let him have it. Leave the hooks available and programmer C can develop his state language and we all benefit.

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

I concur.

>All this thread has mentionned 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.

Again I concur, we must start this project. But we must start it correctly. Too often I loose too much time through not planning ahead. Here we can plan. On the other hand, we all know what happened to Charles Babbage!! Let's get the balance right.

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

Johan Bengtsson

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

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.

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

He/She will be able (eventually) to choose to get help or do it himself/herself

>It seems that the time is worth more than the money.<

True, but this do not necessarily rule out this project...


/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]
 
J

Johan Bengtsson

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

Agree, the actual control should share nothing with the HMI except the memory where the values are stored and perhaps some name<->I/O
definition file

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

Why not all of them, the I/O should be kept apart from the controlling anyway and being some kind of modules (not necessarily the same as a kernel module!) those could be added later anyway

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

?????
Each I/O driver have to be directed to a particualr protocol and a particular comunication card if this is needed. I don't see any problem with this. Several I/O drivers can support the same protocol for different cards and the other way around

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

I agree to that, but that don't exclude it from what would be supported anyway

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

Don't drop ladder, it is a quite compact and readable "language" for those familiar with it.


>6. In the beginning of this diatribe I mentionned that the HMI should be separate. I would think that everyone would want to keep the HMI on a separate machine altogether. Having the HMI on a separate 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.<

The HMI should be kept separated - agree completely
It should however be able to run on the same OR another computer as the end user wish. The control may not be that critical that the extra risk (if any) of only using one computer is with the extra hardware needed.

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/
 
B

Bill Hullsiek

Lynn Linse indicates to use a TCP/IP based communication protocol.

Rather than Modbus/TCP, maybe use something such as SNMP or MMS (Public Domain version). If the architecture is done correctly, then a user could
swap out the public domain version of MMS and replace it with a bullet-proof implementation such as Sisco's product. At least with SNMP and MMS you get a structured record type, rather than a brain-dead register protocol.

MMS also supports various security mechanisms, so you can protect your equipment from spoofing.

Bill Hullsiek
Renewal by Andersen
[email protected]
MES Software Engineer
Work: 651.501.4000 x4624
Pager: [email protected]
 
D
This is more a general response to this topic, than a specific one to Lynn, but:

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

While this is correct in many cases, I think the whole argument is confusing two separate concerns:

1. What are the programs that this project is trying to create.
2. What set of (these and other) programs are allowed to run on a single PC.

It seems to me that early to medium term parts of this project should concentrate on one or more separate programs such as:

+ A Controller/PLC engine with a basic set of device drivers. This should not have a production runtime dependency on any graphical display. I've weasle-worded this because debugging graphical display may be desireable and
because applications written to use the engine may chose to have graphical display requirements.

+ One or more development tools for the above engine. These could be anything from command line compilers to fancy graphical IDEs. I predict
that the former will be available before the later :).

+ One or more HMI tools.

The question of what set of the above are *permitted* to run on the same PC at the same time is really none of our business! Some PC's may be running real time Linux systems that can dependably deliver high, deterministic performance to the control program while still supporting X11 or other graphical apps (we were starting to do this at Encore in the late 1980s).
Other applications may not care about the performance and determinism effects of running both. However, I believe that most product applications will choose to keep the two on separate machines, at least in the early
days.

Dan Pierson
Control.com
 
May I suggest the interface to this new system to be COM+ since it is the leading distributed object system and that will make it much easier for people to interface with it? How about an OPC interface?
 
K
Another (IMHO) huge advantage is that the source code can be inspected, so that the tiniest, most irksome bugs, details, or quirks can be found by
implementers doing real work. This is in contrast to non-open source systems, where one has to rely on the developer's provided documentation, with the only other recourse being throwing test cases at the problem to try to ferret out what is really going on. In a healthy open source project, bugs once found can be fixed, so the code base becomes more robust.

--
Ken Irving
Trident Software
[email protected]
 
L

Lawrence Butler

Hello Lynn,

Up front, if I have misinterpreted your post I stand to be corrected.

I would disagree with your comment that one should not be able to connect to the PLC and modify code or registers, although it would require some form of security. We do this all the time now with PLCs ( I can sit at one PC and connect to PLC's in the same room or ten miles away.)

I haven't used X windows enough to comment on the appropriateness of running it on the PLC machine, but would see no problem using it or Win32s on a remote PC to access the PLC for programming if someone wanted to develop the interface on that platform. The main thing is that the PLC is running on the Linux machine right??

Lawrence Butler
 
B
>So, the first question I have to ask is: Do you think there is a need, and the possibility, of agreeing upon one or more hardware reference platforms?<

In the Linux community, people have typically written drivers for the hardware that they own. This has the obvious side affect that the most
popular hardware gets drivers first. However, hardware that has no documentation tends to be avoided. It is a good idea for hardware vendors
to provide free documentation to the Linux community. This is why Modbus and Modbus/TCP are good choices.
Bill Sturm
Applied Grinding Technologies
 
K
> 3. Do we have the scope of the project defined?

My impression is that the scope is not yet very well defined, and probably needs more discussion to zero in one or more scopes. The originator
of the thread, Curt Wuollet, if I understand correctly, is aiming at an actual PLC running on Linux, but also is interested in other aspects up
to and including a MMI. Others have brought up many good points.

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

To my mind, the most valuable aspect will be the protocols that are defined/selected, since they would be platform independent, and could open up disparate systems to a common protocol. One possible option might be BACnet, which defines an open protocol accomodating many of the services that are useful in dealing with devices, and also accomodates system-specific transactions by transporting foreign (non-BACnet) packets.

--
Ken Irving
Trident Software
[email protected]
 
R

Robert Lunnon

Consider Profibus, It is fast, reliable, cheaper than ethernet for I/O modules (comes in a single chip solution for I/O vendors). Siemens are
pretty open about the protocol, although the profibus associations like to charge for development info (But not a lot). It is also one of the standard international fieldbus protocols. Most of the information should be available from your local university library. From the linux end you would just need to write support drivers for one of the commercially available profibus adapters (Which isn't very hard). Since (the way I read it) Profibus is more or less an asynchronous bitstream it may be possible to
write a protocol stack to generate it using standard Uarts for an el-cheapo solution (At low bitrates) although this would be a LOT more work.
TCP/IP-Ethernet protocol overhead is MUCH higher than typical fieldbusses which can cause latency problems, on the whole it is less deterministic and worst of all 100 base T requires a star wiring topology (Expensive installation) (10 base 2 is too slow for many apps due to the high protocol overhead)

Food for thought

Robert
 
G
> May I suggest the interface to this new system to be COM+ since it is the leading distributed object system and that will make it much easier for people to interface with it? How about an OPC interface?

You have hit the problem on the HEAD ! ! !
COM and OPC (OLE) are Micros~1 propriety protocols. You will never have an open system built on proprietary protocols.

Easy does not mean open...
 
Top