The Linux PLC Project

A

Anthony Kerstens

You mention Momentum with an ethernet adapter. One thing to be careful about is there are two flavours of Momentum with ethernet.
1. 984 compliant ethernet.
2. standard ethernet.

The difference lies in the numbering of the bits within registers, and the numbering of discrete I/O points.

It has the potential to be a pain in the butt.

Anthony Kerstens P.Eng.
 
C

Curt Wuollet

Hi Lynn and all.

Don't take any unnecessary risks at this stage. Bosses have a way of coming around when they realize what the benefits can be. When you think about it it terms of ROI, it's a great investment. You give what you can and receive what no single company could afford on it's own.

I agree on the IP (code) floating around, the only FB code I've found is a DeviceNet driver for the SST cards. If I had $1k or a card, I might do a scanner based on that. I'm doing Modbus/TCP because all I need is the I/O. I don't think anyone will spend thousands just to work on this free project. The problem with the HMI stuff is that, if you write for MS, almost everyone
uses some proprietary libraries that can't be GPL'd. The same is often true for Java. I have found a GPL State Machine generator that looks interesting called Libero. With this you define your states and it passes through your actions and transition conditionals. You would build a machine for the task at hand. I found nothing on RLL, but, I'm sure it's out there.

Regards

Curt Wuollet,
Wide Open Technologies
 
I don't quite understand this thread. Why re-invent this product when there are already commercial products that do this?

for example -- www.steeplechase.com

It is true that these products are for NT, not Linux, but that does not seem to justify the duplicated effort.
 
S

Simon Martin

Hi Bill

<snip>

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

My request here is DON'T ALLOW X TO RUN ON THE PRODUCTION MACHINE. It adds a whole load of additional complexity to the system. My suggestion is to have a TCP/IP based communications protocol to the PLC and interrogate it. This means that the software to monitor, etc can be on any platform and it also avoids using the production machine for tasks other than machine control.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]
 
M
Hello everyone interested in this topic
>
>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.<

I'm not sure that this is a good idea. Any crash of the device driver would bring down the operating system. An interrupt service handler is
necessary, but most of the device interface software should be kept in a non-privileged mode where a failure could be contained and confined (we hope) to the task rather than affecting the entire system.

The U.S. NIST (formerly NBS) has actually coordinated a lot of work in this area. For example, specifically in the area of device drivers, they have implemented a machine controller on Linux called the EMC project. See
http://www.isd.mel.nist.gov/projects/emc/emcsoft.html Also, if you look at the RT linux site (http://www.rtlinux.org/~rtlinux/), you will see a
library called COMEDI for DAC cards. In my review of the site, I don't think they dealt with fieldbuses, but they did address DAC cards.

A good place for depositing device drivers for industrial buses such as MODBUS would be in the RT linux home page.

As you will see by looking at these sites, a lot of the "fun" work has already been done. The world now has a sufficient number of control
software experiments.

In my opinion, the best value that the automation group can provide is by providing assurance that this stuff works well enough for some plant
manager to risk something significant and authorize installation. A testing strategy is also necessary to ensure stability, interoperability, and "nice" behavior upon crash or hang.

Anybody else have an opinion?

Regards

Myron Hecht
email: [email protected]
SoHaR Incorporated
8421 Wilshire Blvd., Suite 201
Beverly Hills, CA 90211
Web Site Home Page: http://www.sohar.com
 
> 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 ...<

I'm not sure that we would have to make a decision on a single gui language at the start of this project. From what I've seen of gui's they all have some provision for connecting to applications. Seems to me that TclTk would provide a relatively easy and portable gui language. It has interpreters available for windows from 3.1 to 98, unix and linux, and Mac.
Release 8.0 even has some look alike features so that the same code blends in with whatever system is showing it.

Ray
 
M
I would suggest a modular system (as have others), whereby the main parts of the system can be used either in an integrated one stop solution, or a distributed network solution. Providing the interfaces are well designed and
published a variety of solutions could be provided.

An ideal solution would support (eventually) multiple interfacing/connection technologies TCP/IP being the most obvious, Unix pipes and CORBA being others.

(My Java controller would act as a TCP server with various ports available some with predefined functions (program upload/download, monitor, data table access etc)).
 
S

Simon Martin

Mark, et al,

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

Linux is a software platform that runs on most of the popular hardware platforms and on some of the more obscure as well (I did see some discussion about Linux on an IBM S/360), so it will allow the software to be run on very dissimilar hardware. If we adhere to the POSIX rules then it should only require minor changes to run on MS Windows (32 bit variety) at least as a console app. I actually do this quite often.

<snip>
>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, documenation databases, HMIs etc. can be written in any language really, just so long as all the interfaces are compliant.<

Ok, here I must differ. In my appreciation there are two completely different things in here. Firstly there is the controller itself. This, in my opinion, must be self contained, independant of all things non-production related, and absolutely 24-7. The front end, programming software, monitors, HMIs, operator panels, etc. are a completely different kettle of fish and should be kept completely separate. On a different computer, hopefully.

Has anyone had any contact with samba? This product (SMB software for different platforms) has a little program called SWAT, that actually emulates an HTTP server and allows remote configuration, etc, completely independantly from the main daemons (smbd and nmbd). This is what I would envisage as a near ideal software package, maybe not HTTP, but then again why not. The system I envisage is:


Production Development
---------------------- ------------------------
| Interface software | | programming software |
---------------------- ------------------------
^
v
---------------------- Manufacturing
| Control software | ---------------------------------
---------------------- | scheduling, pattern handling, |
^ | SCADA, ... |
v ---------------------------------
----------------------
| operating system |
----------------------
^
v
----------------------
| hardware drivers |
----------------------
^
v
----------------------
| hardware |
----------------------

Each set of software is independant of each other. The network protocol is TCP/IP, the interface protocol is ? (HTTP, proprietary),
the programming software is windowed (XWindows, MS Windows, Solaris, ...), manufacturing software is as required.

Comments?

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

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

Mostly - because they are commercial.

Open source software (`free', as in `free speech') means that the source code is supplied with the program and the licence allows redistribution of modifications.(*)

This has several advantages; here's four off the top of my head...

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

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

- Customisability: you can make a custom version. Normally you wouldn't do that, of course, but it's good to know it's there in case of need.

Associated with this is that if you can see a bug, and know how to fix it, you can fix it right then instead of inventing klugey workarounds.

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

Different people will give these different weights, obviously :)


> It is true that these products are for NT, not Linux, but that does not seem to justify the duplicated effort.<

No, indeed it wouldn't; it's the `commercial' that people object to.


Jiri
(*) In a nutshell, anyway. Exact terms of licence subject to holy wars.
(**) RMS is Richard M. Stallman, of GNU fame, author of Emacs. www.gnu.org
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...
 
M

Mark Blunier

I want to get involved too. I hope that the next thing that is done is to create a seperate list for the group. If it is not supported by Control Technology Corporation does not have the resources, I could probably get a list set up on a server my local Linux users group runs.

Mark Blunier
Any opinions expressed in this message are not necessarily those of the company.
 
D
Hi Mark,

We are both able and eager to support this project. I've been away for a couple of weeks, but hope to find out what resources folks would like and get them set up very soon.

Do people want a dedicated email list at this time, or would it be better to keep using the main list for a while?

Dan Pierson
Control Technology Corporation
 
B
The great thing about Linux is that you do not have to use X Windows or any other graphical environment, if you don't want to. The decision to use X on a production machine should be up to the developer.

I agree that X adds some complexity. Some applications will want/need a GUI and some will not. X would be much smaller and faster if you avoid the popular desktop environments, such as GNOME or KDE, and stay with a single app and/or a small window manager such as FVWM or TWM.

I think that most users would want programming and visualization to be done from X.

A possible idea would be to have an X server in a low level PLC type machine, and display to an X client elsewhere on the network. The X client
could be any platform, such as Linux, Mac, or Windows that has an X client written for it.


Bill Sturm
Applied Grinding Technologies
 
B
I agree, the kernel code should be kept small. This is certainly keeping with the UNIX tradition. For instance, a kernel level driver for a motion control card would have hardware interface but no motion algorithms.

Obviously, any kernel space code would need to be debugged thoroughly before it is deployed in a system. Keeping the kernal space code small
makes testing a lot easier.

If we try to stay with I/O systems that use "standard" Linux I/O, such as Ethernet, serial, or parallel ports, then kernel level drivers would be unnecessary.

I am suggesting that we avoid making any hardware specific code in user space. If we write hardware drivers in user space, they must run with root privledges. As I understand, a program with root privledges can be a security hole, if it is not implemented carefully.


Bill Sturm
Applied Grinding Technologies
 
K
I am very concerned by the thread of "code for free". Is everyone asking this question and planning to base products on it, ready to make their product available for free. I doubt that!
 
B
I have just started to look at using TCL/TK for my Linux and/or WINNT GUI applications. It has a lot of capabilities for graphics and networking. I would be in favor of specifying TCL/TK as a open standard industrial GUI language. I think that it would be beneficial if we can agree on one
standard language for graphical front ends. How do the rest of you feel about a standard GUI language?

Bill Sturm
Applied Grinding Technologies
 
S

Simon Martin

With respect writing HMI for Windows, I've been doing that for the past 5 years, so there is experience available. With respect low level control stuff, I've been writing that for the past 10 years in the motion control field, so there is experience there. With respect parsing Ladder Diagrams, I wrote one for DOS many years ago, converting rungs to state transitions, so there is experience there as well. And this is just me!!! There are people on this list who have at least twice my experience and who have already said that they are willing to help.

I think that the idea has been accepted. A lot of people have said that they are willing. So why don't we get down to defining a design team. I have teleworked by e-mail for the past 5 years and it works wonderfully as long as all involved take the responsability or there actions, so that is not an impediment either. We need a good version control system. CVS on Linux is free and you can interact via e-mail, NFS, etc, (it's used by samba so it must be reasonable).

Let's stop saying it "would" be a good idea and start saying it "is" a good idea, and actually go ahead.

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

Lynn August Linse

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

Well, my suggestion is to view these as 3 types (as most HMI do). I won't comment much on the first 2, mainly on the third view. I'd suggest we don't try to do it the theoretical "best way" or complex OOPS way - that is often the down-fall of things like MAP and maybe even Foundation Fieldbus. It becomes easy to use, but complex to implement & near-impossible to make 100%
interoperable. (I hear DeviceNet vendors grumble - what happens if your device passes ODVA cert, but won't talk to a an AB product? Answer: you need to find out how the AB product talks and tweak yours to talk to it.)

Regardless of how "ugly" Modbus is, it is a great 3rd party standard just because it is so easy to implement and interoperate. Even though it gives
lots of headaches to users, these can be and are overcome in thousands of projects each month world-wide.

1) "Complex Objects" for protocols like Foundation-Fieldbus, DeviceNet, ControlNet etc. This we leave to people who understand these & want to do the drivers.

2) "Intelligent I/O" would be like used by many PID controllers etc where they have named resources - SetPoints, HiHiAlarm limits etc.

3) "Simple PLC style" which just has 1 or more tables (arrays) of elemental data (bits, 16-bit words, floats etc). I'd suggest we have a shared resource (shared memory?) for this. Call it VReg (virtual registers). The Linux-PLC could either use this table directly - or better use block-moves to copy data in/out of the VReg as most PLC do with ladder-logic to intelligent cards/coprocessors.

Then any variety of "slave" drivers could serve this data out. One of the exciting "new" features TCP/IP offers over the old serial protocol drivers
is the ability to support almost unlimited protocol connections. Unlike serial where a port is either Modbus OR DF1 OR Host OR ??? but never ALL at once, our "LinuxPLC" could (in effect) look like a slave to Modicon, Allen-Bradley, GE-Fanuc, Siemens, Omron, and any variety of other PLC by Ethernet AT THE SAME TIME.

This could allow our LinuxPLC to become the "Apache web server" of the factory floor - NOT meaning it servers web pages, but that it becomes the
natural choice! An Allen-Bradley PLC uses MSG blocks to read/write data into VReg; a Modicon PLC uses MSTR blocks to read/write into VREG. etc. etc. No doubt hundreds of other drivers could be written to read/write data from VReg also. It could become a simple universal translator for the factory floor.

True, this does not make much use of the "plc" functions, but we could find this is the great Value-Added feature which levers the wide user/coder support required to move the Linux PLC forward the fastest.

Returning to items #1 and #2 above, possibly future additions to the LinuxPLC would be similar virtual tables of Foundation-Fieldbus or DeviceNet
objects which allow mapping between things like Modbus and FF.

Best Regards

Lynn August Linse, Senior Product Application Engineer
 
Top