Linux in the field

A
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 -- [email protected]
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------
 
A
> 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 -- [email protected]
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------
 
C
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
 
C
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
 
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

--
<[email protected]>

Petr Baum, P.O.Box 2364, Rowville 3178
fax +61-3-97643342
 
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 <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
M

Michael Griffin

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
************************
 
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 <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
M

Michael Griffin

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
************************
 
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: [email protected]
Web: http://www.CMC.us
============================================
 
B

Blunier, Mark

> 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.
 
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
 
A
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 -- [email protected]
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------
 
D

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. 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.
 
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
[email protected]
www.spitzerandboyes.com
--------------------------
 
A
> ------------ 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 -- [email protected]
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------
 
M

Michael Griffin

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

Mike O'Connor

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
 
C

Curt Wuollet

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
 
Top