Programmable controllers: How it all began
By Dick Morley
This is the 40th anniversary of the beginning of the programmable logic controller (PLC). It started in 1968 and is a real-time device that acts as the modem to your process. It is not part of the computer.
My work from 1954 to 1964 was working in specialized projects such as aircraft and memory for computers. I sat in a back room and made sketches, diagrams, and reports. On New Year's Day 1968, I outlined a device to get rid of all the projects I have ever worked on. The philosophy of such a project had to be definitive; factory floor and electrical technician- and electrician-oriented. It had to accept heat, never fail or be turned off, substantially over-engineered, and be Coke proof. Also if I did it right, it would make money for me while I slept nights instead of sitting there at my desk. That was the hardware.
The philosophy of the inside system was the device would take a snapshot of the process, then process the interrelationships between the components, needs, and logic of the process, and ship the results of that analysis back out to the process.
In other words, it would take a snapshot at a time rather than continuous solutions. I had hoped this would take care of the inter-modulation effects, namely, the interaction of two events that lead to oscillations and strange phenomena associated with the older ideas of control software.
The memory had to be exquisitely reliable. At that time, we used a thing called core memory threaded on copper wires. This was sufficient for all our needs. They tried to sell me low cost, cheap, fast-core memories, and I suggested otherwise. Claude Shannon's equation in 1948 suggested that reliability and bandwidth are a function of signal -to-noise ratio. I wanted the signal to be strong enough to be resistant to external magnetic and electrical fields.
The hardware had to have no fans with all conductive cooling, sealed, spark immunity. And each of the circuit boards (there were three at the time) would view the world thermally through a copper sheet. Between each printed circuit board there was a copper sheet that conducted the heat to the outside world.
In addition, the hardware had to look good to manufacturing, be power- and voltage-insensitive, rugged, and high priced. I knew then cost was a bad word. We believed our user would want total value, not entry costs. If the programmable controller saved one month of factory up-time, it was worth a million dollars.
The software was designed for the problem, to be implemented by the electrician, and resulted in an adversary relationship with academics. The academics wanted to build microsecond performance while forgetting about quantum theory. The quantum effects of a factory are rather simple. There was a pulse of power every eight milliseconds in the U.S. Nothing can occur any faster than that other than very special processes. Again, the 80/20 rule applies: 20% of the effort will solve 80% of the problems.
The aim of the programmable controller was all relays cannot excite themselves in less than the power cycle process. If you think about it, 25 to 50 Hz is very high speed for bandwidth performance in a factory. All I had to do was make sure all problems, independent of load, did all their processing during that lump of energy in the power line. We were coupled to the environment and the electrician, not to the dream of higher bus bandwidth inside the computer.
The language, besides being fast enough, had to satisfy the hard real-time performance. This means each execution had to be accomplished in the same vision time as it happened the last time, independent of excitation which totally ruled out interrupt structures.
The language had to be robust and never need repair. Instead of a go-to language, we made it come-from logic, or rather a whole sequence of if/then statements with only four references per line.
One or two contacts are useless, three are the minimum, and I threw in an extra one to make four. It is called relay logic. I do not know where the original relay logic came from, but most diagrams with banks of relays had logic diagrams that I believed were developed by the Germans. It represented symbology for relays open and closed. All these lines of logic had to be standalone with no interrupt. And though everyone argued for Boolean, none of the electricians understood Boolean. They did understand relays. The scan was content independent of activity.
Conventional logic in software then (and still today) means there is a single track or flow chart that if one of the components fail, the whole system grinds to a halt. Modern object-oriented software systems have independent operations. We used this same approach in 1968 to make sure that when a single independent operation failed for some reason, all the other operations continued on.
In marketing, we decided this was not a computer. Although we used computer science for design, we had to erase every reference to the word computer. We erased the blackboards and took the paper away from people if the word computer was on it. We had to be real jerks. Language and names carry baggage, and we had to eliminate the baggage.
Hitting the market
We made our first sales trip going up to Bryant, in Springfield, Vt., and the first programmable controller was in my old self-repairing Pontiac's trunk. They opened the cover and said it was wonderful. "It's not another piece of pastel-colored sheet metal."
At that time, we did not know what we had built. We just wanted to get rid of a problem that had plagued me for four years in specialized systems. It turned out to be a box of relays that could do the complexity of relays in the ease of understanding of relays. The language was constrained-you could not expand it.
What it did for the customer was reduce the time to market from months to weeks on a Greenfield project, and maintenance was really low-it runs forever. We got our original money from one of the founders of Digital Equipment Corp. who was making, or so they thought, a competing product.
Manufacturing was easy. Since we had no cost constraints, only value constraints, each unit was tested in a high-temperature box and could be jabbed anywhere with a genuine spark generator and keep running-it was always on.
We developed a programmable controller independent of anyone else. If we had known General Motors had a specification out and Digital Equipment had their PDP-14, we possibly would have never started the PLC story. Even though we are from MIT, we are not that dumb.
We started it with a cold specification without paying any attention to the specifications of the users. Our first big customer was General Electric. They made an over-the-transom request to buy our units on an OEM basis. GE would private label our units for their own use. This was early on in the company, and it was a million dollar order. The first one was delivered to Landis, Pa. Our biggest market development early on was in Japan with Yaskawa and Toyota. The units were called 084, 184, 284, and so on, because hypothetically it was the 84th project in Bedford Associates; our original contracting firm founded in 1964. The 084, was designed by the original team and did not sell well. Professional marketing and engineering then came in and made it a winning unit and program called the 184.
About the Author
Dick Morley (firstname.lastname@example.org) is widely known as the father of the programmable logic controller, or PLC.
Basic PLC architecture
By Kelvin Erickson
The main components of a PLC are the processor module, the power supply, and the input/output (I/O) modules. The processor module consists of the central processing unit (CPU) and memory. In addition to a microprocessor, the CPU also contains at least an interface to a programming device and may contain interfaces to remote I/O and other communication networks. The power supply is usually a separate module, and the I/O modules are separate from the processor. The types of I/O modules include discrete (on/off), analog (continuous variable), and special modules like motion control or high-speed counters. The field devices are connected to the I/O modules.
Depending on the amount of I/O and the particular PLC processor, the I/O modules may be in the same chassis as the processor and/or in one or more other chassis. Up until the late 1980s, the I/O modules in a typical PLC system were in chassis separate from the PLC processor.
In the more typical present-day PLC, some of the I/O modules are present in the chassis that contains the processor. Smaller PLCs are often mounted on a DIN rail. The smallest PLCs (often called micro-PLCs or nano-PLCs) include the power supply, processor, and all of the I/O in one package. However, for many micro-PLCs, the amount of I/O is limited and not expandable.
Within the context of an automation system, a PLC's I/O modules could be in the same chassis as the processor. A typical medium-sized PLC installation can place the PLC processor, I/O modules, power supplies, and wiring terminal blocks within a cabinet. There are also fuses or circuit breakers, one or more per input or output module for protection of the I/O module circuitry. A cabinet is typically assembled and wires at a location away form the process. When ready to install, the cabinet comes to the plant location, and only the plant power and field devices need to connect to the other side of the terminal blocks.
SOURCE: Programmable Logic Controllers; An Emphasis on Design and Application, by Kelvin T. Erickson, 2005.To order, visit www.isa.org/books.