Linux in the field

M

Michael Griffin

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
************************
 
R

Ralph Mackiewicz

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.
 
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 <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
A
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 -- [email protected]
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------
 
C
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
 
M

Michael Griffin

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

Michael Griffin

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

Michael Griffin

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