linux Modbus master

M

Michael R. Batchelor

> >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.
 
C
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
 
R

Richard Higginbotham

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

Food for thought - thanks.

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

Bruce.
 
M

Michael R. Batchelor

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

Michael Griffin

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