advertisement
from the Automation List department...
The Linux PLC Project
Open-source control projects, related links.  topic
Posted by Curt Wuollet on 15 December, 1999 - 10:09 am
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.


Posted by Ken Crater on 15 December, 1999 - 12:08 pm
> 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.
ken@control.com


Posted by Mark Blunier on 4 January, 2000 - 10:32 am
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.


Posted by Dan Pierson on 4 January, 2000 - 10:34 am
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


Posted by Tim Ottinger on 11 May, 2000 - 9:53 pm
I'm kinda interested, having about 20 years programming experience, including C and C++ and more recently being very much into python (if there's any need for that). I'm an OO designer of some capability. But I'm fairly new to control systems, so I'd need a lot of help. Got a lot going on in my life (a control system, a youth ministry, songwriting, etc) but it sounds like a good gig. It could be fun in my evenings off ;-)

A lot of my experience is in the Uni (unixen?), though I'm a little linux-challenged.


Posted by Ken Irving on 16 December, 1999 - 4:31 pm
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
jkirving@mosquitonet.com


Posted by Curt Wuollet on 23 December, 1999 - 9:50 am
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


Posted by Michel A. Levesque on 5 January, 2000 - 11:09 am
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.
mlevesque@aia.qc.ca


Posted by Simon Martin on 6 January, 2000 - 9:36 am
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: smartin@isys.cl


Posted by Johan Bengtsson on 6 January, 2000 - 3:44 pm
>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: johan.bengtsson@pol.se
Internet: http://www.pol.se/


Posted by Jiri Baum on 6 January, 2000 - 4:35 pm
Hello,

Michel A. Levesque, ing., wrote:
> 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 ?<

Ideally all of the above, simultaneously on the one computer :-)

In practice, whichever is easiest to implement first ("easiest" includes considerations such as whichever of them happen to be available/useful to the people doing the coding...), then the others as possible.

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

Well, that's a bit out of the scope of the project. Put a warning in the docs is about all we can do about it. Maybe watch /proc/net/dev and warn if collisions become frequent (shocking as that sounds).

> 5. As far as the GUI of the programming language...since we are starting fresh here, let's drop the ladder language.<

Why? It can just be one of the options... if the base API is in C (it really has to be, anyway), then we can have any number of languages. If
(when) the project supports more than one kind of bus, we can even have a "grab these from bus A and show them to bus B like this" language...

Anyway, ladder language is very simple if you stick with the text version (LD X001 / AND X002 / ...). A couple of days back I wrote a simple
interpreter in an afternoon, just to see if it really was that easy... (I'll upload it if there's an exp(erimental) directory in the CVS.)

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

Yes, though that'd really be the implementer's decision, if it's done properly. The module should be designed to work either way.

(One of the usage modes should be as an HMI box, anyway, in which case you want the HMI module and the industrial bus interface on the same machine.)


Jiri
--
Jiri Baum <jiri@baum.com.au>


Posted by Lynn Linse on 16 December, 1999 - 4:53 pm
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
lynn.linse@lantronix.com www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132


Posted by Curt Wuollet on 23 December, 1999 - 9:52 am
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


Posted by Lynn Linse on 27 December, 1999 - 11:47 am
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


Posted by Curt Wuollet on 3 January, 2000 - 11:33 am
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


Posted by Simon Martin on 4 January, 2000 - 3:10 pm
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: smartin@isys.cl


Posted by Ranjan Acharya on 16 December, 1999 - 5:39 pm
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/
Ranjan.Acharya@grantek.com
Ranjan.Acharya@ieee.org


Posted by RB Taylor on 17 December, 1999 - 3:45 pm
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


Posted by Lynn Linse on 17 December, 1999 - 3:48 pm
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
lynn.linse@lantronix.com www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132


Posted by Simon Martin on 17 December, 1999 - 3:58 pm
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: smartin@isys.cl


Posted by Murry Shohat on 17 December, 1999 - 4:20 pm
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


Posted by John Margaglione on 17 December, 1999 - 4:21 pm
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
john_margaglione@omron.com


Posted by Johan Bengtsson on 23 December, 1999 - 9:54 am
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: johan.bengtsson@pol.se
Internet: http://www.pol.se/


Posted by Ken Crater on 23 December, 1999 - 10:07 am
> John Margaglione [SMTP:John_Margaglione@OMRON.COM] 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.
ken@control.com


Posted by Ken Crater on 5 January, 2000 - 6:02 pm
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.
ken@control.com


Posted by Bill Sturm on 6 January, 2000 - 4:18 pm
>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


Posted by Brian T. Smith on 6 January, 2000 - 4:51 pm
Ken:

Happy New Year and good luck with the Linux PLC Project.

Yes I would think there is a need to define a set of hardware reference platforms.
This would help reduce the project workload and hopefully ensure success by selecting hardware with good potential that is also considered standard in the industry. It was suggested in an earlier post that a specification should be created for this activity. This is a good suggestion for the same reasons I mention above. A general spec may be all that is needed. A detailed spec may be too difficult and cause unnecessary delays in getting the project going (I sense an enthusiasm that should not be dampened by documentation).

You may consider including the short term and long term specifications and intended hardware reference platforms. That could show where the project could go beyond the initial testing and relieve any concerns about hardware that is not initially listed for testing.


Brian T. Smith, CET, email: smithb@novachem.com
Nova Chemicals(Canada)Ltd., Sarnia, ON. Canada.
(519)332-1212 x7920, Fax:(519)339-7301.
Opinions expressed are those of the author and not necessarily those of NOVA
Chemicals.
Personal home page: http://www.xcelco.on.ca/~btsmith/


Posted by Anthony Kerstens on 7 January, 2000 - 9:09 am
It makes sense to focus on one platform first for the sake of orderly development. I don't think Linux started out with the complete gamut of
video cards :).

On the other hand, unlike video cards, there is no lowest common denominator that all I/O systems could communicate with. For example, all PC video cards that I know of support 80x25 text mode. All newer video cards also support 640x480 graphics.

A line will have to be drawn, and in all likelihood it will be something new and on the cutting edge.

Anthony Kerstens P.Eng.


Posted by Mark Hutton on 23 December, 1999 - 9:51 am
---- 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.


Posted by Simon Martin on 23 December, 1999 - 9:59 am
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


Posted by Mark Hutton on 27 December, 1999 - 3:16 pm
<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


Posted by Simon Martin on 3 January, 2000 - 4:03 pm
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: smartin@isys.cl


Posted by Mark Hutton on 6 January, 2000 - 4:37 pm
Simon

I don't see where you differ. I agree entirely.

I already have most of the design for a virtual PLC, that I have been modelling for Java, a personal project only. This PLC is intended to have a very similar achitecture to the one you lay out (though I intend to communicate, atleast initially, with something a lot simpler than HTTP,
straight ASCII over TCP/IP (perhaps a simplified HTTP)).

Connection is via Sockets.

The PLC acts as a server, allowing multiple concurrent client connections via one or more TCP ports. The interface will allow for connection using simple text commands such as GET, SET, LOAD, RUN, QUIT, etc. and will allow for commands to be given or files to be download via a simple terminal (e.g. winterm or hyperterm), or even Telnet.

The PLC takes straight text files of a sub-set of IEC 1131-3 compliant Instruction List (IL).

I have no I/O driver methodology yet, and the first prototype will not support online editing, and maybe not function blocks (this last depends on the time available).

As I have said before, this is a project that I have been planning for a while; I am currently using it as a training project to learn UML and to
help me consolidate my Java knowledge prior to taking the Certification exam.

I will make the code available to any interested parties once I have something worth seeing (or atleast working).

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
mark.hutton@vogal.demon.co.uk


Posted by Aalhad & Ashok Saraf on 23 December, 1999 - 9:53 am
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


Posted by Ratin on 19 December, 2000 - 11:40 am
Hi Ashok,
I gave you a call but I couldnt reach you. I work for a company called Aerotech and we are
trying to implement softplc logic interpreter in
a potion of the c code, which is interrupted
every millisec. This interrupt will send commands to a digital controller. The interpreter code should use shared memory which will be accessible both by the softlogic interepreter engine and the controller code. We are thinking of using linux on a single board computer. I would like to share your idea with this. Please reply if you can.

Thanks,

Ratin
Aerotech INC
412-519-0180
mrahman@aerotechinc.com


Posted by Bill Sturm on 27 December, 1999 - 9:08 am
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


Posted by Simon Martin on 3 January, 2000 - 11:38 am
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: smartin@isys.cl


Posted by Mark Hutton on 3 January, 2000 - 11:49 am
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)).


Posted by Bill Sturm on 4 January, 2000 - 3:05 pm
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


Posted by Simon Martin on 5 January, 2000 - 2:45 pm
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: smartin@isys.cl


Posted by moores3 on 6 January, 2000 - 4:00 pm
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?


Posted by Gary James on 6 January, 2000 - 4:33 pm
> 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...


Posted by Lynn Linse on 5 January, 2000 - 3:54 pm
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.


Posted by Bill Hullsiek on 6 January, 2000 - 3:45 pm
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
whullsiek@andersencorp.com
MES Software Engineer
Work: 651.501.4000 x4624
Pager: 6514020946@airtouchpaging.com


Posted by Pete Sage on 7 January, 2000 - 1:46 pm
I'd take a look at using XML. The OPC Foundation is defining XML data types to layer on top of the OPC Data Access specification. This protocol is
internet ready and will end up being supported by most commercial HMI vendors.

Pete


Posted by Lynn Linse on 10 January, 2000 - 3:39 pm
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


Posted by Ken Irving on 10 January, 2000 - 3:43 pm
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
jkirving@mosquitonet.com


Posted by Mark Hutton on 7 January, 2000 - 1:49 pm
I also still believe that the widest possible range of protocols, both standard, open and proprietry should (eventually) be supported or
supportable.

I am forever telling suppliers that until their product supports the protocol that my customers have installed in their factories, I cannot
support that product.

The project not only needs interfaces to commercially produced hardware, it also needs interfaces to commercially written drivers and application software.

Of course we don't want to run, before we can walk; Modbus/TCP is an ideal starting point.


Posted by Dan Pierson on 6 January, 2000 - 3:47 pm
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


Posted by Lawrence Butler on 6 January, 2000 - 4:13 pm
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


Posted by Myron Hecht on 3 January, 2000 - 11:40 am
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: myron@sohar.com
SoHaR Incorporated
8421 Wilshire Blvd., Suite 201
Beverly Hills, CA 90211
Web Site Home Page: http://www.sohar.com


Posted by Bill Sturm on 4 January, 2000 - 3:06 pm
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


Posted by Curt Wuollet on 5 January, 2000 - 5:52 pm
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.


Posted by Robert Lunnon on 6 January, 2000 - 4:22 pm
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


Posted by Ray Henry on 3 January, 2000 - 11:41 am
> 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


Posted by Myron Hecht on 3 January, 2000 - 4:28 pm
The NIST RT Linux-based Enhanced Machine Control (EMC) project used Tcl/Tk for their GUI. This is somewhat surprising to me because it can be quite
slow, but maybe that's not too much of an issue in these days of 400 MHz embedded processors.

See
http://www.isd.mel.nist.gov/projects/emc/emcsoft.html


Posted by Bill Sturm on 4 January, 2000 - 5:32 pm
I forgot to mention this also, but I downloaded the TCL/TK binaries from http://www.scriptics.com and the demos seemed to be very fast, even on my
Pentium 100.

Bill Sturm
Applied Grinding Technologies


Posted by Brent Welch on 6 January, 2000 - 4:23 pm
Speed issues with Tcl/Tk are mostly a myth. The Tk widget set is implemented in C, and most folks find it uniformly faster that Motif and Java interfaces. The canvas and text widgets are very nice. For more info on Tcl/Tk, visit http://www.scriptics.com
you are free to use Tcl/Tk in any project, commercial or otherwise.

Brent Welch <welch@scriptics.com>
http://www.scriptics.com
Scriptics: The Tcl Platform Company


Posted by Bill Sturm on 4 January, 2000 - 3:09 pm
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


Posted by Ken Irving on 5 January, 2000 - 2:44 pm
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
jkirving@mosquitonet.com


Posted by Lynn August Linse on 4 January, 2000 - 5:31 pm
> 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


Posted by Pete Sage on 5 January, 2000 - 2:50 pm
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


Posted by Mark Hutton on 7 January, 2000 - 11:54 am
I agree entirely, and have been advocating good project management since I began posting.

This is (as far as I know) the first (positive) post in agreement.

I also agree entirely with your comments about C++. Object Orientation has a lot to offer this project.

Back (a long time ago) when I used to do a bit of C, I used to spend a lot of my time creating C++ functionality (unknowingly at the time).

I still haven't given up on Java, despite the potential performance issues, especially not for prototyping. A new realtime Java specification was issued recently, if any one is interested I'll hunt out the link for that.


Posted by Mark Hutton on 7 January, 2000 - 11:56 am
As promised here are a few (existing) Linux resources that you may find useful/interesting, that relate to this project.

First the Linux Lab project. This project has drivers for PC I/O cards, Siemens and Schnieder comms. plus lots of other goodies.

http://www.llp.fu-berlin.de

The following are three (competing?) real time Linux projects.

KURT (KU Real Time project) http://hegel.ittc.ukans.edu/projects/kurt/
RTLinux http://luz.cs.nmt.edu/~rtlinux/
REDLinux http://ece.uci.edu

The following link is to the LesTif project which is a small fast Motif implementation (HMI?)

http://www.lesstif.org

The final link I have is for a project developing IEEE1394 drivers for Linux.

http://www.edu.uni-ku.ac.at/~epiker/ieee1394.html


I haven't visited all of these sites, I found them and others at
http://www.linux.org/projects/software


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
mark.hutton@vogal.demon.co.uk


Posted by Mark Hutton on 12 January, 2000 - 12:36 pm
Another site worth a look.

http://www.tritonetd.com/danny/e_factory/


Posted by Pete Sage on 7 January, 2000 - 1:47 pm
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. This gives greater cross-platform portability to NT, CE, JINI and other to be determined platforms.

Compilation of the ladder diagrams to at least byte code is needed for performance. Interpreters are generally slow. The byte code could probably be further optimized by one of the tools that creates native java (e.g. platform specific machine code.) However, the task of creating efficient, reliable compilers is not a job for the faint of heart.

The way I see it the PLC project really has several components:

1) Langauge Editors (sfc,ladder, etc), can be added as needed
2) Language to Neutral Form converter - converts the language specific description to a neutral form.
3) Neutral Form to Target converter - coverts the neutral form to target (Exe, Java Byte Code, etc)
4) Target Execution Enviroment (for exe, JBC, etc)
5) Device specific interface modules for execution environment.

Pete


Posted by Lynn Linse on 7 January, 2000 - 2:42 pm
> 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. This gives greater cross-platform portability to NT, CE, JINI and other to be determined platforms.<

By all means pursue this.

You are welcome to contribute Java code to the LinuxPLC. It won't likely be considered for the core, but others may find it useful. There is also the possibility of using Java as an intelligent way to allow web access to the
LinuxPLC - kind of an intermediary.

Best Regards
- Lynn Linse


Posted by Mark D. Tompkins on 15 January, 2000 - 9:23 pm
> > 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!!!)


Posted by Johan Bengtsson on 10 January, 2000 - 3:45 pm
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: johan.bengtsson@pol.se
Internet: http://www.pol.se/


Posted by Pete Sage on 11 January, 2000 - 3:39 pm
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.


Posted by Jiri Baum on 12 January, 2000 - 2:47 pm
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...


Posted by Roger Irwin on 12 January, 2000 - 3:50 pm
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.


Posted by Anthony Kerstens on 30 December, 1999 - 1:19 pm
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.


Posted by Dave Geer on 3 January, 2000 - 11:34 am
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.


Posted by R A Peterson on 3 January, 2000 - 4:27 pm
How about so you get the code for free instead of having to pay outrageous fees for them.


Posted by Ken Woodard on 4 January, 2000 - 3:08 pm
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!


Posted by Simon Martin on 5 January, 2000 - 2:48 pm
Please go to the FSF (http://www.fsf.org/philosophy/free-sw.html) web site. It has an interesting description of "free". It is very educational.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: smartin@isys.cl


Posted by Johan Bengtsson on 10 January, 2000 - 3:47 pm
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: johan.bengtsson@pol.se
Internet: http://www.pol.se/


Posted by Curt Wuollet on 5 January, 2000 - 5:49 pm
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


Posted by Bill Sturm on 5 January, 2000 - 5:50 pm
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


Posted by Ken Irving on 6 January, 2000 - 4:12 pm
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
jkirving@mosquitonet.com


Posted by Dave Geer on 4 January, 2000 - 5:36 pm
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.


Posted by Michael Griffin on 5 January, 2000 - 5:57 pm
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
mgriffin@odyssey.on.ca


Posted by Johan Bengtsson on 6 January, 2000 - 9:41 am
>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: johan.bengtsson@pol.se


Posted by Ranjan Acharya on 7 January, 2000 - 9:07 am
Sorry to be cheeky, but does Redhat actually make any money?

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

In lieu of any alternative Linux is certainly the best choice of OS. However the proposed system must follow standards such as ISO 860.1 and EN
6-1131.3 / IEC 1131.3 in both action and spirit.

I absolutely agree with other postings that the actual real-time production machine (PLC) must not contain any rubbish such as the HMI and especially SCADA. The pressure from the cost-cutting side of any project is tremendous
especially if they think that they can get away with putting the MMI/HMI and PLC functionality all in one box. HOWEVER, that being said, for really small machines the HMI and PLC should be able to reside in one box. I currently work for a Systems Integrator where the one-box solution is not looked upon with any affection, but I used to work for an OEM and the cost pressures on an OEM are tremendous. A small machine does not necessarily require two boxes (granted you can go to people such as ZWorld or IEE for a small display [or even use push-buttons if no displays of statistics and animation are required]).

The thoughts of sharing one box also always brings up the issue of keeping control and factory-floor / plant / works intranets on separate buses. I have seen instances of some control (not I/O but intra-PLC communications)
being placed on the same Ethernet as the one used in the front office, luckily switches are being used.

RJ

Ranjan Acharya 905-634-0844 x 238 (V)
Team Leader - Systems Group 905-634-9548 (F)
Grantek Control Systems http://www.grantek.com/
Ranjan.Acharya@grantek.com
Ranjan.Acharya@ieee.org


Posted by Jiri Baum on 4 January, 2000 - 10:30 am
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...


Posted by moores3 on 5 January, 2000 - 5:59 pm
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.


Posted by Mark Hutton on 6 January, 2000 - 4:41 pm
Not wanting to p**s on anyones fire, or to give the impression that I don't fully agree with the usefulness of this project, but I have a number of
comments re-open source.

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

Jiri Baum replied:
>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.<

In most cases I have enough problems with the application code, of each project without having to get in and hack or even tweak system code. If
I had to do this, at all, I would shortly become unprofitable to my employers and would be seeking employment elsewhere.

The 'cost' of the software itself only becomes an issue if commercial and open source products have like for like stability and reliability.

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

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.

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

That doesn't necessarily mean that the open source licences are the natural replacement. Hell, why have a GPL, why not have no license at all.


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.

Linux is becoming more user friendly, or should I say beginner friendly, as new administration tools and wizards are added. Most of these are based on commercial tools available for other OS's, and many are due to the involvement of commercial organisations in the Linux project (Red Hat, Corel, Caldera). Because these items are added by enthusiasts, many in their spare time initial development was slow, much slower than is possible for a commercial house to move.

Linux development is moving rapidly now because, in the last eight or ten years it has picked up many thousands of enthusiasts and has the now
achieved a phenominal momentum, one that the commercial houses (even Microsoft ?) cannot hope to match.

This little project will have to start from a stand still, and it could take an extremely long time to become practical. This is not to say that we shouldn't make the attempt, I am entusiastic about the project. It will be useful, even if only from the learning perspective.

A final note:
I haven't seen any reference yet to the existing relevant Linux projects e.g. Linux Lab, which is an existing project to provide 'data aquisition and process control'. I don't have the references with me, so I will post them later.

Good Hunting! Happy New Millenium!

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
mark.hutton@vogal.demon.co.uk


Posted by Jiri Baum on 7 January, 2000 - 11:53 am
Jiri Baum:
> >- 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.

Mark Hutton:
> In most cases I have enough problems with the application code, of each
> project without having to get in and hack or even tweak system code.

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.

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

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.

Then again, even NASA gets bitten by priority inversion...

> A final note:
> I haven't seen any reference yet to the existing relevant Linux projects
> e.g. Linux Lab, which is an existing project to provide 'data aquisition and
> process control'. I don't have the references with me, so I will post them
> later.

http://www.llp.fu-berlin.de/

The GNU Scientific Library also looks interesting.
http://sourceware.cygnus.com/gsl


Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...


Posted by David Leese on 7 January, 2000 - 1:51 pm
> Jiri Baum:
> 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.<

I'll offer a third advantage. On the office side of our network, we run a custom document management database. We have the source code for software interface, so I can make changes if I have the time and desire. This comes in handy for the non-show-stopper annoyances that can be fixed quickly with a phone call to our consultant, who can talk me through line-by-line edits to the code. Small "upgrades" and bug fixes can be designed, tested and implemented in a
matter of days (with only a few minutes of my time), which tends to make everyone happy.

By the way, I think this requires a good relationship between the customer (me) and the consultant that writes the code, and I think that the open source code facilitates this relationship. We communicate monthly, if not weekly, about system performance and future upgrades. Because of the frequent communication,
my consultant becomes increasingly familiar with our system, service improves, and the relationship grows.

- David


Posted by Mark Hutton on 11 January, 2000 - 9:10 am
>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.


Posted by Jiri Baum on 10 January, 2000 - 3:42 pm
> >- 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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...


Posted by Anthony Kerstens on 5 January, 2000 - 11:06 am
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.


Posted by Michael Griffin on 4 January, 2000 - 5:35 pm
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
mgriffin@odyssey.on.ca


Posted by Ken Crater on 5 January, 2000 - 2:47 pm
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.
ken@control.com


Posted by Curt Wuollet on 4 January, 2000 - 5:38 pm
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.


Posted by Dan Pierson on 5 January, 2000 - 2:58 pm
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


Posted by Dave West on 5 January, 2000 - 10:59 am
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd.
PGP public key available on request.


Posted by Curt Wuollet on 5 January, 2000 - 11:02 am
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


Posted by Dave West on 5 January, 2000 - 11:05 am
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd.
PGP public key available on request.


Posted by Simon Martin on 5 January, 2000 - 6:05 pm
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: smartin@isys.cl


Posted by Dave West on 11 January, 2000 - 1:33 pm
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd.
PGP public key available on request.


Posted by Simon Martin on 11 January, 2000 - 5:07 pm
Hi Dave,

I don't know if there are any other operating systems handled. Check the cygnus website.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: smartin@isys.cl


Posted by Curt Wuollet on 6 January, 2000 - 9:27 am
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


Posted by Gary James on 6 January, 2000 - 5:54 pm
>... I see a group of C programs/modules...

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

I don't want to feed a flame war either but I have one feeling about the C vs C++ discussion.

A small subset of the arguments that came up during the Gnome vs KDE wars that have occured in the last year centered around the C vs C++ problem. Gnome and GTK use C for all APIs and KDE uses C++. This means that all KDE applications must be written in C++, you can't chose your favorite language.

The reason the Gnome and GTK folks chose C over C++ is it's ability to provide a frame work for many other languages. Therefore Gnome and GTK have bindings for many languages.

If we force our interfaces to be in C++, then we force all application developers that interface with our platform components to use C++.

That's just food for thought, I really have no opinion, since I know either language...


Posted by Ted Lechman on 5 January, 2000 - 11:07 am
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


Posted by Jack Gallagher on 5 January, 2000 - 2:42 pm
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: jgallagher@sesco-sw.com


Posted by Ken Irving on 6 January, 2000 - 4:20 pm
> 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
jkirving@mosquitonet.com


Posted by Stan Brown on 7 January, 2000 - 1:40 pm
>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. ?
>

You left out the PLC programing software peice of the puzzle, both for the LinuxPLC, and for existing PLC's. There is absolutely no reason I should have to retain a windoze partition just to run PLC programing software.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.


Posted by Ken Crater on 5 January, 2000 - 2:53 pm
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.
ken@control.com


Posted by Ken Crater on 6 January, 2000 - 4:38 pm
New Maillist: LinuxPLC@linuxplc.org

The maillist is now set up, and you can subscribe via either of the following routes:

1. Go to the website http://linuxplc.org/mailman/listinfo/linuxplc and use the form there to subscribe.
-or-
2. Send email to linuxplc-request@linuxplc.org with the content of the message the single word "subscribe".

The web address may also be used to control your subscription options.

This is an unmoderated list, which should allow the discussion to move more quickly. I'm hoping that we'll move most of the discussion to the new list, so it can be divided into threads with their own subject lines. I think this will make it easier to make progress on individual topics relating to the project.

Ken Crater
Control.com Inc.
ken@control.com


Posted by Mark Hutton on 7 January, 2000 - 9:39 am
>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>.<


This is like saying that because you give away the JVM (yes, I know it is not necessarily GPL'd (but what about the Linux one?)), you must give away the Java written to run on it.

Define the product. In this case the product is the virtual machine (PLC), not the code that runs on it.

Point taken however.


Posted by Ralph Mackiewicz on 7 January, 2000 - 11:58 am
> 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.<

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.

Regards,
Ralph Mackiewicz
SISCO, Inc.


Posted by David Nimmons on 7 January, 2000 - 4:24 pm
> 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.


Posted by Ralph G. McDonald on 25 April, 2000 - 3:05 pm
> > 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.<

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

> Regards,
> Ralph Mackiewicz
> SISCO, Inc.


I have been programming PLCs for many years, going back to the old 5TI with 256 words of menory. Many of my clients in industry would not allow a control program to be released because of concerns about security. I have to sign non-disclosure agreements in order to work on thier systems for process control. If they had to release the actual control programs they would not use the system. However they would probally authorize me to release a driver that I had to write for a specific divice such as a MicroMotion mass flowmeter. In order to be usefull in an industrial setting we must be careful to allow the seperation of common and propritery software.

I would also like to help with this project, however my programming experience has been Ladder Logic, Intellution Fix HMI, Forth, AB Basic, and 6502 & 6809 assembler. No C, C++ yet. I may be of more help in testing then writing code.

Keep up the good work.

Ralph McDonald

Spicer Group


Posted by Kees Kuip on 12 January, 2000 - 2:34 pm
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.


Posted by David Nimmons on 6 January, 2000 - 12:02 am
> 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.


Posted by Lynn August Linse on 7 January, 2000 - 1:45 pm
What about this as a general framework:

I. Control Code - create a "sharable" memory space for the control code. Those who want it to run blind will lose a bit of performance but those who want a RT window open to allow on-line editing of logic can do so. If the code can be formatted as lists of lists, then different blocks of code can be flagged as requiring different processors - ladder logic ... Ok, SFC ..
Ok, Forth ... Ok, Fortran ... Ok, etc. This is a user driven tool and if we retain a 32-bit tag, we could end up with millions of unique control
processors. Maybe some PhD student will create a killer auto-tuning PID processor! Those who don't want on-line editing/HMI can use an FTP tool
someone writes which just rewrites the entire code space, or a Modbus/TCP server which addresses this code memory as extended registers, or as a MMS VD. All it takes is some one to code it

II. Control Data - create a 2nd "shareable" memory space for general control scratch memory. Access to this memory must be sensitive to possible timing coordination with the running code. Perhaps this code is also wrapped as lists of nested lists and access to any sub-section is controlled by some form of header. Some code-processors will want a "update-date, run-code"
cycle; others will not care. Drivers pulling in data for the controller & the various control processors would use this memory.

III. Global scratch data - create an optional 3rd "shareable" memory for general access by remote hosts. The control code should explicitly do block
copies to move data between Control data and Global data, but access to the global data has NO relation to the control operation. This space could also be used for sharing data between remote hosts/protocols. As I mentioned before, allowing this space to be used to coordinate between Siemens, Modicon, Allen-Bradley, GE and other proprietary TCP/IP protocols could be a
big "value-added" to our work.

Really, there is NO reason to pick "one" protocol or "one" HMI method or "one" programming design.

If Curt wants to code Modbus/TCP and Bill wants to code MSS and X chooses ControlNet/CIP and Y chooses FF-HSE, then we all gain more options.

If A wants a RT/on-line interactive programming window, let A code it

If B wants ladder and C wants Flow blocks, let them all code each as each see fit.

We just need to create the wrappers & structure which allow these tools to interoperate - or at least be swappable. We are not making a "Control Tool for Dummies" here. As others have mentioned, I see the largest application being 1) VAR machine makers who tweak the code into an embedded tool, 2) students who can use it to test new control theories, and 3) Custom integrators who specialize in very detailed, niche market systems.

Best Regards;

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
lynn.linse@lantronix.com www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132


Posted by Chetan Chothani on 11 January, 2000 - 9:13 am
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


Posted by Johan Bengtsson on 11 January, 2000 - 9:14 am
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: johan.bengtsson@pol.se
Internet: http://www.pol.se/


Posted by Dan Pierson on 12 January, 2000 - 12:30 pm
---------- Forwarded message ----------
> From: "Mark Hutton" <mark.hutton@vogal.demon.co.uk>
> 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.


Posted by Mark Hutton on 12 January, 2000 - 5:36 pm
But it means you can still leverage the advantages of Object Oriented Design and Programming.


Posted by Dan Hazel on 19 January, 2000 - 9:11 am
Actually, this should only limit the use of polymorphism - as extern "C" just prevents the compiler from 'mangling' the function name..

Dan Hazel


Posted by Dan Pierson on 19 January, 2000 - 9:13 am
It also prevents you from referencing things such as member functions, which are not accessible without name mangling. Of course, they wouldn't mean much to C anyway.

One of the strengths of COM is that it does provide a C level binary interface to a very useful subset of C++ class/member functionality. Of course the C interface is a pain and the Microsoft COM definition requires that it be based on their compiler's vtable layout, but much of that is hard to avoid. (See the first chapter of Essential COM for more insight on this view of the technology, which is rather different from the Microsoft party line.)

Please folks, this last paragraph is just a technical observation, it is neither a proposal that we use COM nor an invitation to yet another
COM/CORBA flame fest.


Posted by Mark Hutton on 19 January, 2000 - 9:15 am
Can you not call the member functions from within the exported C function?

I.e. the C++ member functions are 'private' within the program module, while the exported C methods are public.

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2014 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
"This is a country where people are free to practice their religion,
regardless of race, creed, color, obesity, or number of dangling
keys ..."
Advertise here
advertisements
Servo, steppers, analog, digital & web HMI - Fully Integrated!
Servo, stepping motor control, analog & web HMI in one system!
164-page eBook free download - EtherCAT Applications Guide
View free setup and multi-vendor EtherCAT demo videos online
Time to incorporate data handling, web HMI and motion in one system!
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive