Why can’t my software behave like my hardware?
Software standards simplify packaging machine controls
By Dr. Ken Ryan
Many of us have been in the technology game long enough to remember the pain associated with configuration of new hardware in the early days. Recently, I purchased a printer with a USB interface and was pleasantly surprised by the transparency of the configuration process; most of it was managed automatically without my interaction. All of this leverages the benefit of the USB standard interface and the availability of standardized device description files. These standards allowed the printer to tell my computer all of that obscure information that used to be required in the “black art” of hardware configuration. Application of these standards let me be the judge of printing performance rather than configuration nuances. By presenting me with a known interface and a reduced set of requirements for integration, both manufacturers increased my odds for success and loyalty to their product.
As this plug and play performance becomes more ubiquitous, it also begins to “seep” into surrounding arenas. “Why can’t my software be as easy to write as my hardware system is to configure?” Think about it: I had a simple requirement specification—I want to print.
Given a mature printer object and a guide to its simple, consistent interface, I got exactly that. I was intuitive enough to know what I needed and what tool would provide the desired outcome. This is often the case in control programming. I may know that I want to move a box from point A to point B using a single rotary axis driven conveyor. I am also intuitive enough (or experimental enough) to determine the best velocity and torque to use to move the box. What if I could simply download a MoveBox OnConveyor object as easily as I ordered my printer?
With the release of the official ISA-TR88.00.02 PackML Standard in August 2008 and the PackML Implementation Guide in early 2009, packaging machine control design took a major step forward. We are now able to create robust, modular code that can be reused in the same plug and play fashion described above for hardware. One of the easiest methods to ensure that this code is truly standardized and transportable is to implement the mode and state model outlined in the PackML Implementation Guide using the IEC 61131-3 programming standard.
The PackML Implementation Guide outlines two major components to code design for packaging machines:
- Standardized mode and state models
- Standardized pack tags
Together, these components provide the framework and interface for packaging machines that allow an object-oriented approach to code design.
The example of the printer used earlier envisioned the printer as an object. That object has two principle components:
- What should happen? (Print)
- How should it happen? (Interface of data and commands)
With the standardization of the interface and the print commands, we were able to view the printer as a “black box” that when provided with printable data returned a printed output. The printer thus became a module of functionality that performed in a very predictable manner. The IEC 61131-3 programming standard allows us to treat control code in this same modular fashion.
Let’s start from the beginning.
When provided with a Software Requirements Specification for a machine, it is customary to take a top down approach to decompose the requirements into increasingly granular blocks of functionality. Using the mode and state model of PackML, we already have the first level of this decomposition. We can now characterize the modes in which the machine will operate.
Assume we have the following modes of operation:
IEC 61131-3 allows us to use the Sequential Function Chart to easily code this mode model.
The “Mode model in Sequential Function Chart (SFC)” image depicts part of the unit mode control model as it appears when programmed in SFC to implement the PackML mode model. This particular example is taken from CoDeSys V3, but any IEC 61131-3 implementation of the mode control in SFC will follow the standard and have a similar appearance. The modular design of this mode model and IEC 61131-3 allowance for archiving and reuse of this code “object” assures that unit mode switching behavior will occur predictably as outlined by the model. The advantage of separating the “mode control” object from the “state machine” object is that once the modes have been determined, the state machine executed in each mode can be varied from machine to machine without corrupting the integrity of the mode model.
The PackML mode model next calls the appropriate PackML state model for each unit mode.
The “OMAC state model” image depicts the PackML state model and is copied from the PackML Implementation Guide. It depicts the 17 possible states in which a machine can exist within the PackML standard. The actions performed in each of these states are dependent upon the unit mode of the machine at the time.
Programming the state model in IEC – 61131-3 SFC provides a modular and easy-to-understand design. Consider a portion of this state model depicted in the “Enlarged (partial) State Model View in SFC” image.
A glance at the state machine code in the enlarged/partial state model image indicates the machine is currently in the Resetting state (the large dark blue box labeled stpResetting is the currently active SFC step). Associated with this state is an SFC action (small dark blue box labeled actResetting attached to the right of the SFC step), which calls the code for resetting the machine. Again, the disassociation of the state machine from the actions performed in each state allows for maximum flexibility. This flexibility is necessary since the resetting action will likely be different from machine to machine and may in fact be different from unit mode to unit mode on the same machine. (Resetting action in the Automatic unit mode is not necessarily the same as that in the Manual unit mode.)
Coding of the mode and state machines in SFC has several advantages over coding of these using Ladder Logic:
- There is no need for separate latch/unlatch, bit shifting, or sequencer logic to be developed since this logic is integral to the SFC structure.
- The What, When, and How of each state is readily visible at any point to technicians. It is easy to see the machine is in the Resetting state and to determine what action is being performed. In addition, if this represents an abnormal cessation of function, the technician can easily determine the transition conditions that were not met to move the machine to the next logical state.
- State transition priority can be established based on the left to right orientation of the transition condition in the SFC “tree.”
- Since each step of the SFC code has a time-in-state attribute, it is unnecessary to code separate state timing logic for Overall Equipment Effectiveness (OEE) monitoring.
The “Mode and state model template” image shows a unit mode and Machine state template that was developed to the OMAC specification. Notice the current unit mode (Semi-automatic) and state (Idle) are clearly visible. The monitor also indicates the machine is preparing to switch to the Automatic mode next time it is in the Stopped state. This machine has been limited to making unit mode switches only while in the Stopped state for any given unit mode. In addition, a sample of equipment effectiveness data visualization is shown. This machine has spent a total of 21 minutes, 14 seconds, and 167ms in the Stopped state. Of this stopped time, 11 minutes, 7 seconds, and 730ms were while the machine resided in the Semi-Auto unit mode. It is clear this OEE data can be invaluable when seeking to minimize high-frequency, short-duration, and low-frequency, long-duration production interruptions. Again, since this OEE data collection is embedded in the SFC for the mode/state machine and completely decoupled from the underlying machine execution code, it is transportable to all machines.
What’s under the hood?
IEC 61131-3 coding builds on the PackML guidelines to create modular reusable code. Beyond the mode and state models established by PackML, at the end of the day, it is still necessary to write the code that will control the actions executed in any state in any mode. This is where 61131-3 shines. The ability to create user-defined data types allows rapid implementation of the PackTags standard, and encapsulated program organization units provide truly modular, transportable, reusable code.
An excellent example of this is the set of motion control function blocks created by PLCopen.
The “PLCopen MoveAbsolute” image shows an example of these function blocks, which is used to command an axis (AXIS_REF) to an absolute position using a defined list of parameters for the move.
The PLCopen Motion Standard defines common motion control actions as functions. Users know that motion function controls from vendors that certify to the PLCopen Motion Standard will have the same interfaces and behavior. This is analogous to the printer example.
These function blocks are part of the PLCopen Motion Control standard.
If I need to tell a drill to ramp up to speed and to advance at a high speed to a work surface, drill slowly into the part, dwell at depth for two seconds before retracting at high speed and stopping the drill bit at an indexed position, I need only string together instances of the PLCopen Motion Control function blocks. Once again, IEC 61131-3 programming procedures have been used to “abstract” a standard interface for the motion function blocks. This focus on the interface allows each MoveAbsolute architect to program the inner workings of the function block in the way most complimentary to their hardware, without involving the motion programmer in the details of this optimization.
I do not have to understand how the hardware is optimized by the manufacturer to deliver its superb performance, nor do I need to know the details of the hardware interface.
We are truly at a jumping off point for improved time to market and reduction in errors with the IEC 61131-3 programming standard and the clarity of the OMAC PackML standard. The modular reusability provided by IEC 61131-3 and extended by the PLCopen Motion Function Blocks lets us focus on our application without having to worrying about coding details.
ABOUT THE AUTHOR
Dr. Ken Ryan has taught PLC programming at Alexandria Technical and Community College for 15 years and directs the college’s Center for Applied Mechatronics. He is the author of numerous IEC 61131-6 based curricula for several prominent controls providers in North America. Ryan is member of the PLCopen Board of Management and a Premium System Partner of Smart Software Solutions (3S). All program examples provided where created using CoDeSys V3.