The Linux PLC Project

D

David Nimmons

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

I think he was talking about the possibility that GPL would require that the customer release the control program ( ladder logic, SFC, etc ) they develop for their application. I don't think this would be a very good selling point for many corporations.
 
Great idea. We'd all welcome any XML related code you can offer and put into the FTP archive. You obviously know a lot about XML - unlike me and many others working on the LinuxPLC.

Best Regards
- Lynn Linse
 
> >- Quality: open-source software tends to be high-quality.< <

Mark Hutton:
> 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.<

I don't think anybody really knows *why* it works like that, contrary to conventional wisdom (Fred Brooks "The Mythical Man-Month"), but it's true.
ESR has some eloquently-written guesses.

Even compared with commercial Unixes, the GNU utilities and Linux come out well in front in some benchmarks.

("Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and
Services" (1995) http://www.cs.wisc.edu/~bart/)


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...
 
I've also been looking into XML, and have been working on a way to query a "generic PLC server" via sockets (and other channels) with the transactions formatted using XML. XML provides a good way to organize such data, but does not address the protcol(s) used. I've also been looking at BACnet as a flexible protocol to make queries against different types of controllers.

--
Ken Irving
Trident Software
[email protected]
 
J

Johan Bengtsson

I agree completely to this, but perhaps one small thing (it may be what you meant however)

the individual parts could be programmed in C or C++ as suits them best. In order to do this the interface should be done in pure C. If the interface is done using classes all parts have to be done in C++, but if the interface uses pure C calls and C style in everything parts can be done in C and C++ as is fit for that particular part.

I definitely agree to the HMI beiing one part where C++ would be the *best* option. A PLC interpreter or a device driver *may* however be better written in C than 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/
 
J

Johan Bengtsson

I think the license text would have go something like the intentions of this:

1. the basic parts of this is free
2. add ons may be free or proprietary (ie drivers, HMI-packages etc)
3. work created with tools in this packet (ie PLC-program etc) are not automatically free (study the emacs license)

I think point 2 is important. This follow what you can do with linux. (a program can proprietary and still be targeting linux). This will make
it possible for people to make add-ons to this and get paid as well as the other possible ways to get paid (support, guarantees etc.) This effectively means the original basic drivers, HMI etc. should be "non-copylefted free software", but the basic parts could be "copylefted"

(These terms are quite new to me too, but I think I got it down to what I intended)

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

The point was received as intended, and agreed with.


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

Expert in what? I merely point out that an Automation Engineer or what ever you like to call him/her now days has to be an expert in everything. Electrical engineering, control, process, mechanics, production, software. We now have to add to that TCP/IP, ethernet, Fieldbus, Windows98, Windows NT, Linux, System Admin,
Internet working the list can go on.

There is an old saying 'Jack of all trades, Master of none!'

I am as commited as any one to this project, but I feel that _ALL_ of the salient points should be raised.

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

Exactly! Which means that any system that requires excessive additional learning will not be used.

Many windows based systems can be implemented by customers because they can leverage in house IT expertise, this presents it's own problems. As yet
Linux expertise, in any field is at a premium.

I think that this project is worthy and valid. I also agree that it is a non-commercial, community project. However, if we want the project to end up as something more than just an academic example, we must give people good, honest(?) commercial reasons to use it. To do that we must keep an eye on business priorities and the 'real world'.

We must be looking to supply _real_, not illusory benefits to the customer.

Please bear in mind the wide variety of potential customers, also that maintenance is the (usually)most costly period in the lifecycle of any
system. Maintenance technicians vary from professional engineers to people whose first attempt to fix any thing involves hitting it with a large mallet. The organisations at both ends of the spectrum may be equally succesful.

IMHO the project requires a mission statement and some clear objectives, these objectives must include business (or business like) objectives if we expect the results of the project to be useful to industry.
 
C

Chetan Chothani

I would like to add my two cents to this discussion.

1) I agree with some of the earlier suggestions that the control/plc portion and the HMI portion should be kept seperate. This will allow us to have deterministic, reliable and highly available system.

2) IMHO the data transfer between the Control subsystem to the HMI subsystem should be through a standard protocol such as OPC. The
advantage of using this approach is that a user may want to use the PLC as is however he may want to take advantage of a familiar HMI that he has been using inthe past. Such as wonderware or intellution etc..
Also this gives the end user the flexibility to write their own HMI's, Higher-Level control programs (such as model-based or AI or Neural
Net controls), or use other such standard off-the-shelf programs. The configuration would be through a pre-defined set of function calls
that the PLC supports. These could then be called from any configuration environment. Once the configuration is done from the users preferred environment, a call would be made to the compiler and next a download sequence initiated.
This gives the user the flexibility to use whatever configuration tool he would like to use or write his own.

Be it noted that we would have to provide an HMI and Configuration utility as part of the package which the user can use as he pleases.
We could also publish demos for different platforms.

3) IMHO the actual control would have to be done in a dedicated device which for lack of a better word i will call as a controller. This controller may be a physical (hardware) controller or it could be a soft controller. The soft controller could be something similar to a
service in the NT world. The user selects the device he wants to download to and then the download sequence would be the same.
This will give other vendors an opportunity to develop hardware to be used with this project. The success of any control system depends on the reliability and availability of the system. The vendors could develop hardware and compete for the most reliable/available system in the market.

4) Thin Clients: IMHO we should provide Web Support as a standard option for this system. This will enable the use of thin-clients such as Web-Browsers as alternate HMIs (possibly view-only, but left to the users discretion). The standard HMI included with the system would automatically generate web-pages thus enabling the thin-clients.
What this also gives us is cross-platform HMIs. Anybody with a web-browser would then have access to the system.

5) To stir up the hornets nest <grin> : Is there any plan to include a data historian in this project. This would open up a new can-of-worms !!

I would also like to officialy express my interest to be a part of this PHENOMENON.

Best Regards,

Chetan Chothani

Adaptive Resources
 
J

Johan Bengtsson

I would like to suggest (may be implied by some, but surely not by all) that the control part should be divideable. That is one part interpreting a PLC program, one part running a
precompiled C controller directly using the API, one part running a set of PID controllers and so on at the same time if that is desired.

(two controlling parts should of course NOT affect the same output, but be running side by side towards the same memory area controlling
different outputs) It would even be possible to put them in a chain, one using anothers output as its input.


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/
 
On Wed, 5 Jan 2000, Simon Martin wrote:

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

I don't neccessarily agree with your statement but I agree entirely with the concept. The HMI, programming, editing etc. should be developed as
remote aplications.

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

I was not aware of cygwin. Does it also provide portability to MAC, RISCOS Be OS?

Dave West
E-Mail: [email protected]
Semiras Projects Ltd.
PGP public key available on request.
 
I agree, that the programmer shouldn't have to write a C++ class in order to implement a protocol driver. The key is figuring out a generic interface to plug different protocols into the PLC. The generic interface, I would hope, is not recompiling the LinuxPLC, but rather some sort of configuration that specifies which protocols to load into the PLC. In Windows, you could do this via a DLL, which is what we do for our protocol drivers. Then the main module calls LoadLibrary on the specified protocol DLL and determines what methods it exports. I'll have to admit I don't know much about the current
state of Linux and whether it supports DLL like loading. It is important to not create blob.exe (e.g. all code in one exe), but rather a set of dynamic components that plug together via configuration.
 
---------- Forwarded message ----------
> From: "Mark Hutton" <[email protected]>
> Subject: RE: SOFT, ENGR, INFO: The Linux PLC Project

> I am not sure about this. You seem to be saying that system
> software written
> in C can be accessed and called by software written in any
> language, but
> software written in C++ can only be accessed by software
> written in C++.
>
> Surely this is wrong.

Not exactly. Something exported as a C interface can be used anywhere. Something exported as a C++ interface can only be used by C++, generally only the same C++ compiler.

To write in C++ and export C interfaces you do something like:

extern "C" void* myfunc(int arg);

Of course this restricts you do data types and concepts that are compatible with C.
 
You might consider releasing the software under
the LGPL license (Library Gnu public license).
This means the software which uses the libraries
do not need to be released under the GNU license.
 
Yes, it does - shared libraries, extension .so

The other way is to use separate processes, which protects the programs from one another, and gives you control over scheduling (so the HMI could
run on the same box but in a different process and with lower priority, as a sort of half-way house between integrated HMI and separate HMI).

We should probably move this discussion to the linuxplc list.

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...
 
Linux does support dynamic libraries, in fact it uses them extensively from libc down. Linux ALSO supports loadable loadable kernel modules. Most Linux drivers nowdays ar implement as loadable modules and these may be inserted or removed from the kernel with a simple command, indeed it may even be done automaticaly on the basis of requested resources.

One upshot of this is that it is possible to make a set of high level drivers (for e.g. protocol implementations) with identical interfaces but
with different behaviour, so you can change characteristic by switching modules.
 
M

Mark D. Tompkins

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

I'd like to endorse good design, with accommodation for things like Java, or my favorite - Python. It is slow, mind you, but vvvvvveeeerrryyyyyy easy to learn and use. It can even run within a JVM, because Python generates byte code. A version of Python that runs in the JVM is called JPython. I am learning Python, because a Java Guru said that by using JPython, he was able to produce code 5 times faster. To me, Python is analogous to SQL. High level, but very powerful. Allows for the expression of ideas in code easily.

Not that there is anything wrong with Java, however, Java is proprietary, is it not? Doesn't SUN still retain the right to charge for EJB and embedded Java?

After having had to live with the excesses of one Predatory Monopolist, I think that real serious thought should be given before embracing technology controlled by an aspiring Predatory Monopolist (Maybe I'm wrong about SUN. I hope so!!!)
 
Actually, this should only limit the use of polymorphism - as extern "C" just prevents the compiler from 'mangling' the function name..

Dan Hazel
 
Top