An advantage of the “aged”, a group I have now accidently joined, is memory and experience.
One of the very clear memories for me was the introduction of PCs to factory floor environments in the late 80s and early 90s. It was a heady time. There were people that were certain beyond reasonableness that PCs were going to destroy the PLC business. That PCs would run everything and it was only a matter of time until the world dumped PLCs in the ash can of history.
These people had some interesting arguments. One was price. PCs could be had for thousands and thousands of dollars less than PLCs. And there was a continuous downward trend on prices and increased performance. PCs had enormous resources compared to PLCs. Lots of memory for the day. Sometimes as much as 640K and then a few Megabytes!) The programming environment offered more common programming tools than PLCs. The trend was clear – PCs were going to dominate.
Well, obviously that didn’t happen. And for good reason. PCs were built to the lowest (and cheapest) common denominator. If you were building a machine to last more than 12 months, a PCs would be one of the last things to put on the machine. It wouldn’t last and probably wouldn’t be available in that configuration in a very short time. And the programming environment just didn’t lend itself to the same structured, tried and true mechanisms available in ladder logic.
But mostly, there wasn’t a good way to get I/O into the machine. Remember, this was before any Ethernet had hit the factory floor. It was before EtherNet/IP, Modbus TCP or even DeviceNet or CAN. A little bit of serial was all there was.
So PCs didn’t replace PLCs but people quickly found that they could be very useable for lots of important applications. They were a great tool for building applications that could synthesize and display data in unique ways. Ways that vastly exceeded the limits of HMIs of the day. They also could process algorithms that were beyond the resources, bandwidth and programming capabilities of PLCs.
All that was needed was a way to import factory floor data and get that data into these applications. That’s where DDE (Dynamic Data Exchange), the topic of my last few blogs came in. DDE looked like the lifeline to factory floor data. Write one application that can read and write I/O or data to a factory floor device or a PLC and send that data to one or more applications using DDE.
Well, that didn’t work as well in practice as in concept. DDE was bandwidth limited and Windows in those days (early 90s) wasn’t stable and reliable. Good attempts were made but these systems were not stable, reliable or easily modified. It became expensive to maintain even the simplest of systems.
And it didn’t work over any kind of network. DDE was strictly internal to Windows. Wonderware’s SCADA software eventually solved this problem by creating NetDDE but it was only part of the battle.
One of the huge cost accelerators was the drivers to interact with different factory floor devices. Want to bring scale data in? Well, implement a scale protocol. Need Allen-Bradley PLC data? Well, implement that protocol. Major time and effort went into all these drivers that were often poorly written, buggy, and often proprietary.
That’s the environment that led to the next step in the evolution of Windows for Automation – Ole for Process Control (OPC).