The Language of Choice
I have a few comments about your story on higher-level languages [“Higher Ground—Part I”].
The big trade-off: For almost anything we use in life—tools, programming languages, appliances—there is an inverse relationship between ease of use and flexibility. In programming, assembler can do anything, right down to the metal, but it is hard and hazardous to use. LabView is very much easier to use, but it can’t get really down and dirty.
Know your domain: Closely related to the ease/flexibility issue, a language can be more and more powerful, but only for a narrower and narrower application domain.
Reusability: In 40 years of making embedded controls, I find each new project to be sufficiently unique. I might reuse techniques, but not reuse actual code. One pratical way I see for code reuse is with design-time configurable software components. These are a step further up the ladder than library routines, because they come with property sheets used by the application programmer to tailor the properties and, within bounds, behavior to a specific use. This is a big part of how graphical design environments work.
Horses for courses: I think arguments about which language is best are meaningless without the “for” clause—Language X is best for .... In many control projects, there is a mix of tasks that might require a mix of languages for a cost-effective and reliable solution. In some aspects of programming, assembler is the best tool; maybe we should call assembler a high-level language for I/O drivers and ISRs. A good state machine programming tool is indispensible for reactive controls.
A cabinet maker uses an array of tools to build a chair, selecting the right tool for each task. A wise controls programmer will carry an array of languages in her tool kit.
David Stonier-Gibson, managing director,
SPLat Controls
Cost Benefit
To further Helge Hornis’ April issue comment on Dan Hebert’s article [“How to Build an Automation Professional,” Feb08, p38; www.ControlDesign.com/buildone], I don’t want to be the cheapest, but I do like to be the best. It’s very important to provide the education and the hands-on training for the many control devices available today. It’s like learning to drive a car—you can read and learn everything there is to know about a car, but until you actually get behind the wheel and experience it, that knowledge doesn’t mean too much.
Education and practical application are key to becoming the best. I have no problem paying for something if I feel I get the best bang for the buck.
David Fisher,
senior electrical engineer,
Forest City Technologies
Smarter Than the Boss
I enjoyed Pollard’s column on new technologies and legacy systems [“A New Beginning,” Oct08, p31]. I really envy that sort of process. I work for a industrial Allen-Bradley integrator in Iowa, where I’m the lead IT and automation solutions provider. Basically, everyone comes to me to find out how to do something.
Regrettably, the owner is about 15-20 years behind in keeping up with newer technology. Bringing new technology into a job is like teaching an 8-year-old C# programming. He just doesn’t understand it or realize why we need it. He’ll be on a job 120 days to create ladder and do installs using very old polling radios. It’s actually kind of laughable how he cobbles together his old ideas not knowing how it really could be. I could do what he does in four days with newer technology.
When he hears about simple-to-implement technology like Ethernet connectivity with RSLogix5000, he looks like a deer in headlights. And, let’s not forget the 300% markups he charges for all of these old implementations he installs. Our boss hates when I tell him that something is a legacy product. Of course, we use laptops that are around 10 years old. What does that say?
Brian Boothe, IT administrator,
PLC solutions provider,
company name withheld by request
