In 1997, I sold the 250 shares of Microsoft I’d bought about a year earlier. Today, I would have about 4,000 shares. Hindsight is a wonderful thing. Ten years ago we asked: “How will users be programming control systems in the future?” After all, we were led to believe the control systems of 2007 surely would be completely open systems, using open software, and standards-based programming.
Advanced control programming software and HMI were migrating to Windows in 1997. It was a common phrase around the trade show floor—bad Windows-based software is still bad software.
The PLC market understood that notion, placed huge connectivity and speed resources into a PLC enclosure, still called it a PLC, and sold the end user on it. Some of us decided to call it a programmable automation controller (PAC).
We covered promising news about IEC-61131 programming languages, which today is not the force in North America most of us thought it could be 10 years ago.
Open and Shut Problems
This caused a few print conversations with and about machine builders lulled into believing “plug-and-play” might be easy. The question, nicely summarized in Al Vitale’s OEM Insight column, “Who You Gonna Call? ” Aug. ’98, asked who was responsible for an “open” system constructed from the “open” components of multiple vendors. The IT groups were having some success, but Vitale reminded us, “Industrial automation isn’t about word processing, spreadsheets, or missing a payroll. Faulty controls can kill people. This lands us squarely on the issue of system responsibility.”
Beyond buying from just one “open” vendor, this issue hasn’t approached any type of closure.
In Feb. ’99’s cover story, we looked at Windows CE, finding the non-deterministic 2.0 version “Not Quite Ready” for prime-time machine control, but recognizing the real-time potential that V. 3.0 was to have when released later that year. It was released in mid-2000, and we gave it a promising critique in that year’s October issue.
Y2K? Y Worry?
And for all the discussion about advanced controls, spending money on “fixing” Y2K was a great frustration for many. This was well illustrated in an Apr/May ’98 news story, “User Question Stuns and Silences Experts at Year 2000 Forum,” in which we reported how a controls user grilled experts at an Automation Research Corp. Forum discussion of Y2K. “If the engine chip in my Ford Explorer had a date function problem, the car manufacturer would recall the car, replace the chip for free—even though they didn’t build the chip—and say it was sorry for the inconvenience. He wouldn’t tell me I have to buy a new car! Why don’t [control vendors] do the same thing rather than stick us with the problem?” Audience applause and subsequent murmurs of disagreement with the panel’s answers made it clear that the guy struck a very sensitive nerve.
The Y2K “problem” turned out to be not much of a problem, and more of a good excuse to upgrade the controls. In that same issue, we passed on some web postings of “Y2K’s Unforeseen Perils.” Among the best: “Unexpected demand for COBOL programmers causes severe understaffing of fast-food restaurants.”
Tools Take on new Tasks
In June/July ’99, “Software Glue” reported on the uptick in the use of Visual Basic for Applications for HMI, connectivity, and integrations issues.
“In typical fashion,” we wrote, “Microsoft has taken the original BASIC language, and made it complex and difficult to understand.” We also found that “in a very few instructions it can perform functions that would have required major software projects not long ago.” But in 1999, we saw that “VBA suffers from the same problem as most of today’s PC software. The terminology needed to describe it can be difficult to get a handle on. Explanations of VBA use terms —API, COM, OLE, OPC, ActiveX, objects, and ODBC—we don’t fully understand.”
Likewise, the “Signal Processing at Warp Speed” TechFlash column, Feb. ’04, was one of our first looks at field-programmable gate arrays (FPGAs) as a practical, user-programmable chip that eases how users can customize I/O. This decades-old technology and its cost had improved enough for Dan Hebert to report that, “FPGAs allow OEMs to eliminate speed as a design constraint, and iterative design becomes a given because FPGAs can be reprogrammed.”
The packaging industry was responsible for a lot of development, too. The OMAC packaging group has been very active in user-based specifications for machine control based on motion control. One new story, “The OMAC Beat Goes On,” June ’01, noted the formation of OMAC’s PackML subcommittee with the goal of collecting machine state conventions, tag name conventions, and machine state definitions to arrive at a common set of OMAC-recognized naming conventions for all to use.
OMACÂ’s 2006 survey of packaging automation users also found 79% still use ladder logic for the majority of their control systems.
If anything can be said about the state of machine control today itÂ’s that it progresses slowly, but steadily toward a true system that allows users to choose their weapons and sleep at night.
