Open communications in the doldrums

Joe Jansen:
> Nokia sells their phones to Cingulair, Verizon, and other service
> providers who then give them away to the consumer, binding the
> consumer into a contract in the process that insures that they will
> more than recoup their losses. The problem is that there is no
> "middleman" as it were in the Linux software deal. The software
> developers sell directly to the user.

Sure there are middlemen - they're called integrators. The only difference will be that instead of buying software from the Nokia-equivalent, they'll d/l it off the net.

Every non-trivial project needs an integrator; they are where the bulk of the programming and other work is being done, anyway. Whether the
integration is done in-house or outsourced, the work needs to be done, will be paid for, and the people who do it will have bread on the table.

The only people worse off for it will be the Nokia-equivalent, if they don't manage to ride it somehow, but relatively few people work for them
anyway (perhaps 5%).

|------------------------------------------------(begin sidetrack)-----|
... [Railroad Tycoon II from Loki] ...
> some of their other releases not only had rampant piracy, but people
> would hack their code to make themselves invincible during tournament
> play.

That's poor protocol design, of course: security shouldn't depend on the good behaviour of the client software. It's also poor sportsmanship :)
|------------------------------------------------(end sidetrack)-------|

> IBM and HP both use Linux to sell their hardware. No secret here.
...
> No problem releasing this under GPL, since not many people have a use
> for an AS/400 operating system without the AS/400.

Much the same can be said for PLC programming (and other accessory) s/w: not many people have a use for it without the PLC.

> IA people, like most end users, want it for free.

So, then, what's the problem with it being free?

> As I tried to point out however, an open protocol is the only one that
> Linux can get. Are _you_ going to pony up the licensing fee for DH+?

One way to avoid this is to put the licensed stuff into the specialist interface card that most of the protocols need anyway. I'm not sure
about DH+ in particular, but certainly ASi, CANopen, ControlNet, DeviceNet, Interbus, ModBus+, PROFIBUS and Sercos can be handled this
way quite satisfactorily, and probably most others.

The firmware in the card then translates between the proprietary external protocol on the one hand, and the freely extendable, anhanceable and redistributable software on the other.

[about IBM]
> If making Linux better than Windows means people buy an AS/400 instead
> of an HP machine, or a roomful of little NT boxes, you can bet that
> they will improve Linux just enough to maximize this benefit.

And that's all anyone asks in the open-source world: improve the public pool of software just enough to maximise the benefit to you.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
H

Higginbotham Ricky

A Couple of comments on the Linux thread, in response to Joe Jansen (Re: COMM: OPENC: Open communications in the doldrums [LONG!])

Regarding games, i think its considered common knowledge in the gaming community that the best online servers are dedicated linux boxes. Actually, many companies will release a dedicated server linux version before any other, so the servers are there waiting for people. Some companies like Id Software, release entire games (not just server side) for both platforms out of sheer generosity (they also tend to be some of the best in their jenre, id, Bioware, etc.). The games that don't require much horsepower are a
different story entirely, but there are many such games on Linux that were created for it (ie. not ports) as well. Linux gaming has further to go, but its not being ignored in the gaming community by any stretch.

Reguarding Thriftiness. Theres a lot of open source software for windows. There are many ports of high quality Linux programs to windows. Programs like The Gimp, which has about 90% of Photoshops functionality is available to windows users now for free because enough programers felt like it. I don't pay for most of my Windows software because I don't need to, try
www.download.com sometime. On the other hand I do pay for quality linux software, and donate money to the projects whos work I use, reguardless of platform if i feel they merit it. Another noteworthy organization is the EFF. Not $200 for every app, but no one really pays for windows apps either. In return, I produce GPL software which some people use, and guess what, they probably don't appreciate it very much either ;-). Such is Life.

You might have noticed that Control.com is powered by Zope. Zope is OSS, written in Python, which is OSS and uses many other OSS libraries and code I'm sure (medusa for one i believe). Outside of IA there is a very big world, close your eyes if you want, its still there. Theres a lot of OSS you don't see, that just works, for business and individuals.

I've pretty much given up on Open Source as a movement in IA. Not because of the Venders (who are mostly irrelevant in the face of , but because I think they users are too apathetic about thier problems and don't look into the future when thinking of solutions. They want to save money now, by shoddy designs, cheap materials, etc. etc. by and large.

Having said that, I use a lot of OSS in my daily work for which the companies I work for benefit greatly. Yet they don't feel the need to
contribute to the OSS projects who make it all happen. Now who's the tightwads?

Richard Higginbotham
speaking for me
 
> > Alex Pavloff:
> > > OPC provides a way for any program, via a common API, to access
> > > anyone elses data.
> > ...
> > > If you want to create an open replacement to it though, go right
> > > ahead. Until its done though, I think most people will just use
> > > the technology that already exists and is supported
Jiri Baum:
> > There are such projects underway, of course; in a couple of weeks,
> > we should all meet in Belgium and discuss how best to join forces.


Alex Pavloff:
> For some reason, I don't think I can get the approval and cash to fly
> off to Belgium in a couple weeks. :)


It's a bit late to be organizing international flights, anyway, all the good prices are gone. (Not to say it can't be done, but it'd cost more.)

> I'm curious though. Who is "all"?
Well, all the open-source projects the organizers could find were invited; who'll turn up, we'll see.

> > For now, all I can speak of is MAT, which provides
...

> Well, you've provided one project. Good luck transforming that into a
> vendor-neutral API.
Thank you.

> I strongly believe that if you want to actually make some headway in
> getting industrial automation in Linux, you're going to have do more
> than write some code and put it on a website. How much outreach have
> you done to companies creating industrial hardware that runs Linux?
Some, but not nearly enough; we've been concentrating on getting the code working first... And, of course, our target audience is the integrators and end users as well as hardware vendors.

> > If you ask again in about a month, we should all have a much better
> > idea of where Linux IA is going...
> Tell me who is at this meeting and why I should pay attention.

Well, if we manage to merge half a dozen small projects into one big project, it'll have a much better chance of success, and therefore a much better chance of becoming a significant force in industrial automation.

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

Michael Griffin

On April 24, 2003 12:43, Joe Jansen wrote: <clip>
> As I tried to point out however, an open protocol is the only one that
> Linux can get. Are _you_ going to pony up the licensing fee for DH+?

As far as I am aware, if you buy a Siemens Profibus card, you can get drivers for Suse, Redhat, and Siemens Industrial Linux. I suppose that answers how to talk between machine devices - use Profibus. Plenty of people here will tell you it's a good choice anyway. As for how to talk between automation and IT systems, that field seems to be open. The debate seems to centre around whether it should be based on an industrial protocol like Modbus/TCP, or an IT protocol like XML.

> Are _you_ going to pony up the licensing fee for DH+? What
> about when you have to pay a per-distribution royalty to AB, but all your
> end users are demanding GPL code that they can extend and enhance, and
> _freely redistribute_? Buying into a closed protocol is simply not an
> option, leaving open as the only choice.
<clip>

I don't want open protocols because I want to extend and enhance communications drivers. I want open protocols because I want to eliminate market barriers for specialist companies to write drivers that I can buy. I want a small handful of protocols to emerge as the dominant ones without having them owned by someone who uses them as a club to beat their customers with.

> As you point out though, if a good, open protocol comes along, it may just
> as well be implemented on Windows, and capitalized on by whoever does it.
<clip>

The point of open protocols isn't Linux, or open source software or getting free stuff. All of these are of course nice things, but they are not the main reason. The reason why open communications are good is because it improves the probability that you will be able to get two things to talk to each other without a bunch of computers and magic boxes in between (if you can do it at all).

If all the companies that want to sell me stuff can swallow their pride and all support a common set of protocols my life becomes easier and my projects become practical.

>> You are confusing the "automation market" with PLC programming software.
> True, but the same can be said for SCADA software, HMI systems, etc. The
> majority of development is done on Windows workstations. That is a simple
> fact of life. Databasing is done using whatever the IT dept. has
> installed already (Oracle, SQL Server, etc.)
>
> What systems are you refering to, that have less of a windows dominant
> market? I cannot think of any.

Now for a slight digression. You are thinking about "automation software" as being PLC programming software or SCADA development software. However, this ignores the software running the machinery. Consider a typical custom computerised test system. The value of the software in a single such system will exceed the combined value of all the PLC (and similar) programming software in a typical factory.

When viewed in this context, it can be seen that PLC (or SCADA, etc.) programming software is marginal. If you want to promote Linux, open source, etc., etc., then don't worry about coming up with a substitute for Step-7 or RSlogix. Come up with the development tools and software components that specialist integrators would use to create custom applications. This (integrators) is the same type of market which Linux and open source was sucessful with in the IT world. Take a lesson from that.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
C
Hi Roger

> From: Roger Irwin
> To: [email protected]
> Subject: Re: COMM: OPENC: Open communications in the doldrums
>
> Curt Wuollet wrote:
> ....
>
>>to be well understood by mere mortals. But more complete than Modbus/TCP yet sharing it's attributes of piggybacking on the most successful protocol suite ever built.
>
>
> So far common sense.
>
>
>>It needs to look like the other 99% of the enterprises network traffic so it's not "special" and can be managed with the same tools. And it has to be absolutely, positively, vendor neutral and free of submarine patents and any other discouraging commercialisms.
>
>
> Well I would agree with submarine patents but vendor neutral no. There is no reason why a vendor or consortium of vendors cannot propose a protocol, as long as it is published and achieves the goal of extending usage in general rather than trying to promote a particular vendors approach. I could cite many examples, one of which would be the extended POP3 protocol which many of you will have used to retrieve this message.

In a more rational world, I might yield the point. In other markets ,perhaps. But in this world where vendors have a track record of developing extensive, redundent, offerings rather than cooperate even within standards bodies, we have to remove their incentive for doing this. Since the rationale for so much redundency seems to be competitive positioning, I fear the adoption of a competitors scheme would be far less likely than something that is vendor neutral and beyond manipulation. If this wasn't the case, we wouldn't have seen the medusa rear her ugly heads. It took large amounts of time and effort for these folks committed to coming up with a standard, to determine that they simply couldn't set aside competition and let someone else win. To agree on a neutral standard would be a face saving way to save one hell of a lot of money and actually make progress rather than beating a team of dead horses that stand little chance of reaching the winner's circle.

>>Obviously, it needs to come from the user community, not the vendor community.
>
>
>>And it needs to be built from scratch. And the only possible way for it to meet these goals and avoid balkanization or subversion is for it to be GPL OSS and thus accessable to all equally and poison to those who would enhance, extend, and destroy it for competitive purposes.
>
>
> Now we are right of the rails here Curt! To start with you are clearly referring to a software implementation of a protocol. The protocol itself gets RFC'd or ISO ratified or just plain PUBLISHED without any non-disclosures etc. As the single vendor modicon did with thier modbus.
>
> There is no reason why vendors cannot propose protocols,

No, there isn't any reason that vendors can't propose whatever their heart desires. There seem to be very strong, in fact, insurmountable reasons why they won't be acceptable to other vendors. Or at least historically, haven't been. And I, as a party with no particular axe to grind, can't generate much enthusiasm either, because I know there's always a hook in there someplace. I applaud Modicon's effort with Modbus, but I still couldn't get clear, unambiguous permission to use it the way I need to. I got in touch with their lawyers instead. That's exactly what's wrong with commercial IP.

it is up to the buyers to decide to spend money on proposals that offer the most openness and interoperability. Of course we COULD then implement the protocol ourselves but we all know that if a good and proven implementation is available at a decent price then it is not worth doing.

> I think the IETF is the perfect example of this. Both users and vendors have contributed to the common cause, and most people actually use commercially implemented software to wrap the basic goods. Vendors implement and enhance RFC's in order to enlarge the market. True, they open the market to thier competitors, but being involved at the standards level means they can get a (well earned) competitive edge.
>
> IMHO, as a user I should be bullying vendors (by means of threads like this) into developing standards the way **we** want them.


We quite agree on that point, indeed that may be the only way it shall come to pass. I just wish more folks would join in. A free and truly Open alternative would accelerate this change of heart.

Regards

cww
 
Also, from one who has direct experience in communications protocol development --

I can think of NO communications protocol actually in use that was developed by an end user or even by a university research lab. Vendor participation has been necessary. Let's look:

Ethernet - Developed by Bob Metcalf and contributed to IEEE 802.3 by his company, 3Com and its partners DEC and Intel.

IEEE 802.5 Token Ring. Developed by IBM and contributed royalty-free to 802

IEEE 802.4 Token Bus. Developed by the 802.4 committee, most of whom were representatives from suppliers. The protocol was substantially the work of Tom Phinney, now of Honeywell, then a principle of Concord Communications.

IEEE 802 during these years was chaired by Maris Graube, then from Tektronix now at Relcom.

Modbus (all forms) - Developed by Modicon.

Foundation Fieldbus - based on ISA S50.01 and Type 1 of IEC 61158. The physical layer was led by Martin Zielinski of Emerson. The data link protocol produced by committee with the major portion by Tom Phinney, then and still at Honeywell. The Application Layer protocol was developed by Udo Dobrech, Siemens; Lee Neitzel, Emerson; Yasuo Kumeda, Yamatake; and many others.

Foundation Fieldbus HSE and Type 5 of IEC 61158 - Developed by an international vendor supplied team meeting at and managed by Foxboro and led by Lee Neitzel of Emerson.

DeviceNet, ControlNet, and EtherNet/IP - Developed by teams at Allen-Bradley.

ProfiBus - Developed by a German National Standards committee with major contributions from Siemens and Klockner-Muller. Profibus-PA had major contributions by Endress+Hauser.

WorldFIP - Developed by an industry/university consortium, but commercialized and sponsored by Telemechanique, now part of Schneider, and GEC ALSTHOM, now ALSTOM.

CAN - Developed by Robert Bosch GmbH and contributed to the ISO 11898 standard.

Interbus - Developed by Phoenix Contact.

Where would we be without suppliers creating network protocols for their own vested needs? Nowhere! Even the OPEN support groups created by suppliers has been for their own vested interest: it is necessary to open these protocols via a non-profit foundation or via standards to get them to be used by others. Is it difficult to get suppliers to cooperate - YES, but they eventually yield to the best interests of their customers.

As you can see from my list, eventually network protocols too fall victim to the process of natural selection. Some win and some lose. This is evolution at its finest.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================
 
HTTP (web) - CERN

NCP, TCP/IP (Internet) - ARPA

SMTP (email), FTP (file transfer), UUCP (early email, usenet news), gopher (predecessor of the web), DNS (Internet domain names), all sorts
of other Internet protocols - ARPA and/or various universities taking part in the Arpanet and/or others similar

Your list is strongly biased toward automation protocols; but then the complaint was that automation protocols are proprietary, so that fits. There's no technical reason why an automation protocol couldn't be as open as DNS or TCP/IP - but then vendors would actually have to compete. The cynic suspects they don't want that.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
Having gone through the message from the weekend, I am going to attempt to consolidate several replies into one:

I wrote earlier:

>>>>>
Nonetheless, the critical mass is not there to
justify commercial ventures into Linux, and frankly, the cost of staying with Windows is lower than the cost/risk of moving to Linux. At the end of it all, we need to convince the vendors that Windows hurts more than Linux. Once we can make that argument, the floodgates should open.

<<<<<

Ricky H replied:

>>>>>
You might have noticed that Control.com is powered by Zope. Zope is OSS, written in Python, which is OSS and uses many other OSS libraries and code I'm sure (medusa for one i believe). Outside of IA there is a very big world, close your eyes if you want, its still there. Theres a lot of OSS you don't see, that just works, for business and individuals.
<<<<<

I think this hits right at the heart of the matter. In these instances, it has been proven that Windows hurts more than Linux, and things like webservers, game servers, etc all benefit more from the increased security, stability, and scalability than the pain that was inflicted in
initially porting them from windows, or the expense of writing it natively for Linux in the first place. These markets had to have a pain factor high enough to initially move from Windows to Linux, and once they broke that threshold, it was much easier to continue writing for Linux, since that initial barrier had been overcome.

Michael G wrote:

>>>>>
As far as I am aware, if you buy a Siemens Profibus card, you can get drivers for Suse, Redhat, and Siemens Industrial Linux. I suppose that answers how to talk between machine devices - use Profibus. Plenty of people here will tell you it's a good choice anyway. As for how to talk
between automation and IT systems, that field seems to be open. The debate seems to centre around whether it should be based on an industrial protocol like Modbus/TCP, or an IT protocol like XML.
<<<<<

I agree somewhat with this. Buying hardware cards that have the protocol embedded certainly solves this problem, including MAT supporting
DeviceNet, etc. What about protocols that run on ethernet, within a TCP/IP packet? (Ethernet/IP, for example). There is very little chance that someone will build a card that embeds the protocol and license, since it is plain old TCP/IP.

Now, we could just say that we let Ethernet/IP die on the vine, so to speak. However, Modbus/TCP is not going to solve all of our problems, and unless someone comes up with a truly open protocol, that is supported by others, we are back in the same situation. The protocol support isn't going to be free. It is a matter of where you pay the license. If you pay it when you buy a communication card, then OSS drivers are no problem.
If it uses a standard RS-232 or Ethernet port, where there is no comm card purchase, then OSS drivers become very difficult. And OSS is a big
motivator to the Linux side of the argument for IA.

Remember, there needs to be more pain in staying with Windows than moving to Linux. If the pain is the same, then no transition will occur. I am
becoming more convinced that any push to move to Linux apps has to start with this basis. AutomationX offers Windows and *nix versions of there software (IIRC). Perhaps Paul J. can offer us some insight as to what makes customers choose one flavor over the other. Paul?

Jiri wrote:
>>>>>
Sure there are middlemen - they're called integrators. The only difference will be that instead of buying software from the Nokia-equivalent, they'll d/l it off the net.

<snip>

The only people worse off for it will be the Nokia-equivalent, if they don't manage to ride it somehow, but relatively few people work for them
anyway (perhaps 5%).
<<<<<

The problem with this argument, of course, is that the Nokia-equivalent are the exact group of people that need to produce the software and
hardware to make Linux successful in IA. The fact that they are the ones with the biggest chance of 'losing' is exactly why they don't enter this market space; the point I have been trying to make all along.

This is getting long again, so I will wrap it up. Again, let me mention that I don't want to be painted into a "windows groupie" image, but I am trying to offer my opinions and ideas as to why the major vendors aren't pushing into the Linux market space. Hopefully by identifying some reasons and problems, we can work on overcoming them and get a better Linux/Windows comfort ratio....

--Joe Jansen
 
Dear Jiri,

You failed to answer very simple questions here.

> Alex Pavloff:
> > I'm curious though. Who is "all"?
> Well, all the open-source projects the organizers could find were invited; who'll turn up, we'll see.
>

Who was invited? If this is open source why are those you invited a secret. If the intent is to build confidence in this initiative then I would suggest you don't start by keeping the players in the closet. If there are real players to be had here then they should be showcased.

> Alex Pavloff:
> > Well, you've provided one project. Good luck transforming that into a
> > vendor-neutral API.
> Thank you.

Alex is right here again. This is not about providing ONE project. This is about providing a framework of tools and products that can be used to build automation applications. If your intent is that going forward every automation application will require that everyone involved be a C/C++ programmer then I think you might want to call it a day and get a job doing the "one offs" you are targeting.

And another important thing to note here and perhaps you continue to miss it. If you want this to be successful you must insure that the resulting products and direction CREATE momentum. Now what do I mean by that?

Part of the reason the automation market is what it is is that each product allows another to build upon itself. PLC markers create PLC. PLCs need I/O. PLCs and I/O need user interfaces. User interface need displays. And everything is glue together with a billion bits and pieces, wires, cables, connectors, relays, switches, etc...

All I'm saying is that a successful product is never a market onto itself. You must insure that there is a direction, a plan that makes all the segments of automation a player in the game. Yes some call it spread the wealth. If you intend to make a product that is all things to all people then you better be prepared to make connectors. Otherwise why should the multitudes of vendors really care? Yup it all comes down to one thing and I think Eddie Murphy put it best, "We all want to buy our kids GI Joe with the Kung Fu grip", and we can't do that unless we make real money.

Guess who?
 
Anonymous:
> You failed to answer very simple questions here.

> > Alex Pavloff:
> > > I'm curious though. Who is "all"?

Jiri:
> > Well, all the open-source projects the organizers could find were
> > invited; who'll turn up, we'll see.

> Who was invited?

Yes, I did fail to answer this one, because I didn't have the list handy
at the time. Here it is:

Open Robot Control Software
http://www.orocos.org/

Real-time Experiment Software for Linux
http://www.rtlab.org/

A Framework for Distributed Automation and Control
http://seg.clab.ee.upatras.gr/corfu/

Open Robot Controller Computer Aided Design
http://www.inrialpes.fr/iramr/Orccad/

Enhanced Machine Controller
http://sourceforge.net/projects/emc/

Real Time Controls Laboratory
http://sourceforge.net/projects/rtic-lab/

Dynamic Systems Library
http://sourceforge.net/projects/dslib/

Modular Architecutre Controller
http://sourceforge.net/projects/mca2/

Open Controller
http://sourceforge.net/projects/opencontrollerr

ClassicLadder
http://sourceforge.net/projects/classicladder

matPLC
https://sourceforge.net/projects/mat/

CANfestival
http://sourceforge.net/projects/canfestival/

> > Alex Pavloff:
> > > Well, you've provided one project. Good luck transforming that
> > > into a vendor-neutral API.
> > Thank you.

> Alex is right here again. This is not about providing ONE project.
> This is about providing a framework of tools and products that can be
> used to build automation applications.

Yes. We'll be in a better position to answer that in a couple of weeks, after the workshop, but that's exactly what we're aiming to provide.

> If your intent is that going forward every automation application will
> require that everyone involved be a C/C++ programmer then I think you
> might want to call it a day and get a job doing the "one offs" you are
> targeting.

Even just MAT itself can already be programmed in steplader mnemonics or python scripts. Indeed, stepladder mnemonics have been part of MAT for
years now (since mid-2000). No C or C++ required.

http://mat.sourceforge.net/manual/logic/il.html
http://mat.sourceforge.net/manual/lang/python.html

> If you intend to make a product that is all things to all people then
> you better be prepared to make connectors.

Yes, we're prepared to make connectors. So far, it's only ASi, CANopen, ControlNet, DeviceNet, Interbus, Modbus, ModBus Plus, PROFIBUS and
Sercos on the industrial side, but we're hoping to widen that.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
Well, Duh! Of course my list was biased to automation protocols. Look at this list server - Automation List!

On the negative side, let's look at the user-led protocol efforts. General Motors heavy-handed their suppliers to support MAP (Manufacturing Automation Protocol). Schneider (then Gould/Modicon) spent millions, likewise Allen-Bradley and GE-Fanuc never to see any real return on their investment. The only good thing to come of MAP was MMS, and in turn FMS (Profibus) and
the Application Layer of Foundation Fieldbus. MAP was responsible for IEEE 802.4 Token Bus, on which Profibus was originally based. Thankfully,
Profibus-DP no longer uses the token passing built into its protocol except for redundancy.

However, I do agree that US Government mega$$$ can have major effects. All of the Internet protocols were developed as part of US DoD investment into DARPA (Defense Advanced Research Projects Agency) to develop the ARPAnet which became the Internet.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================
 
R
> So, I thought this might make a good topic of discussion for this group (which has a notorious reputation for heated discussion on comms protocols). <

Hee He...At least I got that bit right:)
 
C
Hi Dick.

I agree in principle that vendors can contribute to an Open process. And this has worked in general computing. The magic in "Ethernet" is it's use with the Internet or TCP/IP family of protocols. It loses almost all of it's luster when used with proprietary protos. My problem is that the altruism that made for this, most successful example seems totally lacking amongst the most likely vendors to contribute in our arena. And it has been demonstrated repeatedly. So it's not really whether they _could_ play by the rules for a widely accepted standard, but if they ever _will_. Any entity should be able to contribute as long as they work for the greater good. But commercial concerns with any hint of a competitive agenda are the kiss of death to a
universal standard. And I, for one, gratefully recognize your efforts and experience and courage in trying to do the right thing. You are certainly most familiar with the problem.

Regards

cww
 
T
One of the defining characteristics of Automation protocol design (as opposed to the protocols Jiri listed) is the need to pass data very efficiently between devices at high speed with low system resources (e.g. microcontrollers with very limited RAM and ROM (say 1K and 32K respectively)). This requires focus and pragmatism during the design of the protocol, which committee based activity doesn't favour - it seems to me that the wider the potential application net is spread (which is an inevitable result of canvassing user support), the less effective (and successful) the protocols become, and the cost of implementation per device
increases.

It's interesting to note for example that although Profibus FMS was a full industry wide committee led development, it was not until a pragmatic decision was made to remove most of the layering and protocol niceties and allow direct access to the Data Link Layer, that Profibus DP was born and took off - FMS has effectively disappeared. Similarly, the bulk of DeviceNet
was designed at AB before being passed over to the ODVA for further development, and so retains a focused and coherent core.

It's an open question whether now we have cheap higher end hardware (e.g. PC) with more resources, devices will migrate to using higher level protocols. I suspect some will (just as many cheap printers have a direct Ethernet or USB connection) - it's also possible that PC type hardware will host clusters of what are today discrete devices to save on comms infrastructure costs. The potential problem with this is that it will tend to favour large one-stop shop vendors at the expense of niche experts, and so rather limit choice and excellence.

Interesting times.

Tim Linnell (Eurotherm)
 
P
>automationX offers Windows and *nix versions of there
>software (IIRC). Perhaps Paul J. can offer us some insight as to what
>makes customers choose one flavor over the other. Paul?

Sure - Our Substation automation system for XJ in China is Linux. This is more for technical reasons. The code we need for input of Chinese characters exists in Linux for X Windows, but not for NT. I was recently in China for a week, our developers about 3-4. The story is here:

www.mnrcan.com/newsdetail.phtml?idno=37

The Chinese have quite a task to develop China's power system and they need the most advanced products but at very aggressive prices. I believe Linux can certainly help that cause.

The other installs we have with Linux are more for let's try it, or prevention of employees hacking & gaming. There are more Windows installs than Linux.

Regards,

Paul Jager automationX
-----
Paul Jager automationX

( Complete thread: http://www.control.com/1026170993/index_html )
 
C

Chiron Consulting

Joe Jansen wrote:
> Please don't misunderstnd my motives. I would really prefer to be
> using a Linux system as well. In fact, I have a QNX box that is going
> into my next project which is there to eliminate a Windows 2000 system
> running WonderWare. I only need access from my PLC to a database, and
> the QNX box handles this nicely. Nonetheless, the critical mass is
> not there ...
> ... frankly, the cost of staying with Windows is lower than the
> cost/risk of moving to Linux. At the end of it all, we need to
> convince the vendors that Windows hurts more than Linux.

I don't think we need to convince anyone of anything. The American/capitalist economic worldview assumes that consumers are rational actors making decisions that they perceive to be in their own best interest. At whatever point they perceive that Windows really is more painful than Linux is risky, they will start opting for Linux. We don't have any control over Windows' painfulness (although I have a certain amount of faith in Microsoft to keep moving in that direction).
All we in the Linux community need to do is keep lowering the riskiness of the choice to use Linux.

In the IA marketplace, that means having a capable, robust application toolkit that they can opt for.

Note, by the way, that I'm not insisting that the automation applications be Open Source. I'd prefer it, but that's not a precondition for the success of Linux in automation. If Wonderware ran on Linux, and people could pay for the Wonderware licenses without having to pay for the O/S, do you think people would run it on Linux? I think so. Not all of them, but some of them. And if their experience were successful, then more and more of them.

The biggest problem is getting the software built for Linux before there's a paying mass market for it. Which is what the Open Source movement does. It builds software for free, without expectation of monetary ROI. That helps feed the limited market for Linux software, the success of which grows the market demand for more and better Linux software. At whatever point the market is large enough, and wants - and is willing to pay for - software and/or support that the volunteer
community can't/won't provide, capitalist market forces will push the vendors to fill that void. Not because we convinced them, but because they can make money doing it.

"Build it and they will come."

--
Greg Goodman
Chiron Consulting
 
Top