How simulation helps automation and controls
The controls often must be programmed for automated machinery and systems before hardware exists, but controls engineers can use simulations to test syntax, proper tag linking and addressing, and code functionality.
When building automated machinery and systems, a controls program often must be written long before there is hardware to test it on. Controls engineers use various kind of simulation to test syntax, proper tag linking and addressing, and functionality of the code.
If the programmer is working with other engineers, they often will use a shared spreadsheet for program tag names and addresses. As long as the spreadsheet is kept up to date when changes are made, multiple programmers should have no problem coordinating.
Programmable logic controller (PLC) and other programming software have utilities that check the program for syntax errors; if illegal operations are performed, the software should catch them. Unfortunately, there are many programming errors that aren’t syntax- or format-related. For instance, operators might put illegal numbers into data registers via an HMI, causing overflows or access data registers that don’t exist. Data entry values need to be limited or protected either in the controller or in the operator interface. Most human-machine interface (HMI) software has a method of linking an application to a PLC program before downloading it to hardware. This allows tag addressing to be checked and catches typographical and formatting errors.
PLC software usually has simulation packages that will run code without a real PLC. When this is used, there are no physical inputs and outputs connected, so virtual addresses need to be substituted for real ones. “Aliasing” (linking) tags to other addresses is possible on some platforms, or routines also can be written that map one address to another. These routines can be disabled or deleted when simulation is complete.
Even when this is done, it is difficult to make simulated input/output (I/O) values react like real devices by toggling bits and changing numbers by hand. Because of this, simulation routines are often written to provide feedback like “real” I/O.
Machine vision simulators
Machine vision has had software simulators that process saved images without a physical camera for a long time. Programmers can use this to set up tools sensors before implementing the system. Images should be captured under a variety of lighting conditions and in various positions.
Companies make software simulation modules that run on a computer to simulate actual objects, but most are only for material handling. For complex assembly operations, there are too many possible combinations of tooling and actuators to make this feasible. Solid modeling software does allow objects to be moved, but there is no method of linking the objects to controls software.
The following logic shows an example of how an address mapped to a memory bit can be used to simulate the movement of an actuator and resulting sensor activation.
The output PLC logic in figure 1 is typical for an actuator. There are various addresses that need to be in the correct state for the Z_Axis_Lower_SV output to energize. These can be manipulated by the programmer, or in the case of the HMI pushbutton, it can link to an HMI program running on the programming computer and actually be pressed.
When the output is activated, it is linked to a tag named “Digital_OutputCard_Pt.3,” which can drive the simulation code in Figure 2.
The timer can then be used to latch (set) a bit simulating a sensor. The sensor in turn provides feedback to step through a sequence of movements. By turning off the “Sim Output Enable” bit, a fault condition can be tested. Faults usually consist of timing an output condition and looking for the corresponding input.
It can be as complicated to write a simulation routine as it is to write the original program, so this is not often done in real machine building applications. This is however useful in showing programmers how a sequence operates, as indicators and objects on an HMI react to the simulated I/O.
Another method of simulation is to build small models representing a machine complete with sensors and actuators, such as with a conveyor and pneumatic pushers, where a simulator might sort colored blocks into bins.
As with writing simulation routines, this is not often done to simulate production machinery, but it is useful in training.
Robotic software usually has software simulations to ensure axes can make it to different positions without cables and hoses “wrapping” or breaking, but, again, it is rare full simulations are done with tooling and products modeled.
Simulation can be an important tool in the arsenal of an automation professional, but it is no substitute for the debug process on actual machinery.
Frank Lamb is founder, owner, and manufacturing and automation business consultant at Automation Consulting LLC. Lamb is a Control Engineering Editorial Advisory Board member and Automation Primer is a Control Engineering content partner. Edited by Mark T. Hoske, content manager, Control Engineering, CFE Media, email@example.com.
KEYWORDS: Software simulator, programmable logic controller, error testing
Automation programming can simulate machine functions to test helping programmers write better code.
Writing a simulation can be as complicated as writing the original program
Simulation code can show how a sequence operates.
How could your control code be improved with simulation?