Today is...
Saturday, November 18, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
Trends and how to grow the industry
I have seen a trend lately with Jim and Walt and others to discuss some "High Level" issues that the industry as a whole faces. In bits and pieces across discussions that sometimes go far abroad there are some recurring themes that are truly important. ...
By Curt Wuollet on 6 February, 2001 - 1:33 pm

Hi all I have seen a trend lately with Jim and Walt and others to discuss some "High Level" issues that the industry as a whole faces. In bits and pieces across discussions that sometimes go far abroad there are some recurring themes that are truly important. Lest they disappear in the noise, I thought I'd restate them succinctly. One of my functions is futurist and I am most interested in these trends and how they relate to what I am attempting to do. As I think it through the collective wisdom appears sound, we differ mostly in what to do about it. Since these are the very problems I seek to solve, I thought this should provide constructive discussion. Trend: The industry as a whole is flat or possibly even shrinking. Offered Causes: Market Saturation, we have done about all we can do with the present paradigm. Everything that can be profitably automated has been automated and further growth will require that we move to higher level integration. My take: True, to some extent. There are still vast opportunities at the low end, the "easy stuff". The trick here is in the "profitably" part and overcoming inertia. My contention is that with the costs involved, we have only been able to address the most compelling needs for automation. I have seen in many instances, companies start down the road and after a project or two are sufficiently bloodied to lose enthusiasm. There are also expectations that we can do things that seem simple and perfectly logical but with the present tools and methods are neither. The higher end opportunities are there but the prevailing attitudes towards closed systems and proprietary solutions is a very weak and in fact, paradoxical position to address these from. Bottom line summation: If I am a company that has invested in some automation seen the elephant so to speak and now seeks to take the next step and tie these islands of automation together and to my enterprise system., my prospects are bleak or worse. If I wanted to make sure that none of my diverse systems would work together or interoperate, I'd call the Automation vendors, they are expert at preventing systems integration. Unless all your automation is from a single vendor and all your IS systems run Microsoft, there isn't much hope. On the low end, the cost of providing solutions is the barrier. How to fix it: Integration and interoperability have to be design goals going forward. This will require acceptance of common standards. protocols, and Open Systems. If there were one universal communications method, the difficulty of integrating systems would decrease by several orders of magnitude. If it were truly open, the drivers would get written on the IS side even for legacy systems and oddballs. The only way that this can realistically be accomplished is if those means are absolutely independent and publicly owned. period. If it even appears that any one vendor or group of vendors can control it in any way, Game Over. If it's owned by a consortium. Game Over. We have already tried those two approaches many times with each one being a complete and utter failure. Public ownership is the only possible way to get full participation in this climate. This industry is also hobbled by the enormous cost of duplication. Not only are there 50 complete lines of incompatible products that accomplish the same tasks, there are at least 25 incompatible busses to do it on. This is not the way to grow an industry. This is not the way to lower costs. 98% of that R&D money was wasted in terms of providing solutions especially at the low end. If the PC industry were still working this way, it would be in the same shape. The ubiquitous, efficient, cheap, networking that makes this message possible is the direct result of standardization around the Internet Protocols. These, it can be argued, are not publicly owned. but they started out that way and at this point they cannot be manipulated to the advantage of any one commercial entity so the effect is the same. Growing sideways is obviously not working at providing explosive growth in this industry. To move forwards requires the same sort of changes that take place in any volume based industry. None of the 50 product lines is going to achieve the volume to lower costs and improve efficiency in delivery of services. Suppose all the cost and effort to maintain all these parallel solutions were concentrated on a few. How much more progress could be made? How much more efficient would support be?, programming? Suppose hardware was compatible. How much less would it cost? Suppose that every one used the same languages and algorithms and common modules were shared. How much less of a project would be programming and how many fewer bugs and problems would there be. How can this be accomplished in this hyper competitive industry? Perhaps it can't. Some days, I begin to think that way. But, if it can, it will be by providing a strictly independent, publicly owned alternative that can be readily expanded, changed, and adapted at will to cover the maximum number of situations. In this way it can achieve volumes where code reuse and commonality attack the problems facing the industry. I'm curious how some of you others see the situation and what exactly you are doing to fix it. Regards cww

By David McGilvray on 7 February, 2001 - 1:13 pm

Hi Curt, I'll bite. I agree with the stated trend and the various market symptoms. My prescription, however, is slightly different. At this point I'll declare my affiliation with automationX since my forecast, while not necessarily requiring automationX specifically, certainly fits the paradigm. I believe that the future of automation will look remarkably like the internet. The internet provides an instructive example of distributed computing. The internet model includes ubiquitous independent thin clients, standardized network protocol and robust servers effectively managing multi-million dollar businesses. The robust servers, in the industrial landscape, instead of interacting with various databases will connect directly to commodity I/O modules and, in the future, commodity final elements (sensors, actuators, etc.). The server software provides the control system functionality (control, data archiving & trending, visualization, alarming, simulation, on line help, etc. as required). As well, the server software will provide the glue to seamlessly connect downloaded software (algorithms) in distributed i/o modules, etc. The advantages are pretty clear. First, industrial automation practitioners finally get a taste of the power of the network. Rather than dedicated operator stations (even if PCs), users including engineers, maintenance personnel and operators will interact with the system using common browser like software than can be easily loaded an any standard machine that doesn't necessarily need to be dedicated to the task. Maintenance and engineering types especially increase efficiency exponentially, by accessing the various systems under their responsibility from wherever they are using existing hardware. While not necessarily using the public internet, users can instantly connect to the process regardless of where they are in the plant, city, or even country, provided a network connection is available. Secondly, the server concept is crucial, not withstanding the inherent reluctance from many on this list and the industry. Clearly a variety of technical solutions are available and actively used by IT people for internet and other mission critical applications, details of which I would be happy to discuss with those interested, to provide the reliability of any DCS and PLC offering. The key, however, is the decoupling of software from the proprietary hardware and rehosting on commodity hardware to ensure standardized protocols and open hardware. The field side will be populated with i/o modules and final process elements that are mixed and matched according to capabilities and not proprietary networks. Today a variety of open fieldbus networks are available that achieve just this, including Profibus and others. Decoupling (ie the end of DCS and PLC as we know them today) can be expected to further the acceptance of open bus networks and increase the proliferation, lower the cost and increase features of the available networks. Eventually, I would expect an office Ethernet (perhaps even Ethernet) will rapidly emerge. The end result is that competition and interoperability exists at all levels for both hardware and software, including the client, server, and field, with barriers effectively removed at all levels. Each component competes on its own merit and can be replaced at any time like switching brands of pencils. Costs plummet and products with favoured features are rewarded. The model is elegant, simple and proven. The only barrier to acceptance seems to be the vested interests of the 50 odd existing vendors and the sheep like behaviour of users and integrators who have blindly accepted their dated message. Best Regards, dwm

By Curt Wuollet on 8 February, 2001 - 11:57 am

Hi Dave The only place we really differ is on private ownership of the IP, protocols, etc. You guys believe that you can do it with proprietary software and live with the existing mess. I have observed that if you are a competitor, you can not attract any cooperation or bring people together. I like your product but interoperability is still an issue. We seek to find a way to form a cooperative effort that is neutral and impartial so that companies can contribute to the common good without aiding a competitor. I'm cautiously optimistic that if there ever will be cooperation and consensus, our model will be the most attractive. Replacing proprietary with less proprietary isn't as good a solution but it's a step in the right direction. Regards cww

By David McGilvray on 9 February, 2001 - 4:37 pm

Hi Curt, I think you raised two important issues, at least one of which has been touched be a previous poster. 1. Proprietary vs GNU or public products. Without a doubt, GNU products are very attractive - certainly due to the cost and frequently the result of attractive features. The success of Linux, both from a participation as well as an adoption perspective, is testament to this approach. Indeed, we think Linux is a great product that we fully support. This approach, however, is generally restricted to software products where product cost is predominantly labour that can be donated on an individual basis. The widespread development of products under this model, particularly where the end users are commercial, for profit enterprises, is questionable. On the other hand, there is a very definite place for commercial products, as the marketplace determines. For both software and hardware, I think it is quite valid for firms to develop and market their products. Of course, the resulting products will not be free, as labour and material inputs, and hopefully profits, must be addressed by a sticker price. I think the development of an operating system for the masses by the masses is a reasonable scenario. The development of, for example, an ERP product, on the other hand, which is used exclusively by corporations (and predominantly large multi-nationals), using donated labour has dubious prospects. The Linux PLC project not withstanding, a soft (server based per my stated model) DCS, like automationX, I think falls into the latter category. Regardless of whether a GNU free or commercial product (or a mix) prevails, however, it seems we both agree the server based model outlined previously will prevail. 2. Open & Proprietary. I get the distinct impression that open, from your perspective, necessarily requires the GNU or equivalent model (ie donated labour where the product including source code is available for free). I don't believe this. AutomationX, for example, is a proprietary product that we license to users. At the same time, automationX is, in my opinion, totally open. We comply with a number of open protocols - we use TCP/IP for client server communication and Profibus predominantly on the field side. Although over the years we have developed a number of interfaces, as a necessary requirement in today's heterogeneous industrial environment, we certainly do not go out of our way to jump on the latest bus bandwagon and generally have many times fewer interfaces than offered by typical HMI/SCADA products (which we really are not). Interestingly, and a testament to our openness, the tools we use to develop interfaces are fully available to end users and/or integrators. Finally, I would have to vehemently disagree with your assertion that we believe in private ownership of IP, protocols, etc. On the contrary, we embrace open industry standards, especially IP, protocols, etc. In fact, automationX, if a competitive product (GNU or proprietary) where available, very much complies with the model I proposed where all individual components (software and hardware) including the client, server, & field components should be individually interchangeable. Best Regards, dwm

By Curt Wuollet on 12 February, 2001 - 1:09 pm

Hi Dave > I think you raised two important issues, at least one of which has been > touched be a previous poster. > > 1. Proprietary vs GNU or public products. Without a doubt, GNU products are > very attractive - certainly due to the cost and frequently the result of > attractive features. The success of Linux, both from a participation as > well as an adoption perspective, is testament to this approach. Indeed, we > think Linux is a great product that we fully support. This approach, > however, is generally restricted to software products where product cost is > predominantly labour that can be donated on an individual basis. The > widespread development of products under this model, particularly where the > end users are commercial, for profit enterprises, is questionable. > > On the other hand, there is a very definite place for commercial products, > as the marketplace determines. For both software and hardware, I think it > is quite valid for firms to develop and market their products. Of course, > the resulting products will not be free, as labour and material inputs, and > hopefully profits, must be addressed by a sticker price. > > I think the development of an operating system for the masses by the masses > is a reasonable scenario. The development of, for example, an ERP product, > on the other hand, which is used exclusively by corporations (and > predominantly large multi-nationals), using donated labour has dubious > prospects. The Linux PLC project not withstanding, a soft (server based per > my stated model) DCS, like automationX, I think falls into the latter > category. Regardless of whether a GNU free or commercial product (or a mix) > prevails, however, it seems we both agree the server based model outlined > previously will prevail. We disagree on the viability of the public development model. Spreading the cost of development to the users provides potentially much greater resources and certainly more objectivity than any single company can afford. We can be solution oriented rather than profit oriented. And we can be an ally to everyone and a threat to no one. As you know, I like your product and have provided only constructive criticism on the problems we saw when we considered distributing it. I am still interested, but the moment may have passed for the people who pay me. I am a pragmatist and a capitalist. Although the "Red Baiters" have already suggested that I am a communist and I've heard an anarchist. I agree with Joe that if there a way to address these needs in a commercial model and the problems would simply go away, I could live with that. I am closer to ESR than to RMS. That is, more OSS than GNU. I am not convinced that everything must be free, (as in free beer) merely that the parts needed to integrate systems and allow interoperability be really truly open or at least to the extent of say Modbus/TCP where I can implement them on an open platform to get the job done. With regard to LPLC vs AutomationX, you can prevent anyone else from exploiting or hijacking your product with the normal commercial means. To prevent anyone from exploiting or hijacking LPLC, we _have_ to use the GNU Public License as it is the only one that lets anyone contribute without having their freely given gift ripped off. The once free, always free provision makes it possible for companies to donate code to LPLC and not see it in a competitive commercial product. My philosophy doesn't enter into it. It is the only way we can make it "safe" to contribute. If the LPLC were perceived for a moment to be anything but totally independent and vendor neutral, we become a competitor. That is, by the way, why I refer to it as LinuxPLC and not PuffinPLC, Ken owns that domain and name and despite his kindness and generosity in giving us a home, we can't afford to be seen as "belonging" to control.com. We have the responsibility of preventing any contribution from ever being exploited or used to the detriment of the contributor or the public. We can't have anyone ever regret acting in the common interest. That doesn't sound like anarchy to me, it's highly principled. I take it very seriously. LPLC must belong to all or none. The important point here is that I see LPLC as a way that people can cooperate to solve the problems without giving away the store. This is widely misunderstood, I think. We can be the neutral go between. We seek to be a solution not a threat. > > 2. Open & Proprietary. I get the distinct impression that open, from your > perspective, necessarily requires the GNU or equivalent model (ie donated > labour where the product including source code is available for free). I > don't believe this. AutomationX, for example, is a proprietary product that > we license to users. At the same time, automationX is, in my opinion, > totally open. We comply with a number of open protocols - we use TCP/IP for > client server communication and Profibus predominantly on the field side. > Although over the years we have developed a number of interfaces, as a > necessary requirement in today's heterogeneous industrial environment, we > certainly do not go out of our way to jump on the latest bus bandwagon and > generally have many times fewer interfaces than offered by typical HMI/SCADA > products (which we really are not). Interestingly, and a testament to our > openness, the tools we use to develop interfaces are fully available to end > users and/or integrators. > > Finally, I would have to vehemently disagree with your assertion that we > believe in private ownership of IP, protocols, etc. On the contrary, we > embrace open industry standards, especially IP, protocols, etc. In fact, > automationX, if a competitive product (GNU or proprietary) where available, > very much complies with the model I proposed where all individual components > (software and hardware) including the client, server, & field components > should be individually interchangeable. > > Best Regards, > dwm Dave, I think you misread what I wrote. I wasn't necessarily referring to _your_ ownership of IP, protocols, etc. I do see open as a binary not a continuum. It wouldn't be a big deal but in this industry they call black white and have abused the word open to the point where it has no meaning. My use of the term is is quite clear. Let's not quibble. I am glad to see a Linux product in the mix and wish you well. I will take another look for Heartland Engineering projects and those I consult to. Regards cww

Automation List : David McGilvray <dmcgilvray@mnrcan.com> gave us a good plan to grow the industry through : >"competition and interoperability exists at all levels >for both hardware and software, including the client, >server, and field, with barriers effectively removed at all >levels. Each component competes on its own merit and >can be replaced at any time like switching brands of >pencils. Costs plummet and products with favoured >features are rewarded." Jim Pinto responds : A wonderful engineering Valhalla! But, sadly NOT a practical Marketing possibility. Because - again - the industrial automation business has low volume and custom, fragmented requirements. David McGilvray comes to the same conclusion : >The model is elegant, simple and proven. >The only barrier to acceptance seems to be the vested >interests of the 50 odd existing vendors and the sheep >like behaviour of users and integrators who have blindly >accepted their dated message. Jim : You are SO RIGHT! There is a Marketing reason for the "vested interests" of the 50-off vendors and the "sheep-like behavior" of the users and integrators. The market is stagnant and even declining. None of the vendors are making enough money to do much beyond survival. The integrators have low margins, and are "downstream" followers. The end-users are simply too busy with other priorities and too short-sighted to look much further than tomorrow. Solution : Inflection point - new technology that will change EVERYTHING, with significant 10-times-better results! The dinosaurs will be dead, and new leaders will emerge..... Cheers: jim ----------/ Jim Pinto email : jim@jimpinto.com web: www.JimPinto.com San Diego, CA., USA ----------/

By Dave Ferguson on 7 February, 2001 - 4:16 pm

I have listened to this for months and I will relate my experience where I work and I still say it has had an effect even though others don't/won't admit it. In 1998 we purchased 100's of PC's for control and networked everything together. We also implemented an ERP due to "Y2K" and passed a ton of information back and forth. We paid Millions$$$$$ doing Y2K audits and going through all of our vendor equipment from Provox DCS's to programs written in Allen Bradley data basic modules to GE drives to ABB systems and on and on. The reality is we found very few bugs but we got caught up in all the fervor just like a lot of companies because noone really knew so therefore better safe than sorry....... Also many jumped on board and got "pet" projects pushed through under the "Y2K" issue and management bought into that excuse. We updated versions of perfectly fine DCS modules etc. "just in case"........we updated old PC's and equipment.....tore out an old IBM mainframe and replaced it (unfortunately) with BAAN and on and on. So in 1998, 1999 and early 2000 any vendor that sold to us and all of the vendor consultants made great profits from us and I assume many others.......................As well as huge amounts of internal resources used on this issue. Then 2000 shows up and very little issues appear (a couple)....management starts questioning the sanity of all of this money spent and 2001's budgets are slashed because we spent so much and double the scrutiny for any "automation" or "IT" project. Now all of these vendors got big dollars for a couple of years and really thin profits for a couple of years and the net result is a couple of great years and a couple of very poor years. Problem is this economy has no long term outlook. We work on a quarter to quarter report world and guess what.......bad quarter.....lay off everyone and "M&A". No profits this quarter....sell your stock and go somewhere else. We put all of our eggs in the quick buck (get rich quick) theory and now we are paying for it...........The other side of the coin involved "CUSTOMER SERVICE"....when money is rolling in left and right, slash customer service...who needs those damn customers. Now customers are demanding service and yet with no income or very discrete spending, no budget for customer service and the viscous circle goes on and on. We reached for the brass ring and made easy money a few years ago and unfortunately crammed many years of updates and revisions into a couple of years and now will pay for that for the next 5-10. There are many other factors involved but IMHO this had a major effect on the problem at least that is what I see at our small corporate piece of the pie. (2-3rd largest forest products corp. in the world, depending on who's survey you use) UPM-Kymmene...... These are my not UPM's opinions but I would like to hear how others see this spending issue (Y2K). I am not trying to create some big Y2K debate as many threads have touched on but rather the "Aftermath" of this debacle. I also am not so foolish to think this is the only issue involved......just one of them but not one to be ignored.......We are all trying to justify our decisions and don't want to talk about them...... Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation

Hello, Automation List : Curt Wuollet <cwuollet@cpinternet.com> has written a significant and insightful commentary on Automation biz trends. Curt agrees that the market is saturated, and re-caps the reasons. He correctly wishes to review the causes and offer solutions. I hope this important subject brings a lottttt of discussion from all us Engineers. The industry as a whole is flat or possibly even shrinking. Curt : >Market Saturation: we have done about all we can do with the >present paradigm. Everything that can be profitably automated >has been automated and further growth will require that we >move to higher level integration. Jim Pinto : Nope! Higher level integration will NOT increase the size of the market. The needs are the needs, and doing more does NOT increase the needs. Indeed, lowering the price often REDUCES market size : If I need an alarm relay, the availability of a half-price product does NOT double the market. Curt : >There are still vast opportunities at the low end, the "easy stuff". Jim : Nope ! The "easy stuff" becomes a commodity, and the "horde of hungry hangers on" starts to lower the price. Curt : >The higher end opportunities are there but the prevailing attitudes >towards closed systems and proprietary solutions is a very weak >and in fact, paradoxical position to address these from. Jim: Yep ! Curt : >Bottom line summation: If I am a company that has invested in some >automation and now seeks to take the next step and tie these >islands of automation together and to my enterprise system, >my prospects are bleak or worse. >The Automation vendors, they are expert at preventing systems >integration. Unless all your automation is from a single vendor and all >your IS systems run Microsoft, there isn't much hope. >On the low end, the cost of providing solutions is the barrier. Jim : Right on, my friend! Every read the above paragraph 3 times, and memorize! Curt : >How to fix it: >Integration and interoperability have to be design goals going forward. >This will require acceptance of common standards. protocols, >and Open Systems. Public ownership is the only possible way to get >full participation in this climate. Jim : Right ! But, in a small and relatively closed-end market, that is a dream which will be VERY difficult to atain. Curt : >This industry is also hobbled by the enormous cost of duplication >Not only are there 50 complete lines of incompatible products that >accomplish the same tasks, there are at least 25 incompatible busses >to do it on. Jim : Amen, brother Curt ! Curt : >Growing sideways is obviously not working at providing explosive growth > in this industry. To move forwards requires the same sort of changes >that take place in any volume based industry. None of the 50 product >lines is going to achieve the volume to lower costs and improve efficiency >in delivery of services. Jim : The primary problem in Industrial Automation is LOW VOLUME - hence only custom solutions at a high price are available. Curt : >Suppose all the cost and effort to maintain all these parallel solutions > were concentrated on a few. How much more progress could be made? > How much more efficient would support be? programming? > Suppose hardware was compatible. How much less would it cost? >Suppose that every one used the same languages and algorithms >and common modules were shared. How much less of a project would >be programming and how many fewer bugs and problems would there be? Jim : All good questions - and all dreams in the industrial automation business for 2 primary reasons : 1/ Low volume and 2/ Vast variety of needs. Curt : >How can this be accomplished in this hyper competitive industry? >Perhaps it can't. Jim : No one has yet found a way. I laud Control.com and others who are trying to stimulate Open Systems. Curt : >If it can, it will be by providing a strictly independent, publicly owned >alternative that can be readily expanded, changed, and adapted at >will to cover the maximum number of situations. In this way it can >achieve volumes where code reuse and commonality attack the problems > facing the industry. Jim : Curt - your entire (fairly long) email (which I have clipped here, for brevity) should be published - I invite InTech, Control Engineering, I&CS, CONTROL - one of the major industry journals, to publish Curt's comments in entirety! Cheers: jim ----------/ Jim Pinto email : jim@jimpinto.com web: www.JimPinto.com San Diego, CA., USA ----------/

By Ralph Mackiewicz on 13 February, 2001 - 9:22 am

I've tried to stay out of this but I just can't help myself when I read some of this malarchy. > >The Automation vendors, they are expert at > >preventing systems integration. I don't know how to say this nicely: To believe that automation vendors sit around thinking about ways to "prevent" systems integration is delusional (I'm glad I toned that down). Automation vendors may not care whether they can provide integration for other peoples products. And, they may not care whether they support public non-MS standards. But, there is no purposeful effort (aka conspiracy) to screw users. If they are too stupid to see the benefit that promoting industry-wide interoperation would bring to their company they are also too stupid to coordinate a massive global conspiracy as well. I think someone recently explained it better by pointing out the silly and counter-productive bureaucratic structures that exist at some of these vendors. That I could believe. > >This industry is also hobbled by the enormous cost of duplication Not > >only are there 50 complete lines of incompatible products that > >accomplish the same tasks, there are at least 25 incompatible busses > >to do it on. > > Jim : > Amen, brother Curt ! Amen too. 25 incompatible systems is exactly what the market wants because that is exactly what the market buys. The automation market is fragmented in many ways and this plethora of comm solutions is simply a natural result of that fragmentation. Regards, Ralph Mackiewicz SISCO, Inc.

By Curt Wuollet on 14 February, 2001 - 10:50 am

Ralph Mackiewicz wrote: > > I've tried to stay out of this but I just can't help myself when I > read some of this malarchy. > > > >The Automation vendors, they are expert at > > >preventing systems integration. > > I don't know how to say this nicely: To believe that automation > vendors sit around thinking about ways to "prevent" systems > integration is delusional (I'm glad I toned that down). Automation > vendors may not care whether they can provide integration for other > peoples products. And, they may not care whether they support public > non-MS standards. But, there is no purposeful effort (aka conspiracy) > to screw users. If they are too stupid to see the benefit that > promoting industry-wide interoperation would bring to their company > they are also too stupid to coordinate a massive global conspiracy as > well. I think someone recently explained it better by pointing out > the silly and counter-productive bureaucratic structures that exist > at some of these vendors. That I could believe. Let me pull on my analyst hat again and spell it out for you. Connectivity and interoperability, "plug compatibility", if you will, are _strategic_. In the beginning there was Modicon. All the startups supported Modbus and friends. The strategy was to carve out a piece of the existing market by being plug compatible. This strategy led to a short period where you could actually dump one vendor for another. Once market share was established, another strategy was called for. Everybody migrated their customer base to their own protocols. This strategy was twofold. It prevented the customers from jumping ship and by being wholly owned and controlled it prevented anyone else from adopting your protocols and carving out a portion of your pie. This has escalated to ridiculous proportions. This is the status quo. There are a few independents whose strategy is parasitical on a single large customer base or as an alternate to be plug compatible with everybody. These are pretty much inhibited by threat of lawsuit. The fieldbus folks have tried an end around, but have created their own mess by settling on proprietary stuff which means each new effort has to roll their own. Result....deadlock. The computer industry has had a parallel progression from IBM monopoly to plug compatibility to chaos to standardization. The real growth has come from standardization. The current situation is not inadvertant but strategic. I don't think anyone knows how to kill the monster they have created that gobbles huge amounts of diminishing resources. We seek to provide that next strategy in a healthy face-saving way and tear down the walls, it's in everyone's best interest. > > >This industry is also hobbled by the enormous cost of duplication Not > > >only are there 50 complete lines of incompatible products that > > >accomplish the same tasks, there are at least 25 incompatible busses > > >to do it on. > > > > Jim : > > Amen, brother Curt ! > > Amen too. 25 incompatible systems is exactly what the market wants > because that is exactly what the market buys. The automation market > is fragmented in many ways and this plethora of comm solutions is > simply a natural result of that fragmentation. Everyone bought black Model T's too. The auto industry prospered when someone came along and offered a real choice of colors and platforms. Henry Ford's "They can have any color they want as long as it's black" is the stage we are in today. In the not too distant future the proprietary duplicative model will seem just as dated. Strategy... Regards cww

By Ian Verhappen on 23 February, 2001 - 12:03 pm

I believe it was stated earlier in this thread that the potential is there, all we need is the will power to make it happen. IF we could all agree on which 'flavour' of Ethernet to use as a backbone, and which 'flavour' or maybe even a few 'flavours' of fieldbus to use we could soon have an all Digital Control System (new acronym for DCS) thus allowing us to use 'best in class' devices for each level of our integrated control and business system architecture. Of course, having everything able to talk to each other electronically is only one part of the story. We also need to be able to interchange the devices in the field which implies similar form factors and face to face and/or process connections. ISA S-97 is trying to start some work in that area. If you are interested in helping let me know. Let's grow together. Ian Syncrude Canada Ltd. PO Bag 4009, MD 0032 Fort McMurray, AB T9H 3L1 P 780 790-4079, Cell -799-6017 F 780 799-5190 verhappen.ian@syncrude.com

By Ralph Mackiewicz on 23 February, 2001 - 12:07 pm

> Let me pull on my analyst hat again and spell it out for you. > Connectivity and interoperability, "plug compatibility", if you > will, are _strategic_. I don't think anybody disagrees with that (communications ARE strategic). What I disagree with is the contention that the majors purposely try to prevent integration ("experts at preventing integration" was the term). They don't think that your definition of equipment interchangeability via a standardized application protocol is what their customers want/need. You can disagree with them, as I do partially, on this point but: from personal experience I can tell you that the people within these companies firmly believe that they are behaving in a manner consistent with the best interests of their customers. Many of their customers reinforce that explicitly (by endorsing their activities) and implicitly (by buying their equipment). I strongly disagree with you that their intent is to screw the user. > In the beginning there was Modicon. All the startups supported > Modbus and friends. The strategy was to carve out a piece of the > existing market by being plug compatible. This strategy led to a > short period where you could actually dump one vendor for another. > Once market share was established, another strategy was called for. > Everybody migrated their customer base to their own protocols. This > strategy was twofold. It prevented the customers from jumping ship > and by being wholly owned and controlled it prevented anyone else > from adopting your protocols and carving out a portion of your pie. Your history is a bit off. Modbus was not universally accepted in the early days of PLCs. Acceptance of Modbus came much later. The early motivation to develop your own protocol was not driven by customer retention concerns, it was technical. If you wanted to support on-line programming over the same port as data access you had to develop your own protocol for it. I specifically remember this process when I was an engineer at Westinghouse's PLC group, Numa-Logic. We looked at Modbus but it did not provide the services needed to implement the features we wanted (at least the published version did not). No one from the marketing or the business side told us that we could not use Modbus. In fact, it would have been a stroke of genius to do this because we would have loved to capture market share from Modicon at the time. But we were not that smart then and NONE of our users (or potential users) asked for this at that time. We did not use Modbus because it couldn't fit the requirements. I am very confident that Data Highway, GELAN, SyNet, etc. etc. were all developed with the same basic motivations. Interoperation of equipment was simply not a consideration at that time (late 70s). The Personal Computer wasn't even an idea then. PC stood for programmable controller. Once again you attribute purposeful (and vindicative) motives to a result that happened accidentally. In hindsight, I wish we were smart enough at the time to predict the future, but the truth is we weren't that smart or prescient. > The fieldbuss folks have tried an end around, but have created > their own mess by settling on proprietary stuff which means each > new effort has to roll their own. I suppose this depends on the definition of "proprietary". > The current situation is not inadvertant but strategic. The issue I am arguing is inadvertent versus purposeful malicious intent. I maintain that the current situation is a natural result of vendors trying to satisfy customer concerns in a highly fragmented market. There is no widespread desire (anymore) by the vast majority of IA users to utilize a single application protocol to which all the vendors can respond in a unified fashion. You have a need for this, and I think its a good idea, but most users don't seem to care about this. > > > >This industry is also hobbled by the enormous cost of duplication > > > >Not only are there 50 complete lines of incompatible products > > > >that accomplish the same tasks, there are at least 25 > > > >incompatible busses to do it on. > > > > > > Jim : > > > Amen, brother Curt ! > > > > Amen too. 25 incompatible systems is exactly what the market wants > > because that is exactly what the market buys. The automation market > > is fragmented in many ways and this plethora of comm solutions is > > simply a natural result of that fragmentation. > > Everyone bought black Model T's too. The auto industry prospered when > someone came along and offered a real choice of colors and platforms. > Henry Ford's "They can have any color they want as long as it's black" > is the stage we are in today. In the not too distant future the > proprietary duplicative model will seem just as dated. You make my case. Users did not want the standard of a black model T. They opted for a plethora of different makes and models with non- interchangeable parts (even between model years). Once the industry abandoned the black Model T paradigm it grew tremendously by providing what customers wanted: constantly changing models (accompanied by excited marketing). This is exactly how we ended up with 25 incompatible systems: vendors responding to their customers. Mistakes are very easy to spot looking backward and very difficult to predict looking forward. Regards, Ralph Mackiewicz SISCO, Inc.

By Michael Griffin on 23 February, 2001 - 2:14 pm

At 16:59 15/02/01 -0500, Ralph Mackiewicz wrote: <clip> >There is no widespread desire (anymore) by the vast majority >of IA users to utilize a single application protocol to which all the >vendors can respond in a unified fashion. You have a need for this, >and I think its a good idea, but most users don't seem to care about >this. <clip> This is more or less a chicken and egg problem. People will develop useful and profitable software products which can make use of communications to each machine provided the machines can easily be connected together. For example, most customers could see a benefit to a system which will tell them how efficiently their equipment is performing and give them hard data on down time, etc. The problem with implementing something like this though is trying to talk to the hardware. I'm sure it can almost always be done but it adds to the cost and complexity, which must be set against the potential savings. Something like this will only become popular when the communications becomes easy. At that point, universal communications will be something everyone will expect. I recall that PCs were around for a number of years before office networking became popular. Now, even very small businesses take office networking of PCs for granted. Widespread networking has changed the way PCs are used and created entirely new applications (e-mail, etc.). Few businesses today would consider buying an office PC which could not be networked. I forsee the same thing happening with industrial controls. If you want to see the sort of application I am talking about, take a look at: http://www.executivetechnologies.com/ I don't have any connection with the company other than I am looking at using their software in our plant. They produce software which monitors your production equipment, collects real data, and helps you analyse where your production bottlenecks are. The tough and expensive part (at least in my situation) is getting the PLCs to talk to it. Please keep in mind that I am not offering any sort of recommendation on the company or their particular product since I haven't used it myself yet. But this is the *type* of product which I think will cause customers to suddenly decide that all their PLCs need to communicate. Other companies are bound to come up with even more ideas. At that point simple, easy, and inexpensive connections to a plant wide communications system will be one of the most significant points on which PLCs are judged. ********************** Michael Griffin London, Ont. Canada mgriffin@odyssey.on.ca **********************

By Curt Wuollet on 23 February, 2001 - 2:51 pm

Hi All Let's take imagination one step further and put it in real terms. Let's say that all Automation Engines (PLC, NC, Robot, MCS, etc.) shared just one common feature. This would be kinda like NFS (file sharing) for automation. Let's call it VMB (virtual memory blocks). Connected to an ethernet lan, you could cross mount a block of memory from one controller to another. On the wire, they would use a machine independant (consistant) format. So whatever weird byte order you have would be handled automatically and would be mapped correctly on the other end. You would specify what IP could do this on each end for security. It would be transparent. Many PLC's do this for "global" registers, etc. so obviously it must be handy :^). Think what this one feature could do. Instead of screwing around with all sorts of bridges, BASIC, protocols, passing BCD on groups and all the other horrid kludges we now have to do to pass info from one device to another, you would now simply dump it into a register, the linguia franca for automation. It would magically appear on the other side. This could be done economically with off the shelf silicon and free TCP/IP stacks. If it were completely open and public property, it could be universally implemented and even retrofitted with a "VMB module" to older systems. Tell me this wouldn't be a huge leap forward with just _one_ cooperative effort. Now tell me how it's impossible, there's no market, it's not deterministic, it's communism, it needs to be "specialized" for sewer work, and all the other BS I get for advocating things that are only common sense. I'd be interested in what the downside would possibly be. Why all those engineers in all those megacorporations couldn't figure something like this out. I'll tell you why....... It would _have_ to be an OSS project, it would _have_ to be public property and absolutely independent. We could do it! If any one company even suggested it, there would be 50 incompatible proprietary versions and nothing would be accomplished. That's the trap we're in that means this industry can only grow sideways instead of going forward. We're trying to find a way forward, no more, no less. Can you hear what I'm saying. Am I connecting at all? Regards cww

By Joe Jansen/ENGR/HQ/KEMET/US on 23 February, 2001 - 2:55 pm

I'm with you. And regardless of what others think, I feel that this is what is holding back the growth in the automation industry. The market is saturated with the current crop of products, but a move forward like this or a number of other cooperative or truely innovative progressions would suddenly create an unsaturated area of the market, and we would see something start to happen. The problem in the automation market today is that all of the vendors have spent so much time building their walls up to keep out the competition, that they now find themselves trapped inside their own little towers. --Joe Jansen

By Bob Peterson on 23 February, 2001 - 2:57 pm

> Let's take imagination one step further and put it in real terms. > Let's say that all Automation Engines (PLC,NC,Robot,MCS, etc.) > shared just one common feature. This would be kinda like NFS > (file sharing) for automation. Let's call it VMB (virtual memory > blocks). Connected to an ethernet lan, you could cross mount a > block of memory from one controller to another. On the wire, they > would use a machine independant (consistant) format. So whatever > weird byte order you have would be handled automatically and > would be mapped correctly on the other end. You would specify > what IP could do this on each end for security. It would be > transparent. > > Many PLC's do this for "global" registers, etc. so obviously > it must be handy :^). > > Think what this one feature could do. Instead of screwing around > with all sorts of bridges, BASIC, protocols, passing BCD on groups > and all the other horrid kludges we now have to do to pass info > from one device to another, you would now simply dump it into a > register, the linguia franca for automation. It would magically > appear on the other side. > Yea it would be a nifty feature, BUT, how many people actually need such a feature? What you are advocating might actually end up being a step backwards, allowing uninformed number crunchers to decide that even though the rest of the plant is AB, if it costs $100 less to buy a certain machine with an XYZ PLC on it, go buy the XYZ controlled machine. Afterall, they are all "compatible" with each other. Few people want to have a lot of different platforms, for various reasons, but primarily reduction of spare parts and training issues. This is sort of like an airline having 20 different models and brands of airplanes. They all can work together, but the extra spare parts and training issues make it far more practical to try to focus on one (or a few) brands/models. The fact is that even in the TCP/IP world, getting things to talk to each other is not always that simple. Try setting up an NT machine to talk peer-peer with Linux based machine (or even a Win98 machine) sometime. Yes, it can and has been done, BUT it sometimes requires some people with a lot of technical skills a substantial amount of time to get it working. Virtually any electrician/technician with a minimal amount of training can get two DH+ PLCs to talk to each other. The same thing goes for the various bridges between these networks. All the ones I have tried, have worked pretty quick, right out of the box, with not a lot of screwing around. Some have been a little tedious to set up, but they setup fairly straightforward, and then just work. And I don't have to worry that the next version of Windows is going to introduce some new "feature" that will cause it to mysteriously stop working. Do you really believe the average factory floor electrician is going to be able to learn enough about TCP/IP and ethernet to debug and test the types of connections you are advocating? Be real. Get much past a hub, and i don't want to deal with ethernet. I don't want to mess with switchers, routers, rights assignments, etc. I want to hook up a cable between two PLCs and make them talk 30 seconds later. I can do that with DH+ or Modbus+. With Ethernet, it is not so simple. Yes the, DH+ hardware costs me more. BUT, my time is not free. And the production start date is fixed. Do I really want to screw around for an extra couple hours/days to save a $1000 on hardware? I am not suggesting your idea does not have merit. I am suggesting you look a little past your bias against the ABs and Microsofts of the world. There are good, solid reasons why people have spent a lot of money on AB and Microsoft products over the years. Bob Peterson

By Curt Wuollet on 26 February, 2001 - 3:35 pm

PETERSONRA@AOL.COM wrote: > In a message dated 2/23/01 9:02:36 AM Central Standard Time, > wideopen@ECENET.COM writes: > > > Let's take imagination one step further and put it in real terms. > > Let's say that all Automation Engines (PLC,NC,Robot,MCS, etc.) > > shared just one common feature. This would be kinda like NFS > > (file sharing) for automation. Let's call it VMB (virtual memory > > blocks). Connected to an ethernet lan, you could cross mount a > > block of memory from one controller to another. On the wire, they > > would use a machine independant (consistant) format. So whatever > > weird byte order you have would be handled automatically and > > would be mapped correctly on the other end. You would specify > > what IP could do this on each end for security. It would be > > transparent. > > > > Many PLC's do this for "global" registers, etc. so obviously > > it must be handy :^). > > > > Think what this one feature could do. Instead of screwing around > > with all sorts of bridges, BASIC, protocols, passing BCD on groups > > and all the other horrid kludges we now have to do to pass info > > from one device to another, you would now simply dump it into a > > register, the linguia franca for automation. It would magically > > appear on the other side. > > Yea it would be a nifty feature, BUT, how many people actually need such a > feature? What you are advocating might actually end up being a step > backwards, allowing uninformed number crunchers to decide that even though > the rest of the plant is AB, if it costs $100 less to buy a certain machine > with an XYZ PLC on it, go buy the XYZ controlled machine. Afterall, they are > all "compatible" with each other. Yes, they might do that. And with a reasonable means of communication, there is every chance that it would work. And the XYZ controlled machine might actually be a lot better. But consider this. This is what it would take to get my GE PLC's working with my GEF machine control and my Fanuc robot as there are no reasonable means to connect them. And I fail to see how this could be a step backward. Something is typically better than nothing. > Few people want to have a lot of different platforms, for various reasons, > but primarily reduction of spare parts and training issues. This is sort of > like an airline having 20 different models and brands of airplanes. They all > can work together, but the extra spare parts and training issues make it far > more practical to try to focus on one (or a few) brands/models. And it wouldn't affect those folks one way or the other. Especially if it was implemented as a plugin. You don't _have_ to use it. > The fact is that even in the TCP/IP world, getting things to talk to each > other is not always that simple. Try setting up an NT machine to talk > peer-peer with Linux based machine (or even a Win98 machine) sometime. Yes, > it can and has been done, BUT it sometimes requires some people with a lot of > technical skills a substantial amount of time to get it working. Virtually > any electrician/technician with a minimal amount of training can get two DH+ > PLCs to talk to each other. If you do it right, you need only enter the two IP addresses and possibly a gateway. By the way, it's really no problem to get two Linux machines talking. Linux uses the standards as intended. And I'm not buying that the proprietary stuff is any easier. The market is full of plug and play net appliances. > The same thing goes for the various bridges between these networks. All the > ones I have tried, have worked pretty quick, right out of the box, with not a > lot of screwing around. Some have been a little tedious to set up, but they > setup fairly straightforward, and then just work. Not needing one is a lot easier. > And I don't have to worry that the next version of Windows is going to > introduce some new "feature" that will cause it to mysteriously stop working. I can assure you, nothing I built would ever depend on what Windows does :^) That would be the goodness of the thing. Instead of kludging in stuff from office automation, this would be designed specifically for automation, lean, simple, and truly open. A reference implimentation on Linux wouldn't be very many lines of code. Most of it is already there. It would be a bit harder on RTOS style stacks but, I guarantee there are folks who are reading this who could do it quickly without any problem on their hardware. It's when you get too general that network programming gets hairy.. > Do you really believe the average factory floor electrician is going to be > able to learn enough about TCP/IP and ethernet to debug and test the types of > connections you are advocating? Be real. Get much past a hub, and i don't > want to deal with ethernet. I don't want to mess with switchers, routers, > rights assignments, etc. I want to hook up a cable between two PLCs and make > them talk 30 seconds later. I can do that with DH+ or Modbus+. With > Ethernet, it is not so simple. Yes the, DH+ hardware costs me more. BUT, my > time is not free. And the production start date is fixed. Do I really want > to screw around for an extra couple hours/days to save a $1000 on hardware? You've been doing Ethernet on the wrong platform if it's not "plug and play". I'll bet I can find a lot more people in any given organization that can make the Ethernet work than would have a clue what Modbus+ is. And DH+ is much the same idea, they simply make the assumptions and charge you $2000.00. If I got a little fancier, I could use dhcp to configure the devices and discover the peers and have no configuration at all on the floor. The trick is to use what others have already developed. But simpler would be better and entering the IP's would be positive and secure. > I am not suggesting your idea does not have merit. I am suggesting you look > a little past your bias against the ABs and Microsofts of the world. There > are good, solid reasons why people have spent a lot of money on AB and > Microsoft products over the years. And there are good solid reasons why Linux is growing faster than both of them put together. Open is easier and I have a whole community to help me. I have the code for world class networking to start with and enough examples with source code that I can do something like this with hardly any new code. And since I would GPL the code, It would be even easier for the next guy. It's much harder when you start from scratch in secret. It's not that I am so biased against MS and AB, It's that I can do so much more, so much easier in an OSS world that I would like to help others shed their shackles too. Why would you want to reinvent something like this over and over and over. instead of simply sharing and helping each other. If I did some looking around at PDA and database synchronizers, I might even find that someone has already done this and use their code. Regards cww

By Bob Peterson on 28 February, 2001 - 2:57 pm

> Yes, they might do that. And with a reasonable means of communication, > there is every chance that it would work. And the XYZ controlled machine > might actually be a lot better. But consider this. This is what it would > take > to get my GE PLC's working with my GEF machine control and my Fanuc > robot as there are no reasonable means to connect them. And I fail to see > how this could be a step backward. Something is typically better than > nothing. > Are you suggesting there is no way for a GEF robot controller to talk to a GEF PLC? Even AB has a communications interface from its PLcs to its CNC stuff. I would have to believe that GEF has something with this functionality. > > Few people want to have a lot of different platforms, for various > > reasons, but primarily reduction of spare parts and training issues. > > This is sort of like an airline having 20 different models and > > brands of airplanes. They all can work together, but the extra > > spare parts and training issues make it far more practical to try > > to focus on one (or a few) brands/models. > > And it wouldn't affect those folks one way or the other. Especially if it > was implemented as a plugin. You don't _have_ to use it. But you still have to pay for it. regardless of your willingness to give away the code, the manufacturers are going to have to incur substantial costs to implement such a thing. Even if the code is free and the chips are $10 per unit, the actual cost to implement such a channel is likely to be a whiole lot more then $10. This is because you have made the error of looking at a case in the PC world of huge quantities of ethernet stuff and tried to apply it to a tiny PLC market. > > The fact is that even in the TCP/IP world, getting things to talk to each > > other is not always that simple. Try setting up an NT machine to talk > > peer-peer with Linux based machine (or even a Win98 machine) sometime. > > Yes, it can and has been done, BUT it sometimes requires some people > > with a lot of > > technical skills a substantial amount of time to get it working. > > Virtually any electrician/technician with a minimal amount of training > > can get two DH+ PLCs to talk to each other. > > If you do it right, you need only enter the two IP addresses and possibly a > gateway. By the way, it's really no problem to get two Linux machines > talking. Linux uses the standards as intended. And I'm not buying that the > proprietary stuff is any easier. The market is full of plug and play net > appliances. Note that i did not say anything about getting two Linux machines to talk to each other. They are designed to do this from the ground up. nothing else really is. you are suggesting a massive change in approach that is NOT free, nor simple to implement. > > The same thing goes for the various bridges between these networks. All > > the ones I have tried, have worked pretty quick, right out of the box, > > with not a lot of screwing around. Some have been a little tedious to > > set up, but they setup fairly straightforward, and then just work. > > Not needing one is a lot easier. You are only suggesting changing the exisitng bridges for a universal bridge. To make this work would require a standard software and hardware interface. The industry would have to come together and agree on this standard, and possibly and testing procedures for insuring they actually do work together. Think about how long this took for devicenet, or interbus, and they still have wierd quirks. > > And I don't have to worry that the next version of Windows is going to > > introduce some new "feature" that will cause it to mysteriously stop > > working. > > I can assure you, nothing I built would ever depend on what Windows does > :^) That would be the goodness of the thing. Instead of kludging in stuff > from office automation, this would be designed specifically for > automation, lean, simple, and truly open. A reference implimentation > on Linux wouldn't be very many lines of code. Most of it is already > there. It would be a bit harder on RTOS style stacks but, I guarantee > there are folks who are reading this who could do it quickly without > any problem on their hardware. It's when you > get too general that network programming gets hairy.. But no one in the "real" world wants Linux. Not to disparage it (or you) but I don't want it. I already have to know 2-3 PLCs, half a dozen I/O systems, 3 or 4 HMIs, god knows how many motion controllers, and 3-4 different SCADA packages, plus windows 98 and enought NT to get by. when i am suppsoed to learn enough about Linux to get by. I have read the book. It ain't that simple. > > Do you really believe the average factory floor electrician is going to > > be able to learn enough about TCP/IP and ethernet to debug and test the > > types of connections you are advocating? Be real. Get much past a > > hub, and i don't want to deal with ethernet. I don't want to mess > > with switchers, routers, rights assignments, etc. I want to hook up > > a cable between two PLCs and make them talk 30 seconds later. I can > > do that with DH+ or Modbus+. With Ethernet, it is not so simple. Yes > > the, DH+ hardware costs me more. BUT, my > > time is not free. And the production start date is fixed. Do I really > > want to screw around for an extra couple hours/days to save a $1000 > > on hardware? Plug and play is not as simple as all that, and you know it. Once you hook into even a small ethernet network, things change. Point to point ethernet is usually pretty simple to implement. But point-to-point is not what ethernet is all about. > You've been doing Ethernet on the wrong platform if it's not "plug and > play". > > I'll bet I can find a lot more people in any given organization that can > make the Ethernet work than would have a clue what Modbus+ is. And DH+ is > much > the same idea, they simply make the assumptions and charge you $2000.00. > If I got a little fancier, I could use dhcp to configure the devices and > discover the peers and have no configuration at all on the floor. The trick > is to use what others have already developed. But simpler would be better > and entering the IP's would be positive and secure. I don't disagree. But they are not the guys out on the floor trying to get it working at 3 am. And I would be willing to bet that anyone that can get ethernet to work can read the manual and in 10 minutes or less and get modbus+ to work. Modbus+ (or DH+) is far more plug and play then ethernet will ever be. > > I am not suggesting your idea does not have merit. I am suggesting you > > look a little past your bias against the ABs and Microsofts of the > > world. There are good, solid reasons why people have spent a lot > > of money on AB and Microsoft products over the years. > > And there are good solid reasons why Linux is growing faster than both of > them put together. Open is easier and I have a whole community to help me. > I have > the code for world class networking to start with and enough examples with > source code that I can do something like this with hardly any new code. And > since I would GPL the code, It would be even easier for the next guy. It's > much harder when you start from scratch in secret. It's not that I am so > biased against MS and AB, It's that I can do so much more, so much easier > in an OSS world that I would like to help others shed their shackles too. > Why would you want to reinvent something like this over and over and > over.instead of simply sharing and helping each other. > If I did some looking around at PDA and database synchronizers, I might > even find that someone has already done this and use their code. Percentage of growth is really meaningless when the market share is near zero. If there are 100 Linux platforms out there doing industrial control and you add a hundred more you have doubled it. To double the number of PLCs out there means you'd have to add millions of them. As for your openness idea. i am not all that thrilled with it. I sort of like the security I have knowing that the new electrician/hacker on third shift can't rewrite my RLL complier to do what he thinks is the way it should be, Openness is definitely A way to go. A few years ago I probably would have thought the same way you do. I am less convinced now. Those of us in the trenches have enough problems just getting machines out the door and keeping them running, without having to worry about learning another complex operating system. Bob Peterson

By Curt Wuollet on 28 February, 2001 - 3:46 pm

> From: PETERSONRA@aol.com > > > > Yea it would be a nifty feature, BUT, how many people actually need such > > > a feature? What you are advocating might actually end up being a step > > > backwards, allowing uninformed number crunchers to decide that even > > > though the rest of the plant is AB, if it costs $100 less to buy a > > > certain machine with an XYZ PLC on it, go buy the XYZ controlled > > > machine. Afterall, they are all "compatible" with each other. > > > > Yes, they might do that. And with a reasonable means of communication, > > there is every chance that it would work. And the XYZ controlled machine > > might actually be a lot better. But consider this. This is what it would > > take > > to get my GE PLC's working with my GEF machine control and my Fanuc > > robot as there are no reasonable means to connect them. And I fail to see > > how this could be a step backward. Something is typically better than > > nothing. > > Are you suggesting there is no way for a GEF robot controller to talk to a > GEF PLC? Even AB has a communications interafce from its PLcs to its CNC > stuff. I would have to believe that GEF has something with this > functionality. Actually, no they don't. They supposedly have a genius interface but no one I talked to has ever seen one. > > > Few people want to have a lot of different platforms, for various > > > reasons, but primarily reduction of spare parts and training issues. > > > This is sort of like an airline having 20 different models and > > > brands of airplanes. They all can work together, but the extra > > > spare parts and training issues make it far more practical to try > > > to focus on one (or a few) brands/models. > > > > And it wouldn't affect those folks one way or the other. Especially if it > > was implemented as a plugin. You don't _have_ to use it. > > But you still have to pay for it. regardless of your willingness to give > away the code, the manufacturers are going to have to incur substantial costs > to implement such a thing. Even if the code is free and the chips are $10 > per unit, the actual cost to implement such a channel is likely to be a > whiole lot more then $10. This is because you have made the error of looking > at a case in the PC world of huge quantities of ethernet stuff and tried to > apply it to a tiny PLC market. If they would quit fragmenting it and actually cooperate on something like this the market would be plenty large. But you're missing the point. Because there is a huge Ethernet market, the components are cheap and available and mature. If you create yet another private offering, the volumes never get attractive. If you join the Ethernet market you benefit from the vast volumes. The really twisted part or that argument is that they seem to be able to afford the expensive case, yet can't afford the cheap one. The engineering and total work needed to use ethernet is a tiny fraction of what rolling your own costs. > > > The fact is that even in the TCP/IP world, getting things to talk to each > > > other is not always that simple. Try setting up an NT machine to talk > > > peer-peer with Linux based machine (or even a Win98 machine) sometime. > > > Yes, it can and has been done, BUT it sometimes requires some people > > > with a lot of > > > technical skills a substantial amount of time to get it working. > > > Virtually any electrician/technician with a minimal amount of training > > > can get two DH+ PLCs to talk to each other. But it's nearly impossible to get them to talk to anything else. With the ethernet approach it would take the same time even if the vendors were different. Talking to themselves has never been an issue. Getting a Linux box to talk to a Sun box isn't a challange because they use standards. > > If you do it right, you need only enter the two IP addresses and possibly a > > gateway. By the way, it's really no problem to get two Linux machines > > talking. Linux uses the standards as intended. And I'm not buying that the > > proprietary stuff is any easier. The market is full of plug and play net > > appliances. > > Note that i did not say anything about getting two Linux machines to talk to > each other. They are designed to do this from the ground up. nothing else > really is. you are suggesting a massive change in approach that is NOT free, > nor simple to implement. No, but it would be easier and cheaper than what they are doing now. > > > > > The same thing goes for the various bridges between these networks. All > > > the ones I have tried, have worked pretty quick, right out of the box, > > > with not a lot of screwing around. Some have been a little tedious to > > > set up, but they setup fairly straightforward, and then just work. > > > > Not needing one is a lot easier. > > You are only suggesting changing the exisitng bridges for a universal bridge. > to make this work would require a standard software and hardware interface. > the industry would ahve to come together and agree on this standard, and > possibly and testing procedures for insuring they actually do work together. > think about how long this took for devicenet, or interbus, and they still > have wierd quirks. No the industry would fail miserably in standardizing this. In fact they would fail intentionally, exactly like the fieldbus fiasco or any other standardization attempt. An independant body would have to write a protocol, a very simple high level protocol. Everything else is already done and in use by a million sites. That's the advantage of using what already works. > > > And I don't have to worry that the next version of Windows is going to > > > introduce some new "feature" that will cause it to mysteriously stop > > > working. > > > > I can assure you, nothing I built would ever depend on what Windows does > > :^) That would be the goodness of the thing. Instead of kludging in stuff > > from office automation, this would be designed specifically for > > automation, lean, simple, and truly open. A reference implimentation > > on Linux wouldn't be very many lines of code. Most of it is already > > there. It would be a bit harder on RTOS style stacks but, I guarantee > > there are folks who are reading this who could do it quickly without > > any problem on their hardware. It's when you > > get too general that network programming gets hairy.. > > But no one in the "real" world wants Linux. Not to disparage it (or you) but > I don't want it. I already have to know 2-3 PLCs, half a dozen I/O systems, > 3 or 4 HMIs, god knows how many motion controllers, and 3-4 different SCADA > packages, plus windows 98 and enought NT to get by. when i am suppsoed to > learn enough about Linux to get by. I have read the book. It ain't that > simple. I am suggesting Linux only as one of the clients. To be meaningful it would be implemented in whatever RTOS or RT exec the PLC uses. Doing it only on Linux would accomplish nothing. There would be no reason at all for you to learn Linux if you weren't going to use it. It would be a feature of whatever you use now. > > > Do you really believe the average factory floor electrician is going to > > > be able to learn enough about TCP/IP and ethernet to debug and test the > > > types of connections you are advocating? Be real. Get much past a > > > hub, and i don't want to deal with ethernet. I don't want to mess > > > with switchers, routers, rights assignments, etc. I want to hook up > > > a cable between two PLCs and make them talk 30 seconds later. I can > > > do that with DH+ or Modbus+. With Ethernet, it is not so simple. Yes > > > the, DH+ hardware costs me more. BUT, my > > > time is not free. And the production start date is fixed. Do I really > > > want to screw around for an extra couple hours/days to save a $1000 > > > on hardware? > > Plug and play is not as simple as all that, and you know it. Once you hook > into even a small ethernet network, things change. Point to point ethernet > is usually pretty simple to implement. But point-to-point is not what > ethernet is all about. But you could take a single hub and make a network just for this purpose for less than some automation connectors. The complexity only comes if you want to hook to a larger world. At that point I would assume you know what you're doing. > > You've been doing Ethernet on the wrong platform if it's not "plug and > > play". > > > > I'll bet I can find a lot more people in any given organization that can > > make the Ethernet work than would have a clue what Modbus+ is. And DH+ is > > much > > the same idea, they simply make the assumptions and charge you $2000.00. > > If I got a little fancier, I could use dhcp to configure the devices and > > discover the peers and have no configuration at all on the floor. The trick > > is to use what others have already developed. But simpler would be better > > and entering the IP's would be positive and secure. > > I don't disagree. But they are not the guys out on the floor trying to get > it working at 3 am. And I would be willing to bet that anyone that can get > ethernet to work can read the manual and in 10 minutes or less and get > modbus+ to work. Modbus+ (or DH+) is far more plug and play then ethernet > will ever be. > > > > I am not suggesting your idea does not have merit. I am suggesting you > > > look a little past your bias against the ABs and Microsofts of the > > > world. There are good, solid reasons why people have spent a lot > > > of money on AB and Microsoft products over the years. > > > > And there are good solid reasons why Linux is growing faster than both of > > them put together. Open is easier and I have a whole community to help me. > > I have > > the code for world class networking to start with and enough examples with > > source code that I can do something like this with hardly any new code. And > > since I would GPL the code, It would be even easier for the next guy. It's > > much harder when you start from scratch in secret. It's not that I am so > > biased against MS and AB, It's that I can do so much more, so much easier > > in an OSS world that I would like to help others shed their shackles too. > > Why would you want to reinvent something like this over and over and > > over.instead of simply sharing and helping each other. > > If I did some looking around at PDA and database synchronizers, I might > > even find that someone has already done this and use their code. > > Percentage of growth is really meaningless when the market share is near > zero. If there are 100 Linux platforms out there doing industrial control > and you add a hundred more you have doubled it. To double the number of PLCs > out there means you'd have to add millions of them. > > As for your openness idea. i am not all that thrilled with it. I sort of > like the security I have knowing that the new electrician/hacker on third > shift can't rewrite my RLL complier to do what he thinks is the way it should > be, Openness is definitely A way to go. A few years ago I probably would > have thought the same way you do. I am less convinced now. Those of us in > the trenches have enough problems just getting machines out the door and > keeping them running, without having to worry about learning another complex > operating system. Again, I am talking about your existing platforms supporting an open interconnect means. How would that entail your learning a new OS? cww

By Joe Jansen/ENGR/HQ/KEMET/US on 28 February, 2001 - 4:40 pm

Bob Peterson wrote: >As for your openness idea. i am not all that thrilled with it. I sort >of like the security I have knowing that the new electrician/hacker on >third shift can't rewrite my RLL complier to do what he thinks is the way >it should be, ***** If that's what you think Open means, then you have missed the entire point. It doesn't mean that you have to give your machine operators source code, compilers, etc. Linux/Unix offers a stronger security model than Windows anyway. (Especially for the local machine. If you are at the machine under NT, you have access to everything. With Linux/Unix, you can still lock out areas of the hard drive and OS based on login account. This is how you would keep Joe Hacker out of the compilers.) You think that the idea is to implement a security system and then ignore it? >Those of us in the trenches have enough problems just getting machines >out the door and keeping them running, without having to worry about >learning another complex operating system. ***** Believe me, you do not speak for all of us "in the trenches". Some of us are actually still willing to try to expand our knowledge, rather than proclaiming that "This is what has worked before, so it must be true that it will always be the best". You are starting to sound like someone "out of the trenches" and in the corner office somewhere. The day I stop wanting to learn is the day I die. I may continue to breathe and eat, but I will be dead. Joe Jansen

By Michael Griffin on 27 February, 2001 - 3:36 pm

At 11:02 23/02/01 EST, Bob Peterson wrote (with regards to networking): <clip> >Yea it would be a nifty feature, BUT, how many people actually need such a >feature? What you are advocating might actually end up being a step >backwards, allowing uninformed number crunchers to decide that even though >the rest of the plant is AB, if it costs $100 less to buy a certain machine >with an XYZ PLC on it, go buy the XYZ controlled machine. Afterall, they are >all "compatible" with each other. However, I think we are not seeing the forest for the trees. I don't think the big advantages from universal communications will come from being able to more easily connect different low level or machine level devices together. There are many solutions to this problem today. They may not be ideal solutions, but they exist, and require only the application of money. I think the real advantages will come when simple, reliable, inexpensive communications make entirely new applications possible. Step back from your own particular world of valves, sensors, relays, software, etc., and think of the plant as a whole. Think of what you would need to do to increase overall reliability and productivity of the entire plant week by week, year after year. Where would you start? Unless you work in a fairly small plant, you would find that your biggest problem is a complete absence of reliable information. Do you collect downtime and productivity information manually? Do you actually trust any of these numbers? Or have you discovered that people fill in whatever numbers they think look believable? Can you take this bogus data and spend a large sum of money correcting a problem and be confident that it will make the difference (in terms of parts at the end of the line) you predicted? For that matter what *are* your worst problems? Are they the once every five years nightmare breakdown that everyone remembers? Or, are they the continuous little problems that happen every day and everyone is used to? Do you have production and test parameter data inside various machines? Are they correct? Are they up to the latest engineering revision? Did someone change them to get parts out the door? Plant managers understand the value of trustworthy data. They understand the value of measureable performance. Their eyes may glaze over if you start to talk about Profibus versus ethernet, but they will wake right up if you offer to give them a window into what is really happening in their plant 24 hours a day, 7 days a week. Think about things from their point of view. This has all been done before, but it has been expensive and too technically difficult for smaller companies to see a benefit. One of the biggest problems has been that there is no simple solution which will allow *everything* at the cell level to be connected together to a higher level. You end up with bridges and data concentrators everywhere, if it is possible at all. If those barriers were removed, a whole new demand would exist which is not apparent today. <clip> >This is sort of >like an airline having 20 different models and brands of airplanes. They all >can work together, but the extra spare parts and training issues make it far >more practical to try to focus on one (or a few) brands/models. <clip> I have heard this aircraft example several times, and I wonder what relevance it has to industrial automation. I can't think of any market that has a higher degree of vendor lock-in, hidden rebates, politics, and even simple corruption than aircraft sales (except for perhaps armaments?). You are very unlikely to get an honest answer from any airline as to why they bought (or leased) a particular aircraft. Spare parts? How many airlines maintain their own aircraft these days? Some don't even have their own air crews - they subcontract that to someone else as well. Some smaller airlines don't own a single asset other than their office furniture. Airlines usually have few models of aircraft because the aircraft manufacturers and dealers make it very expensive to buy aircraft unless you sign a long term contract for a number of aircraft with them. Industrial automation companies can only dream of having the sort of vendor lock-in which exists in the large aircraft business. ********************** Michael Griffin London, Ont. Canada mgriffin@odyssey.on.ca **********************

By Johan Bengtsson on 27 February, 2001 - 3:39 pm

> What you are advocating might actually end up being a step >backwards, allowing uninformed number crunchers to decide that even though >the rest of the plant is AB, if it costs $100 less to buy a certain machine >with an XYZ PLC on it, go buy the XYZ controlled machine. Afterall, they are >all "compatible" with each other. Backwards? an added feature that you could choose not to use being a step backwards? I think some features added to Win2000 is steps backwards, but that is because I can't turn them off, but no one HAVE to use this one just because it is there. Such decisions should be based on more things than interoperability, but without interoperability there isn't really anything to decide since you are locked in. >Few people want to have a lot of different platforms, for various reasons, >but primarily reduction of spare parts and training issues. Of course, but you are talking about opposite ends of the scale here. And of course this is one thing to take into consideration when making decisions. More education to the people making decisions too! >The fact is that even in the TCP/IP world, getting things to talk to each >other is not always that simple. Try setting up an NT machine to talk >peer-peer with Linux based machine (or even a Win98 machine) sometime. Yes, >it can and has been done, BUT it sometimes requires some people with a lot of >technical skills a substantial amount of time to get it working. Virtually >any electrician/technician with a minimal amount of training can get two DH+ >PLCs to talk to each other. With a minimal amount of training anyone knowing enough about computers to dare to enter the control panel in windows can connect an NT machine to a Win98 machine, if they both have a ethernet card for the same type of cable. >The same thing goes for the various bridges between these networks. All the >ones I have tried, have worked pretty quick, right out of the box, with not a >lot of screwing around. Some have been a little tedious to set up, but they >setup fairly straightforward, and then just work. Why do it if it is not necessary? >And I don't have to worry that the next version of Windows is going to >introduce some new "feature" that will cause it to mysteriously stop working. What do that have to do with this topic? I agree on the point as a general statement but fail to understand what it does have to do with this >Do you really believe the average factory floor electrician is going to be >able to learn enough about TCP/IP and ethernet to debug and test the types of >connections you are advocating? Be real. Get much past a hub, and i don't >want to deal with ethernet. I don't want to mess with switchers, routers, >rights assignments, etc. I want to hook up a cable between two PLCs and make >them talk 30 seconds later. I can do that with DH+ or Modbus+. With >Ethernet, it is not so simple. Yes the, DH+ hardware costs me more. BUT, my >time is not free. And the production start date is fixed. Do I really want >to screw around for an extra couple hours/days to save a $1000 on hardware? And what is your point? getting two devices using ethernet and TP to talk to each other doesn't require a switch, not even a hub. It requires a cable. 30 seconds, well it could take that long if it takes you take 30 seconds to walk from one PLC to another and plug it in. There is no real reason it need to take more time necesarily you could do more things, and doing those will of course take more time than your 30 seconds. >I am not suggesting your idea does not have merit. I am suggesting you look >a little past your bias against the ABs and Microsofts of the world. There >are good, solid reasons why people have spent a lot of money on AB and >Microsoft products over the years. Probably, but that won't mean it will last forever. The needs just might change, for one thing. /Johan Bengtsson ---------------------------------------- P&L, Innovation in training Box 252, S-281 23 H{ssleholm SWEDEN Tel: +46 451 49 460, Fax: +46 451 89 833 E-mail: johan.bengtsson@pol.se Internet: http://www.pol.se/ ----------------------------------------

By Heavner, Lou [FRS/AUS] on 27 February, 2001 - 3:47 pm

>Yea it would be a nifty feature, BUT, how many people actually need such a >feature? Probably enough to cover the developement cost with quite some margin and actually make money out of it Sure makes you wonder, with all the bright people on this list and off, why it hasn't been done. Must one of the vendors like AB, Siemens, etc do this or is it something anybody could do and sell? Even if only one of the vendors could do it, there must be something missing from the analysis. If there really are enough people who actually need it to pay for it and allow somebody to make something out of it, I can only think the opportunity cost is too high. If it is legally precluded by patents or other, perhaps there is too much protectionist regulation. We have no end of people chasing rainbows at dot.coms and elsewhere. There must be somebody out there willing to make a buck at a sure (or at least probable) thing. Regards, Lou Heavner (speaking for myself with tongue firmly in cheek)

By Curt Wuollet on 27 February, 2001 - 4:01 pm

The reason we haven't seen it is that one vendor doing it is like the sound of one hand clapping. It requires cooperation between vendors which seems impossible in the current mindset. Look at the fieldbus fiasco. No one could agree to using anyone else's protocol. Result: deadlock and marginalization of fieldbus as a Tower of Babel rather than standardization and volume deployment. Actually almost all vendors use some type of memory block transfer to propagate global registers, I/O, etc. That isn't new. It isn't crazy or impractical or useless or uneconomical. The radical concept here is to get them to do it the same way so it's useful across product lines. And of course to use a totally open and extremely well understood and totally commoditized transport. So it's something they can do and already do and it makes a lot of sense and solves a lot of problems but the idea of making it work with someone else's is blasphemy and utterly taboo. That would be useful to users and integrators and would imperil the lock-in strategy. That's why I picked it as an example. Even I could do it. Kind of a challenge where the only challenge is political courage. Like Ronald Reagan "Mr. Gorbechov, Tear Down That Wall". And no, it couldn't be done without their cooperation. About all we could do is write a reference implimentation and give it to them. The attitudes have to change before this sort of thing or any universal mechanism can be adopted. The one model we have seen is COM or OPC and that is appealing as it can be strictly to a third party and can be kept proprietary, thus preserving the barriers while purportedly "open" in a twisted paradoxical definition of the word. Regards, cww

Mr. Peterson and All, >>I am not suggesting your idea does not have merit. I am suggesting you >>look a little past your bias against the ABs and Microsofts of the world. >>There are good, solid reasons why people have spent a lot of money on AB >>and Microsoft products over the years. I do not have the same bias against these major vendors Curt seems to express. I simply believe that interoperability between automation equipment would bring advantages, features, new applications, and cost savings to users. In my opinion, it would be an answer to interoperability if the existing vendors would simply work on a common protocol; it does not require a platform shift to new companies, platforms, or OSS. As Michael Griffin suggested, I believe the opportunity with interoperable systems is in new and enhanced applications. Chances are we could not imagine half of the new applications, or enhancements to existing applications and tools that would result from having a common protocol. I was recently researching a protocol called DICOM for communication between radiology equipment (MRI, X-Ray, CAT, printers, software, etc). I was shocked. The relatively small field of radiology rates interoperability so highly that the major vendors in that market have focused on providing it, but in the much larger field of industrial automation, so many users are satisfied with the status quo of closed systems. This sort of interoperability doesn't discount the knowledge and infrastructure it takes to build and sell an MRI machine (or a PLC) but it does allow for small players to come up with new, innovative ways to leverage the information. In the case of MRI's and CAT scans, there are only a few vendors making the hardware, but there are many vendors making analysis and diagnostic software, and since it's open for public use, research academics get their chance to play as well. I wonder how far along would MRI technology be if GE Medical and Siemens were the only ones writing software and developing equipment in support of their machines? It might look as amazingly fragmented and stagnant as the automation market. :) >>The same thing goes for the various bridges between these networks. All the >>ones I have tried, have worked pretty quick, right out of the box, with not a >>lot of screwing around. Some have been a little tedious to set up, but they >>setup fairly straightforward, and then just work. The small companies that created these bridges have done a great job of filling the gaps where the major vendors have failed. But tell me, does bridging protocols just not seem like a kludge? Is it not another piece of equipment to break? More embedded software that could have bugs? Another connection that could come loose? It's not that the information being transferred on either protocol is special. In most cases it's the same class of information. But instead of pressuring vendors to send the information in an industry standard format, we're satisfied to have to buy more equipment and software to interoperate with anther vendors hardware. I can't even begin to count the number of applications I've been involved in that use 3 and sometimes 4 different OPC servers, all gathering information 2 or 3 times a second. Not special information. Just information from different networks or hardware. >>Few people want to have a lot of different platforms, for various reasons, >>but primarily reduction of spare parts and training issues. This is sort of >>like an airline having 20 different models and brands of airplanes. They all >>can work together, but the extra spare parts and training issues make it far >>more practical to try to focus on one (or a few) brands/models. Training is a valid issue - and for that reason I suspect there would still be a standard platform or platforms set for the equipment a company would purchase. However, you would not be stuck with that vendor for life. No longer will having $400,000 (US) worth of equipment in your facility [almost] automatically mean they'll get the next refit or upgrade. They would have to truly compete on price and quality because you could choose another vendor and still count on everything working together. If we look back at the topic of this conversation "Trends and how to grow the industry": I suggest the industry is best served, and new opportunities for development and technical innovation will be created when it starts opening up the closets and cleaning out the cobwebs. The amalgam of AB, Siemens, GE, Schneider/Modicon/Square-D/yadda yadda, Honeywell (or is that GEneywell), Fisher-Rosemont, Moore, Opto, and all the others I've forgotten to list are so concerned with guarding their niches in Automotive, Petrochem, pulp-n-paper, specialty chemical, or whatever your flavor may be, that they miss the white-space in between. It's within that white-space that innovation occurs. I would prefer these vendors express the attitude of "we're working to make our industry vibrant and innovative" than "we're working to keep vendor B out of our stronghold accounts/cities". In my opinion, the defensive goals would be better served by innovation and growth... but then what do I know about managing an automation company. :) All those folks come from the sales ranks, and I'm "just" an engineer. ;) Still ranting, Jeff jeffdean@execpc.com

By Willy Smith on 23 February, 2001 - 2:59 pm

Curt, I hear what you are saying, and you are definitely out in space. I can only get away with saying this because I am in a farther orbit...but I'm close enough to wave! If I posted half of what I think on this board, I would be fired, banned from the list, then drawn and quartered ;^) But please keep going. What you are doing, especially with the Puffin Project, is very important. Anyone who goes agains the establishment status quo is going to be laughed at, called a wacko communist or worse, and publicly denigrated. At least you are trying, and you are not afraid to be on the bleeding edge of this Internet revolution. My personal opinion is that the Open Source movement, which to me is so far the intellectual culmination of Internet-enabled technology, is the one single most important facet of this revolution. But just as we would not be able to see the future revolutionary implications if we were living right at the time of the invention of the printing press, we are still too close timewise to see the long-term, larger effects of Open Source. Just remember that when there are large monoliths in the road, it often takes more than one person with a sledgehammer to break them up and get them out of the way. If you get tired or discouraged, put down the sledgehammer and go back to hacking on the keyboard for a while. At some point, either someone with a Cat D9 will come along and help push, or (even more likely) a new superhighway will be built around the mess. Be comforted also that there are other wackos out there. Phil Hughes, the owner of Linux Journal and Embedded Linux Journal, visited me while he was down here in December. He's very excited about open source. I told him about the Puffin Project, and you should be getting some good publicity from ELJ. And he's so wacked out that he's moving down here, too! The innovations don't come from stationary anthills, they come from individuals who see a new path and start walking. Regards, Willy Smith (may not reflect the views of our sponsors) Costa Rica

By Dave Ferguson on 16 February, 2001 - 2:04 pm

I agree with Ralph Just like there are many, car manufacturers, cell phones, VCR's, light bulbs and on and on, because the public demands it...... Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation

By Joe Jansen/ENGR/HQ/KEMET/US on 16 February, 2001 - 5:22 pm

And the public also demands that all those cars use the same fuel. All those cell phones work off of the same towers. (ie: my Nokia can call a Motorola) All VCR brands work with all TV's Light bulbs screw into the same sockets. That's my point. Interoperability between brands. I would be better convinced if you show me different brands of the same product that are completely incompatible. Like PLC's. --Joe Jansen

> All VCR brands work with all TV's > > That's my point. Interoperability between brands. I would be better > convinced if you show me different brands of the same product that are > completely incompatible. Like PLC's. But in the same way that "any" VCR can work with "any" TV, so "all PLC" work the same. I can take PLC from Koyo, Modicon, and AB - each with 8 110vAC input and 8 relay out and they are all interchangeable in the high-level sense. I can swap one out and another in & control will be the same. The 8 inputs relate to the 8 outputs in the same manner. Just like the VHS tape in my VCR shows me the image on the TV. But a Sony VCR is NOT the same to program as an Emerson VCR - that's what all those "magic codes" you need to enter into your Remote mean. Each has thier own proprietary commands and proprietary data and the world keeps turning just the same. The universal remote just uses the "magic code" to handle any specific proprietary details of this one brand of appliance. Sounds like OPC drivers of sorts to me. Maybe we just need to find the lost book of "magic codes" which allow any HMI or programmer to talk to any PLC? Sounds like a quest for Bilbo (sp?) of Tolkien fame. regards - Lynn A. Linse

By Ralph Mackiewicz on 23 February, 2001 - 12:04 pm

> And the public also demands that all those cars use the same fuel. All > those cell phones work off of the same towers. (ie: my Nokia can call > a Motorola) All VCR brands work with all TV's Light bulbs screw into > the same sockets. These analogies aren't very good for a number of reasons (e.g. All cell phones don't work off the same towers. I have a cell phone that only works with SprintPCS. Yes I can communicate with any other phone through SprintPCS but I can't change my service provider because Cingular (or whoever) won't interoperate with my phone). > That's my point. Interoperability between brands. I would be > better convinced if you show me different brands of the same > product that are completely incompatible. Like PLC's. But the critical point is that all of these examples of integration are the norm because the buyers of these products demand it. The vast majority simply won't buy an audio speaker that doesn't have an 8 ohm load with 2 wires (for example). The majority of people who buy PLCs simply don't care if every PLC is made with indentical programming software or an identical communications port. They care that they can implement the job at hand but they haven't been able (or willing) to attach VALUE to uniform standards in the PLC industry for communications (and to a lesser degree) programming software. I personally think that this is short-sighted, but then again, I don't buy PLCs so what do I know? I assume that the people who do buy PLCs are smart enough to buy what is good for them. They obviously think numerous communications standards is not that big of a problem as long as they can buy the products they need for the system they are using at the moment. If buying habits changed towards standards, the majors would all become involved in a massive global conspiracy (aka the "market") to develop and support those standards. Regards, Ralph Mackiewicz SISCO, Inc.

By Curt Wuollet on 23 February, 2001 - 2:17 pm

Hi Ralph Ralph wrote: <clip> .... > But the critical point is that all of these examples of integration > are the norm because the buyers of these products demand it. The vast > majority simply won't buy an audio speaker that doesn't have an 8 ohm > load with 2 wires (for example). The majority of people who buy PLCs > simply don't care if every PLC is made with indentical programming > software or an identical communications port. They care that they can > implement the job at hand but they haven't been able (or willing) to > attach VALUE to uniform standards in the PLC industry for > communications (and to a lesser degree) programming software. I > personally think that this is short-sighted, but then again, I don't > buy PLCs so what do I know? I assume that the people who do buy PLCs > are smart enough to buy what is good for them. They obviously think > numerous communications standards is not that big of a problem as > long as they can buy the products they need for the system they are > using at the moment. If buying habits changed towards standards, the > majors would all become involved in a massive global conspiracy (aka > the "market") to develop and support those standards. The hole in that theory is that no one has offered the option of things that work together. Let me draw an analogy as long as everyone else has :^) A lot of people could really use a basic plain jane get to work car (or truck) All the vendors tell us that's the last thing we want and offer a lot of luxury vehicles and trucks with leather upholstry. And their argument is the same, "We don't sell any of those" This _is_ logical since they don't offer any of those. Chrysler had the last one with their Omni and Horizon America series. They quit making them when they had two lines running and the cars were on allocation and selling over sticker. I'm sure those lines went to producing vehicles with a larger margin. Nothing wrong with that, just don't tell me that's what the "public demanded". Which is exactly the same line they used The truth of the matter is that after people rallied to help them out of their dire situation, they forgot them and went to the same "high margin only" policy as Ford and GM. And the Japanese won't help this time as they (with the help of their Big 3 investors) held the same line. That's why even the low line vehicles are outfitted like the space shuttle. Because "That's what the market demanded" The public can demand basic vehicles all they want but strangely, they buy only what's available. And none at all of the non-existant. Kinda skews the statistics to suit the vendors. Regards cww

> A lot of people could really use a basic plain jane get to work > car (or truck) All the vendors tell us that's the last thing we > want and offer a lot of luxury vehicles and trucks with leather > upholstry. And their argument is the same, "We don't sell any of > those" This _is_ logical since they don't offer any of those. I hate to say it, but the whole car analogy is pretty weak. But the market response is not. The above statement is about as accurate as it gets. The customer doesn't always know what he/she "wants" because the customer doesn't always know what is possible. (why do I feel myself getting flamed for that one) For instance: Cellular phone development started 20 years ago (give or take). Did you know you wanted one? Did you know it was possible? Was the market screaming for wireless phones? Did you want a 24 hours news channel that repeats the same stories every 30 minutes? Was the market for "news" going to revolt without it? Before it was created, did you know you wanted a PLC to replace all your pneumatic and relay controls? Personal copiers? Fax machines? Safety pin? Post-it notes? To my knowledge and recollection, the market for these products were not demanding that the manufactures of these products create them. They didn't even know it was possible, and no one even imagined how these products would change the world when they were introduced. I suggest that, thought the technologies are closely related and in many cases identical, the best analogy is computing. Imagine if your company standardized on IBM PC's... but IBM PC's could only network with other IBM PC's. Further consider if you could only use IBM monitors, keyboards, hard drives, and mice. How difficult would it be to bring a Compaq or Dell computer into your company knowing that it would not communicate with the IBM computers? What if you had to pay thousands of dollars to buy protocol "bridges" so your IBM computers could talk with your Company computers? Insane you say? Well, I say it's insane that AB doesn't talk to Siemens. The advantages to the end user may not all be obvious, but imagine if the majors all shared a common protocols for data and I/O. Systems could then be built with the best equipment, not just what works with the hardware that's already installed. I hope you will spend some time to imagine the new solutions that would be possible, and the opportunity that would ensue if Siemens, AB, Honeywell, GE, and Modicon hardware were all interchangeable without functional loss? I'd be surprised if you couldn't imagine at least a few advantages such as cost savings, availability of spare parts, ability to use another vendors specialty I/O, freedom of choice - to pick the best product at every level and stage of your applications. Real competition in all aspects of the automation system (ever felt raped by the cost of I/O cards? Because they have you locked in to a controller, network, and protocol!). Think about it - I have, Jeff Dean jeffdean@execpc.com

By Bob Peterson on 23 February, 2001 - 2:32 pm

The hole large enough to drive a freight train through in this analogy is that the main reason the car was made was to meet the government CAFE requirements. IIRC, supposedly Chrysler barely broke even on them, even though they were reasonably popular cars. No manufacturer will make anything for any length of time for little or no profit when they can put the same resources to work at something else and make a lot more money at it. And don't blame the car companys for not building stripped down models. There just was very little market for such a vehicle. Even low end car buyers want some of the amenities, and it was far more cost effective for the car companies to make the cars with what most people wanted rather then adding just a few options to every vehicle to satisfy a particular customer. If you look closely at the car market, you will find that no car manufacturer really wants to have a sub-compact high mileage car. They only do it to meet govt CAFE regulations. Bob Peterson

By Curt Wuollet on 23 February, 2001 - 2:46 pm

> The hole large enough to drive a freight train through in this analogy is > that the main reason the car was made was to meet the government CAFE > requirements. IIRC, supposedly Chrysler barely broke even on them, even > though they were reasonably popular cars. No manufacturer will make anything > for any length of time for little or no profit when they can put the same > resources to work at something else and make a lot more money at it. That's exactly the point I was making, public demand has nothing to do with it. The reason we don't have compatibility and interoperability is strictly strategic. > And don't blame the car companys for not building stripped down models. > There just was very little market for such a vehicle. Even low end car > buyers want some of the amenities, and it was far more cost effective for the > car companies to make the cars with what most people wanted rather then > adding just a few options to every vehicle to satisfy a particular customer. That's why the Omni/Horizon were scavenging sales from the high line models? Because no one wanted them? Huh? They were selling like hotcakes. Killing them was strictly strategic also. To push buyers to the creampuffs thay wanted to sell. Same thing in our market, "if no one offers what they want, they'll have to settle for what we want to sell them" > If you look closely at the car market, you will find that no car manufacturer > really wants to have a sub-compact high mileage car. They only do it to meet > govt CAFE regulations. You're not so much refuting my point as reinforcing it. That the consumer gets the options the manufacturer wants to sell. Since the vendors don't want stuff to work together we haven't seen the option, not even by accident. But it's ludicrous to infer that there is no market. Which is what I'm hearing as arguments. In the consulting business, I call that post decision support. That's where you make a decision first and then arrange for the data to support it. Regards cww

By Bob Peterson on 27 February, 2001 - 3:12 pm

> > And the public also demands that all those cars use the same fuel. All > > those cell phones work off of the same towers. (ie: my Nokia can call > > a Motorola) All VCR brands work with all TV's Light bulbs screw into > > the same sockets. > > These analogies aren't very good for a number of reasons (e.g. All > cell phones don't work off the same towers. I have a cell phone that > only works with SprintPCS. Yes I can communicate with any other phone > through SprintPCS but I can't change my service provider because > Cingular (or whoever) won't interoperate with my phone). But as long as the functionality exists to be able to use the product (i.e.-make a phone call) what difference does it make to the user if his cell phone won't work on a different tower? The reason there is little interoperability amongst PLCs is because its not needed, there is no real benefit to it, and no one wants it enough to make it economically viable for PLC manufacturers to do it. > > > That's my point. Interoperability between brands. I would be > > better convinced if you show me different brands of the same > > product that are completely incompatible. Like PLC's. > > But the critical point is that all of these examples of integration > are the norm because the buyers of these products demand it. The vast > majority simply won't buy an audio speaker that doesn't have an 8 ohm > load with 2 wires (for example). The majority of people who buy PLCs > simply don't care if every PLC is made with indentical programming > software or an identical communications port. They care that they can > implement the job at hand but they haven't been able (or willing) to > attach VALUE to uniform standards in the PLC industry for > communications (and to a lesser degree) programming software. I > personally think that this is short-sighted, but then again, I don't > buy PLCs so what do I know? I assume that the people who do buy PLCs > are smart enough to buy what is good for them. They obviously think > numerous communications standards is not that big of a problem as > long as they can buy the products they need for the system they are > using at the moment. If buying habits changed towards standards, the > majors would all become involved in a massive global conspiracy (aka > the "market") to develop and support those standards. > PLC buyers also demand certain standards. For example: 24VDC digital I/O 120VAC digital I/O 4-20 mADC analog I/O Serial (RS232) communications Ethernet capability Modbus capability RLL programming PLC Networking Remote I/O These are the things that users care about. And guess what? All PLC brands support these things in one way or the other. That a Siemens I/O module will not work in an AB I/O rack is not important to any user I know of. The PLC producers will make whatever the PLC buyers will support with their purchases. And the fact that you might have to buy an adaptor "do-hickey" (software and/or hardware) to make your Modicon PLC talk to your AB PLC is not all that significant to most users. If they need the capability, it's available. Most will never need this capability. Bob Peterson

By Dave Ferguson on 27 February, 2001 - 3:33 pm

Agreed: I think that Open is great if economically achievable but I agree, the MAJORITY (and majority rules) of users have one brand of PLC/DCS/HMI and if they have calculated costs(IE training, software, knowledge, support, spare parts, etc.) in their plants, therefore are not that interested in this. This may not be the case in projects such as municipalities, where low bidder rules and therefore there is a kludge of different equipment, but rather than push for open communications standards (which I agree with whether Curt thinks so or not). I vote for ENGINEERING standards whereby you have to justify the total cost of ownership rather than the initial cost of purchase and design and therefore most of these "kludges" are not allowed to happen. This is a bigger issue for INTEGRATORS than for company Maintenance or Engineering because Integrators must know so many different links. And second, when needed because of OEM skids etc......this interoperability is available, even though at a higher price than it would be if they all followed an open protocol. If we got all vendor equipment to talk to all other vendor equipment would be great.....but is it a top 10 concern of mine to which I would die for............no way. I agree, there is much pain to set up and "Engineer" these links but it is usually a one time cost that amounts to maybe 5k out of a 2-30 million project for me it is chicken feed, and once set up, I usually never touch them again. We have 100's of these "proprietary" links for "Control" to "top floor" systems as well as "Control" to "Control" due to a number of OEM type stuff and the reality for me is, I rarely have to work on them once running and if well Engineered (IE Documented), the rare occasions when I do work on them, it is very little time. And since adopting a standards on AB equipment there is less and less of this hastle for me and our costs are down (the truth hurts). Again Open communications would be great but in my day to day fight with the systems world, it barely hits my radar.......sorry. Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation

By Curt Wuollet on 27 February, 2001 - 3:49 pm

Hi Dave, Believe it or not, I agree with you! (for a 20 or 30 million dollar project) But the bulk of the growth potential is in those projects which can not be economically addressed at present. Providing this sort of versatility in the base set or as a low cost option (if there is such a thing in this business) would open up a window of opportunity especially for applications where it is not feasible to rip out everything you have now and replace it all from a single vendor. Compatibility would allow justifiable "best of breed" solutions to be built. We both agree we need standards and commonality. Also I think it would be disasterous to apply ENGINEERING standards to the automation business as practiced. Engineering standards would disallow single sourcing, dependance on obscure technology and many other features of the status quo and require acceptable quality, reliability, and cost/value standards. In many cases, a strictly engineered solution would not involve PLC's, Windows, or the most expensive components on the face of the planet. Be careful of what you wish for. Most of the rationale for "off the shelf" is _avoidance_ of engineering, these are tools for relative amateurs as evidenced by the fact that marketing is more important than specifications and Windows compatibility is more important than reliability. RLL is not a BSCS tool. Regards cww

By Bob Peterson on 27 February, 2001 - 3:59 pm

> Most of the rationale for "off the shelf" is _avoidance_ of engineering, > these > are tools for relative amateurs as evidenced by the fact that marketing is > more important than specifications and Windows compatibility is more > important than reliability. RLL is not a BSCS tool. > > You got it part way right. The off-the-shelf stuff is designed to allow the guy on the floor at 3 am to debug and fix problems. Thats why its RLL based, and not C++. If the only criteria was that it worked and got out the door as cheap as possible, a lot of things could happen. BUT, there are other criteria. One of the big ones is maintainability in the field. RLL has proven to be the only practical solution (at least so far) for 100% uptime. I am unaware of any other solution that allows one to modify the program on the fly, without requiring a reboot, or a program restart. Windows compatability is not only important, it is CRITICAL for most plants for PCs. The reason is that most people can already use Windows, and no additional training is required. Allowing other operating systems to come into play adds another layer of training that is needed. If Linux can be put in a factory floor machine, why not a Commodore 64 (as long as it has ethernet)? Or some other operating system? If the ONLY criteria is that they can somehow talk via ethernet in some reasonably straightforward way, you are allowing absolute chaos on the factory floor. Bob Peterson

By Curt Wuollet on 28 February, 2001 - 12:27 pm

PETERSONRA@AOL.COM wrote: > In a message dated 2/26/01 4:05:40 PM Central Standard Time, > listm@CTHULHU.CONTROL.COM writes: > > > Most of the rationale for "off the shelf" is _avoidance_ of engineering, > > these > > are tools for relative amateurs as evidenced by the fact that marketing is > > more important than specifications and Windows compatibility is more > > important than reliability. RLL is not a BSCS tool. > > You got it part way right. > > The off-the-shelf stuff is designed to allow the guy on the floor at 3 am to > debug and fix problems. Thats why its RLL based, and not C++. If the only > criteria was that it worked and got out the door as cheap as possible, a lot > of things could happen. BUT, there are other criteria. One of the big ones > is maintainability in the field. RLL has proven to be the only practical > solution (at least so far) for 100% uptime. I am unaware of any other > solution that allows one to modify the program on the fly, without requiring > a reboot, or a program restart. The reason you don't know of any other solutions that allow this is that you have never been presented with another solution that allows it. Underneath it all I would bet the PLC is coded in C, so obviously it's possible to have other solutions. And cheap as possible has nothing to do with the open discussion. If the present vendors were to release their source code, would that suddenly make their products somehow shoddier or less in any way than what they are? Trying to equate free and open with cheap and shoddy is not a technical argument. There is absolutely no reason that the same product could not be built either way. In fact the _demonstrated_ quality of OSS tends to be better due to peer review. > Windows compatability is not only important, it is CRITICAL for most plants > for PCs. The reason is that most people can already use Windows, and no > additional training is required. Allowing other operating systems to come > into play adds another layer of training that is needed. If Linux can be put > in a factory floor machine, why not a Commodore 64 (as long as it has > ethernet)? Or some other operating system? If the ONLY criteria is that > they can somehow talk via ethernet in some reasonably straightforward way, > you are allowing absolute chaos on the factory floor. Who is allowing what? If by that you mean the customer would have options, Yes, absolutely! They are the ones paying for a solution. If you can't sell Windows World or BIGBUCKS on it's merit then they _should_ have options. If those things you mention are absolutely CRITICAL, they would do the right thing,....wouldn't they? Who is this authority that is deciding that they should have no choice? If you are implying there can be no good solution other than the status quo, that's absurd. Regards cww

By Dave Ferguson on 28 February, 2001 - 4:42 pm

Curt Wuollet wrote: >>Believe it or not, I agree with you! (for a 20 or 30 million dollar project) That was 2-30 Million...........(small $18 Million point of contention) Dave

By Anthony Kerstens on 23 February, 2001 - 12:05 pm

Actually, not all VCR's work with all TV's. There is NTSC and PAL. That's why there are services around for video conversion. And then there's also the coming HDTV and web based media. And then DAT, CD, MP3, and that old 8 track I have in my basement. Looks to me like consumer electronics is just as confused as automation. Anthony Kerstens P.Eng.

> > >The Automation vendors, they are expert at > > >preventing systems integration. > > I don't know how to say this nicely: To believe that automation > vendors sit around thinking about ways to "prevent" systems > integration is delusional (I'm glad I toned that down). Automation > vendors may not care whether they can provide integration for other > peoples products. And, they may not care whether they support public > non-MS standards. But, there is no purposeful effort (aka conspiracy) > to screw users. If they are too stupid to see the benefit that > promoting industry-wide interoperation would bring to their company > they are also too stupid to coordinate a massive global conspiracy as > well. I think someone recently explained it better by pointing out > the silly and counter-productive bureaucratic structures that exist > at some of these vendors. That I could believe. What was that "flavor" of Occam's Razor: Never attribute to malice what could be equally attributable to stupidity. (one of my personal faves)

By Michael Jewell on 23 January, 2002 - 11:00 am

The issue with each manufacturer trying to maintain a seperate bus and getting you to buy all of one manufacturer's product is of course
driven by the bottom line. If you have to use all of one company's hardware they will be more profitable.
It looks on the surface that the PC industry is an ideal to "fix" our industry (System Integration) but it fact the companies that make PCs are bleeding money and are falling off the cart as we progress and soon we will have only monsters of industry left.
I really don't think that we want to see only the big two left in Automation.
As an engineer dealing with System Integration daily I can say that it has gotten tons better and there are some bright spots like Profibus
which is not a company owned standard but is owned by a society. Almost all manufacturers are offering Profibus. And on the signal side
almost all are standarized to 4-20ma and -10 to +10 VDC. So it isn't that bad.
Also there is the issue of distributorships if you can not sell AB competitively but it is the US standard what do you do? Sell whoever is
willing to give you competitive pricing in your area.
Just some thoughts provoked by your acticle. I sounds good on the whole but the end result might end like the PC business..
Mike