linux Modbus master

P

Thread Starter

Pushpa

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

Raymond van der Tas

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
 
A

Alex Pavloff

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
 
L

Lynn August Linse

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
[email protected] www.lantronix.com
Tel: (949)300-6337 Fax: (949)453-7152
 
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 <[email protected].com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
M

Mario J. R. de Sousa

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 [email protected]
--------------------------------------------------------------------------

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

Alex Pavloff

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
 
G

Greg Goodman

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

Alex Pavloff

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

Mark Blunier

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

Alex Pavloff

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

Curt Wuollet

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
 
J
Alex Pavloff wrote:
> -----Original Message-----
> From: Jiri Baum [mailto:[email protected]]
> Sent: Friday, March 01, 2002 10:15 PM
> To: [email protected]
> 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
 
A

Alex Pavloff

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