Today is...
Wednesday, July 26, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
linux Modbus master
Can we emulate modbus RTU master at linux system without modbus driver? ...

We have Redhat Linux petium-3 pc having c218 MOXA asyc 8port(RS-232) serial card. Through this card one of the ports we want to access PLC modbus RTU slave (from RSTHAL). Can we emulate modbus RTU master at linux system without modbus driver? We tried the standard modbus protocol RTU format frames i.e slaveno, functioncode, addresshigherbit, addresslowerbit, no. pts higherbit, lowerbit, CRClowbit, CRChighbit from redhat linux pc. But there is no response from the RTU slave. But from Windows-NT pc vendor send program is able to send
frames and able to get reply from slave.
Please let me know the bare standard Master RTU frame format generation alone is not enough to get response from slave. Any driver software have we to install at the linux pc?

By Raymond van der Tas on 20 February, 2002 - 11:10 am

Yes, you can we emulate modbus RTU master at a linux system. (or any other operating system OS9, DOS, Win9x, WinNT,2000, XP,...)

The modbus rtu master has to send out bytes in the following order (least significant bit first):

<address-8 bits><function-8bits><data-n bytes><crc-16 bits>

In case there's no response from your slave PLC you will have to verify the next steps:
- serial cable wiring
- does the node address match
- does the bitrate and parity match
- does the PLC expect hand shaking RTS/CTS

Since the Windows program from PLC vendor is able to get replies from the slave I would advise you to write a little program that reads the bit stream from the working program. You then compare this bit stream with the output of your program and adjust your program.

Good luck !

ICONICS EUROPE BV
Raymond van der Tas
www.iconics.com

By Alex Pavloff on 20 February, 2002 - 4:55 pm

Modbus RTU will work on any platform. I suspect you have a problem with your code, and would highly recommend putting a serial breakout (we had a thread on this last week, I recall) to examine the packets coming from your PC to the RTU slave.

I also wonder why you have OPENC as your topic -- as it seems to be a COMM question.

Alex Pavloff
Software Engineer
Eason Technology

By Lynn August Linse on 21 February, 2002 - 10:10 am

Confirm your CRC is correct - for example compare what you send to that of your NT demo for the same message. Many vendor's "example code" for the Modbus-RTU CRC16 contain out-right bugs and/or compiler-dependant "()" usage (or lack thereof). Sign-extensions on a 32-bit machine could create incorrect CRC16 results easily as it assume 16-bit unsigned manipulation.

The other issue is the common 11-bit async char of 8,N,1 or 8,E,1 may not be the default on some serial ports - some of which are limited to 10-bit async chars like 7,E,1 but not 8,E,1. Or the driver you have may not support the 11-bit async char even if your hardware does.

Ron Gage ( "www.rongage.org":http://www.rongage.org ) had a Linux Modbus/TCP library out - possibly you can contact him and see if it's still available.

regards::

Lynn August Linse, Senior IA Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
lynn.linse@lantronix.com www.lantronix.com
Tel: (949)300-6337 Fax: (949)453-7152

By Rodney Stevens on 21 February, 2002 - 11:30 am

pushpa

Could you explain how you sent the standard modbus RTU protocol. This is all that a driver will do. How did you receive the reply. Have you written a program to do this.

Rodney Stevens
CSIRO Minerals
http://www.minerals.csiro.au

Ph. 61 2 97106701
Fax 61 2 97106789

Personal Home Page
http://mywebpage.netscape.com/rodjohnstevens/HomePage.htm
Under Re Construction

The MAT LinuxPLC has a modbus driver (including RTU master), but Mario has recently finished reorganizing it and I don't think it's in the manual yet.

I'll forward him your post.

MAT is open-source, so you can use the whole project, or cut out just the modbus driver and modify it to be stand-alone. At the very least, you'll be able to see how we did it :-)

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 Mario J. R. de Sousa on 21 February, 2002 - 3:47 pm

Hi all,

In fact we do have a working modbus RTU master module for MatPLC.

You can get it from our website http://mat.sf.net You will either have to download the files you need using cvs, or download the weekly tarball using the link on our home web page which contains the whole project source code.

You will find the relevant code under /io/modbus
Under this directory you will find a modbus_m.c file that contains code specific to the MatPLC project. The code you probably want is under /io/modbus/protocol. I have implemented it as a two layered protocol. Please read the README in this directory that will explain how the files are organized.

You will be calling the functions declared in mb_master.h Start off by calling mb_master_init() to initialise the library. This will open and configure the serial port. From here on you simply need to call the functions that will send modbus frames.

Remember that if you give very short timeouts, especially when using low transmission speeds, the library will timeout before it gets a chance to receive the whole response frame. Be sure to call get_min_timeout() once you have initialised the library to figure out if you are using timeouts that are large enough.

If you look at the code it will probably seem very complex. In fact it is this way simply because the modbus protocol was designed to be
implemented at the device driver level, and not as a user program. The complexity is required in order for the library not to get confused if:
- it happens to receive an aborted frame (i.e. a slave starts sending a frame but stops half way);
- it happens to be running on a heavily loaded system, which means it will be reading the frames from the serial port with a small delay after they arrived.
If anybody can figure out a method of doing it more simply, please be sure to tell me. I would really like to know how!


Please note that the ASCII protocol you will find on our web site does not compile. On my development machine I have just finished implementing the TCP protocol along with the ASCII protocol. I have not yet put up this code on our web site because, due to the connection oriented nature of the TCP protocol I was forced to change the API between the master protocol implementation and the lower layers(i.e. TCP, RTU and ASCII). This means I am now busy bringing the RTU and ASCII implementations up to speed with the new API. Once I manage to get everything to compile cleanly I will be putting up the code. Unfortunately, at the rate I am going I will probably take a couple more weeks...


If you need any help, don't hesitate to email me...

BTW, you might just want to have a look at our whole project, it might just already be doing what you want...


Cheers,

Mario.


--
--------------------------------------------------------------------------
Mario J. R. de Sousa msousa@fe.up.pt
--------------------------------------------------------------------------

"Humanity is the earth's cancer" - Agent Smith - The Matrix

By Alex Pavloff on 21 February, 2002 - 4:44 pm

Jiri -

I'm in the market for a Modbus Ethernet driver for Linux myself, but as I understand it, Mario's driver falls under the GPL. I can't link it with my code without GPLing and open sourcing my code. I can't "pull it out" and make it standalone. Now, it seems to me that something like this Modbus code would be really useful under the LGPL. I'd love to take a modbus library that did RTU, ASCII, and TCP and do stuff with it -- and of course, test the code and release all enhancements/bug fixes back to the MAT project.

But as it stands, all it is a nice block of code to look at.

I also had a question related to the license -- the entire LPLC project is under the GPL. When I create a LinuxPLC module of any sort, does it fall under the GPL? If so, does this mean the code I use your IEC or any other translator to make a LPLC module fall under the GPL?

I don't think this is your intent, but it is unclear to me exactly what parts are covered by the GPL and which parts aren't.

Alex Pavloff
Software Engineer
Eason Technology

By Greg Goodman on 23 February, 2002 - 1:25 pm

Alex,

When you say "module of any sort," are you talking about compiled or interpreted code?

If the question is:

"Are my ladder or SFC programs open source just because i use your open source MAT/PLC to execute them?"

then the answer is no, and is addressed by the GPL FAQ:

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

If the question is:

"If i write 'C' code that links with GPL libraries to communicate with a running MAT/PLC, is my code also open source?"

then the answer is yes. Code that links with GPL libraries must be released under a license compatible with the GPL.

Regards,

Greg Goodman
Chiron Consulting

Alex Pavloff:
> I'm in the market for a Modbus Ethernet driver for Linux myself, but as I
> understand it, Mario's driver falls under the GPL.

Yes, it does.

> I can't link it with my code without GPLing and open sourcing my code. I
> can't "pull it out" and make it standalone. Now, it seems to me that
> something like this Modbus code would be really useful under the LGPL.
> I'd love to take a modbus library that did RTU, ASCII, and TCP and do
> stuff with it -- and of course, test the code and release all
> enhancements/bug fixes back to the MAT project.

> But as it stands, all it is a nice block of code to look at.

You have several options:

- use the MAT LinuxPLC as a whole, writing your program in one of the end-user languages (mnemonics or stepladder only at this stage, unfortunately). That avoids the whole question of licensing for MAT and for your program, as they're completely separate.

- make your code GPL. Depending on the details of your business this may or may not make sense for you, but if you're an integrator it should have little effect on your income because your clients pay time & materials for your expertise and the code is not important.

- put it in a stand-alone program which talks Modbus and interfaces to your own (separate) program in some other way. Beyond a certain degree of isolation, it becomes simply two programs that are packaged on the same media and happen to work together.

- reimplement it, using Mario's code as a reference. This requires a certain amount of judgement and care to avoid outright copying, but it can be done. Preferably you would have the Modbus spec and only refer to Mario's code for clarification (not that Mario would have some magical source of information).


> I also had a question related to the license -- the entire LPLC project
> is under the GPL. When I create a LinuxPLC module of any sort, does it
> fall under the GPL? If so, does this mean the code I use your IEC or any
> other translator to make a LPLC module fall under the GPL?

Some of these details we haven't quite worked out, but the translator case is reasonably clear - no, it would not. It's just like running any other translator, interpreter or compiler.

Probably the most complicated and difficult case will be writing a module in C; that's a can of worms I'd rather not open right now.


The easiest solution, of course, is to GPL your code; most likely it is not all that different from the informal status quo (see the ``BUSN: "Software licenses" for PLC applications'' thread), only formalized.


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 25 February, 2002 - 5:27 pm

> From: Jiri Baum [mailto:jiri@BAUM.COM.AU]
>
> You have several options:
>
> - use the MAT LinuxPLC as a whole, writing your program in one of the
> end-user languages (mnemonics or stepladder only at this stage,
> unfortunately). That avoids the whole question of licensing for MAT
> and for your program, as they're completely separate.

The LinuxPLC is in pre-alpha state. Its also bears little relation to what I'm doing. This is not an option.

> - make your code GPL. Depending on the details of your business this
> may or may not make sense for you, but if you're an integrator it
> should have little effect on your income because your clients pay
> time & materials for your expertise and the code is not important.

I'm not an integrator. I am a hardware/software OEM. The hardware is pretty standard, the software is our differentiator. We just had the "why should I GPL my code" question, and I frankly don't thinking giving up all my work to a competitor is a good idea.

So here I am, doing a Linux project with two developers that will form the basis our next HMI product line, and I can't use the major open source Linux project dealing with machine automation because otherwise, I'd have to give
up all the code that will make my product unique. Are you guys sure that this is what you want? I'd happily contribute code and bug fixes to a general Linux Modbus driver.

> - put it in a stand-alone program which talks Modbus and interfaces
to
> your own (separate) program in some other way. Beyond a certain
> degree of isolation, it becomes simply two programs that are
packaged
> on the same media and happen to work together.

So I can get around the GPL by using a binary boundary. It sure is a good thing that the GPL was written before IPC became commonplace, huh? I just can't wait to see what RMS does when he makes a new version of the GPL and addresses this issue. (And the flame wars that will result no matter what he does).

I'd also like to point out that small footprint systems will have problems using GPLed software. Because they're limited in RAM, ROM/flash, and have a small CPU, programs are usually compiled together into one big block.

> - reimplement it, using Mario's code as a reference. This requires a
> certain amount of judgement and care to avoid outright copying, but
> it can be done. Preferably you would have the Modbus spec and only
> refer to Mario's code for clarification (not that Mario would have
> some magical source of information).

I already have a Modbus driver. I've got two: one that I wrote, and another freeware one for Windows at "http://members.tripod.com/~mbserver/":http://members.tripod.com/~mbserver/ . I just want to have a better one that I can work with multiple people to find bugs and improve. To me (and many people), this sort of thing is a communication library.

On of the other libraries I'm using is the CommonC++ library. ( "http://sourceforge.net/projects/cplusplus/":http://sourceforge.net/projects/cplusplus/ ). It is also GPLed but has a specific exception... "If you link the Common C++ Library with other files
to produce an executable, this does not by itself cause the resulting executable to be covered by the GNU General Public License."

As a result, I am using the library, and have already added code which I have turned around and submitted back to the maintainers. I'm using it,
everyone's got my fix, and everyone is happy.

> Some of these details we haven't quite worked out, but the
> translator case is reasonably clear - no, it would not. It's just like
> running any other translator, interpreter or compiler.

But I translate it into C... and then link. Do I have to give you my translate C code? It may be clear to you, but it sure seems to me that a
strict reading of the GPL says that my translated code must be GPLed.

> Probably the most complicated and difficult case will be
> writing a module in C; that's a can of worms I'd rather not open right
now.

You're going to have to do it sooner or later.... Are you could be waiting for a quiet time on the list so you can start a 300-post flame war? :-)

> The easiest solution, of course, is to GPL your code; most likely it is
not
> all that different from the informal status quo (see the ``BUSN:
"Software
> licenses" for PLC applications'' thread), only formalized.

It is different: I'm not an integrator or machine builder. My customers are.::

Alex Pavloff
Software Engineer
Eason Technology

Jiri Baum:
> > You have several options:

> > - use the MAT LinuxPLC as a whole, writing your program in one of
> > the end-user languages (mnemonics or stepladder only at this stage,
> > unfortunately). That avoids the whole question of licensing for MAT
> > and for your program, as they're completely separate.

Alex Pavloff:
> The LinuxPLC is in pre-alpha state.

Obviously, this is something we're hoping to improve :-)

> Its also bears little relation to what I'm doing.

Right. (BTW, any chance of more details? We're always looking for suggestions of new features to add...)

> > - make your code GPL. Depending on the details of your business
> > this may or may not make sense for you, but if you're an integrator
...
> I'm not an integrator. I am a hardware/software OEM. The hardware is
> pretty standard, the software is our differentiator.

In that case no, GPL is not a good fit.

> So here I am, doing a Linux project with two developers that will form
> the basis our next HMI product line, and I can't use the major open
> source Linux project dealing with machine automation because otherwise,
> I'd have to give up all the code that will make my product unique.

You've chosen not to share your code... Open Source is built on the principle of ``share and share alike''. If you won't share, you'll have
trouble convincing others to share with you.

Mind you, this is no different to any other project you might want to use - if you want to incorporate anyone's code in yours, you have to give them something back, typically a lot of money. GPL makes it a straight exchange, your code for ours.

> > - put it in a stand-alone program which talks Modbus and interfaces
> > to your own (separate) program in some other way. Beyond a certain
> > degree of isolation, it becomes simply two programs that are
> > packaged on the same media and happen to work together.

> So I can get around the GPL by using a binary boundary.
...

Yes. Just like you could with a closed-source program.

> I'd also like to point out that small footprint systems will have
> problems using GPLed software. Because they're limited in RAM, ROM/flash,
> and have a small CPU, programs are usually compiled together into one big
> block.

It's not such a big problem - under Linux, there's not a big difference between threads and processes, and once you're on a small CPU without a MMU most of that difference disappears altogether. Just put it into the flash, run the pre-linkloader, and execute it straight from flash (XIP).

> > - reimplement it, using Mario's code as a reference. This requires
> > a certain amount of judgement and care to avoid outright copying,
> > but it can be done. Preferably you would have the Modbus spec and
> > only refer to Mario's code for clarification (not that Mario would
> > have some magical source of information).

> I already have a Modbus driver. I've got two -- one that I wrote, and
> another freeware one for Windows at http://members.tripod.com/~mbserver/.
> I just want to have a better one that I can work with multiple people to
> find bugs and improve.

The GPL is not very good for differentiated software. What differentiates your code is that you wrote it and maintain it. Unfortunately, that means that *you* have to maintain it.

If you were to GPL your product, the maintenance burden would lighten, and it would likely improve, but it wouldn't be differentiated any more.

> > Some of these details we haven't quite worked out, but the translator
> > case is reasonably clear - no, it would not. It's just like running any
> > other translator, interpreter or compiler.

> But I translate it into C -- and then link. Do I have to give you my
> translate C code? It may be clear to you, but it sure seems to me that a
> strict reading of the GPL says that my translated code must be GPLed.

Something we need to clarify in the manual, yes.

The translated C code isn't the source code, anyway, because it's generally not "the preferred form [...] for making modifications".

> > Probably the most complicated and difficult case will be writing a
> > module in C; that's a can of worms I'd rather not open right now.

> You're going to have to do it sooner or later....

Yes, we know.

> > The easiest solution, of course, is to GPL your code; most likely it is
> > not all that different from the informal status quo (see the ``BUSN:
> > "Software licenses" for PLC applications'' thread), only formalized.

> It is different -- I'm not an integrator or machine builder. My
> customers are.

Right. Your customers would benefit, but not (necessarily) you. At the least, it'd be a big shake-up, which probably isn't what you want.


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 5 March, 2002 - 10:35 am

> Jiri Baum wrote:

> Obviously, this is something we're hoping to improve :-)

Great, It doesn't matter what license a project is under -- if its not done, its not done.

> Right. (BTW, any chance of more details? We're always looking for
> suggestions of new features to add...)

Right, I'm going to tell you so you can make a GPLed version and take all my customers? Errr... no. :-)

> If you were to GPL your product, the maintenance burden would lighten,
> and it would likely improve, but it wouldn't be differentiated any
> more.

How many people are out there that have the skills, the time, and the desire to work on an open source project for FACTORY AUTOMATION. I mean, seriously here. This ain't exactly the sexiest job in the world here. There's a possibility of getting ones hands dirty! You have to deal with factory workers! You may have to actually GO PLACES! Its like a job straight out the 1800s!

Now, that's exaggerating, yes, but compared to standard IT -- these jobs are, on the surface, unappealing to the vast majority of people out there. For that matter, you've said before that many open source projects get done by "bored grad students". Ok, neat. How many grad students out there are well versed in programming that want to do factory automation?

Not many, compared to those wanting to do more traditional computer problems.

> Right. Your customers would benefit, but not (necessarily) you. At the
> least, it'd be a big shake-up, which probably isn't what you want.

So, what you're basically saying is that "If you are a company that's trying to make money on good software or a good hardware/software solution, you shouldn't join a GPLed project." I'll keep that in mind.

And I think you should to, and not be surprised when people don't use your stuff for the very reason that there isn't a company behind the LinuxPLC.

Alex Pavloff
Software Engineer
Eason Technology

By Jiri Baum on 5 March, 2002 - 10:37 am

Jiri Baum:
> > Right. (BTW, any chance of more details? We're always looking for
> > suggestions of new features to add...)

Alex Pavloff:
> Right, I'm going to tell you so you can make a GPLed version and take all
> my customers? Errr... no. :-)

OK. If the feature is something that's generally useful, chances are it'll be generally requested, though, and possibly obvious.

> > If you were to GPL your product, the maintenance burden would lighten,
> > and it would likely improve, but it wouldn't be differentiated any
> > more.

> How many people are out there that have the skills, the time, and the
> desire to work on an open source project for FACTORY AUTOMATION.

The people who are already in factory automation, currently using a closed source product. Instead of working around bugs, they could go fix them, which will fairly often end up less painful than the work-arounds. Similarly if they need a minor feature added.

> For that matter, you've said before that many open source projects get
> done by "bored grad students". Ok, neat. How many grad students out
> there are well versed in programming that want to do factory automation?

Procrastinating, actually. The usual term is `thesis avoidance'.

And there are a few, especially if you expand to those who'd merely use it to run their model trains and the like.

> > Right. Your customers would benefit, but not (necessarily) you. At the
> > least, it'd be a big shake-up, which probably isn't what you want.

> So, what you're basically saying is that "If you are a company that's
> trying to make money on good software or a good hardware/software
> solution, you shouldn't join a GPLed project." I'll keep that in mind.

Basically, yeah. GPL is good for commodity software, the infrastructure and so on. If your software contains something innovative, it's not a good fit.

It also depends on what's already out there - if there's already a GPL program that would be a good fit, then it'll be difficult to come up with something sufficiently differentiated for people to actually notice.


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 Mark Blunier on 6 March, 2002 - 11:52 am

> > For that matter, you've said before that many open source projects get
> > done by "bored grad students". Ok, neat. How many grad students out
> > there are well versed in programming that want to do factory
> > automation?
>
>
> Procrastinating, actually. The usual term is `thesis avoidance'.

This is a fallacy. It was generally assumed that students and non professionals do most of the work, but when the issue was researched, they found that most open source software is programmed
by professional programmers in their spare time. The students are a small minority.

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

By Alex Pavloff on 6 March, 2002 - 11:55 am

> OK. If the feature is something that's generally useful, chances are it'll
> be generally requested, though, and possibly obvious.

Of course -- however, I have a head start.

> The people who are already in factory automation, currently using a
closed
> source product. Instead of working around bugs, they could go fix them,
> which will fairly often end up less painful than the work-arounds.
> Similarly if they need a minor feature added.

I have the firm belief, based on my dealing with integrators using my products, that most of them don't have the time to go messing around with writing something new. Working around bugs isn't that hard. Maybe when you guys actually have a working system, your statement will be true. However, right now, as you say, the LinuxPLC is in pre-Alpha, not for production use, and probably has lots of bugs to work around. (Heck, I can't get anything in your project system to compile, and I don't have the time to find out why).

Using the LinuxPLC it right now is more painful than working around bugs. Therefore, people won't use it (because they have product to ship), therefore, no work will get done. Chicken & Egg problem, and the only way you're going to get out of that is by getting enough developers as possible. For the lack of a better term, have you considered that your "GPL snobbery" is going to turn away developers (like me) that could otherwise contribute to your project?

> Procrastinating, actually. The usual term is `thesis avoidance'.
>
> And there are a few, especially if you expand to those who'd merely use it
> to run their model trains and the like.

Great. I just can't wait to see your finished programming environment.

> It also depends on what's already out there - if there's already a GPL
> program that would be a good fit, then it'll be difficult to come up with
> something sufficiently differentiated for people to actually notice.

True.


However, the LinuxPLC is just a copy of one of a hundred existing PLCs (most of which actually work now). Doesn't seem too differentiated to me.

Alex Pavloff
Software Engineer
Eason Technology

By Jiri Baum on 7 March, 2002 - 6:12 pm

Jiri Baum:
> > Instead of working around bugs, they could go fix them, which will
> > fairly often end up less painful than the work-arounds. Similarly if
> > they need a minor feature added.

Alex Pavloff:
> I have the firm belief, based on my dealing with integrators using my
> products, that most of them don't have the time to go messing around with
> writing something new. Working around bugs isn't that hard. Maybe when
> you guys actually have a working system, your statement will be true.

Yeah, that's how it was intended - when we have a working system. Sorry, wasn't very clear in my post.

> (Heck, I can't get anything in your project system to compile, and I
> don't have the time to find out why).

Oops, that'd most likely be because we're switching to Automake, and the Automake stuff isn't working yet. We need to get that OOBE better...

> Using the LinuxPLC it right now is more painful than working around bugs.
> Therefore, people won't use it (because they have product to ship),
> therefore, no work will get done. Chicken & Egg problem,

Yes.

> For the lack of a better term, have you considered that your "GPL
> snobbery" is going to turn away developers (like me) that could otherwise
> contribute to your project?

The GPL is the only way we know to guarantee that the project will remain a community project, though. It has to stay; in some ways, it's the very core of the project, the one part that has to remain for it to still be MAT.

> > Procrastinating, actually. The usual term is `thesis avoidance'.

> > And there are a few, especially if you expand to those who'd merely use
> > it to run their model trains and the like.

> Great. I just can't wait to see your finished programming environment.

One thing I'm thinking of doing is a three-paned thing, with a tree view (program outline) in the left pane, a graph view of the program in the middle pane (state / petri / data-flow) and details of the selected node in the right pane. But first I have to get the time to implement it, and then I find out if it's workable or not... Could be neat, though.


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 Curt Wuollet on 7 March, 2002 - 7:52 pm

Hi Alex

I think "snobbery" is way wrong. As you can plainly see, there are plenty of people who would like to take work freely given and exploit it for profit. To take what is Open and close it, for whatever reason, is a step in the wrong direction. If you, as the author, decide to license _your_ code, both under the GPL and your private license, you are free to do so and then your product, using your code need not be GPL. The only thing you are prohibited from is taking someone else's GPL code and making it part of a closed product against their wishes. What's snobbish about that? And, you can license code from the author under different terms, if they are willing, and use it in your closed product. This is the same as the situation for closed source. The only difference is that, if you use code under the GPL, you GPL your code. The only thing GPL does is ensure that code that is intended to be publicly available and free remains that way, according to the wishes of the author. And, no it isn't for every author or every situation. It is right for what we are building and authors who want to see that happen in the automation environment, and don't want their donated code exploited. All authors retain the right to license _their_ code however they want.

Regards

cww

By Alex Pavloff on 8 March, 2002 - 2:15 pm

> I think "snobbery" is way wrong.... <snip rest of stuff that we all know> <

Curt, my major point about the problems with the GPL in regards to your MAT project:

a) Most work done in our field is done by companies.
b) Hardware and software companies need to have proprietary software. (As the LonTalk thread shows)
c) Your project is allergic to proprietary software

Therefore: Hardware and software companies will not support your project.

In this field, I don't think you can get far without the support of established companies. This isn't a new market -- this isn't a new idea.
You're copying things that have been done before. The only people that will use your project with the current licensing terms are integrators. That's it.

And I don't think that you have enough integrators and "procrastinating grad students that want to run their train set" with the programming skills and time to create a PLC that can even compete with some of the AutomationDirect
and other cheap PLCs out there.

In regards to the Modbus Master, it doesn't even make any sense to be GPLed. If it was a kernel driver, as Mr De Sousa says it really should be (to deal with all the fun Modbus RTU timing issues), then I COULD use it from proprietary software.

Alex Pavloff
Software Engineer
Eason Technology

By Curt Wuollet on 10 March, 2002 - 6:20 pm

Hi Alex

> Curt, my major point about the problems with the GPL in regards to your MAT
> project:
>
> a) Most work done in our field is done by companies.

Yes.

> b) Hardware and software companies need to have proprietary software. (As the LonTalk thread shows)

They believe they need it, yes. Whether they actually need it in every case is debatable. A lot of successful high tech companies own no IP whatsoever. IBM used to think that way as well. Now they are finding that contributing needed things to the Linux community has been one of their _very_ best investments. Jealously guarded, they weren't doing anyone much good. One would be very hard pressed to find any plausible downside for either party and these were things that represented substantial investment. The guy who pushed it is now in the top spot.

> c) Your project is allergic to proprietary software

No, we're allergic to mixing the two. There will be no problem running proprietary applications on the system and it's likely we will have some proprietary stuff driven by the system, but the system itself will be Open. It's more that proprietary software is allergic to us. It's quite clear which is more beneficial to the consumer and community.

> Therefore: Hardware and software companies will not support your project.

I don't think anyone will mind selling more IO, that's where the money is. And we don't need much from the software companies. Besides, it's not a question of who supports us, it's who wants the business we generate and who wants to sell to the customers who want IO and services. The current model is to push a wide variety of articles by bundling them inseperably. The companies that will be most important to us will be those that want their stuff to fill the demand. For example, the companies that sell Ethernet IO should be fairly friendly and work with us on protocols. Integrators are a good market to start with.

> In this field, I don't think you can get far without the support of
> established companies. This isn't a new market -- this isn't a new idea.
> You're copying things that have been done before. The only people that will
> use your project with the current licensing terms are integrators. That's
> it.

Like I said, that's an excellent place to start, they get an extremely flexible platform that makes integration easier (possible?) and we get the benefit of their experience and knowlege. If integrators start using MAT/LPLC the right kind of things will happen. Integrators are an important part of the market and will form an excellent community.

> And I don't think that you have enough integrators and "procrastinating grad
> students that want to run their train set" with the programming skills and
> time to create a PLC that can even compete with some of the AutomationDirect
> and other cheap PLCs out there.

We'll keep you on the mailing list anyway:^) It depends a lot on how much the limitations of the current model affect you. For what I do it's already vastly superior. If you have to connect diverse equipment together, PLCs are a non-starter. If you need sophisticated communications, a Linux box, even without a logic engine on it is at least an order of magnitude better at it than any PLC. The logic engine is becoming a small part of a total solution and PLCs simply don't do the other stuff well. If you find you have all sorts of bridges, converters, adapters, and you need to have a PC in the mix anyway, it's a no brainer.

> In regards to the Modbus Master, it doesn't even make any sense to be GPLed.
Why not?

> If it was a kernel driver, as Mr De Sousa says it really should be (to deal
> with all the fun Modbus RTU timing issues), then I COULD use it from
> proprietary software.

And with my blessing and best wishes. All we want is for our stuff to stay free and available for everyone on equal terms. It's a pretty good deal if you use it that way.

Regards

cww

By Michael Griffin on 11 March, 2002 - 10:23 am

On March 7, 2002 08:36 pm, Alex Pavloff wrote:
<clip>
> In regards to the Modbus Master, it doesn't even make any sense to be
> GPLed. If it was a kernel driver, as Mr De Sousa says it really should
> be (to deal with all the fun Modbus RTU timing issues), then I COULD
> use it from proprietary software.
<clip>

Might I suggest cutting this Gordian knot by separating the Modbus master (and other protocols) from the MAT project? There seems to be enough interest in industrial protocols that it deserves to be a stand alone project. The MAT project would benefit from having other people working on various protocols for their own purposes. Mr. Linse made the rather convincing point in another message that we will be dealing with many protocols for the forseeable future, so the more people there are working in this area, the better.

Mr. Pavloff might also wish to consider the implications of his above statement. If the Modbus master is subject to GPL, then there is nothing to prevent someone from taking it and turning it into a kernel driver, providing this kernel driver was also released as GPL. While GPL prevents you from turning the code into a proprietary product, it does not prevent you from making any GPL derivatives you may wish to create.
While Mr. Pavloff's new proprietary product may have some unique features, I doubt that the ability to speak Modbus is something he is counting on to differentiate it from his competition. While some people may have a Pavlovian reaction (sorry, but I couldn't resist) to "proprietary", I don't see what objection they could raise to this suggestion. I don't know if Mr. Pavloff is in a position to undertake this work by himself. Perhaps though, someone would be willing to assist in this, given enough good will and the preception that this would be generally useful.

As a technical note, while I am not an expert in Linux drivers, I have been given to understand that the future trend is away from kernel drivers, and towards loadable drivers. This might be something to keep in mind if we have to deal with multiple drivers.


> This isn't a new market -- this isn't a new idea.
> You're copying things that have been done before. The only people
> that will use your project with the current licensing terms are
> integrators. That's it.
>
> And I don't think that you have enough integrators and
> "procrastinating grad students that want to run their train set" with
> the programming skills and time to create a PLC that can even compete
> with some of the AutomationDirect and other cheap PLCs out there.
<clip>

While I don't have any involvement in this project, I was under the impression that it was more properly a soft logic system than a conventional PLC.
I am aware of several soft logic systems that are perhaps a bit more proprietary than you may be familiar with. Some equipment OEMs who produce "standard" machines have written their own soft logic systems. These systems have their faults, the main ones being that they are all different, and rarely come with any useful documentation (or even any at all). However, they do work and most of the companies which created them are not particularly large. They apparently felt they had good reason to create a system which would be under their own control, rather than rely on a third party.
When these companies can come up with their own working soft logic system, I don't find it too suprising that "integrators and procrastinating grad students" could do the same. I think rather, that too large a number of people working on a software project like this would be more likely to sink it than help. Too many cooks spoil the broth, as it were.

Michael Griffin
London, Ont. Canada

By Jiri Baum on 18 March, 2002 - 2:39 pm

> Michael Griffin (on the MAT LinuxPLC):
> > While I don't have any involvement in this project, I was under the
> > impression that it was more properly a soft logic system than a
> > conventional PLC.

Yes, it is. Mind you, there's not that much difference (technically) between a soft logic system and the firmware of a PLC, so it may well eventually be both.

> > I think rather, that too large a number of people working on a
> > software project like this would be more likely to sink it than
> > help. Too many cooks spoil the broth, as it were.

For the time being, though, additional people would help rather than hinder, so feel free to join in :-)

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 Curt Wuollet on 18 March, 2002 - 2:40 pm

And if you put it on the PCPLC Open Hardware project, it will, in effect, be a PLC. Even quack like one :^)

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net. Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

Alex Pavloff:
> Curt, my major point about the problems with the GPL in regards to your
> MAT project:
...
> The only people that will use your project with the current licensing
> terms are integrators. That's it.

Then again, every machine project has an integrator towards the end of the chain. In-house or external, formal or de facto, it doesn't matter - it's still an integrator. Someone who has to say ``to make *this* particular pile of rust move and do something useful, we can use X, Y or Z and these are the pros and cons of each''.

So appealing `only' to the integrators is perhaps not as bad a strategy as you might make it out to be...


Jiri, assuming for the sake of the argument that you're right
--
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 8 March, 2002 - 3:59 pm

On Thu, 7 Mar 2002, Curt Wuollet wrote:
> As you can plainly see, there are plenty of people who would
> like to take work freely given and exploit it for profit. To
> take what is Open and close it, for whatever reason, is a
> step in the wrong direction.

Depends on your motive. This is exactly the effect of the BSD style license. Red Hat, GPL lovers that they are, have taken OpenBSD, which is freely available, but not GPL, and have created
the Stronghold web server, which is not freely distributable, and is not free to use. You've got to buy a license.

Now, most people in the GPL crowd find that repulsive, but Theo and the crew at OpenBSD are free to release their code under any license they want, and that's how they choose to do it.

> If you, as the author, decide to license _your_ code, both
> under the GPL and your private license, you are free to do so
> and then your product, using your code need not be GPL.

This is an important point that most people fail to understand. If you, as a developer, create some neat-o whiz-bang program that the whole world wants, and stuff it out on the net under GPL, then I'm not free to take that code, do something with it myself, and resell it closed source. The GPL protects *YOUR* right to make the code freely available. But it's still your code. I can say, "Hey. Good stuff there. Sell me a license to put it in my xyz not GPL." You can look at my offer, decide it's good money, and give me a piece of paper that says I'm free to distribute exactly the same software, but commercially licensed, and I don't have the GPL restrictions. In other words, if you release
something under the GPL then that's not an exclusive license to the world. You can commercially license it to 40 different people,
who are free to us it in what ever manner you gave them permission. But the can't take the free distribution and use it any way they want. They can only use the free distribution if they also make their stuff free.

See Curt's next paragraph.

> The only thing you are prohibited from is taking someone
> else's GPL code and making it part of a closed product
> against their wishes.

The GPL has a place. It's exactly the reason the whole GNU/Linux movement exists today. The BSD style license has a place. It promotes commercial development in a way the GPL restricts. Closed source has a place. It feeds most of us. There isn't a "best" license. It's more a matter of a "best fit" license depending on your purpose.

MB

By Curt Wuollet on 10 March, 2002 - 6:26 pm

Well put, Micheal and the GPL is very good for our purpose here. I have code under other license and some under no license and a lot that is unpublished and privately owned. And I find no particular conflict in that. If your purpose is to open things up and keep them open, you use the GPL. If your purpose is to collect a paycheck, you might not have much to say about it. But, more and more, people are realizing the enormous value of tapping in to the bounty of GPL software for the small price of giving back the part you add. The majority of users use it as is or don't publish what they change and so owe nothing.

Regards

cww

By Michael R. Batchelor on 10 March, 2002 - 4:19 pm

On Thu, 7 Mar 2002, Curt Wuollet wrote:
> As you can plainly see, there are plenty of people who would
> like to take work freely given and exploit it for profit. To
> take what is Open and close it, for whatever reason, is a
> step in the wrong direction.

Depends on your motive. This is exactly the effect of the BSD style license. Red Hat, GPL lovers that they are, have taken OpenBSD, which is freely available, but not GPL, and have created the Stronghold web server, which is not freely distributable, and is not free to use. You've got to buy a license.

Now, most people in the GPL crowd find that repulsive, but Theo and the crew at OpenBSD are free to release their code under any license they want, and that's how they choose to do it.

> If you, as the author, decide to license _your_ code, both
> under the GPL and your private license, you are free to do so
> and then your product, using your code need not be GPL.

This is an important point that most people fail to understand. If you, as a developer, create some neat-o whiz-bang program that the whole world wants, and stuff it out on the net under GPL, then I'm not free to take that code, do something with it myself, and resell it closed source. The GPL protects *YOUR* right to make the code freely available. But it's still your code. I can say, "Hey. Good stuff there. Sell me a license to put it in my xyz not GPL." You can look at my offer, decide it's good money, and give me a piece of paper that says I'm free to distribute exactly the same software, but commercially licensed, and I don't have the GPL restrictions. In other words, if you release something under the GPL then that's not an exclusive license to the world. You can commercially license it to 40 different people, who are free to us it in what ever manner you gave them permission. But the can't take the free distribution and use it
any way they want. They can only use the free distribution if they also make their stuff free.

See Curt's next paragraph.

> The only thing you are prohibited from is taking someone
> else's GPL code and making it part of a closed product
> against their wishes.

The GPL has a place. It's exactly the reason the whole GNU/Linux movement exists today. The BSD style license has a place. It promotes commercial development in a way the GPL restricts. Closed source has a place. It feeds most of us. There isn't a "best" license. It's more a matter of a "best fit" license depending on your purpose.

MB

By Joe Jansen on 8 March, 2002 - 11:37 am

Alex Pavloff wrote:
> -----Original Message-----
> From: Jiri Baum [mailto:jiri@BAUM.COM.AU]
> Sent: Friday, March 01, 2002 10:15 PM
> To: AUTOMATION@ALIST.CONTROL.COM
> Subject: Re: OPENC: linux Modbus master

> OK. If the feature is something that's generally useful, chances are
> it'll be generally requested, though, and possibly obvious.

Of course -- however, I have a head start.


Joe replies:
So did Netscape. When IE became free, netscape was forced to change their business model to the server market. The one issue that does concern me
about OSS is that it does push into legitimate markets (in my opinion) and pull the ground out of them.

Alex:
> The people who are already in factory automation, currently using a
> closed source product. Instead of working around bugs, they could go
> fix them, which will fairly often end up less painful than the
> work-arounds. Similarly if they need a minor feature added.

I have the firm belief, based on my dealing with integrators using my products, that most of them don't have the time to go messing around with
writing something new. Working around bugs isn't that hard. Maybe when you guys actually have a working system, your statement will be true.
However, right now, as you say, the LinuxPLC is in pre-Alpha, not for production use, and probably has lots of bugs to work around. (Heck, I can't get anything in your project system to compile, and I don't have the time to find outwhy).


Joe:
Working around the bugs isn't that hard, compared to.....? There really is no option right now, is there?

Nobody has claimed (that I have seen) that L-PLC is in a production ready state. Yes, it probably does have a lot of bugs to *fix*.

Why don't you have time? Are you busy working around artificial barriers in other systems?


Alex:
Using the LinuxPLC it right now is more painful than working around bugs. Therefore, people won't use it (because they have product to ship),
therefore, no work will get done.


Joe:
Gee, what have we been doing then? I am sorry to hear that no work has been getting done. Apperently those code check in's are just random bit flips at sourceforge then.....


Alex:
Chicken & Egg problem, and the only way you're going to get out of that is by getting enough developers as possible. For the lack of a better term, have you considered that your "GPL snobbery"
is going to turn away developers (like me) that could otherwise contribute to your project?

Joe:
you said yourself that the problem you had with GPL was that you couldn't take the GPL-ed code, tie it into your product, and sell it on the market. What sort of contribution to the project would this be, exactly?

Alex:
> Procrastinating, actually. The usual term is `thesis avoidance'.
>
> And there are a few, especially if you expand to those who'd merely
> use it to run their model trains and the like.

Great. I just can't wait to see your finished programming environment.


Joe:
Ooooh! Good one! Anyone who has a hobby that could use controls is apparently incapable of being a professional programmer at the same time.

Alex:
> It also depends on what's already out there - if there's already a GPL
> program that would be a good fit, then it'll be difficult to come up with
> something sufficiently differentiated for people to actually notice.

True.

However, the LinuxPLC is just a copy of one of a hundred existing PLCs (most of which actually work now). Doesn't seem too differentiated to me.


Joe:
Each of those 'hundred existing PLCs' seems to have found a niche. I am sure the LPLC will do likewise.

Alex:
Alex Pavloff
Software Engineer
Eason Technology

Joe:
--Joe Jansen

By Alex Pavloff on 10 March, 2002 - 5:02 pm

> Joe replies:
>
> So did Netscape. When IE became free, netscape was forced to change their
> business model to the server market. The one issue that does concern me
> about OSS is that it does push into legitimate markets (in my opinion) and
> pull the ground out of them.

That's interesting that you brought up Netscape. The open source version of Netscape, Mozilla, is licensed under the MPL. An open source project under the MPL that I will be using shortly (and, of course, looking at and fixing bugs and submitting my code to) is Microwindows. (www.microwindows.org). I can write my NDAed code, I can write my proprietary drivers, and I can distribute this.

As a result, I use it, and plenty of other people use it, and things get bug fixed and features get added.

> Joe:
> you said yourself that the problem you had with GPL was that
> you couldn't take the GPL-ed code, tie it into your product, and sell it
> on the market. What sort of contribution to the project would this be,
exactly?

If I took your code, changed things in it, fixed bugs, and added features, does that count as a contribution? I've already done this for an LGPL project (CommonC++), but can't do it for you. You use a less restrictive license, and more companies will look at your code, finding more bugs, and add features to your code.

As it stands, your project is fairly OEM hostile. I can't use it. You've got an all-or-nothing license here.

> Joe:
>
> Ooooh! Good one! Anyone who has a hobby that could use controls is
> apparently incapable of being a professional programmer at
> the same time.

No, I just really doubt the desire of a hobbyist programmer to get into the nuts and bolts and actually put together a system half as usable as one put together by a company that wants to make a profit. Once all the sexy work has been done, whose going to write documentation? Whose going to sit around and tweak the user interface of your ladder editor to make it user friendly?

I know that you guys can get the technical stuff done -- its fun to work on, and makes stuff work. Its the secondary things that don't get done in open source projects unless there's a company spending money directly on the project.

Remember -- this is a PLC that you're working on. In the end, you're going to have to get it to the point where an electrician can debug that ladder logic at two in the morning to make the plant go.

> Each of those 'hundred existing PLCs' seems to have found a
> niche. I am sure the LPLC will do likewise.

I thought that the goal was to conquer the world and make life easier for all the integrators tired of dealing with crappy software, overpriced
hardware, and evil companies.

Alex Pavloff
Software Engineer
Eason Technology

By Richard Higginbotham on 11 March, 2002 - 1:38 pm

Some secondary things will be done by LPLC members as time allows, others will be done by companies selling support or who just want it done. The difference is that you dont have just one source for this service who can charge whatever they feel like. Competition LOWERS prices, which in general, is good for the users.

What I think a lot of people seem to be missing is that the Modbus code wasn't drawn out of the ether, it was written by someone and DONATED to the LPLC project. As such its thier (whoever it may be) right to decide what licience it is released under. If you want to write parts under a less restrictive liciense and donate those to the project, as far as I know, you are free to do so (Curt, Jirri, help me out on this one). What they can't do is force you to release your code under a licience that you don't like or think is fair. No ones stoping you from doing this they are just preventing you from taking someone elses code and make money off of it against their wishes. In this way, you and these "other companies" can share a code base (used in your proprietary code) and at the same time it can be debuged and patched by those who don't want to work for you for free (like myself).

Problem solved.

Richard Higginbotham
Speaking for me

By Curt Wuollet on 12 March, 2002 - 10:48 am

As far as I'm concerned everything that goes in the cvs archive must be GPL. There are just too many variables if we start mixing and even
attorneys can't figure out all the implications. That's not to say that it can't be done, just that the core project needs to be consistant. Anything not GPL would be distributed seperately and the author can be responsible for the legalities. We don't have a legal volunteer. We may need to work with drivers, for example, under other licenses but I'd like to keep these seperate so a legal problem can't shut us down.

Regards

cww

By Richard Higginbotham on 12 March, 2002 - 5:01 pm

Sorry, should have been more clear but ran out of time. I don't mean to have several different liciensing requirements for different parts of LPLC (what a nightmare that would be). I meant to say that an "outside" organization could donate code to LPLC under the GPL (ie. make available thier code under more than one licience) which would keep everything in LPLC GPL happy. That same group could also license their source code with LGPL (or any other) for
commericial users. We'd simply be using a library of functions proprogating bug fixes, problems, etc. back up to another group who was responsible for the software same as any other library that was external to LPLC. We could take
advantage of the code base, assuming there are all these companies who are willing to donate and not just take, and they would get a bigger pool of people helping out. It wouldn't be any different than anything we do now. If libX
doesn't work correctly, you send an email to the developers, right? I agree that it shouldn't be part of Linux PLC (back door for too many outside rather nefarious influences), but I think it would be a benefit to help support said outside group so long as there is benefit for us (it might even be worth a branch). If it turns out that the "commercial" entities aren't updating, fixing, etc. at a fast enough rate, we still have GPL code we can use and modify according to our needs. If it helps get IO drivers written, I think its worth trying. I doubt that there will be that much corporate interest, but, hey, Alex says he wants to help us out. Perhaps he is willing to donate his modbus code...

Richard Higginbotham
speaking for me

By Curt Wuollet on 13 March, 2002 - 1:12 pm

Hi Richard

And some of the reason is pragmatic. Lawyers and courts are entirely for organizations with money. The GPL does what we want to keep the code free and Open and it tends to be enforced by the community. If you break the rules, you get slashdotted and the world becomes a much lonelier place. And the fact that the same code can be GPL licensed as well as in the customary manner lets folks contribute bits and pieces we need without affecting what they are doing with it to stay in business. For libraries, in the case where the library _is_ the product, there are provisions made. All in all it's pretty reasonable. Usually, having parts of your product dual licensed shouldn't affect your business negatively, in fact, some companies are capitalizing on this to make parts of their products user supportable and customizable at no cost to them. Getting past the knee jerk reaction to realisticly addessing the real effects of contributing, I think it's very clearly a positive for all involved if they have any use for the project code.

Regards

cww

By Alex Pavloff on 15 March, 2002 - 10:19 am

> If it helps get IO drivers written, I think its worth trying. I doubt
that there
> will be that much corporate interest, but, hey, Alex says he wants to
> help us out. Perhaps he is willing to donate his modbus code...

I'm not against the idea. I've got drivers that I've written for quite a few platforms that will eventually be ported over to Linux. However, there are a couple things that are problems.

I'm a C++ programmer. Yes, I'm evil, but all my communications code is written in C++. Curt has said a while back on the list that he wants to keep everything C so people can read it.

This aforementioned C++ driver code has dependencies on other parts of my code. Again, while I'm not really against the idea of GPLing some of this code, it would take a bit of work to get it into a distributable state. I don't think it would fit too well into a pre-existing project like the MAT because its from a completely separate lineage.

I work for a small company -- we don't have a lot of programmer bandwidth. I say "it doesn't seem like a bad idea to provide some of my code under the GPL", but then I have to prove to the people writing my paycheck that its actually a worthwhile use of my time.

Accolades in source code comments and nebulous "goodwill" don't really do that. To be brutally honest, will GPLing my code make my company money? Answer me that question.

Alex Pavloff
Software Engineer
Eason Technology

By Richard Higginbotham on 15 March, 2002 - 10:26 am

>To be brutally honest, will GPLing my code make my company money?
>Answer me that question.

No, probably not, GPL benefits the users and work-in-your-spare-time developers far more than corporate interests. BUT thats not the million dollar question. GPLing your code or not does not mean that the code won't be available (the
code will be there, hence this thread). What will you do when the same (functional wise) code is either available for free or your competition has 10x the develeopers, testers your company does at
no cost? GPL will probably not make you more money than you make now, but it may reduce your costs enough that you can compete later. Its up to you (your company) do develope a business strategy that will work in that (new) environment.

Richard Higginbotham
speaking for me

By Alex Pavloff on 16 March, 2002 - 3:10 pm

So then, when a large body of GPLed code that does what I'm doing exists, THEN I should make another decision? This assumes that there are a large number of linux-using automation companies out there. As far as I can tell, the number of Linux-using automation companies is very small. There doesn't appear to be any companies the likes of Intellution doing the same thing on Linux. There doesn't appear to be companies like Software Toolbox selling drivers for Linux. Most of the big automation companies are going with Windows CE for their embedded HMI needs.

Call my cynical here, but where are these other developers and testers that can provide 10x the resources that my puny company has coming from? I don't think anyone is going to blame me for not being the first one to jump in the pool here on the promise of "lots of people are going to follow you."

And here's the thing -- the things I AM using on Linux right now (CommonC++, Microwindows, the kernel, busybox, etc...) I can use just fine without GPLing all my code. Half the stuff I'm not even touching the code for, and most of the rest is LGPLed or MPLed. I test their stuff, I contribute my changes, and we all win.

Exactly how will the GPL help me? Where is the large body of GPLed code that I need to link statically to that will make my life easier?

You guys talks about this "new" way of doing business, and, I'm sorry, but it ain't here yet! (Of course, I'd point out that I'm hedging my bets in case it does, as I'm already using Linux <g>)

Alex Pavloff
Software Engineer
Eason Technology

By Jiri Baum on 18 March, 2002 - 9:06 am

Richard Higginbotham:
> > What will you do when the same (functional wise) code is either
> > available for free or your competition has 10x the develeopers, testers
> > your company does at no cost? GPL will probably not make you more
> > money than you make now, but it may reduce your costs enough that you
> > can compete later.

Alex Pavloff:
> So then, when a large body of GPLed code that does what I'm doing exists,
> THEN I should make another decision?

Yes - there may well be a cross-over point (ESR has a whitepaper on this) after which it's rational for you to go GPL. It might be good to run a few hypotheticals in your spreadsheet so you can tell that point when it comes.

> This assumes that there are a large number of linux-using automation
> companies out there. As far as I can tell, the number of Linux-using
> automation companies is very small.

Yes. One would hope (we would hope) that this will increase in the future.

> I don't think anyone is going to blame me for not being the first one to
> jump in the pool here on the promise of "lots of people are going to
> follow you."

The only reason you might want to be first is that there's a certain advantage to it (easier to attract developers if you're first-of-kind). This doesn't really apply to the Modbus driver, seeing as Mario already put one in the MAT CVS (and there's likely others floating around).

As for the MAT LinuxPLC project, one way we expect it'll proliferate is the already-mentioned model train layouts; but mainly we hope to provide an irresistible combination of features and flexibility.

As has been observed, most likely the first ``real'' adopters will be integrators, who own little IP beyond the code they sell to each individual customer. In that situation, it is merely a question of replacing TnD or AutomationX with the MAT LPLC - a feature-based comparison will quickly show which is the better approach.

> Exactly how will the GPL help me? Where is the large body of GPLed code
> that I need to link statically to that will make my life easier?

Yeah - when you see a body of GPLed code that you want.

> You guys talks about this "new" way of doing business, and, I'm sorry,
> but it ain't here yet! (Of course, I'd point out that I'm hedging my
> bets in case it does, as I'm already using Linux <g>)

Hedging bets is good :-)


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 Richard Higginbotham on 18 March, 2002 - 12:18 pm

>There doesn't
>appear to be any companies the likes of Intellution doing the same thing on
>Linux. There doesn't appear to be companies like Software Toolbox selling
>drivers for Linux. Most of the big automation companies are going with
>Windows CE for their embedded HMI needs.

And which of those will give their "product" away for free, which will be open? Given two nearly functionally identical products, but one whose price is "free" and whose architecture is "open", it doesn't take a psychic to figure out which will be used more often. We just need some time to work on that that open option before it can be proved to you.

>I don't think anyone is going to blame me for not being the first one to
>jump in the
>pool here on the promise of "lots of people are going to follow you."

I suppose that all comes down to whether you prefer action or reaction. There's risk either way, if you don't get warm and fuzzies for helping a common interest, then I probably wouldn't do it if I were you. You certainly don't need to do anything now, and you will only know afterward whether you made the right decision at the right time or not, in which case it will probably be too late good or bad. If you were a user then I would say that the work would directly benefit and be geared toward you so its probably in your best interest to help as much as possible, but as your a vendor it probably won't make any difference at all until theres a competing 'free' product if there ever is one (don't know what your product is). By then, it will probably be too late, as I've already mentioned. Like I said earlier, only you have to live with your decisions. At least your looking at options so you'll be better prepared if theres anything to prepare for. heh, at least if I were you, I would keep track of the progress to see if there is anything developing that might be in competition to you, that would seem to be a good time to make a decision ;-)

>You guys talks about this "new" way of doing business, and, I'm sorry, but
>it ain't here yet! (Of course, I'd point out that I'm hedging my bets in
>case it does, as I'm already using Linux <g>)

Has anyone said it was? No one I know of is arguing to rip out your AB, Siemens PLCs just yet. My optimistic best guess is that you've still got a couple of years before there's a mature code base to work with. I can't imagine it taking less than 10 man years just for an IDE. I suspect it will be usable well before then, just not something I'd hand over to one of my customers.

Regards,
Richard Higginbotham
speaking for me

By Michael R. Batchelor on 19 March, 2002 - 11:22 am

> >There doesn't
> >appear to be any companies the likes of Intellution doing the same thing on
> >Linux. There doesn't appear to be companies like Software Toolbox selling
> >drivers for Linux. Most of the big automation companies are going with
> >Windows CE for their embedded HMI needs.
>
> And which of those will give their "product" away for free, which will be
> open? Given two nearly functionally identical products, but one whose price
> is "free" and whose architecture is "open", it doesn't take a psychic to
> figure out which will be used more often. We just need some time to work on
> that that open option before it can be proved to you.

This is true, but see below for a little bit of analysis about why this is such a touchy subject. And feel free to point out where I'm wrong. I've been wondering about this for a long time.

> >I don't think anyone is going to blame me for not being the first one to
> >jump in the pool here on the promise of "lots of people are going to
> >follow you."
>
> I suppose that all comes down to whether you prefer action or reaction.
> There's risk either way, if you don't get warm and fuzzies for helping a
> common interest, then I probably wouldn't do it if I were you.

Years ago, before my hair turned gray, I hammered my boss to send a yearly donation to a little outfit know as the Free Software Foundation, aka Richard Stallman. I was, and still am, a big
proponent of free software. But there's a difference in the discussion here that most people don't realize. (Frankly I hadn't
figured it out, either, until I started thinking about this thread. And some may be willing to say I still haven't figured it out.)

Back in the old days when we were all contributing stuff to the yet to be named "Open Source" movement we weren't contributing anything that was "the company product." We were contributing time and expertise to help other poor suckers stuck in the same boat. In other words, the free stuff that got contributed was a
"tool" we built to accomplish a task we needed performed in our own organization. Unsurprisingly other people in other companies with the same jobs had to perform the same tasks and the tools
were handy for them, too. Since software isn't like a wrench, i.e. if I give you my wiz-bang gizmo I still have it for myself, but if I give you my 11mm wrench I do without, we all shared
freely, and we all were happy.

But, here, we're not talking about sharing a tool to solve a problem we have internally, we're talking about giving away our flagship product.

If you look at the OS community it's done a tremendous job of building tools, but the only real word processor with a prayer of unseating MS Word from the driver's seat is Sun's Open Office. And that's strictly a calculated maneuver to stab a competitor in the back without hurting their own market position. (OK, sure there is some altruism, but if Star Office was going to *HELP*
Microsoft in Intel hardware at the expense of Sparc hardware, do you think they'd do it? If MS would port MS Office to Solaris and thereby *INCREASE* Sparc sales Open Office would get dropped like a hot potato.) And the reason is that a word processor is a finished good, not a tool or component to build a finished good.

DING, DING, DING!

OPEN SOURCE LICENSING WORKS WELL FOR TOOLS OR COMPONENTS, BUT IT'S AN AWKWARD FIT FOR FINISHED GOODS!

Now, the System Integration market is mostly about one thing. As an SI, my company can take all this "stuff" and make it solve the customer's "problem." Well frankly, the customer buys the "stuff" irrespective of whether it's free or a million bucks. I don't absorb any of the cost unless it's a calculated maneuver to
increase my customer base one way or another, like grumbling about the cost of RSLogix when I write the check.

So, the logical place that Open Source solutions will be beneficial is in the machine builder side where the customer doesn't care what's inside the box, because he doesn't buy the "stuff" inside the "box." He buys the "box" and expects it to
work. The machine builder wants to cut costs on producing a bunch of "boxes" so he uses OS tools to lower his cost of the "stuff" inside those boxes. So far this isn't a "real" scenario. but I think it's how things are going to pan out.

Comments?

MB
--
Michael R. Batchelor - Industrial Informatics & Instrumentation, Inc.
Linux is like a wigwam...
No windows, no gates.
Apache inside.

By Curt Wuollet on 19 March, 2002 - 5:07 pm

Hi Michael.

Just one note. We're _not_ asking companies to give their flagship product. What we need is much more bits and pieces that shouldn't affect their business except positively. We will have the core that everyone does, logic solving, HMI, etc. What we will need is what most companies will benefit by sharing. Protocols, languages, and anything that someone wrote for a purpose that now sits moldering in a file someplace. The protocols and languages are things that people _want_ to propagate for various reasons. What better way to get people using your proto, language, etc,? Growing market share for these is extremely difficult, especially if you're a second or third tier vendor. MAT/LPLC is about the only way I can see to get people to take a serious look at your knowlege based wares if they usually buy elsewhere. These things aren't the product for most companies, yet they are strategic and can sell the rest. For the independant IO manufacturers, for example, it's crazy not to release your protos as widely and openly as possible. For the more vertical stuff, the reasons are less obvious but still there. I agree mostly with what you said, but it's counterproductive to say we want your flagship when all we need is to be able to interoperate. The F and O words scare enough people as it is.

Regards

cww

By Alex Pavloff on 20 March, 2002 - 3:28 pm

> What we will need is what most companies will benefit by sharing.
> Protocols, languages, and anything that someone wrote
> for a purpose that now sits moldering in a file someplace.

I find it hard to believe you want moldy old communications code. I HAVE lots of moldy old communication code, and trust me, you don't want it. I don't even want it. It stays in source control locked in a box with a stake through its heart, and I will never, ever let some of that stuff see the light of day again.

Here's a thought -- write a serial and TCP/IP communications toolkit that you can use to put a driver together in as little time as possible. Once you have generic communications & packet code in place, implementing other protocols can be done in a week. Do that, and make your own drivers, and then you'll get people to use your stuff.

As it stands, your request for "moldy" old code will just cause you and your buddies piles and piles of grief.

(This, of course, assumes that the spec is available for the protocol -- without a spec, I'm not sure you would want code anyway!).

> MAT/LPLC is about the only way I can
> see to get people to take a serious look at your knowlege based
> wares if they usually buy elsewhere.

I have never actually talked to someone off this list or outside my office that has ever heard of MAT/LPLC.

> For the more vertical stuff, the reasons are less obvious but still there.

And these reasons are... ? I just went through that entire discussion with Jiri, and we pretty much agreed that, at this point, there isn't much obvious gain that can be made via GPLing my code. I can use GCC, I can use Linux, I can use people's libraries, and I win, and since there doesn't appear to be a large body of GPLed code out there that can help me, there isn't any reason for me to GPL my code.

"Kudos" in source is not a source of revenue, and the lack of widespread use of the MAT/PLC project means that I don't get any exposure that way.

Alex Pavloff
Software Engineer
Eason Technology

By Curt Wuollet on 22 March, 2002 - 1:41 pm

Hi Alex

> > What we will need is what most companies will benefit by sharing.
> > Protocols, languages, and anything that someone wrote
> > for a purpose that now sits moldering in a file someplace.
>
> I find it hard to believe you want moldy old communications code. I HAVE
> lots of moldy old communication code, and trust me, you don't want it. I
> don't even want it. It stays in source control locked in a box with a stake
> through its heart, and I will never, ever let some of that stuff see the
> light of day again.

You haven't seen some of my code :^) and yes, there is quite a bit that is specific enough where it wouldn't help many people. But some people are writing stuff that is general enough and fills a need. For example, we needed a graphical ladder editor. Now I know there are quite a few around, done as school projects or for older versions of PLC tools. As it turns out we found one on sourceforge and the author has graciously let Jiri fold it into the project. He gains a testbed and we gain a chunk of functionality that would take quite an investment of time to write. I would bet there are quite a few partial implementations of the IEC languages floating around that are curiosities unless attached to a going project. Many people have done something for their company that is not of commercial value because that's not their line of business yet is first class work and deserves a wider audience. You authors know who you are. Even the equivalent of DOS tools would be a welcome addition where we have holes. Of course, there are many on the list who would be happier with the better DOS tools than what has forcibly replaced them. But, that's another story. Protocols are another case where we want to support stuff that may be considered obsolete. They may not be commercially viable when you need high gross margins, but with collaboration and cooperation they can be user supported indefinitely. This is another niche that is well suited to our model and considered a burden by many vendors. I know I've done a lot of things for people that would be good enough to contibute but they are owned by them and will never see the light of day. It would be a lot more useful donated and it wouldn't have any effect on the owners that I can see.

> Here's a thought -- write a serial and TCP/IP communications toolkit that
> you can use to put a driver together in as little time as possible. Once
> you have generic communications & packet code in place, implementing other
> protocols can be done in a week. Do that, and make your own drivers, and
> then you'll get people to use your stuff.

I have thought of something like that, modeled on COMEDI, a project that provides a driver framework for DAQ cards. I'm not good enough to write it and it would take scads of money to cover all the cards available, but I agree it would be a very good thing indeed.

> As it stands, your request for "moldy" old code will just cause you and your
> buddies piles and piles of grief.
>
> (This, of course, assumes that the spec is available for the protocol --
> without a spec, I'm not sure you would want code anyway!).
>
> > MAT/LPLC is about the only way I can
> > see to get people to take a serious look at your knowlege based
> > wares if they usually buy elsewhere.
>
> I have never actually talked to someone off this list or outside my office
> that has ever heard of MAT/LPLC.

I labored for years in isolation with nobody who had heard of Linux :^).

> > For the more vertical stuff, the reasons are less obvious but still
> there.
>
> And these reasons are... ? I just went through that entire discussion with
> Jiri, and we pretty much agreed that, at this point, there isn't much
> obvious gain that can be made via GPLing my code. I can use GCC, I can use
> Linux, I can use people's libraries, and I win, and since there doesn't
> appear to be a large body of GPLed code out there that can help me, there
> isn't any reason for me to GPL my code.

And I agree that your particular situation wouldn't benefit much. In discussing this, I am speaking to the whole community. Their situations and strictures may well be different.

> "Kudos" in source is not a source of revenue, and the lack of widespread use
> of the MAT/PLC project means that I don't get any exposure that way.

Yes, but if enough people help it will become widespread. And I simply can't see any way that would be a bad thing for the automation community. I'm pretty sure you can agree with me there.

Regards

cww

By Richard Higginbotham on 19 March, 2002 - 5:31 pm

Ahh, its a flag ship product for a PLC vendor, but its NOT for us. I see a PLC as a tool. I don't care what its called so long as its easy to use and works. I want to able to enhance my tools if I feel they need it. I want to see features added and not have the rug pulled out from under me when someone decides they aren't making enough money, "lets switch to a new product and not provide an upgrade path". I don't expect AB or Siemens, or any other large vendor to jump on the LPLC band wagon. I work on it partly because I'm frustrated with them and see the benefits of something that is user centered. Whether someone makes money off of it or not doesn't matter. "they" are not user centered, no matter what the brochure says, "they" are stock holder centered. That's what makes the world go round as they say, but it might not make them necessarily the best "tool" developers as they have a direct,monetary interest in making sure I can't use anyone else's hardware/tools with my software(tool). I'd much rather have those tools developed by people who care about the tools themselves, how well they work, how easy they are to use, and how well they can integrate with all the possible combinations of equipment out there.


>Now, the System Integration market is mostly about one thing. As
>an SI, my company can take all this "stuff" and make it solve the
>customer's "problem." Well frankly, the customer buys the "stuff"
>irrespective of whether it's free or a million bucks. I don't

It matters to them when they shell out the money and pay for maitenance. It matters to them if its buggy or not or if they are locked in to certain hardware or not. It matters to you when you want to get training or have test equipment. It matters to you if you can say "Yes, we can integrate this all together seamlessly. We can support your legacy systems and your new systems with very little work." It matters when you can't get the system up and running because of buggy software, but the customer doesn't care about your excuses, etc.

I work for an SI too, and I've come across so many instances when I would love to have new features but there's nothing I can do. Or when I want desperately to fix a system that I know is kludgey but can't do anything about it. I've spent enough time on the phone waiting futility for someone to care just because we pay them tons of money. With LPLC I will be able to. It will expand greatly the things that I can do, AND be PAID to do, so I'm all for it.
I've seen a lot of SIs do things the hard way, and to an extent if your all about making $ the longer it takes, the harder it is, the better off you are. I personally would rather make money off of what I know and can do than just being one guy willing to go through the tedious motions at the lowest bid. Its the end users though who are really going to see a difference, I think. In upfront costs as well as time, etc. As to the applications. Open source doesn't make you smart (though it increases your opportunities to learn), it doesn't make you better either at coding or designing apps. If open source "fails" at a particular task, its not because the code was available, its because the developers/designer did a poor job. It just means I can see where xxx failed, take the good parts and make them better if I choose to. If LPLC is kludgy, buggy, user unfriendly, or anything else, its because of those of us working on it failed, not because you can see the source or its developed on someone's goodwill. You will always have the opportunity to learn from our mistakes i.e.. we are not out to hide them because we don't care if we sell X units, only if the end product works well (we use it too after all).


Richard Higginbotham
speaking for myself

By Jiri Baum on 20 March, 2002 - 2:22 pm

Michael R. Batchelor:
> Back in the old days when we were all contributing stuff to the yet to be
> named "Open Source" movement we weren't contributing anything that was
> "the company product." We were contributing time and expertise to help
> other poor suckers stuck in the same boat. In other words, the free stuff
> that got contributed was a "tool" we built to accomplish a task we needed
> performed in our own organization. Unsurprisingly other people in other
> companies with the same jobs had to perform the same tasks and the tools
> were handy for them, too. Since software isn't like a wrench, i.e. if I
> give you my wiz-bang gizmo I still have it for myself, but if I give you
> my 11mm wrench I do without, we all shared freely, and we all were happy.

Bingo!

> But, here, we're not talking about sharing a tool to solve a problem we
> have internally, we're talking about giving away our flagship product.

The real product in Automation is ``machine works''.

Software tools to help accomplish this are epiphenomenal. They exist, and they're sold or shared (or not), solely to help with the ultimate goal of making a machine work. If you could make a machine work by waving a magic wand, it wouldn't matter one whit to the client (though it'd look suss on the job bid).

> Now, the System Integration market is mostly about one thing. As an SI,
> my company can take all this "stuff" and make it solve the customer's
> "problem."

Precisely.

> Well frankly, the customer buys the "stuff" irrespective of whether it's
> free or a million bucks. I don't absorb any of the cost unless it's a
> calculated maneuver to increase my customer base one way or another, like
> grumbling about the cost of RSLogix when I write the check.

The customer will probably prefer integrators that minimize overall cost; if you can get the "stuff" for free, there's one way to decrease overall cost without decreasing your share.

Certainly there will be some rearrangements in the industry, as players who used to make a living by selling software-as-product will have to adjust; but the flagship product automation - making machines work - will remain, and possibly pick up if per-job costs go down.

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

Michael,

Food for thought - thanks.

But remember - the software house's "finished good" is the production factory's "tool".

Bruce.

By Michael R. Batchelor on 20 March, 2002 - 3:04 pm

> Food for thought - thanks.

Well, food for thought was my goal. I'm not sure there is a "clearcut" answer to all of this, nor am I sure I can even clearly express my various enthusiasm and concerns to myself, much less to a whole mailing list of people.

>
> But remember - the software house's "finished good" is the
> production factory's "tool".

I think the most interesting point here, as brought out by several other posts I'm not referencing in this particular message, is that all the current debate comes to the surface
because we're "at the edge" of where finished goods and tools or materials get all mixed up.

Let me give an example of how things have changed. In the "former life before gray hair" I spoke about I used to work for a
publishing/broadcasting news organization. My responsibilities were to manage a lot of infrastructure stuff to makes things happen. I.e., plant HVAC systems, radio transmissions systems, all of the data processing communications and email, etc. In other words, my staff "made things go" in the background so the
visible staff, i.e. the reporters, etc., could get the "product" out the door.

Back then every time I had a problem I'd turn to Usenet first, and when I had a solution I'd put it out for the world. But the problems I was solving were not related to the core "product" of
my organization. They were necessary to the functioning of the organization, but they were not part of the finished goods. And most of the other people I dealt with then were also not part of the "finished goods" department. (In fact, for a lot of years I used to expound that IT should be a maintenance and engineering department, not part of finance. I still think that, I just keep
my mouth shut about it now.)

While it's true that these "tools" or "products" we're talking about here are just so much "stuff" inside the "box" once it gets in the plant, they are sometimes the "finished goods" of a process or vendor a little further up the line.

Now, even though that was just as true way back then, the fact is that SCO's development package for Xenix was pretty far removed from the reporters desk, and nobody cared if I threw it out in favor if GCC. In fact, except for the people who worked with me, most of them didn't even know that I had gutted just about everything but the kernel in every node in the whole organization and replaced all the peripheral stuff with stuff from comp.sources.unix. But we were a separated from the finished goods edge by a mile, and nobody cared.

Shift to the conversation we're having now, and we're not talking about changing infrastructure stuff a mile away from the company's finished goods, we're talking about things that are
centimeters away from the finished goods. And that knife blade is making people nervous. (Sometimes it makes me nervous, too.)

Yes, I agree that, "once were on the other side all this free stuff will make life better for everyone." Yes I understand the altruistic motive. But at the same time I understand that I might put a 1000 hours into something and not see a dime while someone else, like my direct competitor, sees a huge benefit from my sweat. Someone, somewhere, is going to get cut by that knife at the edge. And we're all just trying to find a way to make sure it isn't us.


Just more food for thought, here. Comments are welcome.

Michael

By Michael Griffin on 20 March, 2002 - 3:37 pm

If the project is a success, I wouldn't expect it to be a direct competitor to traditional PLCs, at least not initially. I would see it as rather having two areas of commercial application.

1) As a replacement for proprietary soft logic systems for those machine OEMs who have written their own. There are quite a few of these proprietary soft logic systems in "standard" (but customisable) machines, none of which seem to have any documentation or any support outside of what little the equipment OEM can offer. This would seem to be a fairly straight forward replacement by the OEM of one system by another.

2) As a soft logic engine for helping to integrate either custom or "standard" automated test systems into production lines (e.g. doing things like test fixture control). Again, this is more or less a replacement by the OEM of existing proprietary code.

Neither of the above sell soft logic systems, but both use them. What is being replaced in these examples isn't generally a traditional PLC or even a third party soft logic system, but the OEM's own proprietary code. This isn't code which is sold to the public independently of the machines it is incorporated into, so it doesn't show up in market share statistics.

These OEMs are not in the software business and aren't considered to be software companies. However, they do find themselves doing software development and a certain amount of support. Using a widely accepted "open" system would offer the potential to reduce both while still providing them with the degree of control over the software which their own proprietary system does.


An additional area of application could be industrial research establishments, or university engineering departments. Both of these share two qualities - a desire to experiment, and a lack of money to do it with. A "free" system with source code would seem to fit the bill quite nicely. It was these considerations which made Unix so popular in university computer science departments, who in turn developed it further and spread it to the wider world.

The above would seem to be a good market fit, even if it is less ambitious than replacing the existing PLC manufacturers.


--

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

By Jiri Baum on 18 March, 2002 - 9:02 am

Alex Pavloff:
> I'm a C++ programmer. Yes, I'm evil, but all my communications code is
> written in C++. Curt has said a while back on the list that he wants to
> keep everything C so people can read it.

That's not such a problem in itself.

> I say "it doesn't seem like a bad idea to provide some of my code under
> the GPL", but then I have to prove to the people writing my paycheck that
> its actually a worthwhile use of my time.

> Accolades in source code comments and nebulous "goodwill" don't really do
> that. To be brutally honest, will GPLing my code make my company money?

Another benefit may be bugfixes, improvements and extensions, but assuming the code is pretty good to begin with, there might not be much scope for that. Especially for something like modbus, which, after all, isn't such a rich universe (unless somebody adapts it to talk to a a not-quite-modbus product).

It may well be that GPL is not a good idea for you at this time, financially speaking. I guess people have pointed out the costs and benefits to you, it's up to you to do a cost/benefit thingy.


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 10 March, 2002 - 6:38 pm

Jiri Baum:
> > > OK. If the feature is something that's generally useful, chances are
> > > it'll be generally requested, though, and possibly obvious.

Alex Pavloff:
> > Of course -- however, I have a head start.

Joe Jansen:
> Joe replies:

> So did Netscape. When IE became free, netscape was forced to change
> their business model to the server market. The one issue that does
> concern me about OSS is that it does push into legitimate markets (in my
> opinion) and pull the ground out of them.

One could argue that whether volunteer or paid goods are better in some wider sense; if a market is better served by an open-source product, then why would it be a bad thing?

> > Using the LinuxPLC it right now is more painful than working around
> > bugs. Therefore, people won't use it (because they have product to
> > ship), therefore, no work will get done.

> Gee, what have we been doing then? I am sorry to hear that no work has
> been getting done. Apperently those code check in's are just random bit
> flips at sourceforge then.....

Alex is right that the work proceeds much slower for the time being; in addition, while it's not being used for a real project, it lacks the very important grounding influence that such projects would provide.


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