Trends and how to grow the industry

B
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
 
C
> 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
 
C
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
 
J

Joe Jansen/ENGR/HQ/KEMET/US

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
 
B
> 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
 
W
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
 
C
[email protected] wrote: > In a message dated 2/23/01 9:02:36 AM Central Standard Time, > [email protected] 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
 
> > >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)
 
B
> > 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
 
D

Dave Ferguson

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
 
M

Michael Griffin

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

Johan Bengtsson

> 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: [email protected] Internet: http://www.pol.se/ ----------------------------------------
 
H

Heavner, Lou [FRS/AUS]

>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)
 
C
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
 
B
> 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
 
C
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
 
C
[email protected] wrote: > In a message dated 2/26/01 4:05:40 PM Central Standard Time, > [email protected] 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
 
B
> 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
 
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 [email protected]
 
C
> From: [email protected] > > > > 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
 
Top