Open communications in the doldrums

R
> If that is true, then you can give up on any solution based on Modbus. I don't see the EDP/IT world moving to Modbus.

Well I can access a Modbus/TCP/IP server from an AS400, or an oracle based system on solaris, or just about anything with sockets, with little effort. More to the point it would be quite easy to implement e.g. a modbus/TCP server in POSIX code that would easily adapt to any platform.

As has been pointed out, OPC was intended as an API and the use of DCOM to make it an enterprise wide access medium, is as everbody here points out, not satisfactory. That is why OPC proposed XML DA, but as this has been 'real soon now' for 2 years we cannot just sit back forever and say someday it will be arrive and it will work.


> A more practical approach is the is to leverage the technologies that the IT world has already embraced.

So instead of inventing a new protocol we leverage an existing one (modbus) which is capable of being used at an enterprise level and was designed as a master/slave protocol to allow computers to interogate field devices.

....switch......

open source and 'free' seem to have crept into this argument, not from me. If one actually read the title of the thread it implies nothing of the sort. I regard OPC to be an open protocol, and I do not mind paying for OPC products (heck, I have spent several thousand Euro over the last few months on various installations). I said they are in the doldrums because they are not coming up with goods they promised (despite the money).

On a final note I do not like the fact that many people claim that it is not OPC's fault that users attempt to use their 'API' for enterprise wide networking. We are festooned with OPC literature **especially** from certain major players in the OPC field, which tout it as such, and have been doing so for years. They used to say DCOM, for the last 2 years they have been saying that DCOM is not suitable but their XML DA standard, allready in beta and about to be released is their enterprise protocol. Deadlines come, deadlines go.......

( Complete thread: http://www.control.com/1026171355/index_html )
 
Mark -

The folks at KEPWARE have gotten me out of more than 1 comm nightmare by providing with OPC drivers to less common plc's. The small software vendors, can provide good products when the needs of the customer aren't met by a Emerson/GE/Invensys/AB/Schneider solution.

Canary Labs trend software Sytech reporting software.

Note: They are all small independent software companies in Northeast of the USA.

Steven Landau SPEC Process Engineering & Construction. Burlington, MA www.spec-eng.com
 
C
Hi Mark

Actually screwing the customers were Alex's words, not mine. I was merely chafing at the solidarity to keep automation all Microsoft, forever. I am truly and respectfully interested in your opinion on the more basic questions: Should it be possible to persue automation as we know it without having Microsoft involved? And why is this seen as destructive rather than constructive, threatening, or whatever gets poeple so hot and bothered.

Regards

cww
 
Ralph,

Now you know why Schneider created Modbus/TCP intended to be used with a web browser (port 80). It passes through the entire corporate IT world as "just another TCP/IP message". More elegant protocols such as Foundation Fieldbus HSE and EtherNet/IP will also travel on an IT network, but can cause problems if IT chooses to close their port numbers on their firewalls.

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
============================================
 
Hi Curt,
Trust me in the grand scheme of things I don't believe that Microsoft has all the answers and specifically all the right ones. However, and this is a big however. Due to the strong market position and technologies like COM upon which OPC is based, companies like Kepware can exist.

So in simplest terms it will always be a chicken and egg issue reagarding market size and breadth.

I mention breadth from the standpoint that even if a single vendor produced and became a substantial provider of automation software within the Linux space that still would suit the market needs of a small company like Kepware. Kepware is a small company by many standards, only 14 strong, but it is 14 people that eat, sleep, and live communications drivers. I have been very fortunate to keep all of my employees even through the heady days of the Dots Coms. These people and their accumulated talents cost most of what Kepware earns. As such I can not afford to move into questionable markets where the return on that investment may be minimal. To be honest I invest in a lot of development efforts under the windows environment but at least there I can see the potential because I know the players.

I don't profess to know much about the Linux market but I haven't seen anything like OPC for the Linux world. What I mean by that is that I don't see a standard API that a large range of existing mainstream vendors support. An API that the average Joe using some BASIC like language can access(we have a lot of VB users). In short I don't see MASS.

In the windows world we already have to work very hard to pitch our products to the various vendors whom in many cases already have their own legacy drivers. Given the roughly one billion dollar size of the automation software market we can get our little piece of that pie. I don't see a market any where near that size in the Linux platform(for automation).

Everything said, in the final analysis, even if we had a Linux product I wouldn't want to make my source code available since I'm the one paying my engineers, testers, and support group, why should I make it easier for someone to copy all of our work? As any one that has written drivers knows, having the protocol doc is only half the story when it comes to writing a good driver.

I know this is a little long winded but you asked.
 
C

Chiron Consulting

> Now you know why Schneider created Modbus/TCP intended to be used with a web
> browser (port 80). It passes through the entire corporate IT world as "just
> another TCP/IP message".

Nothing I know about Modbus/TCP indicates that it's designed for use with a web browser. A Modbus/TCP message is "just another TCP/IP
message", but has nothing to do with the HTTP, the protocol supported by web servers and browsers.

> More elegant protocols such as Foundation Fieldbus
> HSE and EtherNet/IP will also travel on an IT network, but can cause
> problems if IT chooses to close their port numbers on their firewalls.

Ditto Modbus/TCP, which uses (by default) port 502, not port 80 (the default port for HTTP service).

Regards,

Greg Goodman
Chiron Consulting
 
A
Dick Caro wrote:
> Ralph,
>
> Now you know why Schneider created Modbus/TCP intended to be used with a
web
> browser (port 80). It passes through the entire corporate IT world as
"just
> another TCP/IP message".

I'm confused. Modbus/TCP is port 502, and doesn't use the "wrap in HTTP to punch through firewalls" trick.

Alex Pavloff - [email protected]
Eason Technology -- www.eason.com
 
R

Ralph Mackiewicz

I understand that using port 80 enables passage of protocols through firewalls without requiring IT to specifically allow it. This does eliminate a barrier. However, I don't think that this will
necessarily make Modbus/TCP acceptable to the broader IT community. IMHO, if the IA community desires to bridge the gap between the IT and IA world, then the IA community should adapt IT technology because the IT world will not likely adapt IA technology. If the IDA people abstract the modelling information so that it can be mapped to an IT oriented protocol like http-XML, SOAP-XML, TIBCO, MQ, or whatever, then the probability of acceptance by the IT staff is
increased because the cost for them to deploy it will decrease. Requiring the adaption of an IA protocol like Modbus/TCP by IT staff may unneccessarily create a barrier to acceptance of the useful IDA modelling work.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
R
> I understand that using port 80 enables passage of protocols through firewalls without requiring IT to specifically allow it. This does eliminate a barrier.

Not much of one for me, my major problem is working with IT systems within an Intranet.

>IMHO, if the IA community desires to bridge the gap between the IT and IA world, then the IA community should adapt IT technology because the IT world will not likely adapt IA technology.

Exactly!

>If the IDA people abstract the modelling information so that it can be mapped to an IT oriented protocol like http-XML, SOAP-XML, TIBCO, MQ, or whatever, then the probability of acceptance by the IT staff is increased because the cost for them to deploy it will decrease.

OK.

>Requiring the adaption of an IA protocol like Modbus/TCP by IT staff may unneccessarily create a barrier to acceptance of the useful IDA modelling work.

Hmmm... This is where it breaks down. Modbus/TCP is
much less of a problem than OPC/DCOM, basiclly because it is very easy to wrap into any environment. Certinaly the XML-DA looks promising and **could** be a great step forward. But it is still vaporware and we have no idea what real world performance will be like, or how good the implementation is.

But let's look at the issue another way round, suppose the IT world were to be offered a cross-platform application level interface such as IDA or something analogous to OPC DA (I am talking about the very top level here). What would be the simplest and most acceptable technology to use to actually implement the interfaces? What is actually here and now and deployable? We have cited Modbus/TCP as an easy to implement and well proven technology (also the limitations are well known!), and we have cited MMS as a valid but more complex solution that is well proven in utility industry WAN's but not in IA LAN's.

We have also toched on Foundation fieldbus/FMS, as solutions we never gained popularity in IA LAN's despite heavyweight backing.

Any other contenders?
 
The largest amount of inertia comes from the fact that in general, people expect to pay for software that runs on Windows. On the other hand, people expect "free-as-in-beer" distribution for anything on Linux.

As long as this is the case, developers are afraid to move to the Linux platform. Either they give up any hope of being a profitable company, or they get crucified when they actually try to enforce a paid-for licensing program. As a case in point, one of the complaints about Linux desktop is a lack of games. Loki Software entered the market to fill that very vocal gap. Loki is now bankrupt because very few people wanted to pay for the Linux version of the games, even though they spent $40 or more for the same game on windows.

Obviously I am generalizing, and this does not include everyone, however, you have to admit that the majority of Linux users typically don't pay for their software either through piracy, or simply refusing to use software that isn't GPL'ed. The GPL is a kiss of death for profitable software businesses. How many of the 'give away the software and sell the services' companies are still alive? Red Hat is changing business models, IBM and HP claim profits, but then again, they are using Linux on their own hardware, which I think is not a factor that can be ignored.

The service oriented business model is a failure. Nobody wants to pay for tech support. I have always thought that selling services (read support) for free software just encourages developers to release software that is difficult to use. Show me how I am wrong, please. I really would prefer to see how selling services encourages easy to use software.

Until Linux is pervasive enough that the people willing to pay for software are using it, there will be a large vacuum for commercial apps. And without commercial apps, it will be extremely difficult to achieve critical mass around a free-as-in-beer protocol. Without a commercial interest, there is no way to buy your way into an existing protocol and implement it on Linux (unless you find an angel investor, but that is a whole different story).

Bottom line: AB, Omron, Siemens, etc. all exist to make a profit. If they give away their R&D for free, then they have a much more difficult time doing that. Until the majority of Linux users are willing to pay real money (not $5 distribution fees) for real software developed by professional, commercial programmers, this gap will continue.

In direct answer to your question, I absolutely think it should be possible to persue automation without MS. Unfortunatly, windows holds a vast majority of the desktop, which is where you develop your IA applications, and until there are enough paying, Linux desktops to cost justify writing a port for RSLogix, CxProgrammer, etc. the automation vendors who make the development software and tools have no motivation to try to make a non-MS automation market.

Just my rambling thoughts....

--Joe Jansen
 
G

George \(Jim\) Hebbard

In the grand scheme of things it may not make much difference (at least to IA) whether Microsoft "wins" or Linux or QNX or whatever. However, as a 60+ year old Registered Professional Chemical (Process) Engineer, I have
been burned deeply by this whole proprietary/open argument in the past.

My "Open" friends tell me that COM (common object model) was an early and weak attempt that Microsoft picked up to try to improve inter-process communication. It was somewhat strengthened my modification to DCOM when Bill Gates's people realized that networking (and the Internet) was where the money is. They assure me that COM/DCOM isn't really an ORB (object
request broker) protocol interface like CORBA (common object request broker architecture) which they prefer. So even DCOM (distributed common object model) is, they say, inadequate for cross-platform work. I don't know.

The argument has ascended to a higher plain with Micro$oft types pushing XML-RPC and the Open types pushing SOAP, which they tell me is even strong enough to clean up the defects in COM/DCOM. A good reference on the discussion starts here:

http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto-corba.html

When I was (severely) burned by the ONSPEC Concurrent DOS/PC-DOS arguments over operating system GUI (pixel graphics versus raster graphics) I learned quickly how negative a big fish is a small pond can be for the denizens of
the small pond. IBM reportedly threatened to drop ONSPEC as a VAR if they upgraded the successful Concurrent DOS version before they launched the IBM compatible version.

Pixel graphics are arguably more satisfactory for IA because the excellent graphics available at (relatively) high speed at the end of an RS-232c signal provided for very inexpensive color graphic remote displays located well away from the CPU. In any case, I had recommended ONSPEC and IBM effectively made me wrong. Microsoft has more clout, but has also learned that defects in design can be overcome by excellent marketing.

I am more concerned with Microsoft's tendency to consider the results of their marketing prowess as THE STANDARD and totally proprietary, making
competition a farce.

=>Jim<=
 
L
>As long as this is the case, developers are afraid to move to the Linux
>platform. Either they give up any hope of being a profitable company,
>or they get crucified when they actually try to enforce a paid-for
>licensing

I think it's actually simpler than this, and has nothing to do with fear - no one is prevented from making money selling into Linux systems, and many people do. Vendors (and I work for one) know that targetting Windows for support tools will cover the entire automation market (with the exception maybe of Curt) in a single hit. The existence of technologies like OPC help a good deal, and development tools and underlying features are good and stable; fundamentally it's an easier deal in terms of the development and
ongoing support. On the other hand Linux developments for shrink wrapped software are much more difficult because there are many different
distributions, desktop environments, and even hardware platforms. Some poor sod in customer support has to keep up with all of these!

Regards

Tim Linnell
 
M

Michael Griffin

On April 23, 2003 11:10, Joe Jansen wrote: <clip>
> The largest amount of inertia comes from the fact that in general, people
> expect to pay for software that runs on Windows. On the other hand,
> people expect "free-as-in-beer" distribution for anything on Linux.
<clip>

I would suggest this is only true for a certain segment of the market. I would also point out that a very large percentage of people don't expect to pay for Windows software either (and don't). In many parts of the world, most Windows software (including WIndows itself) is "free" for all practical purposes.

> As a case in point, one of the complaints about Linux desktop is
> a lack of games. Loki Software entered the market to fill that very vocal
> gap. Loki is now bankrupt because very few people wanted to pay for the
> Linux version of the games, even though they spent $40 or more for the
> same game on windows.
<clip>

Games are a very difficult consumer market. Plenty of companies are going broke selling games for Windows and proprietary game consoles as well. In addition, Linux is currently mainly used for professional applications, not for consumer entertainment. I seriously doubt there is much of a games market for Linux at this time. In other words, your games example isn't very relevant.

> The service oriented business model is a failure. Nobody wants to pay for
> tech support. I have always thought that selling services (read support)
> for free software just encourages developers to release software that is
> difficult to use. Show me how I am wrong, please. I really would prefer
> to see how selling services encourages easy to use software.

The problem with the above is that you are looking at the computer on your desk, and assuming the entire "computer market" is the same thing writ large. The traditional business desktop is a backwater in the industry. There are only two computing areas where significant new development is taking place. One is consumer entertainment (e.g. games, music, etc.), and the other is servers. In both areas "services" are considered to be the future of the industry, and software as simply a channel for delivering these services.

If you want a good analogy, just consider the cell phone market. Few people buy cell phones, rather they buy a cell phone service and the cell phone is "free" (or at least below cost). That doesn't mean that companies like Nokia can't make money. It just means that you are looking at the market from the wrong end if you think of it only in terms of Nokia selling cell phones directly to consumers.

> Until Linux is pervasive enough that the people willing to pay for
> software are using it, there will be a large vacuum for commercial apps.
> And without commercial apps, it will be extremely difficult to achieve
> critical mass around a free-as-in-beer protocol. Without a commercial
> interest, there is no way to buy your way into an existing protocol and
> implement it on Linux (unless you find an angel investor, but that is a
> whole different story).

I don't see "open protocol" and Linux as being synonymous. Any advantages of a truly open protocol for Linux would be equally great for Windows. The advantages of a truly open protocol (or set of protocols) would be that everyone can use it without restriction, and no one avoids it because they are afraid the licensing rules could be manipulated against them later. The open Internet has been good for Windows as well as good for Linux.

> Bottom line: AB, Omron, Siemens, etc. all exist to make a profit. If
> they give away their R&D for free, then they have a much more difficult
> time doing that. Until the majority of Linux users are willing to pay
> real money (not $5 distribution fees) for real software developed by
> professional, commercial programmers, this gap will continue.

IBM exists to make a profit, and I hear they are doing quite well indeed. They give away a good deal of R&D for free. They are giving away R&D that helps to grow the market for their services.

The results of R&D may be more profitable for you if they enable something you want done than they would be just collecting dust on a proprietary shelf. Not all ideas on the "proper" way to success should be jammed into the same pigeon hole just because this makes classification neater.

I don't know about AB or Omron, but Siemens has set up a division to do "IT Integration" - that is to integrate automation systems with a company's larger IT systems. Siemens sees a large market for this, and quite frankly so do I, provided the communications barriers can be overcome.

Siemens has Profibus and Ethernet drivers for Linux, and they even have their own Linux distribution (Siemens Industrial Linux Distribution). This shouldn't be surprising, since as someone else pointed out that if you are going to interface with IT systems, you have to talk their language.

> In direct answer to your question, I absolutely think it should be
> possible to persue automation without MS. Unfortunatly, windows holds a
> vast majority of the desktop, which is where you develop your IA
> applications, and until there are enough paying, Linux desktops to cost
> justify writing a port for RSLogix, CxProgrammer, etc. the automation
> vendors who make the development software and tools have no motivation to
> try to make a non-MS automation market.
<clip>

You are confusing the "automation market" with PLC programming software. The latter is merely a subset of the former. There are sound business reasons at the moment why PLC programming software would target only the largest desktop operating system. However, the engineering or maintenance office desktop isn't the entire automation market or even a very large percentage of it.

************************
Michael Griffin
London, Ont. Canada
************************
 
C
We need a middleweight contender, focused on the job. Not warmed over office automation technology tightly enmeshed in one vendors schema having been designed for the purpose of replacing interoperability, or the grandiose "do everything" specifications that are too complex
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. 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. It's easy to see how these goals can be met and equally easy to see why they won't. One need only look as far as the Medusa to
see this vital neccessity turned to stone. 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. This is the only way that I can see to build something attractive enough to become truly universal. The reasons for the problems are painfully obvious. Everyone + dog, wants to own or control the next big thing, by any means neccesary. That's why the only moderately successful examples are owned by a
non-competitive entity. We've abdicated that role to a dictator as that at least brings order. If we replace the dictator with a publically and
politically supportable democracy, we have the basis to finally go forward. I'm very interested in other ideas of how this could be accomplished in the automation environment that prevails.

Regards

cww
 
C
Hi Joe

Between your remarks and Mark's, both of which are uncharacteristically civil, which I much appreciate, we have a clear picture of why it can't happen. So are we doomed to fly blindly through endless upgrades and increasingly zany and irrelevent gyrations, with often conflicting
consequences, to accomplish factory automation? Do I take my football and go home? Are we confined to the set of solutions that most favor
the profitability of the vendors at the expense of progress and even sound engineering? I have committed my energies to change things for the better. Towards the elimination of problems and barriers that even the greatest of my
antagonists clearly recognize and acknowledge. I would consider any change in the things that we all mostly agree are bad for business a major accomplishment. The only cure I can see as having a track record of success in such circumstances is indeed a much larger role for Linux and software not controlled by any one entity. This puts me at odds with the (happy?) Microsoft users and I am flamed as thoroughly as I flame.

What I would like to discuss, is _any_ ideas on how to effect change. This could be a less contentious and more productive discussion. If my
ideas stink and offend, what are the competing ideas towards this goal? We all, perhaps grudgingly, agree that competitive deadlock is holding back progress and growth. And I think it's safe to say that no one's overtly proprietary, for profit, solution will solve the problem and gain universal acceptance among the aware.

Where do we go from here? How do we actually solve the problem?

Regards

cww
 
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

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.

For now, all I can speak of is MAT, which provides a common API to access various protocols (for now we have only Modbus ASCII/RTU/TCP and
one vendor's cards supporting ASi, CANopen, ControlNet, DeviceNet, Interbus, ModBus Plus, PROFIBUS and Sercos), a BASIC-like scripting
language (python), HMI builder, the beginnings of a stepladder editor, PID module, and so on.

If you ask again in about a month, we should all have a much better idea of where Linux IA is going...

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

I am very happy that we have been there to help you out. Thank you very much for the kind words and as always never hesitate to call us if you ever do have a problem. We always take the stance of "Hmm, maybe there is an issue lets take a look at it". We try not to let pride get in the way of answers. When we hire new engineers thats one of the first things I try to teach them. Pride, placed incorrectly, is the enemy.

Thanks again.
 
>>>>>
<snip>
> people
> expect to pay for software that runs on Windows. On the other hand,
> people expect "free-as-in-beer" distribution for anything on Linux.
<clip>

I would suggest this is only true for a certain segment of the market. I would also point out that a very large percentage of people don't expect to pay for Windows software either (and don't). In many parts of the world, most
Windows software (including WIndows itself) is "free" for all practical purposes.

<<<<<

True indeed. However, (making numbers up as I go here, but it should illustrate the point nonetheless) if platform A has 100 million users, and platform B has 100,000 users, and each one has a 50% pay to steal/get-for-free ratio, platform A is still the big choice. Also, many
Linux users simply won't use non-GPL software. This is not an issue for Windows users.

>>>>>

<snip>

Games are a very difficult consumer market. Plenty of companies are going broke selling games for Windows and proprietary game consoles as well. In addition, Linux is currently mainly used for professional applications, not for consumer entertainment. I seriously doubt there is much of a games market for Linux at this time. In other words, your games example isn't very relevant.

<<<<<

Yeah, you are probably right. I heard once that there are no good analogies. Probably true. My main point again was that, as a generalization, people are less willing to pay for Linux software than they are for Windows software.

>>>>>

> The service oriented business model is a failure. Nobody wants to pay
for
> tech support. I have always thought that selling services (read
support)
> for free software just encourages developers to release software that is
> difficult to use. Show me how I am wrong, please. I really would
prefer
> to see how selling services encourages easy to use software.

The problem with the above is that you are looking at the computer on your desk, and assuming the entire "computer market" is the same thing writ large. The traditional business desktop is a backwater in the industry. There are
only two computing areas where significant new development is taking place. One is consumer entertainment (e.g. games, music, etc.), and the other is servers. In both areas "services" are considered to be the future of the industry, and software as simply a channel for delivering these services.

If you want a good analogy, just consider the cell phone market. Few people buy cell phones, rather they buy a cell phone service and the cell phone is "free" (or at least below cost). That doesn't mean that companies like Nokia can't make money. It just means that you are looking at the market from the wrong end if you think of it only in terms of Nokia selling cell phones directly to consumers.

<<<<<

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.

In reply to your other points, my poor analogy was pointed at the game industry. You state here that the entertainment industry (games) is a
growth market. Still, the Linux gaming market is very weak. Most games out there are GPL'ed efforts that originate from Sourceforge. This
supports my earlier statement that a commercially successful Linux software company, including one targeting what you state is a growth area, games, cannot exist because of the free-as-in-beer demands of the GPL only market. True, you can try to release a commercial project with GPL, and I have heard argued that GPL does not prevent you from selling your product (MySQL, Sendmail, etc. all try this) but how do you control piracy and
re-distribution within the controls of GPL? I actually paid real money for my copy of Railroad Tycoon II from Loki, although they were already
bankrupt when I did, but some of their other releases not only had rampant piracy, but people would hack their code to make themselves invincible during tournament play.

I agree that the server market is a good growth segment. It is interesting to see how this is developing though. IBM and HP both use Linux to sell their hardware. No secret here. Linux is the loss leader (like the phone) that IBM gives away so that you buy their hardware which only they can support. This is no different than the 'old' IBM. Since IBM needs to have an OS for their hardware, why not use the one that they
can give away without paying licensing (free-as-in-beer), and anything that needs to be added, they can redirect their internal AIX people to
develop. No problem releasing this under GPL, since not many people have a use for an AS/400 operating system without the AS/400.

Red Hat, on the other hand, has no hardware to recoup their 'loss' for giving away the OS. How are they making money? Red Hat's subscription
based Enterprise Network seems very similar to Licensing 6.0, where you pay an annual fee in order to get up to date fixes. Furthermore, they
advertise that what you pay for are the enhancements Red Hat makes to the system, including Kernel Enhancements, clustering, etc. These are only available through their subscription service. (see
www.redhat.com/software/whichlinux.html and
www.redhat.com/software/subscriptions.html)

I am not saying that they are wrong for doing this. I am simply pointing out that the free-as-in-beer model wasn't working out so well for them, and they migrated to something better. The server room is a very different environment than that of IA, though. Server admins expect to pay for everything. IA people, like most end users, want it for free.

>>>>>

> Until Linux is pervasive enough that the people willing to pay for
> software are using it, there will be a large vacuum for commercial apps.
> And without commercial apps, it will be extremely difficult to achieve
> critical mass around a free-as-in-beer protocol. Without a commercial
> interest, there is no way to buy your way into an existing protocol and
> implement it on Linux (unless you find an angel investor, but that is a
> whole different story).

I don't see "open protocol" and Linux as being synonymous. Any advantages of a truly open protocol for Linux would be equally great for Windows. The advantages of a truly open protocol (or set of protocols) would be that everyone can use it without restriction, and no one avoids it because they are afraid the licensing rules could be manipulated against them later. The open Internet has been good for Windows as well as good for Linux.

<<<<<

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+? 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.

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.

>>>>>
IBM exists to make a profit, and I hear they are doing quite well indeed.
<<<<<

By getting paid to support the hardware that they sell by giving away a popular OS. Not because of any income derived Linux itself. IBM is not a
bunch of idiots. They know what to give away in order to maximize their profit in their core competencies. 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.

>>>>>

<snip>

You are confusing the "automation market" with PLC programming software. The latter is merely a subset of the former. There are sound business reasons at the moment why PLC programming software would target only the largest desktop
operating system. However, the engineering or maintenance office desktop isn't the entire automation market or even a very large percentage of it.
<<<<<

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.

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

>>>>>

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

--Joe Jansen
 
A
> From: Jiri Baum
>
> 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
>
> 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.

For some reason, I don't think I can get the approval and cash to fly off to Belgium in a couple weeks. :) I'm curious though. Who is "all"?

> For now, all I can speak of is MAT, which provides a common API to
> access various protocols (for now we have only Modbus ASCII/RTU/TCP and
> one vendor's cards supporting ASi, CANopen, ControlNet, DeviceNet,
> Interbus, ModBus Plus, PROFIBUS and Sercos), a BASIC-like scripting
> language (python), HMI builder, the beginnings of a stepladder editor,
> PID module, and so on.

Well, you've provided one project. Good luck transforming that into a vendor-neutral API. 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?

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

Alex Pavloff -- [email protected]
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-- www.eason.com/5Koverview.htm --
 
R
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.


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