C
Curt Wuollet
Hi RA
Glad you brought up these points. For starters I don't do billion dollar systems. Not that the the technology wouldn't handle it, but it would require a different approach and much more resources. I don't follow some of your arguments at all because each and every company obviously had _someone_ design and build their equipment and write the software. To put it out of the range of human possibility for me to do the same, at least as well, is simply without basis. If I were working for a megacorporation, would what I do during the day be vastly superior to what I do at home? I can laugh for two reasons. First, I've been in a megacorporation and second, the
complexity of the equipment we're talking about, compared to state of the art electronics, leads me to think that you have been mislead. Or to put it another way, if an idiot like me can design fairly robust optoisolated IO for $3.00 a point, how hard can it be? Take for example, the MAT/LPLC project. I am, perhaps, the least
qualified person on the project, being just an old *nix hacker who's done some hardware. Do you really think they have better staff?
Now, to your points.
> There seems to be a serious disconnect among those who want to "roll their
> own". Homemade PLCs, HMIs, SCADA systems, etc., may indeed have a lower
> upfront price. However, the long term and ongoing costs of these things are
> almost never discussed by the proponents of such things.
Elucidate please, how would they be more expensive long term. This is FUD. I would be happy to discuss them in detail. I can't see any possible way that we could be more expensive than forced upgrades, planned obsolecense and the other nickle and diming costs of the status quo. Nickles and dimes being of course, an understatement.
> Someone who shall remain nameless, but who posts here regularly, claims he
> saves his customers a "lot" of money by doing his own thing in Linux. And
> tech support is only a phone call away (to him). The problem with this
> approach is that if he gets run over by a truck, there is no more tech
> support available at all. That was the real problem I was trying to get
> at in my original post, not that VB was good or bad.
I would assume that to be me, and this is a very important point. I'll answer it simply this way. Pick even the most prevalent toolset in the
automation market. Hell, add all these folks together. Then compare this to the number of people who can understand and fix my plain old C code when the source is available. No contest. Any electronics tech can repair the hardware, it's really very simple and mine is documented with full schematics. As far as I know, none of the competition is field repairable beyound swapping boards or modules. And you often swap those spendy boards or modules instead of replacing a 49 cent IC. If downtime is an issue,
you can afford a lot more spares. And generic PC equipment is cheap and readily available for the rest. If, as we are, you are doing ongoing
development, the spares are in house already. And this stuff will be always be supportable, no one can cut you off or force an "upgrade". The application situation is no different than if you were to be run over by the proverbial bus. Except the C guy would probably figure out what I was doing faster than say, a bunch of State Logic or a whole new proprietary toolset.
> With off the shelf items supplied by companys with a history of supporting
> their stuff, there is a support path. There is also a pool of qualified
> people available to service and support it. With the homebrew crowd, there
> is typically a guy working out of his basement. Who are you going to trust
> with your next $1 billion plant?
I'll ask you that next time your vendor obsoletes a product. Also see above.
> These systems do not go out in the world for a few months. They often run
> for many, many years. What happens to the end user when the homebrew control
> system dies 5-10 years down the road and the designer is no where to be
> found? Or the parts he used can no longer be procured?
See above. Also, I use no unmarked IC's, ASIC's, potted modules, FPGA's etc. Every part I use can be procured from hundreds of electronics houses.
Which do you see as more likely to become unavailable? And my stuff becomes cheaper as the years go by.
> Thats why smart plants rarely care about the upfront costs of the control
> system. Its usually such a small part of the overall cost of a system, that
> little bit of upfront savings is dwarfed by the long term costs, not the
> least of which is loss of production. A one hour outage in a car plant can
> easily cost them a $1 million worth of production. If they go down and can't
> repair it quickly because the designer is not answering his cell phone right
> this second, you can bet that the control system will be out the door as fast
> as they can get it replaced.
They will be much happier if they can repair it quickly and inexpensively without picking up the cell phone. And a plant of that size would almost
certainly have the people on staff to do it. That's why a lot of them roll their own.
And it's true that some situations will favor one or the other. And if you have no skilled staff, the package approach can be better. But it's also true that my stuff has greatly simplified some designs by doing things that packaged stuff simply can't do without lots of kludging and the uptime and mttr has been less of an issue than with the packaged parts of the system. I would settle for both being viable approaches to be used where most appropriate. At least I don't resort to using FUD like the packaged system vendors do. I simply show where I can do it
cheaper faster and better with equipment designed for what we do and point to the fact that the unfounded fears have never been realized. It's madness to try and argue that highly specialized, low volume, and secret proprietary stuff is gonna be easier to support than generic and open stuff. That simply defies reason. But still, the FUD works.
Regards
cww
>
> Bob Peterson
>
Glad you brought up these points. For starters I don't do billion dollar systems. Not that the the technology wouldn't handle it, but it would require a different approach and much more resources. I don't follow some of your arguments at all because each and every company obviously had _someone_ design and build their equipment and write the software. To put it out of the range of human possibility for me to do the same, at least as well, is simply without basis. If I were working for a megacorporation, would what I do during the day be vastly superior to what I do at home? I can laugh for two reasons. First, I've been in a megacorporation and second, the
complexity of the equipment we're talking about, compared to state of the art electronics, leads me to think that you have been mislead. Or to put it another way, if an idiot like me can design fairly robust optoisolated IO for $3.00 a point, how hard can it be? Take for example, the MAT/LPLC project. I am, perhaps, the least
qualified person on the project, being just an old *nix hacker who's done some hardware. Do you really think they have better staff?
Now, to your points.
> There seems to be a serious disconnect among those who want to "roll their
> own". Homemade PLCs, HMIs, SCADA systems, etc., may indeed have a lower
> upfront price. However, the long term and ongoing costs of these things are
> almost never discussed by the proponents of such things.
Elucidate please, how would they be more expensive long term. This is FUD. I would be happy to discuss them in detail. I can't see any possible way that we could be more expensive than forced upgrades, planned obsolecense and the other nickle and diming costs of the status quo. Nickles and dimes being of course, an understatement.
> Someone who shall remain nameless, but who posts here regularly, claims he
> saves his customers a "lot" of money by doing his own thing in Linux. And
> tech support is only a phone call away (to him). The problem with this
> approach is that if he gets run over by a truck, there is no more tech
> support available at all. That was the real problem I was trying to get
> at in my original post, not that VB was good or bad.
I would assume that to be me, and this is a very important point. I'll answer it simply this way. Pick even the most prevalent toolset in the
automation market. Hell, add all these folks together. Then compare this to the number of people who can understand and fix my plain old C code when the source is available. No contest. Any electronics tech can repair the hardware, it's really very simple and mine is documented with full schematics. As far as I know, none of the competition is field repairable beyound swapping boards or modules. And you often swap those spendy boards or modules instead of replacing a 49 cent IC. If downtime is an issue,
you can afford a lot more spares. And generic PC equipment is cheap and readily available for the rest. If, as we are, you are doing ongoing
development, the spares are in house already. And this stuff will be always be supportable, no one can cut you off or force an "upgrade". The application situation is no different than if you were to be run over by the proverbial bus. Except the C guy would probably figure out what I was doing faster than say, a bunch of State Logic or a whole new proprietary toolset.
> With off the shelf items supplied by companys with a history of supporting
> their stuff, there is a support path. There is also a pool of qualified
> people available to service and support it. With the homebrew crowd, there
> is typically a guy working out of his basement. Who are you going to trust
> with your next $1 billion plant?
I'll ask you that next time your vendor obsoletes a product. Also see above.
> These systems do not go out in the world for a few months. They often run
> for many, many years. What happens to the end user when the homebrew control
> system dies 5-10 years down the road and the designer is no where to be
> found? Or the parts he used can no longer be procured?
See above. Also, I use no unmarked IC's, ASIC's, potted modules, FPGA's etc. Every part I use can be procured from hundreds of electronics houses.
Which do you see as more likely to become unavailable? And my stuff becomes cheaper as the years go by.
> Thats why smart plants rarely care about the upfront costs of the control
> system. Its usually such a small part of the overall cost of a system, that
> little bit of upfront savings is dwarfed by the long term costs, not the
> least of which is loss of production. A one hour outage in a car plant can
> easily cost them a $1 million worth of production. If they go down and can't
> repair it quickly because the designer is not answering his cell phone right
> this second, you can bet that the control system will be out the door as fast
> as they can get it replaced.
They will be much happier if they can repair it quickly and inexpensively without picking up the cell phone. And a plant of that size would almost
certainly have the people on staff to do it. That's why a lot of them roll their own.
And it's true that some situations will favor one or the other. And if you have no skilled staff, the package approach can be better. But it's also true that my stuff has greatly simplified some designs by doing things that packaged stuff simply can't do without lots of kludging and the uptime and mttr has been less of an issue than with the packaged parts of the system. I would settle for both being viable approaches to be used where most appropriate. At least I don't resort to using FUD like the packaged system vendors do. I simply show where I can do it
cheaper faster and better with equipment designed for what we do and point to the fact that the unfounded fears have never been realized. It's madness to try and argue that highly specialized, low volume, and secret proprietary stuff is gonna be easier to support than generic and open stuff. That simply defies reason. But still, the FUD works.
Regards
cww
>
> Bob Peterson
>
