Today is...
Thursday, December 14, 2017
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A demonstration of EtherCAT control of linear motors using the CTC EtherCAT master.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Linux in the field
I would have thought that linux would be dominating automation by now. But half the links I follow even from this forum are dead. Has anyone actually used it for a commercial application?
By Patrick Allen on 25 April, 2003 - 4:26 pm

The newest Mandrake release has really polished Linux as a desktop and has made installation far easier and less painfull than loading a machine with Windows. But for some reason a lot of the open source control projects seem to have lost their steam in the last year or so. Links are broken, webpages go unmaintained. What happened?

Admittedly, I'm more of an electrician than a software developer. But I have been a Linux advocate and home user for a number of years now. But my employers have had no interest in using it commercially. Potential for troubleshooting has always been an argument against Linux. That, and the lack of at least one or two polished looking products out there; say...something along the lines of LabVIEW.

Is there something out there and I'm just missing it?

By Alex Pavloff on 26 April, 2003 - 11:12 am

Why Patrick, I'm glad you asked that question!

(Perfect segue into a little product-hawking of my own followed by some general observations about why Linux doesn't appear to be everywhere).

My company just released (this weeks) a Linux-based HMI. It doesn't run on a desktop -- rather, its using an embedded Linux to run our proprietary code that does all the things (and more) that one would expect to see from an HMI. The programming software is still Windows based. Here's the thing -- in all the companies that we talk too about applications, in all the contacts we've got, I can count the people that actually use Linux on the plant floor on one hand (and that's stretching). Linux (so far) is an IT thing. The small/medium business that my company deals with have little IT experience. They're good at making things move and things turn on.

They all use Windows on their desktops, and all the PLCs, motion controllers, and HMIs are programmed with Windows-based tools. Obviously, we'd be stupid to try and sell Linux HMI that runs on Mandrake/Red Hat/what have you to these customers. Now, the IT-savvy companies like OPC. Why? Because it works like its supposed to on Windows servers and desktops. The customers can mix and match OPC servers and applications from a variety of vendors.

In contrast, on the Linux side, there is no "critical mass" of automation software out there. Sure, you've got code here and code there, with some sample projects, but very little guidance on where to go next. Compare this to Windows, where googling for, say, "OPC tutorial" finds numerous examples on how you can quickly slap together a simple data viewer with VB.

As to why all various projects seemed to lose their steam, thats easy. The entire industry is sucking wind right now. Linux software devlopment won't help the bottom line _right now_, will it? Nope, so companies don't do it. Hence, developers that would like to work on Linux are forced to use Windows and other eeeeevvviilll things like that so that they can eat.

The difference between my company (with the just-released Linux product) is that its more of a classical embedded software system (albeit a very flexible one) sold as a piece of hardware rather than a fuzzy "customizable software-as-service" like many of the Linux advocates here and elsewhere like to push. From my viewpoint, Linux works great for embedded software projects, irregardless of any arguments about freedom or speech or beer. Hrm, its friday, I think I'll have a beer.

Alex Pavloff -- apavloff@eason.com Eason Technology --- www.eason.com --- Linux-based industrial HMI ---
-------- www.eason.com/5k --------

By Curt Wuollet on 27 April, 2003 - 10:21 pm

Hi Alex

Congrats on the new product!

On April 26, 2003, Alex Pavloff wrote:
> My company just released (this weeks) a Linux-based HMI. It doesn't run on a desktop -- rather, its using an embedded Linux to run our proprietary code that does all the things (and more) that one would expect to see from an HMI. The programming software is still Windows based. Here's the thing -- in all the companies that we talk too about applications, in all the contacts we've got, I can count the people that actually use Linux on the plant floor on one hand (and that's stretching). Linux (so far) is an IT thing. <

It's that chicken and egg thing again. I know quite a few people who would happily run Linux on the factory floor if the products were available. And the products aren't available because so few people run Linux on the factory floor. Linux is becoming very big in IT because a few of the people with the apps finally broke down and did some ports. And between Oracle and IBM and what you can get from the OSS community, you can do IT with Linux fairly comfortably.

The critical path was convincing application vendors, not customers. That is especially true in automation since the hardware is not generic and the OSS community can't help as much. No matter how much I want to I can't really make products for an AB shop or a GE shop. But, it's crazy to cite a lack of customers when there's nothing for them to buy. It's like saying I'm not going to bring out this new car line because nobody's bought any of them yet. Except for people like myself who can roll their own, how could there possibly be Linux customers with no Linux products?

The small/medium business that my company deals with have little IT experience. They're good at making things move and things turn on.

> They all use Windows on their desktops, and all the PLCs, motion controllers, and HMIs are programmed with Windows-based tools. Obviously, we'd be stupid to try and sell Linux HMI that runs on Mandrake/Red Hat/what have you to these customers. Now, the IT-savvy companies like OPC. Why? Because it works like its supposed to on Windows servers and desktops. The customers can mix and match OPC servers and applications from a variety of vendors.
>
> In contrast, on the Linux side, there is no "critical mass" of automation software out there. Sure, you've got code here and code there, with some sample projects, but very little guidance on where to go next. Compare this to Windows, where googling for, say, "OPC tutorial" finds numerous examples on how you can quickly slap together a simple data viewer with VB.
>
> As to why all various projects seemed to lose their steam, thats easy. The entire industry is sucking wind right now. Linux software devlopment won't help the bottom line _right now_, will it? Nope, so companies don't do it. Hence, developers that would like to work on Linux are forced to use Windows and other eeeeevvviilll things like that so that they can eat.
>
> The difference between my company (with the just-released Linux product) is that its more of a classical embedded software system (albeit a very flexible one) sold as a piece of hardware rather than a fuzzy "customizable software-as-service" like many of the Linux advocates here and elsewhere like to push. From my viewpoint, Linux works great for embedded software projects, irregardless of any arguments about freedom or speech or beer. Hrm, its friday, I think I'll have a beer. <

Again congrats on the Linux product, even if it's a closed one.

Regards

cww

By Michael Griffin on 28 April, 2003 - 10:13 am

On April 26, 2003 07:12, Alex Pavloff wrote:
<clip>
> My company just released (this weeks) a Linux-based HMI. It doesn't run on
> a desktop -- rather, its using an embedded Linux to run our proprietary
> code that does all the things (and more) that one would expect to see from
> an HMI. The programming software is still Windows based.
<clip>
> They all use Windows on their desktops, and all the PLCs, motion
> controllers, and HMIs are programmed with Windows-based tools. Obviously,
> we'd be stupid to try and sell Linux HMI that runs on Mandrake/Red Hat/what
> have you to these customers.
<clip>

The MMI panel is "automation". The programming software is "office use", just like the CAD or project management software that gets used as part of the same project as well. I think this is a very important distinction to make. "Automation software" runs on systems which control or interact closely with machines. "Office software" runs on computers which get used for general
purpose computing tasks.

There are other people debating whether Linux is ready to take over the office. That sort of discussion belongs on another mailing list however. If you wanted to hedge your bets, you might think about making sure your software is desgned so that a port to a Linux desktop won't be a catastrophic experience if you feel the need for it several years from now. Most of what would be required for that would probably be prudent software design in any case.

************************
Michael Griffin
London, Ont. Canada
************************

By Alex Pavloff on 28 April, 2003 - 5:05 pm

> The MMI panel is "automation". The programming software is
> "office use", just like the CAD or project management software that gets
used as
> part of the same project as well. I think this is a very important
> distinction to make. "Automation software" runs on systems which control
or
> interact closely with machines. "Office software" runs on computers which
get used
> for general purpose computing tasks.

So what category does the custom VB app or SCADA system running on bog-standard Windows go into? Office or Automation?

> There are other people debating whether Linux is ready to
> take over the office. That sort of discussion belongs on another mailing
> list however. If you wanted to hedge your bets, you might think about
making sure your
> software is desgned so that a port to a Linux desktop won't
> be a catastrophic experience if you feel the need for it several years
from
> now. Most of what would be required for that would probably be prudent
software
> design in any case.

I do much of my debugging on a Linux desktop, and yeah, my stuff could run there with a few modifications and mainly some more robust configuration options. Heck, using C++ and some clever libraries, I suspect even a Windows port wouldn't be too far out of line (although the HMI itself would have to be rewritten).

Alex Pavloff -- apavloff@eason.com
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------

By Michael Griffin on 29 April, 2003 - 9:42 am

On April 28, 2003 13:04, Alex Pavloff wrote:
<clip>
> So what category does the custom VB app or SCADA system running on
> bog-standard Windows go into? Office or Automation?
<clip>

Automation. It is operating in a dedicated industrial application. I think this is a useful distinction to make. The software for a dedicated
application can be selected according to its own merits. General purpose (office) applications are affected by what everyone else (finance, sales,
product design, human resources, etc.) is using.


************************
Michael Griffin
London, Ont. Canada
************************

By Petr Baum on 29 April, 2003 - 9:34 am

Hi Alex

a) You can make sure that your Windows based programming software is WINE compatible. It may require some - probably insignificant - changes but it will allow people to make choice.

b) Where can we get more information about this product, please? (reply to private address or to may be appropriate...)

Thanks

Petr

--
<petr@baum.com.au>

Petr Baum, P.O.Box 2364, Rowville 3178
fax +61-3-97643342

By Alex Pavloff on 29 April, 2003 - 5:57 pm

Petr Baum wrote:
> a) You can make sure that your Windows based programming
> software is WINE compatible. It may require some - probably insignificant -
> changes but it will allow people to make choice.

Well, I'll try it. Can't promise anything though. The program does make heavy use of DAO and COM, so if it falls over because of that, it isn't exactly an "insignificant" change. :-)

> b) Where can we get more information about this product,
> please? (reply to private address or to may be appropriate...)

Check my signature at the bottom.

Alex Pavloff -- apavloff@eason.com
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------

By Michael Griffin on 26 April, 2003 - 11:38 am

On April 25, 2003 12:26, Patrick Allen wrote: <clip>
> The newest Mandrake release has really polished Linux as a desktop and has
> made installation far easier and less painfull than loading a machine with
> Windows. But for some reason a lot of the open source control projects
> seem to have lost their steam in the last year or so. Links are broken,
> webpages go unmaintained. What happened?
<clip>
> Is there something out there and I'm just missing it?
<clip>

I'm not really the one to answer this, but since you haven't had any other replies yet, I'll make an attempt. "What happened" is that not a lot has happened yet. I think the biggest problem is that people don't know what needs they should be fulfilling.

--

************************
Michael Griffin
London, Ont. Canada
************************

Michael:

Actually, at least as far as my stuff is concerned, my projects have languished because of unemployment and lots of it too (essentially since last June).

My projects, CELL, ABEL, etc..., have all fallen by the wayside as trying to find employment has moved into the "job #1" position. This coupled with the strong urge to change careers (after 8+ years in this field) and also keeping my family happy and fed has consumed what little free time I have had for my Linux based projects. End result - the projects sit stagnant.

--
Ron Gage - Saginaw, Michigan
I am looking for work - resume at http://www.rongage.org/resume.doc
Electrical Engineering, Linux Programming, Networking

By Michael Griffin on 28 April, 2003 - 10:49 am

On April 27, 2003 06:08, Ron Gage wrote:
<clip>
> My projects, CELL, ABEL, etc...,
<clip>

These are drivers for communicating with AB PLCs. This is exactly the type of basic software "infrastructure" which needs to be in place before Linux is used widely "in the field".

I believe that industrial communications drivers is one of the key technologies Linux requires for use in automation. What is also needed is some sort of common API for these drivers, equivalent to what OPC does for Windows. At the moment though, the common API is probably less important than the drivers being available.


************************
Michael Griffin
London, Ont. Canada
************************

By Joe Jansen on 28 April, 2003 - 4:53 pm

Out of curiosity, has anyone done this work for Omron? Any links for finding it?

Thanks!


--Joe Jansen

By Donald W. Carr on 28 April, 2003 - 4:50 pm

Devices that communicate via ethernet can work very well under Linux, no special driver needed, just re-compile the communication routines for
your version of Unix or Linux. For example:

http://www.edasce.com/multifunctionedas.asp

I am not sure what operating system they use for the device itself, might be Linux?

By Alex Pavloff on 28 April, 2003 - 4:59 pm

Michael Griffin wrote:
> I believe that industrial communications drivers is one of the key
> technologies Linux requires for use in automation. What is
> also needed is some sort of common API for these drivers, equivalent to
what
> OPC does for Windows. At the moment though, the common API is probably
> less important than the drivers being available.

Here's the other thing: The drivers can't be GPLed. LGPLed, *yes*, but I don't think that any integrator is going to write a bunch of code so as to control the widget machine and just give that away to anyone that asks. Sure, small programs that twiddle a few bits and turn on a motor, yeah, but I can't see any integrator spending weeks on a project and just giving the
machine-specific code away.

This is one of the issues that has to be addressed -- directly -- by anyone wanting to push GPL software into machines.

Alex Pavloff -- apavloff@eason.com
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------

Alex Pavloff:
> Here's the other thing: The drivers can't be GPLed. LGPLed, *yes*,
> but I don't think that any integrator is going to write a bunch of
> code so as to control the widget machine and just give that away to
> anyone that asks. Sure, small programs that twiddle a few bits and
> turn on a motor, yeah, but I can't see any integrator spending weeks
> on a project and just giving the machine-specific code away.

In reality, it's not such a big problem, because:

- The GPL requires the integrator to give the code to the client, but
not to anyone else. Indeed, the integrator can be under NDA not to
give the code to anyone else, and that's quite OK under the GNU GPL.

The client probably wants the code anyway, and the right to fix it and
make improvements, so there's no difference there. The GPL protects
the client by making it clear that they are allowed to do that.

http://www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA

- There is no publishing requirement, merely a right.

- The integrator gets paid by the hour to make the machine work (or by
the estimated hour to make the machine work). Whether that code ends
up on one machine or a thousand makes no essential difference.

The only real difference is in the amount of support required, so the
contract should be carefully formulated as to the amount of support
that's included in the price (ie, only for the one machine).

- It is machine-specific. Most likely the next machine will be improved,
requiring someone (an integrator) to update the code and, perhaps more
importantly, verify that it is still appropriate.

> This is one of the issues that has to be addressed -- directly -- by
> anyone wanting to push GPL software into machines.

Most of the packages make no such statement about user programs, anyway,
so that the stepladder might have completely different licensing than
the automation package running it.

This is the same as using the gcc (GNU C compiler) to compile a program:
it says nothing about the license for the program, even though the gcc
is GPL.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Blunier, Mark on 29 April, 2003 - 5:34 pm

> From: Jiri Baum
>
> Alex Pavloff:
> > Here's the other thing: The drivers can't be GPLed. LGPLed, *yes*,
> > but I don't think that any integrator is going to write a bunch of
> > code so as to control the widget machine and just give that away to
> > anyone that asks. Sure, small programs that twiddle a few bits and
> > turn on a motor, yeah, but I can't see any integrator spending weeks
> > on a project and just giving the machine-specific code away.
>
> In reality, it's not such a big problem, because:
>
> - The GPL requires the integrator to give the code to the client, but
> not to anyone else. Indeed, the integrator can be under NDA not to
> give the code to anyone else, and that's quite OK under the GNU GPL.

The argument was that the integrator would not his code spread around - assuming that the integrator owned the code.

So there are times that a LGPL license might be more palatable to integrators that do not want their code redistributed. But I wouldn't go so far as to say GPL shouldn't be used, but rather some people may prefer LGPL over GPL.

- There is no publishing requirement, merely a right.
>
> - The integrator gets paid by the hour to make the machine work (or by
> the estimated hour to make the machine work). Whether that code ends
> up on one machine or a thousand makes no essential difference.

It makes a very big difference. When we have a company A come in and put in a distillation system, even though we paid them to design the process, it is there design. We can't take their engineering drawing and sell or give them to company B to have them build another system just like it. Code linked with GPL'd drivers would be free for us to give away as we like. Code linked with LGPL'd drivers could be restricted.

>
> > This is one of the issues that has to be addressed -- directly -- by
> > anyone wanting to push GPL software into machines.
>
> Most of the packages make no such statement about user
> programs, anyway,
> so that the stepladder might have completely different licensing than
> the automation package running it.

They should make such a statement. They should be very clear as to when the copyright holder considers the user program a modification of the
main program if it is something that has its own license.

> This is the same as using the gcc (GNU C compiler) to compile
> a program:
> it says nothing about the license for the program, even though the gcc
> is GPL.

Its close, but not the same. Gcc code can run after its been compiled without gcc being installed. It is probably more similar to using
binary modules compiled separate from the Linux kernel.

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

By Curt Wuollet on 5 May, 2003 - 4:41 pm

This is a matter that has to be thought through rather than going with the way things have always been done. I'm confident there are ways that will benefit all parties. There is always an agreement
( or should be ) outside the software licenses and this is a good vehicle for such considerations. This agreement is a legal contract
and arguably easier and cheaper to enforce than the area of software licenses anyway. It would sure be great if we could get a lawyer who knows the subject area to enlighten us, pro bono, as a service to the community. We really should have a scheme worked out that we can suggest. And I don't think we can be sure opining on our own.

Regards

cww

By Jiri Baum on 12 June, 2003 - 5:56 pm

> > Alex Pavloff:
> > > Here's the other thing: The drivers can't be GPLed. LGPLed,
> > > *yes*, but I don't think that any integrator is going to write a
> > > bunch of code so as to control the widget machine and just give
> > > that away to anyone that asks. Sure, small programs that twiddle
> > > a few bits and turn on a motor, yeah, but I can't see any
> > > integrator spending weeks on a project and just giving the
> > > machine-specific code away.

Jiri Baum:
> > In reality, it's not such a big problem, because:
> > - The GPL requires the integrator to give the code to the client, but
> > not to anyone else. Indeed, the integrator can be under NDA not to
> > give the code to anyone else, and that's quite OK under the GNU GPL.

Mark Blunier:
> The argument was that the integrator would not his code spread around
> - assuming that the integrator owned the code. <

The integrator is being paid by the client; as such, the client has (should have) final say as to who may or may not have the code, etc.

> So there are times that a LGPL license might be more palatable to
> integrators that do not want their code redistributed. But I wouldn't
> go so far as to say GPL shouldn't be used, but rather some people may
> prefer LGPL over GPL. <

Never the end-users, though, as far as I can see.

> > - There is no publishing requirement, merely a right.
> > - The integrator gets paid by the hour to make the machine work (or
> > by the estimated hour to make the machine work). Whether that code
> > ends up on one machine or a thousand makes no essential difference.
> It makes a very big difference. When we have a company A come in and
> put in a distillation system, even though we paid them to design the
> process, it is there design. We can't take their engineering drawing
> and sell or give them to company B to have them build another system
> just like it. <

Precisely. If you decide that company A no longer meets your needs and you want company B to take over that part of your supply, you will have to pay for that part of the design *again*, even though you've paid for it once already, and then have to live with having a mixture of two different designs.

Much better to insist that company A use the GPL in the first place and then simply have company B take over when circumstances so dictate (or some other licensing arrangement that allows this).

This means, of course, that company A will have to be paid for the design in full (that is, in cash rather than in lock-in), but that's fairer all around anyway.

> > > This is one of the issues that has to be addressed -- directly --
> > > by anyone wanting to push GPL software into machines.
> > Most of the packages make no such statement about user programs,
> > anyway, so that the stepladder might have completely different
> > licensing than the automation package running it.
> They should make such a statement. They should be very clear as to
> when the copyright holder considers the user program a modification of
> the main program if it is something that has its own license. <

They should, true.

> > This is the same as using the gcc (GNU C compiler) to compile a
> > program: it says nothing about the license for the program, even
> > though the gcc is GPL.
> Its close, but not the same. Gcc code can run after its been compiled
> without gcc being installed. It is probably more similar to using
> binary modules compiled separate from the Linux kernel. <

Note that binary modules in the kernel are a special exemption granted by Linus, and tend to be a lot of bother to use.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael R. Batchelor on 14 June, 2003 - 12:42 pm

Unless the customer has an explicit "work for hire" agreement, or the integrator works on-site "at the customer's direction" the code belongs to the integrator by international copyright law. Most customers will disagree with this, and my little 5 man two room integration firm isn't going to take on Ford Motor Company's lawyers to argue it, but those are the rules.

MB
--
Michael R. Batchelor - Industrial Informatics, Inc.
Contribute to society: http://www.distributed.net/ogr/
MB

By Jiri Baum on 17 June, 2003 - 2:36 pm

> > Mark Blunier:
> > > The argument was that the integrator would not his code spread
> > > around - assuming that the integrator owned the code.

Jiri:
> > The integrator is being paid by the client; as such, the client has
> > (should have) final say as to who may or may not have the code, etc.

Michael Batchelor:
> Unless the customer has an explicit "work for hire" agreement, or the
> integrator works on-site "at the customer's direction" the code
> belongs to the integrator by international copyright law. Most
> customers will disagree with this, and my little 5 man two room
> integration firm isn't going to take on Ford Motor Company's lawyers
> to argue it, but those are the rules.

Which is why the client should insist on the GPL (or similar) up-front rather than being unpleasantly surprised afterwards.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Peter Whalley on 17 June, 2003 - 10:48 pm

Hi Michael,

That's the default situation in most jurisdictions if the contract says nothing to the contrary. Many clients however will explicitly require in their contracts that they get assigned copyright. If so then that's what they get.

The problem arises however when the SI or consultant is either re-using code developed on a previous project and wishes to retain rights to use this in the future or is producing code on a project but would like to be able to use it in the future or is using code under license but doesn't own it (very common if you use libraries or boiler plate text).

In the first case the client is not paying to have the code produced but is just paying to make use of the code for this project. In all my contracts where the client requests ownership of IP I put in a caveat that it only applies to material created specifically as part of the project.

In the second case you may not charge the full cost of development because of the future value of the work done or you may assign ownership to the client but on the condition that they license you in reverse to allow you to use the code for other projects in future.

At the end of the day IP rights are defined under contract not on the basis of what anyone thinks is fair or reasonable but have not bothered to document. And yes sometimes might is right.

This is not legal advise. If you need legal advice see a lawyer.

Regards

Peter Whalley

By Ralph Mackiewicz on 18 June, 2003 - 5:16 pm

Mark Blunier wrote:
> > > The argument was that the integrator would not his code
> > > spread around - assuming that the integrator owned the
> > > code.

Jiri Baum wrote:
> > The integrator is being paid by the client; as such, the
> > client has (should have) final say as to who may or may not
> > have the code, etc.

Michael R. Batchelor wrote:
> Unless the customer has an explicit "work for hire" agreement, or the
> integrator works on-site "at the customer's direction" the code
> belongs to the integrator by international copyright law. Most
> customers will disagree with this, and my little 5 man two room
> integration firm isn't going to take on Ford Motor Company's lawyers
> to argue it, but those are the rules. <

Your take on copyright law is correct. My personal opinion is that most customers aren't really interested in "owning" this code anyway. They will typically just want to have the flexibility to use what they paid for internally. I suspect that most integrators don't have a problem with their customers using the code they produce for a project more liberally than what a strict interpretation of copyright law would allow. I think having integrators own the code is better for the user in the long run. Integrators that are allowed to retain this stuff will be more productive on the next job if they don't have to redo it again to avoid using pre-existing code (assuming that you could even identify what was prexisting and what wasn't). Integrators that own code will be motivated to improve it. As long as the integrator treats the user reasonably, as the vast majority do, the original user reaps the benefit in subsequent projects. Besides, there is very little truly original code produced unless it is the first project done by the integrator. All code produced is generally a by-product of the code previously produced by the same integrator. This happens even if the code is not copied instruction by instruction. After a couple of projects, a user isn't paying the entire cost anymore. This is one of the many reasons why users like experienced integrators.

Regards,
Ralph Mackiewicz
SISCO, Inc.

By Bob Pawley on 20 June, 2003 - 1:41 pm

Hi Ralph

If the integrators own the code what's to stop them from charging the client ongoing licensing fees as do all proprietary software vendors?

When I hire a programmer to do work for me I make sure he gives up any rights to the code - or he doesn't get the job.

If I ran a plant I would also retain the copyright. Why should I pay for developing code, and the great expense of testing it, that my competitor can obtain for less money (maybe a lot less) or with which the software developer can make a profit at my expense? If he wanted the right to resell for his profit I would expect that our deal would involve very favorable terms for me. If this isn't happening now, it will soon change when the plant operators realize what it is costing them.

Bob Pawley

By Ralph Mackiewicz on 23 June, 2003 - 7:19 pm

On June 20, 2003, Bob Pawley wrote:
> If the integrators own the code what's to stop them from charging the
> client ongoing licensing fees as do all proprietary software vendors? <

Nothing, unless you have an agreement. We would typically grant the client a paid-up, irrevocable, non-exclusive license to use the code. That way, we can use our own pre-existing works without losing ownership of the stuff we already developed and we don't have to re- create everything from scratch for each new project. Clients typically don't need ownership. They just need to use the code,so this approach works in that case.

> When I hire a programmer to do work for me I make sure he gives up any
> rights to the code - or he doesn't get the job. <

That is your choice and we have also done work under these conditions. There are certain kinds of projects, those that require we use pre-existing works to be effective, where we could not accept those terms. I suppose the company that eventually won that project would disagree, but IMHO the customer did not receive the best value. They simply paid too much to have software created that didn't need to be created just so that they could own software that they didn't need to own.

> If I ran a plant I would also retain the copyright. Why should I pay
> for developing code, and the great expense of testing it, that my
> competitor can obtain for less money (maybe a lot less) or with which
> the software developer can make a profit at my expense? If he wanted
> the right to resell for his profit I would expect that our deal would
> involve very favorable terms for me. If this isn't happening now, it
> will soon change when the plant operators realize what it is costing
> them. <

If you are paying on a time and material basis and are accepting the entire risk of the development, then ownership would be appropriate. There are also circumstances where the code embodies a proprietary process that gives you a competitive advantage. In that case, it would make sense for you to own the result. I'm not sure that is typical though. I've seen clients demand ownership for routine stuff that was done a hundred times before and will be done a thousand times more. All they get is routine software that costs them more than it should. Or, the integrator just included pre-existing work and took a chance that anybody would notice it in the future. That is probably more typical.

Regards,
Ralph Mackiewicz
SISCO, Inc.

By Dick Caro on 20 June, 2003 - 9:47 pm

Right on Ralph! All integrators worth their rates will have blocks of code that they have written for themselves or others to which they can claim ownership. When I worked at Modcomp in the "old days" our standard agreement was that any original code belonged to Modcomp, while any existing code used by the contract programmer/ integrator was forever licensed to Modcomp. This is called "Intellectual Property" (IP) by the courts, and provision for the protection of IP should be in all contracts in which programming or other technology is provided by a supplier. It is even more important when the customer intends to merchandise products containing that IP. Read the fine print!

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: RCaro@CMC.us
Web: http://www.CMC.us
============================================

By Lynn at Alist on 19 June, 2003 - 11:57 pm

On June 12, 2003, Jiri Baum wrote:
>The integrator is being paid by the client; as such, the
>client has (should have) final say as to who may or may not
>have the code, etc. <

Of course, "receiving the code" is not the same as actually having it. I once was contracted to evaluate the "source code" some big company had been given as part of a contract 4 years earlier. Unfortunately, at hand-over some idiot just looked at all the thousands (literally) of files of code and said "Yup, looks like the source is here". They may even have run a "Make" to confirm it could recreate the code.

Unfortunately, they didn't look through the code itself. The contractor had run some form of filter thru 95% of it. Literally all comments were striped, all variables and function calls had been renamed to things like int2345 and func0345(). And the 5% that missed the filter had all comments and variable name in a foreign language.

So in effect they had nothing really usable - even though they had the source code. ;^]

- Lynn

By Michael Griffin on 22 June, 2003 - 8:04 pm

On June 19, 2003 23:53, Lynn at Alist wrote: <clip>
> Unfortunately, they didn't look through the code itself. The contractor
> had run some form of filter thru 95% of it. Literally all comments were
> striped, all variables and function calls had been renamed to things
> like int2345 and func0345(). And the 5% that missed the filter had all
> comments and variable name in a foreign language.
> So in effect they had nothing really usable - even though they had the
> source code. ;^]
<clip>

This sounds like something that used to be called "shrouded source code". I haven't heard of it in a while, but it was used at one time for distributing libraries. You could compile it so it was to some degree portable, but it was impractical (or at least extremently difficult) to see how it actually worked.

Of course, quite a few people produce Visual Basic programs that look like that without needing any additional help at all...

--

************************
Michael Griffin
London, Ont. Canada
************************

By Michael Griffin on 29 April, 2003 - 10:04 am

On April 28, 2003 12:57, Alex Pavloff wrote:
<clip>
> Here's the other thing: The drivers can't be GPLed. LGPLed, *yes*, but I
> don't think that any integrator is going to write a bunch of code so as to
> control the widget machine and just give that away to anyone that asks.
> Sure, small programs that twiddle a few bits and turn on a motor, yeah, but
> I can't see any integrator spending weeks on a project and just giving the
> machine-specific code away.

That depends on what the project is. If someone were doing a custom integration job for me as an end user, I would expect to get the source code
anyway (as part of the terms of the contract), even without a GPL. "Weeks" is not a very big custom project for PC software. More common are ones which take months (which drag on into years...).

"Open source" means the source code must be provided to the end user. It doesn't mean you have to post it on the internet. If the customer is the end user and is going to receive the source code anyway, then using GPL drivers
changes nothing of significance. The integrator isn't "giving it away" if the customer paid him for it. The customer would be the one "giving it away" if they *didn't* demand the source code which was written during the hours they paid for.

> This is one of the issues that has to be addressed -- directly -- by anyone
> wanting to push GPL software into machines.
<clip>

Note that in many GPL licenses there is nothing to prevent you from reaching a separate deal with the author of the software. If you want to use their stuff for free then yes, you have to make any "derivative works" open source also.
However, if you are willing to negotiate a commercial license from them, you can use it in a conventional closed source product. The GPL driver software still belongs to the original author and he can do what he wants with it,
including selling licenses for closed source use.

However, I would say that your point is an important one. If someone is planning on organising a "driver project" with many parties contributing various minor bits to a common pool, then this needs to be addressed by one means or another. A "common driver" project may have advantages if it gets the drivers tested and debugged quickly by a lot of people with various odd hardware in different applications. The situation you are concerned about could arise though if the authorship were so diffused that it was unclear who actually owned it. There is no point in having drivers lying about gathering dust because of licensing issues.

Of course, there is also no reason why companies wouldn't offer conventional commercial drivers. If all communications drivers were easy, people wouldn't be able to sell them for DOS or Windows either.


************************
Michael Griffin
London, Ont. Canada
************************

By Donald W. Carr on 29 April, 2003 - 6:18 pm

>I don't think that any integrator is going to write a bunch of code so as to
>control the widget machine and just give that away to anyone that asks.
>Sure, small programs that twiddle a few bits and turn on a motor, yeah, but
>I can't see any integrator spending weeks on a project and just giving the
>machine-specific code away.

You assume that large projects do not work under open source. To see this is wrong, look at all of the big open source projects. Linux, Apache, OpenOffice, Gimp, and so on. With open source, companies make money on consulting and services, and give away the source code. Of course customers sometimes end up paying for open source development when they need something added to an existing open source project to fit their specific needs. They get to use the main software for free, but pay for modifications that others can later use for free. This is often much cheaper than starting from scratch, or paying a vendor to add to a proprietary project, where he will then own these modifications and charge you and others for it over and over again in the future. This is kind of like open science where we can build on the work of others. The great thing from a customer perspective is that you avoid vendor lock-in. This may be bad for established companies that are used to incorporating a lot of customers ideas into their product, then charging for them over and over again like it was their idea! There will eventually be a number of large open source project for control applications. Some will fail, some will succeed. I plan on starting one or two myself.

By Alex Pavloff on 30 April, 2003 - 5:12 pm

> ------------ Forwarded Message ------------
> From: Donald W. Carr
>
> >I don't think that any integrator is going to write a bunch of code so
as to
> >control the widget machine and just give that away to anyone that asks.
> >Sure, small programs that twiddle a few bits and turn on a motor, yeah,
but
> >I can't see any integrator spending weeks on a project and just giving
the
> >machine-specific code away.
>
> You assume that large projects do not work under open source. To see
> this is wrong, look at all of the big open source projects. Linux,
> Apache, OpenOffice, Gimp, and so on.

You mean like the programs I use on a regular basis? I am well aware of the benefits of open source. Here's the thing though -- we here at Eason are an OEM. Frequently, we get calls from integrators who don't want the people they're selling the machines too to be able to buy products direct from us, upload the code, and cut out the integrator. Less frequently we get calls
from end users wondering how they can upload code from units and buy products directly from us.

If I was buying a machine -- yeah, I would definitely want all the source. However, thats _not_ always the case, and I think stepping anywhere into the realms of GPL (as opposed to LGPL) for any industrial project that involves
piles of C code, _especially communications drivers_, is a complete non-starter.

Alex Pavloff -- apavloff@eason.com
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------

Alex wrote:
> You mean like the programs I use on a regular basis? I am well aware of the
> benefits of open source. Here's the thing though -- we here at Eason are
> an OEM. Frequently, we get calls from integrators who don't want the people
> they're selling the machines too to be able to buy products direct from us,
> upload the code, and cut out the integrator. Less frequently we get calls
> from end users wondering how they can upload code from units and buy
> products directly from us.

Ok, I can see companies like that. They are greedy, they want to use free software that others created, and then add their proprietary extensions and keep it to themselves to lock in the customer and lock out competition. The reason
for using the GPL vs the LGPL (or BSD) is to prevent this type of behaviour. And the end users really should demand the source code (no matter what the license) to avaoid the lock-in and over charging. The companies like to charge for
modifications, then charge the customer again and again on subsequent machines. If the customer pays for the changes, they should insist on rights to them. Most customers realize too late that they were screwed.

>From the point of view of a programmer, who realeases open source software, it
would be very disapointing to have someone use your software, make propriatary
extensions, make lots of money, and not even give back the changes. This is an
issue of fairness. The GPL prevents this type of behaviour.

>From the point of view of fragmentation, you can end up with fragmentation when
many people use the software, then keep the changes proprietary. This is what
happend with Unix. Each Unix vender wanted to differentiate themselves and lock
in customers. This was good for them in the short term, but bad for Unix (not
compatible), and maybe bad for them in the long run. With the GPL, the best
changes all get folded back in and everybody uses the same version which has all
the best features and is compatible. Customers can not get locked in and
everybody competes based on merit.

So, a project might be much more successfull in the long run using GPL. There might be some people that refuse to use your software for reasons that have been mentioned, but in the end you have a product that is not fragmented and includes the best changes from all users. Some believe that as customers become more and more educated on open source, they will be less and less likely to let vendors lock them in with their dirty tricks. The vendors will be forced to release the source code and compete on the merits.

Well, that said, GPL is not for everything or everybody. A device manufacturer would want to release drivers for their hardware under LGPL or BSD so they hardware could be incorporated into proproietary and non-proprietary systems. And, it is a free world. Many successful project are LGPL or BSD like. Take Apache for instance (BSD like) and OpenOffice (LGPL).

Don.

By Curt Wuollet on 29 April, 2003 - 9:32 am

I would add that an "Industrial Automation" API built specifically for the purpose could be much more efficient and needn't be nearly as complex or bloated. And I quite agree about comms drivers. With some vendor cooperation this could happen quickly. Without it, it may not happen at all. The vendors really control that aspect.

Regards

cww

By Curt Wuollet on 28 April, 2003 - 10:58 am

Hi Ron

I'm sure this has affected many OSS folks. A great many do something else during the day and so, don't benefit from the fact that Linux is
growing and expanding rapidly as even PHBs are required to look at the value/cost/benefit equation. The problem is, that Linux in the roles it is dominating, doesn't create many jobs. Replacing dozens of Windows servers with a few Linux boxen may actually create unemployment as one person can manage quite a few servers that stay running. So far, the "lack of Linux talent" argument that is ballyhooed whenever people want
to keep Linux out, has been shown to be a farce when a Linux job posting produces a very vigorous response from qualified people, both unemployed
and those who are employed but doing something else. I was told by one employer that I was about applicant #240 for a Linux SA job. As this thing continues to snowball, I expect to see great opportunity, if we don't starve to death first.

Linux in automation will probably lag far behind, as the monopoly is well entrenched and the vendors enforce it and openness prevention
vigorously. Birds of a feather and all that.

The unfortunate part is that folks like you and I are interested in automation rather than ISPs or corporate IT and are victims of a vast and successful "dumbing down" movement. This is focused on ensuring that most computer related jobs can be filled with lower paid, "windows
operators" rather than skilled labor or specialists. This is good for business but very bad for progress and advancing the state of the art. The number of people who actually create things has plummeted as the number of folks who simply run other people's creations has skyrocketed. This is not meant as criticism, but as a reflection of what is really going on. Is the revolution over, so now they are shooting
revolutionaries? Is it now just a business thing rather than a science or technology thing? Is automation a place for machanics rather than
engineers? Should I be looking for a haven with the craftsmen of yesteryear? Or perhaps a tar pit with a friendly compliment of other
dinosaurs? Are we there yet?

I just went through the unemployment experience and for the first time, I was left with the impression that being a knowledgable and experienced "computer guy" with a hardware background was a liability rather than an asset. And to add insult to injury, people would actually ask me if in addition to designing, building, and coding test systems, if I could
possibly "run Windows" and would even look skeptical when I assured them that I could operate a mouse and reboot at need. Isn't there
something very wrong when this is held as the height of achievement? This was held in much higher esteem than even whether I could interpret
ladder diagrams, which was also grudgingly accepted with some skepticism.

What I heard was, "Experts?, We don't need no steenking experts!" Is this where the industry is where you are?

I now hold a maintenance job, which strangely, pays as well as any of the openings I have seen. What happened since the last time I changed jobs? And is this percieved leap in technology holding the adoption of Linux back?

Regards

cww

Curt,

I too, am recently unemployed, and I believe this bias toward windows was partially responsible for my current situation. Early on in the last major
project I was looking at using Linux and GNU tools for a distributed automation platform.

However, the powers that be were more convinced that the "availability of Windows programmers" was a strong enough argument (not to mention the "hacker's OS" taint) to stick with Windows and Visual C++ and Windows CE. If anyone knows windows

CE back at version 2.?, it scarcely had a nodding acquaintance with real-time and robustness. Also, I naively though it might not be too bad, because I could one piece of code that could run on NT and CE (same binaries) - Wrong!

Suffice to say, the project has had several project leaders and direction changes over
several years, where it probably would have been completed under a year the GNU/Linux way.

One linux practitioner tells me companies like to have "one neck to choke" when things go wrong and they don't feel they get that with Linux.

Well, today Windows CE is almost to the point of being usable, but it's too late for me.

Perhaps my experience with Windows CE and Visual C++ may give me more job openings available, but it also may be a clue to the nature of the folks I'll be working for...

And a general jobless observation, (not Windows vs. Linux):

It seems most employers want specialists that have been working with the same stuff for a
couple years. I, unfortunately, have smatterings of experience in different stuff (PLC's, PC's,
Motion control, Barcode readers, software, hardware, firmware etc..). Hard to market oneself as bright and versatile but without a specialty.

Rufus

By Walt Boyes on 30 April, 2003 - 1:50 pm

You are an Industrial IT Generalist. Use it.

Walt Boyes
"advice to the 'joblorn' columnist"
AutomationTechies.com

---------------------
Spitzer and Boyes LLC
"consulting from the engineer
to the distribution channel"
21118 SE 278th Place
Maple Valley, WA 98038
Ph. 425-432-8262
Fx. 253-981-0285
walt@waltboyes.com
www.spitzerandboyes.com
--------------------------

By César García on 27 April, 2003 - 10:21 am

I think, that many people don't say anything about that.

The backend = Linux
The frontend = Windows

Regards,

César García

By Peter Whalley on 27 April, 2003 - 11:37 pm

Hi All,

To which I would add:

embedded controller with TCP/IP comms = Linux

This is happening big time but in most cases the operating system is all but invisible.

I'm involved in a project with some 300 embedded servers (Axis cameras) running Linux and talking to 10 or so servers running Win200 and similar number of HMI also running Win2000.

Regards
Peter Whalley
Magenta Communications Pty Ltd
Melbourne, VIC, Australia
e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending

By Curt Wuollet on 27 April, 2003 - 9:39 am

What's missing in this market are customers willing to demand Linux solutions and become part of the community. The intentional barriers set up make it very painful to get out of whatever same old thing you are into. For example, the company I work for has consolidated their enterprise IT on Linux on huge IBM mainframes, but I'm still stuck using RSLogix on Windows because there isn't RSLogix for Linux.

Regards

cww

By Bob Pawley on 27 April, 2003 - 10:38 pm

Maybe the time has come to make two lists that should reinforce the role of Linux in the control industry.

List 1 - The strengths of Linux as control system.

List 2 - The weaknesses of Linux as a control system.

If Linux proponents and Linux detractors wish to participate, by posting their thoughts and perceptions, I'll keep a running record and post the results when the two lists appear to be complete.

Bob Pawley

By Curt Wuollet on 29 April, 2003 - 9:30 am

Sounds like a good idea: I'll start.

Pro: It isn't Windows and makes some things much easier.

Con: It isn't Windows and new ways of doing things would have to be learned.

Pro: No license hassle.
Con: Less vendor opportunity for upgrade revenue and customer control.

Pro: Excellent communications with standard protocols and commodity equipment.

Con: Very Limited support for the "Tower of Babel" and "special" hardware at present.

Pro: Can't be owned or subverted or managed for profit.
Con: This makes vendor support unlikely.

Regards

cww

Hey Curt,

There is no RSLogix for Linux because nobody is asking for it! There is no RSLogix for Apple computers for same reasons. 1 or 2 people ask now and then but not enough for any benefit for the porting of software.

As other people have mentioned here, Linux is great for embedded products because there are no runtime fees. Microsoft, however, is very competitive but will struggle to crack this market.

The only hope for Linux products on the desktop is when there is a .NET port available for Linux. This allows software development to target both platforms with little cost.

On April 25, 2003, Patrick Allen wrote:
> But for some reason a lot of the open source control projects seem to
> have lost their steam in the last year or so. Links are broken,
> webpages go unmaintained. What happened?

In a couple of weeks, there's a Libre Software in Automation Workshop in Leuven, Belgium. It is expected that it will improve cooperation between the various projects, so that instead of disjoint pieces of code there will be a more-or-less coherent system. It should also raise the profile of work which now might be taking place behind somewhat closed doors. (We are aware of a number of projects running in parallel and/or orthogonal with ours.)

As far as MAT is concerned (I can't speak for anyone else), we're still going! We're aware that there was some slow-down, but we expect that the Leuven workshop will give this work new impetus.

We will keep you informed.

> Potential for troubleshooting has always been an argument against
> Linux.
Isn't it the other way around? :-)

> That, and the lack of at least one or two polished looking products
> out there; say...something along the lines of LabVIEW.
Agreed.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

Would you (or anybody else) be willing to contribute to our wish-list document?

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael Griffin on 28 April, 2003 - 11:54 am

On April 27, 2003 08:46, Jiri Baum wrote:
<clip>
> On April 26, 2003, Michael Griffin wrote:
> > I think the biggest problem is that people don't know what needs they
> > should be fulfilling.
>
> Would you (or anybody else) be willing to contribute to our wish-list
> document?
<clip>

Perhaps you could tell us what you consider "using Linux" to be? Is this supposed to be about "using Linux", or is it supposed to be about "Open Source" which happens to use Linux? Siemens, Sixnet, and now apparently Eason all "use Linux" in some fashion. I could add several more companies to the list if I spent the time to look up their names. These companies are not in the "open source" business though. They just picked an operating system which they thought made good technical and economic sense. I sometimes get the impression that what some people have in mind when they say "Linux" is a
philosophy rather than an operating system.

To answer your question more closely, one of the biggest things that you lack now which can be readily solved is a good way to make information available. Someone who is new at this, doesn't know where to start. Telling someone to use Google, or to search around on Sourceforge, or to post a question on a mailing list isn't good enough.

You need a central web site which points to where to find things. This should include useful commercial items as well (e.g. people who provide Linux drivers with their special boards). The "automation" market includes a lot of overlap with the lab and scientific fields, so these sources should be kept in mind as well when they are useful (drivers for data acqusition boards,
signal processing libraries, etc.). "Automation" on Linux also requires conventional software tools as well (e.g. Python) as alternatives to things like "VB" which are used on Windows.

I would suggest you also need an "official" organisation to promote what people are doing. "Jiri Baum's Web Page" doesn't sound very impressive to people who don't know you. Something like "www.LinuxAutomation.org" however
sounds like something to take seriously when the trade magazines get your press releases. A lot of what counts in this business *is* just good
promotion. Arguing with people on this mailing list doesn't constitute promotion.

Finally, I would suggest that you give careful consideration to what your target market should be for the near future. I see three main areas which would have near term promise:

1) Machine OEMs who use PC based controls in standard machine designs. Some of these write their own softlogic or MMI software.

2) Automated production test equipment.

3) Interfaces to IT systems.

************************
Michael Griffin
London, Ont. Canada
************************

By Jiri Baum on 29 April, 2003 - 9:37 am

Michael Griffin:
> > > I think the biggest problem is that people don't know what needs
> > > they should be fulfilling.

Jiri Baum:
> > Would you (or anybody else) be willing to contribute to our
> > wish-list document?

Michael Griffin:
> Perhaps you could tell us what you consider "using Linux" to be? Is
> this supposed to be about "using Linux", or is it supposed to be about
> "Open Source" which happens to use Linux?

Yes, Open Source, sorry. Should've made that clearer.

> To answer your question more closely,

Thank you.

> one of the biggest things that you lack now which can be readily
> solved is a good way to make information available.

Right. Each project has its own webpage, but there's no way of finding
out which project(s) one needs for a given problem.

> The "automation" market includes a lot of overlap with the lab and
> scientific fields, so these sources should be kept in mind as well
> when they are useful (drivers for data acqusition boards, signal
> processing libraries, etc.).

Yes - MAT has interfacing with the COMEDI (www.comedi.org) drivers in the wishlist, but nobody's managed to put in the code yet. COMEDI has drivers for quite a few data acquisition boards.

Signal processing libraries and the like we'll have to look out for.

> "Automation" on Linux also requires conventional software tools as
> well (e.g. Python) as alternatives to things like "VB" which are used
> on Windows.

We have python; any others that we should cover?

> I would suggest you also need an "official" organisation to promote
> what people are doing. "Jiri Baum's Web Page" doesn't sound very
> impressive to people who don't know you.

Right - that goes with the central information repository problem.

> Finally, I would suggest that you give careful consideration to what
> your target market should be for the near future. I see three main
> areas which would have near term promise:

Yup.

Thank you

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael Griffin on 2 May, 2003 - 2:10 pm

On April 29, 2003 05:36, Jiri Baum wrote:
<clip>
> > "Automation" on Linux also requires conventional software tools as
> > well (e.g. Python) as alternatives to things like "VB" which are used
> > on Windows.
>
> We have python; any others that we should cover?
<clip>

C/C++, Java, Borland Kylix (Delphi), and Labview should rate a mention as many people will prefer to use something they are already familiar with and these alternatives may be better suited for certain applications. You wouldn't need to provide too much detail on these other languages, other than to point out where to get more information on them.

As well as langauge compiler or interpreter, most projects need additional components. GUI builders, math and signal processing libraries, databases, etc. The point should not be to build an exhaustive list (this would be difficult to maintain), but rather to show people that what they need for their projects is available.

I mentioned three areas which I thought you should concentrate on for the near term. I think if you made a list of typical software each one would need, then you would have a pretty good idea of how to recommend collections of packages. I would strongly suggest that you not neglect listing commercial offerings. Following are some brief examples.

1) Machine OEMs who use PC based controls in standard machine designs, in particular ones who write their own proprietary software.
- Soft logic system. Some sort of motion control is typically needed with these.
- CNC control.
- Computer based custom MMI. This would be just a "widget" set and not a large scale "MMI system".
- Drivers for I/O systems (Profibus, etc.).
- Web browser for the help system.
- Web server for reporting production statistics.
- How to do the above on a diskless system (solid state drive).

2) Automated production test equipment.
- Programming languages (Python, etc.).
- Widget sets (for MMI).
- Database for logging test results.
- Data acquisition board drivers.
- Drivers for interfacing to PLCs (Profibus, Modbus, etc.).
- Bar code generator (for serialised labels).

3) Interfaces to IT systems.
- Drivers, drivers, and more drivers.
- Web servers, XML stuff, etc.

************************
Michael Griffin
London, Ont. Canada
************************

By Jiri Baum on 12 June, 2003 - 6:13 pm

> > > "Automation" on Linux also requires conventional software tools as
> > > well (e.g. Python) as alternatives to things like "VB" which are
> > > used on Windows.

Jiri Baum:
> > We have python; any others that we should cover?

Thanks for the list, Michael - I'm definitely saving it for future reference...

Michael Griffin:
> C/C++,

Natively supported by the MatPLC.

> Java, Borland Kylix (Delphi),

Not familiar with them, but they shouldn't be particularly difficult; just a question of writing a small wrapper around the MatPLC library.

> and Labview

Labview is proprietary, so it's up to them to be compatible with us. Not much we can do about it. We might be able to use something like Modbus to interface to them, but that would always be a kluge.

> You wouldn't need to provide too much detail on these other languages,
> other than to point out where to get more information on them.

Right.

> As well as langauge compiler or interpreter, most projects need
> additional components. GUI builders,

For now, we use glade, which is a general-purpose GUI builder.

> math and signal processing libraries,

MatPLC has a "DSP" module which does some of this.

> databases,

We can log to a database right now, but not very flexibly. Of course, a python script can be used to do that, or anything else that goes between a database and a MatPLC setup.

> 1) Machine OEMs who use PC based controls in standard machine designs, in
> particular ones who write their own proprietary software.
> - Soft logic system. Some sort of motion control is typically
> needed with these.

Classicladder is the preferred one, it's a graphical ladder thingy. Other than that, we have a simple mnemonics compiler, and the IEC languages are in progress.

Motion control we don't have, but we're in communication with the Orocos and EMC controller projects, which each have that.

> - CNC control.

See the EMC controller project. Interface with the MatPLC is currently being discussed and planned.

> - Computer based custom MMI. This would be just a "widget" set
> and not a large scale "MMI system".

MatPLC has this.

> - Drivers for I/O systems (Profibus, etc.).

We have a few of those, but not nearly enough, and most of them are through the Hilscher cards.

> - Web browser for the help system.

Yeah, use a standard web browser.

> - Web server for reporting production statistics.

Juan has an on-line demo which links MatPLC to Zope and does this kind of thing, but the howto is not all there. I don't remember the URL, but there's a link from our homepage (http://mat.sf.net).

> - How to do the above on a diskless system (solid state drive).

Largely the same as normal - Linux doesn't make much of a distinction between different kinds of drives. The only specialty would be executing the programs directly from the drive (XIP - eXecute In Place).

> 2) Automated production test equipment.
> - Programming languages (Python, etc.).
> - Widget sets (for MMI).
> - Database for logging test results.

As above.

> - Data acquisition board drivers.

COMEDI is the standard library for this; linking MatPLC and comedi is near the top of the to-do list.

> - Drivers for interfacing to PLCs (Profibus, Modbus, etc.).

As above.

> - Bar code generator (for serialised labels).

No idea, here; a quick search shows that linux should be able to generate UPC-A, UPC-E, EAN-13, EAN-8, ISBN, code 39, code 128 (b and c), and interleaved 2 of 5, but I've no experience with it.

> 3) Interfaces to IT systems.
> - Drivers, drivers, and more drivers.

Yeah.

> - Web servers, XML stuff, etc.

XML has been strongly pushed at the Linux in Automation workshop, but I don't think anyone is using it yet.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael Griffin on 14 June, 2003 - 12:57 pm

On June 12, 2003 17:44, Jiri Baum wrote: <clip>
> Precisely. If you decide that company A no longer meets your needs and
> you want company B to take over that part of your supply, you will have
> to pay for that part of the design *again*, even though you've paid for
> it once already, and then have to live with having a mixture of two
> different designs.
<clip>
> This means, of course, that company A will have to be paid for the
> design in full (that is, in cash rather than in lock-in), but that's
> fairer all around anyway.
<clip>

I think what was being discussed wasn't an "integrator", even though that was the term used. There are a lot of applications involving off the shelf equipment where although the general theory is common knowledge, the actual methods, equations, and algorithms used are secret. If you buy a balancing machine, you are not really paying for the manufacturer's software and assembly manhours. You are paying for their detailed knowledge and experience of the application area which is incorporated into the hardware/software design.

For the customer, there is no benefit in having "the design in full". This level of sophistication is far beyond most customers, and even further beyond any typical third party "integrator" they may wish to hire.

If you are not aware of the type of equipment I am talking about, then you are missing your main opportunity. These sorts of companies are the ones who are most likely to be interested in "Linux in automation" in the near future. They provide a finished product, they have service departments, and they already provide ongoing support for their customers. Their customers buy a finished product, and don't specify what sort of "computer stuff" goes into it. If any application is going to introduce Linux into the factory in an obvious way in the near future, this is it.

You're not going to get the interest of these people though, unless you can provide a way for them to use drivers (Profibus, Modbus, etc.) without putting the entire application under GPL. Either you grasp this nettle firmly and deal with it, or else write off your best prospects.

--

************************
Michael Griffin
London, Ont. Canada
************************

By Jiri Baum on 19 June, 2003 - 10:33 pm

On June 14, 2003, Michael Griffin wrote:
> There are a lot of applications involving off the shelf equipment
> where although the general theory is common knowledge, the actual
> methods, equations, and algorithms used are secret.
...
> You're not going to get the interest of these people though, unless
> you can provide a way for them to use drivers (Profibus, Modbus, etc.)
> without putting the entire application under GPL. Either you grasp
> this nettle firmly and deal with it, or else write off your best
> prospects.

In other words, you think we should write their code for them, but not expect them to give anything back?

(The GPL doesn't require people to contribute back; but it does encourage it.)

I agree that there are certain applications for which proprietary code is an advantage, though they are probably much more rare than you think; but part of the cost of writing proprietary code is that one may not use the great treasury of code that is Open Source.

There are sufficient other markets in which the MatPLC can thrive without compromising the core principles upon which it is built.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael Griffin on 22 June, 2003 - 8:03 pm

On June 19, 2003 22:30, Jiri Baum wrote: <clip>
> In other words, you think we should write their code for them, but not
> expect them to give anything back?
<clip>

I think they can write code for you, if you will let them. The things you should be looking for co-operation on are things like communications drivers, GUI widgets, and other commodity building blocks. They want to protect their trade secrets from the 2 or 3 other companies in the world that compete with them. They can share the commodity items with the hundreds of companies that don't.

> I agree that there are certain applications for which proprietary code
> is an advantage, though they are probably much more rare than you think;
The number of different applications is small, but since these machines get produced in quantity (e.g. in hundreds or thousands), the designers can afford to spend more time on the software. They will spend years on a development project, rather than trying to get a one-off out the door in weeks. They have the time to work on the sorts of things you want to do, and they have the incentive since the effort can be spread over a large number of sales.

> but part of the cost of writing proprietary code is that one may not use
> the great treasury of code that is Open Source.
I would be rather surprised if you were not aware that virutally every major business software company except Microsoft is basing the future of their business on combining their proprietary offerings with open source commodity foundations. And quite frankly your statement is simply wrong in that the GPL isn't the only open source license. Even Microsoft was able to cut and paste a lot of BSD and other stuff into Windows.

> There are sufficient other markets in which the MatPLC can thrive
> without compromising the core principles upon which it is built.
<clip>

The MatPLC is intended as a complete stand alone product. I agree that the safest thing to do with it is to license it under GPL. Anything else has too much potential for problems.

However, this doesn't address what to do about things that are essentially general purpose libraries. The most important item that comes to mind is communications drivers. Why can't they be treated under a license that requires the libraries to be open source, but allows them to be linked to a proprietary program (LGPL)?

--

************************
Michael Griffin
London, Ont. Canada
************************

By Jiri Baum on 23 June, 2003 - 7:30 pm

On June 19, 2003, Jiri Baum wrote:
> > In other words, you think we should write their code for them, but
> > not expect them to give anything back?
> <clip>

On June 22, 2003, Michael Griffin wrote:
> I think they can write code for you, if you will let them.

See below about MS and BSD - they'll write code, but not for us.

...
> > but part of the cost of writing proprietary code is that one may not
> > use the great treasury of code that is Open Source.

> I would be rather surprised if you were not aware that virutally every
> major business software company except Microsoft is basing the future
> of their business on combining their proprietary offerings with open
> source commodity foundations. And quite frankly your statement is
> simply wrong in that the GPL isn't the only open source license. Even
> Microsoft was able to cut and paste a lot of BSD and other stuff into
> Windows.

Yes, but didn't do BSD any good, did it?

What would be the point of putting ourselves in the same situation?

> > There are sufficient other markets in which the MatPLC can thrive
> > without compromising the core principles upon which it is built.
> <clip>

> The MatPLC is intended as a complete stand alone product. I agree that
> the safest thing to do with it is to license it under GPL. Anything
> else has too much potential for problems.

Precisely.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Alex Pavloff on 24 June, 2003 - 1:16 pm

Jiri, you completely ignored Michael's original point -- which was the very valuable idea that the PLC drivers should be broken off into a separate LGPLed library. As it stands, you can see all the people that ask on this list about Modbus drivers. Good serial & TCP drivers that could be improved upon by a community would be great -- and the fact that they are separate and can be linked with proprietary apps would be a great benefit. Add a generic scheme for accessing PLCs, and you could shortly have *the* robust and 'standard' Linux communications library.

Heck, if you had done that a year ago the _last time_ I suggested this very point, there's a good chance that I would have happily used that as the basis for my Linux based HMI (see sig). Instead, since you tied the PLC drivers so closely to the rest of the MAT project (of which I have very little interest), I went and wrote my own, and will continue to write my own.

You and project lost out -- because I think you see the entire MAT project as a whole, when bits of it could useful in completely different places. You expect the users of your project to use some sort of barely working CSV format, when in fact, they'd be very happy banging together a simple program in C and just using your MAT project to talk to other devices.

But its your project -- feel free to make decision so that people that DO have to deal with things like code ownership can't use your project in anyway. Its your call, even though I think its the wrong one.

Alex Pavloff -- apavloff@eason.com
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------

By Curt Wuollet on 25 June, 2003 - 10:18 pm

Hi Alex

Jiri is not responsible for that decision in any case. Licensing is the sole right of the author. Very early on, it was agreed that the project would consist of GPL'd code, period. The author is free to also license his code LGPL or BSD or whatever. We will certainly consider LGPL where appropriate, but it's use tends towards sneaking closed code into places where we would prefer Open code. You wrote code for which there is a price in dollars and you prefer not to share. We respect your right to license your code as you see fit. I haven't ever suggested that you should contribute it or share it. We write code for which the price is writing more Open code and sharing it if you publish. This way each contributor gets back more than they contribute and the rest of the world gets to use it free for abiding by the rules. This whole rift started because you wanted to take what you could have for free and exploit it in a manner unacceptable to the author and that is the very reason we write under the GPL. Each file is clearly identified as to authorship and it is extremely easy to get in touch with our coders. You could make arrangements for a license for your purpose if the author is willing. And you can certainly buy numerous implementations of the Modbus code. I find expecting something for nothing and expecting payment for the work of others somewhat inconsistant. In the end, you did the right thing and wrote your own code for the purpose of selling it. Just as I would not expect to use your code free outside your license. you should not expect to sell our code for profit outside our license. I see that as very reasonable, I'm not sure why you don't. We are contributing for the purpose of increasing the amount of code available to anyone who needs it and ask only that the GPL be respected and that improvements and derivatives be shared. You are free to use the code in any manner consistant with that goal as defined by the GPL. I see no need for hard feelings. As the founder, I can live with the consequences, good and bad of upholding these principles. Our code gets read and used more than your code.

Regards

cww

By Jiri Baum on 27 June, 2003 - 1:43 pm

What Curt wrote... (Well, I did suggest you could contribute, but it was just that - a suggestion.)

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael Griffin on 29 June, 2003 - 12:36 pm

On June 27, 2003 13:32, Jiri Baum wrote: <clip>
> (In the absence of such a layer, it will probably be the MatPLC that
> does this; let us know your plans for it, so we don't duplicate effort.)
<clip>

I started writing some nonsense about investigating the need to write a 3964 for a future project when I thought I really ought to do a more thorough web search to see if its been done already. A google search on "linux siemens 3964" turned up the following:

http://www.control.com/997885484/index_html

> Aug 15, 2001 11:12 am, by Curt Wuollet
> Subject : LinuxPLC Project
> Hi all
> Found some interesting items when configuring a new RH7.1 kernel.
> There is support for Applicom protocol cards. (profibus and various others).
> There is support for a Siemens r3964 protocol (serial).
> Does anybody know, or want to find out, how we can use these?
> We really should take advantage of gimme's
> Regards
> cww
It sounds like some of this stuff comes built in to Linux already. Perhaps we ought to contact this guy somehow and ask him if he can help us out ...

--

************************
Michael Griffin
London, Ont. Canada
************************

By Jiri Baum on 30 June, 2003 - 2:42 pm

Thanks for pointing that out - that really does belong on our to-do list, but Curt wrote that before we had one, so it didn't get put in.

It's there now - SF tickets 762967 and 762968.

Thank you

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Jiri Baum on 26 June, 2003 - 1:16 am

Alex Pavloff:
> Jiri, you completely ignored Michael's original point -- which was the
> very valuable idea that the PLC drivers should be broken off into a
> separate LGPLed library.

That is, of course, a possibility - and MatPLC is quite happy to cooperate with such separate libraries (see below).

> Add a generic scheme for accessing PLCs, and you could shortly have
> *the* robust and 'standard' Linux communications library.

That is largely what the MatPLC is.

If you wish to access the MatPLC from proprietary code, you'll be able to do so once we implement the CORBA interface, which is on the to-do list. (Sorry - we'd love to have everything finished already, but...)

> Heck, if you had done that a year ago the _last time_ I suggested this
> very point, there's a good chance that I would have happily used that
> as the basis for my Linux based HMI (see sig).

On the other hand, most of this is the kind of functionality we'd like to have as part of the MatPLC - really, there's no reason why different vendors should implement different versions of features like buttons and
alarming. These should be part of the basic infrastructure.

> You expect the users of your project to use some sort of barely
> working CSV format, when in fact, they'd be very happy banging
> together a simple program in C and just using your MAT project to talk
> to other devices.

I'm not sure what you mean here (what CSV format?) - but if you want to bang together a simple program in C as a user, there's no problem using the MatPLC. As far as the program is concerned, MatPLC is just a library that does its stuff, largely behind the scenes; and since you're the
user, the restrictions on distribution don't apply to you (because you aren't planning to).

> But its your project -- feel free to make decision so that people that
> DO have to deal with things like code ownership can't use your project
> in anyway. Its your call, even though I think its the wrong one.

If you think an LGPL library and generic scheme for accessing PLCs is the Right Thing to do - why don't you? We'll be quite happy to use your architecture as I/O, it'll allow us to concentrate on other interesting parts of the project.

I believe this is currently a gap; COMEDI does this for data acquisition cards, but I don't think anybody is doing it for access to PLCs. MatPLC can try to fill this gap (by using PLC-specific libraries where they are available, writing them when they're not), but a generic scheme on the same layer as COMEDI would be sensible.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael Griffin on 25 June, 2003 - 10:50 pm

On June 23, 2003, Jiri Baum wrote: <clip>
> Michael Griffin:
> > I think they can write code for you, if you will let them.
>
> See below about MS and BSD - they'll write code, but not for us.
<clip>

My example of how Microsoft has copied BSD (and other open source) code into Windows was not intended as an example of how things should be done. It was used as an extreme example to point out that the GPL is not the only open source license. I did not suggest that a BSD type license would be a good idea for a driver library.

Whatever sort of license is used, I think the communications drivers need to be a stand alone project, and not tied to something else. It also needs some sort of systematic treatment (by someone who understands it better than I do) to define a general API for different drivers. If someone for example wanted to write a 3964 driver, they should hopefully create an interface to it that isn't too radically different from what someone else created for a Modbus (or DF1) driver.

At this point it probably isn't worth while trying to create an open source OPC equivalent until there is a large enough collection of useful drivers in place to justify the effort. A basic driver project though should be one of the cornerstones of any "Linux in the field" effort.

--

************************
Michael Griffin
London, Ont. Canada
************************

By Jiri Baum on 27 June, 2003 - 1:38 pm

Michael Griffin:
> My example of how Microsoft has copied BSD (and other open source)
> code into Windows was not intended as an example of how things should
> be done. It was used as an extreme example to point out that the GPL
> is not the only open source license. I did not suggest that a BSD type
> license would be a good idea for a driver library. <

Right.

> Whatever sort of license is used, I think the communications drivers
> need to be a stand alone project, and not tied to something else. <

As I wrote to Alex - it would be a good idea for such a project to exist. I myself ain't going to start it, because I have a big enough to-do list as it is (in MatPLC and elsewhere), but it would be a good idea if somebody did.

> It also needs some sort of systematic treatment (by someone who
> understands it better than I do) to define a general API for different
> drivers. <

Yup. Again, I suggest you look at COMEDI (and get in touch with them, if you start this project) - as a source of ideas for this API. Obviously, there will be some differences; but much will be similar.

> At this point it probably isn't worth while trying to create an open
> source OPC equivalent until there is a large enough collection of
> useful drivers in place to justify the effort. A basic driver project
> though should be one of the cornerstones of any "Linux in the field"
> effort. <

Actually, it's a sort of chicken-and-egg situation: there are drivers out there - CANopen, ABEL, that sort of thing - but without a uniform API, they're just individual projects that don't get the critical mass. If somebody joined two or three of the existing libraries under one
umbrella, it would benefit them all.

(In the absence of such a layer, it will probably be the MatPLC that does this; let us know your plans for it, so we don't duplicate effort.)

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael Griffin on 14 June, 2003 - 12:59 pm

On June 12, 2003 18:07, Jiri Baum wrote: <clip>
> > - Bar code generator (for serialised labels).
>
> No idea, here; a quick search shows that linux should be able to
> generate UPC-A, UPC-E, EAN-13, EAN-8, ISBN, code 39, code 128 (b and c),
> and interleaved 2 of 5, but I've no experience with it.
<clip>

There is bar code generation software for Linux (I don't recall what it is called), but I believe it prints to ordinary laser printers. This is fine for applications which print on paper, but is no good for proper label printers.

"Label printers" are generally thermal transfer printers which print on rolls of label stock, and can handle various difficult media including things like foil. They typically use a printer language like "IPL" (Intermec Printing Language) or "ZPL" (Zebra Printing Language). These printer languages are generally human readable (if somewhat cryptic) ASCII text.

Now that I think of it a bit, I'm not sure that bar codes would be a big problem with these printers, as it is possible that the printers may generate the bar code graphic internally from ASCII text. I would have to check some manuals to see if this is so. I've only used bar codes for constant data, and I haven't used them for serialising (yet), so I haven't checked this point carefully.

Label design software would be nice though. Normally, you can buy label design software where you draw the label on the screen and it writes the label printer "program" for you. It would be nice to be able to run this software on the system that has the label printer hooked up to it so that when you introduce a new label you can "tweak" the label design on the spot as you try it out. This is a lesser issue though.

I seem to have used a lot of words to say that maybe there isn't a real problem here after all. I will report back on this if I can remember to check it out at work.

> > - Web servers, XML stuff, etc.
>
> XML has been strongly pushed at the Linux in Automation workshop, but I
> don't think anyone is using it yet.
<clip>

XML is a buzz word you have to have. You want to be able to say "we have XML" to show that you have your full complement of jargon. There are lots of XML parsers for Linux, so availability of tools is not a problem. The problem is going to be figuring out ways of making use of it.

I can see a use for XML though as a form of electronic data sheet. The XML tags would get embedded in the actual data sheet. You can read the data sheet, and your machine can read it too. This sounds a lot less cryptic than GSD files, especially if you could edit it in OpenOffice using some form of template. This might be a good standardised way of creating configuration or initialisation files that are self documenting.

--

************************
Michael Griffin
London, Ont. Canada
************************

By Curt Wuollet on 17 June, 2003 - 4:16 pm

I have personally used Zebra printers with Linux, no problem. I also wrote software to generate barcode labels on an ordinary epson inkjet once upon a time for a hospital system. The Zebras work well, but are kinda spendy, both initially and in consumables. A good inkjet will cut the cost per label way down. It might be hard to write the software now as half the printers are Winjunk and the rest are so dumbed down that you can't get the technical information you need on raster graphics methods. Fortunately, the Linux ghostscript driver source can be mined for much useful information. But, a quick google for Linux barcode shows that you wouldn't have to roll your own anymore. This was a big deal 10 years ago.

Regards

cww

By Ralph Mackiewicz on 18 June, 2003 - 5:17 pm

Michael Griffin wrote:
> > > - Web servers, XML stuff, etc.

Jiri Baum wrote:
> > XML has been strongly pushed at the Linux in Automation workshop,
> > but I don't think anyone is using it yet.
<clip>

...snip...snip...

Michael Griffin wrote:
> I can see a use for XML though as a form of electronic data sheet. The
> XML tags would get embedded in the actual data sheet. You can read the
> data sheet, and your machine can read it too. This sounds a lot less
> cryptic than GSD files, especially if you could edit it in OpenOffice
> using some form of template. This might be a good standardised way of
> creating configuration or initialisation files that are self
> documenting. <

IMHO, XML is an excellent way of creating configuration/installation files that are self documenting. If XML was popular years ago, concepts like the Device Description Language and Profibus GSD files would be much more widely used than they currently are in their IA specific formats. For instance, the IEC61850 standard is using XML for the basis of a substation configuration language (SCL) that enables the configuration of substation devices to be described in an open manner.

Regards,
Ralph Mackiewicz
SISCO, Inc.

By Greg Goodman on 19 June, 2003 - 1:50 pm

This sort of software is available for Linux. Here are some highly capable commercial offerings:

http://www.nicelabel.com/nicelabel/nlbl_ver_linux.php
http://www.unibar.com/
http://www.labelsoftware.com

Here's the most capable open source package I found:

http:/ http://www.kbarcode.net/

From the project's Freshmeat page:

KBarcode is a barcode and label printing application for KDE 3. It can be used to print everything from simple business cards up to complex labels with several barcodes, such as article descriptions. KBarcode comes with an easy-to-use WYSIWYG label designer, a setup wizard, batch
import of labels (directly from the delivery note), thousands of predefined labels, database managment tools, and translations in many languages. Even printing more than 10,000 labels in one go is no problem for KBarcode. Additionally, it is a simple xbarcode replacement for the
creation of barcodes. All major types of barcodes like EAN, UPC, CODE39, and ISBN are supported.

Regards,

Greg Goodman
Chiron Consulting

By Michael Griffin on 21 June, 2003 - 12:57 am

On June 19, 2003, Greg Goodman wrote: <clip>
> This sort of software is available for Linux. Here are some highly
> capable commercial offerings:
>
> http://www.nicelabel.com/nicelabel/nlbl_ver_linux.php
> http://www.unibar.com/

These both look very interesting. The Nicelabel product has some Linux printing software for doing certain things, but not for actual label design. Their label design software is still Windows only. I'm not quite sure just what Unibar was offering.

This issue isn't very important though. If you are printing serial number labels at test stations, you don't need any special software to print the labels. The label designs are a file, and you print that file to the printer. Given that commercial label design software tends to be rather expensive, it may not really be that desireable to have it loaded on the test equipment just to let you try out new label designs.

> Here's the most capable open source package I found:
>
> http:/ http://www.kbarcode.net/

I was aware of this one. It uses a back end which generates postscript. This is good for conventional printers, but not for thermal label printers which use specialised printing languages. I haven't seen any label printers which use postscript (I rather wonder why that is so).

--

************************
Michael Griffin
London, Ont. Canada
************************

AFAIK the main developer of kbarcode is working on ZPL translation in these days. He was able to create ZPL file (should be suitable for Zebras). But this features are not finished yet and therefore not included in stable versions. But it should be question of few weeks to have kbarcode exporting to ZPL.

Postscript is often used in Linux as an intermediate format (rather like PDF), to be translated into whatever the printer does support before being sent out the parallel port.

This means that any printer listed as working with linux will work with kbarcode. Check ttp://www.linuxprinting.org for particular models - there are some thermal label printers listed as "works perfectly".

Most printers actually work this way, since only high-end printers support postscript natively. Postscript requires a fairly grunty processor and lots of memory, which low-end printers don't have.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael Griffin on 2 February, 2004 - 10:34 am

In reply to Jiri Baum's message of the 31st of January,

The sort of industrial thermal transfer label printers I am familiar with don't work the same way as document printers. You've described a CUPS printing system, which is used for document printing (that is, almost all normal printing).

Industrial printers such as Zebra or Intermec have their own printing languages (ZPL and IPL respectively). Many other similar brands of printer use the same print engines, and so also use ZPL or IPL.

Software which wants to print bar codes on document printers would normally send it as a graphic image to the printer. This means the software in the computer needs to know how to generate and scale the bar code.

A ZPL or IPL printer however will generate the bar code within the printer itself. The computer doesn't need to know how to create bar codes. You send the printer a command to generate the bar code, together with the data to be encoded. Lines and text are created similarly. This tends to be much faster than downloading large high quality graphic images to the printer, especially as you can often send subsequent commands to modify only part of the label (e.g. a serial number). You can print graphic images (e.g. logos), but these tend to be slower. These printers are not intended as general purpose printers, but are optimised for printing labels (product labels, shipping labels, etc.).

"GG" mentioned in his message that Kbarcode has experimental support of ZPL. According to the Kbarcode web page, they are also working on IPL (the latest versions support both, but this feature isn't considered ready for production yet). I appreciate his bringing this development to my attention.

This is significant because when you need a printer, you fairly often need a PC to go with it. A good example would be to conduct a test, store the test results in a database, and print out a product label with a serial number linked to the test results.

Labels are normally designed by using commercial label software which will have a WYSIWYG label editor. These would then generate a ZPL or IPL file. This software tends to be quite expensive and (when I last looked) runs on Windows only, so Kbarcode support of ZPL and IPL is good news for "Linux in the field" (our subject). Having the label software on the production PC is a convenience when you are testing a new label because it allows you to make minor changes to it on the spot. Commercial label design software costs an arm and a leg, so you normally buy one copy to install at your desk and copy the label files to the target PC.

I should point out though that while you use this software to design the labels, you don't need it to actually print labels. You just send the label file to the printer as is, or modify it dynamically (for variable data). In other words, this software is very "nice to have", but you can work without it if you need to, so its present "work in progress" status wouldn't prevent someone from using "Linux in the field". Having said that, I still welcome this development.

The above explanation holds for labelling applications which are part of the production process. Shipping and warehousing operations may have different requirements that I am not familiar with.

As a matter of minor interest, a search on Google for "kbarcode +ZPL" lists as 4th from the top a conversation we had last summer on this subject (see this subject, 14th of July 2003), which is the thread which "GG" quoted from.

On January 31, 2004 00:08, Jiri Baum wrote: <clip>
> Postscript is often used in Linux as an intermediate format (rather like
> PDF), to be translated into whatever the printer does support before being
> sent out the parallel port.
> This means that any printer listed as working with linux will work with
> kbarcode. Check http://www.linuxprinting.org for particular models - there
> are some thermal label printers listed as "works perfectly".
> Most printers actually work this way,
<clip>

--

************************
Michael Griffin
London, Ont. Canada
************************

On February 2, 2004, Michael Griffin wrote:
> The sort of industrial thermal transfer label printers I am familiar with
> don't work the same way as document printers.
...
> Industrial printers such as Zebra or Intermec have their own printing
> languages (ZPL and IPL respectively). Many other similar brands of printer
> use the same print engines, and so also use ZPL or IPL.
...
> A ZPL or IPL printer however will generate the bar code within the printer <
...

Right, my mistake.

> "GG" mentioned in his message that Kbarcode has experimental support of
> ZPL. According to the Kbarcode web page, they are also working on IPL (the
> latest versions support both, but this feature isn't considered ready for
> production yet). <

According to the webpage, ZPL was added 21 Oct 2003 and IPL was added 31 Oct 2003, so there's probably not that much difference between them.

> I should point out though that while you use this software to design the
> labels, you don't need it to actually print labels. You just send the label
> file to the printer as is, or modify it dynamically (for variable data). In
> other words, this software is very "nice to have", but you can work without
> it if you need to, so its present "work in progress" status wouldn't
> prevent someone from using "Linux in the field". Having said that, I still
> welcome this development. <

For that matter, if you're somewhat tolerant of bugs and willing to apply hot patches, you can probably use kbarcode already. (As usual, depends on the balance of costs and benefits, and on the general situation.)

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Michael Griffin on 16 June, 2003 - 4:31 pm

Further to my discussion with Mr. Baum in a previous message on printing bar codes (Thursday the 12th), I checked into printing bar codes on a typical label printer (Intermec in this case), and yes this appears to be a built in feature of the printer. These are generated on the printer itself and not via some magic software in the computer. In other words, there should be no problems using typical label printer features with Linux.

I believe there is a Linux bar code generator program for use with conventional printers. I don't however know if conventional printers are ever used for industrial label printing. If they are, then that bar code generator could be useful.

--

************************
Michael Griffin
London, Ont. Canada
************************

By Mike O'Connor on 3 May, 2003 - 2:53 pm

As you may or may not know, SIXNET offers a line of industrial controllers and RTUs that use Linux. We have been offering this product for 7 months and are just getting up to speed. For us and most of our OEM customers, "Linux in the field" was the perfect solution. We needed an operating system for our new products. We had considered porting our old proprietary firmware
over to a new processor but it just didn't make sense. Everyday someone asks us if we can interface to this or support that. It would be impossible to write our own code for every functionality users, system integrators and
especially OEMs wanted. Linux was the perfect fit. First, we were able to implement it in record time because we could use "off-the-shelf" code. Secondly, there are no OS licensing fees for us or our customers. Everyone saves money in the long run. Finally, our users can add their own drivers and applications, or even completely customize the firmware to meet their needs. The flexibility with Linux is still amazing us.

However, we haven't completely abandoned Windows. Just a couple years ago we marketed ourselves as "I/O for Windows" when some thought PCs would replace PLCs. Anyways, our configuration utility is still a Windows app. Most of our users are still carrying around Windows laptops for setup and diagnostics.
So far our users and OEMs have accepted this arranagement.

We know that many are not ready to adopt "Linux in the Field" so we've designed our Linux-based products to meet the needs of both the Linux
-ignorant end-user to the Linux-savvy OEM. Here's how we do it:

1. "I don't know Linux" user: For these people we have pre-integrated into our Linux-based controllers/RTUs many automation features (such as PID, datalogging, etc.) that they can easily configure (with our Windows utility) or program (with our IEC 61131 package that supports ladder logic and 5 other languages). They truly don't even need to know that the Linux is there. For many users, the Linux tends to actually scare them away. So we try to pull the Linux card only when appropriate.

2. System Integrators: We offer a free development kit that allows someone to create their own applications to run in our Linux-base controllers. They can develop their code in Red hat Linux or Windows (using MSYS & MINGW). We
provide the cross-compiler, and a debugger for Linux. Our firmware already includes many advanced features such as PPP, IP Tables, SNMP, DHCP, Boa Web Server, and much more. We have integrators now adding AGA3, DNP, Hart, and
much more. When we can we will make this code available to everyone.

3. OEMs: We publish most of our firmware source code on www.sixnetio.com. This allows advanced users (typically OEMs) to basically do anything they want. We even offer our CPU engine to be integrated into other hardware.

I hope this info. fits in with the discussion which seems to already have gone off in several directions. We are basically betting (and counting on) Linux making a big impact in industrial automation, just like Ethernet has
done.

For details on our Linux products please go to www.linux4oems.com.

Mike O'Connor - SIXNET Product Marketing Manager

By Curt Wuollet on 6 May, 2003 - 7:48 pm

Hi Mike

I would say that yours is a good example of making it work rather than simply assuming it can't be done. I have been trying to do much the
same with a PLC form factor, PC compatible, hardware platform for MAT or other, preferably Linux control software. Showing that the problems
are relatively easy to solve gains a lot more traction than discussing them. My recent enforced vacation virtually wiped out this effort and I
still haven't managed to find the time and resources to proceed, but the approach is much the same.

For users who don't want to know, it could be treated in much the same way as any other PLC product. although I don't see myself writing
Windows tools. Because it would be really Open, anyone with a burning desire could do so and contribute them to the community. People with
sophisticated needs or tastes could do nearly anything possible with Linux, which would raise the bar for automation platforms considerably.

Since I am from a T&M background this could answer the gap between automation and autometed testing as well. And the growing need for hard or soft realtime with PLC functionality could be met fairly easily on this platform. Currently I am torn as to whether I can go it alone and publish a free design, or gather up a few investors and
make a product out of it.

It's not at all that I want or need to make money from it, but that a ready to run product with spares, support, etc. might have a bigger impact and do more to further the cause. Just as many are struggling to get their arms around a suitable software model, I am thinking hard to find a hardware model where there is even less precedent. SoftPLC's Tealware and Grayhill's modular product haven't set the would on fire.
And very few people could or would make their own from a reference design.

Something in the middle is needed. A way to do the hard parts without doing a full blown manufactory and raising burden. And all of it while staying Open and giving the customer a clearly better deal. Stuff you can buy and/or use is what's really limiting Linux in the field. And a platform that is as user friendly as Linux and already commoditized. It's a tall order, but quite doable. I can feel it. I know I can do it. I just want to build a winner for all parties.

Regards

cww

By Andrey Romanenko on 28 April, 2003 - 2:14 pm

The site www.realtimelinuxfoundation.org provides
a lot of information about various industrial and
research applications where (real-time) Linux has been used. For the reasons the other people
have highlighted in this thread, these solutions
are mostly small scale, in-house, experimental, and research. But they are successful. The market is yet to be upset towards Linux, though.

Andrey

Hi all,
i don't know the actual situation but in 2000 i saw a shift to Linux as a platform for HMI applications.

At that time i had some projects - i'm a freelancer - for a mid sized engineering company in Germany. They mainly work for steel companies.

This company sells an own HMI System called PRODAVIS which is OS and PLC independent, available for Win - Linux - SCO.

The most projects were done with Linux as OS, followed by SCO Unix.

But maybe this was historical thing. They are suppliers for the steel industry since more than 40 years and supporting the Unix environment since the late 80's. So the shift was mainly from SCO to Linux and not from Win, what means their customers are already used to have Unix systems.

Btw. not only european steel plants were using it, i know at least one project that was done in the US (can't remember the company name) at that time.

Sorry if my English is not the best, i'm trying to improve it everyday.

Lothar Kontowski

By Dick Caro on 29 April, 2003 - 1:19 pm

Lothar, your English is just fine! Clearly understood.

There were/are many HMI packages originally programmed for different flavors of UNIX, especially QNX that featured a real-time pre-emptive kernel, and was blazingly fast. BJ Software's RealFlex was such a SCADA/HMI package and BJ was concerned that QNX would not be perceived as a "real UNIX" since it was an original port (like Linux) and did not use the AT&T kernel. Eventually, BJ ported their software to Windows (FlexWin). Maybe someone else can tell me the fate of BJ Software and their really great software.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: RCaro@CMC.us
Web: http://www.CMC.us
============================================

By Paul Jager on 20 June, 2003 - 12:16 am

On April 25, 2003, Patrick Allen wrote:
>Is there something out there and I'm just missing it? <

This entire thread missed it! Hint do a search with Google and type "soft PLC" or "Linux HMI".

We have available complete Linux solutions for most of the past decade and have many installations running very successfully in different parts of the world. Not just HMI but a client server system that does all control, HMI,
trending, etc. We are developing for the Chinese market right now with a large effort for substation automation.

We are staging an acceptance test in Europe for their system next week, and plan to go into a second round of independent quality testing in China for the last week of June. We invested a few 100 thou on this project as well as the customer.

With this effort we have developed a great version of automationX for Linux. We are debating a plan to release this software under a "free" license program for certain parts of the world, like North America. Parameters would
be to limit the variable count to support around 100 I/O, have a nominal registration fee to cover issuance of the license.

Right now the penetration of Linux is small - the question is would even free software increase the number of users?

Regards,

Paul Jager
www.mnrcan.com

By Paul Jager on 28 June, 2003 - 9:08 am

>From a buyer desicion standpoint, does the market even care what the strengths and weaknesses of a control system are? A while ago we started a thread to ask the question "Why did you buy brandX of automation software on your last project?" (Thanks again to those who replied.)

The reasons given for choice are summarized as:

Recommended by customer, influenced by others, or what was used before Relevant Industry Experience Local and Widespread Support Model Proven & large Installed Base Simple to Understand Communications to a variety of equipment without custom code Customer friendly license arrangement Features that fit the application (We added this - Appeal to Buyer or Buyer Relationship)

A linux based system could have perhaps one or two "wins" on the list. How can a new linux product ever be selected by an end user with this decision logic?

Paul Jager www.mnrcan.com