Controlling the controllers

Citation

Loughlin, C. (2008), "Controlling the controllers", Assembly Automation, Vol. 28 No. 1. https://doi.org/10.1108/aa.2008.03328aaa.001

Controlling the controllers

PLCs have been around for a long time. The first time I ever used one was in 1977 and they were well established by then. The programming was achieved by using a system called ladder logic which was in itself a bit of a revelation at the time as I was then more used to controlling equipment by sending eight bit binary numbers to one of the output ports on a Z80 microprocessor.

The theme of this issue is “Programming languages for assembly and automation” and the idea is that we review how programming languages have changed over the years and what languages are currently popular. It would be easy to assume that programming languages for automation had gone the same way as programming languages in general – or in other words re-useable object-oriented modules that define the characteristics of a given device that you can feed with various commands and which reply with one or more responses. The “device” can be anything from a graphics chip that is used to display data on an LCD display to a servo axis of a robot arm. However, the big difference between computer programs that control spreadsheets or accounts or the latest 3D games and those that control automated systems is that the automated systems control the movement of real parts that have mass, velocity, and inertia. These differences mean that things do not happen instantaneously and as a result the timing of software programs becomes all important.

My Z80 was programmed in assembler or machine code and every instruction took a precisely defined time to execute because the system “ticked” at a rate defined by a crystal controlled oscillator. The result was that you were in total control of the whole system and new exactly what would happen and when. Interrupts that were prompted by some external event did add a slight diversion, but you still knew that they were happening and could plan and reschedule accordingly.

PLCs running ladder logic greatly simplified the programming required but were quite a bit slower in operation and while a machine code program might test for a certain input every microsecond the PLC was running much slower and could have a response time that was in the milliseconds. This much slower response time did not matter at all if one was simply monitoring some pushbuttons and opening a valve or two; however if you were trying to control a moving object then unacceptable errors or variance could render the PLC unsuitable for the application.

One really good thing about both Z80 microprocessors and PLCs was that they worked as soon as they were switched on and were extremely reliable and predictable. As a programmer you felt totally in control and any software bugs were readily corrected.

Current state of the art languages such as Visual C run on Windows or Vista-based PCs, and although these enable you to quickly put together highly sophisticated programs with excellent graphic displays, the programmer is several steps removed from what is actually happening and when. Also the program can take a minute or worse to get running from the time that it is first switched on and in that minute, the states of various inputs and outputs may not be rigorously defined.

It is usually possible for the programmer to add in extra code to ensure that events are synchronised correctly but this coding adds considerably to the systems overall performance. Basically, the programmer is forced to take extra measures to overcome the problems caused by the operating system rather than being helped by it as was originally intended.

In this issue, we explore some of the recent developments that are working to overcome both the difficulties of machine code and the limitations of higher level languages.

Clive Loughlin