Support-focused enterprise controls: machine application model
Mechanical designers develop a time-based sequence of operation charts as a way to convey information to designers developing machine control applications. Control system designers then add information to these charts to create new versions. These enhanced charts convey mechanical and control information to support personnel. A support-focused control system can improve the effectiveness of these charts by actively integrating them with conveyor application models. The combined models improve the abilities of support personnel to monitor and interact with interlocked conveyor and machine control applications.
Time-based, sequence-of-operations charts have bars that represent the normal sequence of machine events. Machine events are typically mechanism movements, standalone external processes, or special application executions. The length of a movement bar represents the allotted time a mechanism has to travel between two physical positions. The length of a standalone process and special application bar represents the amount of time needed to complete a task. It is critical to recognize that the ordered placement of bars identifies the desired sequence of controlled events. Individual bar descriptions and property fields identify critical design and operation information for each controlled event.
To merge application models, control system designers convert sequence of operations charts from the time domain to a step domain. Step domain charts have standard-sized bars for each mechanism movement, process, and application. The conversion to a step domain reduces the size of bars on charts, but does nothing to improve the ability of support personnel to monitor and interact with applications. Variable length bars maintain a perspective of time, thus making animated bars that represent movements, processes, and applications more intuitive. Therefore, time-based bars and associated property fields provide support personnel with an effective design picture. The terms listed below help explain the type of bars found on machine application models:
- Motion command bar identifies when a mechanism sequentially moves from one physical position to the next.
- Recovery bar identifies when it is safe to move a mechanism from one position to the next when the mechanism is out of position.
- Activity bar identifies another sequential activity for another group of mechanisms, standalone process, or special application.
- Template bar identifies the existence of a template-based application that must execute within the allotted amount of time.
- Interlock bar identifies the need to communicate with a conveyor control application.
Mechanical designers place motion and opposing motion-command bars on separately charted rows and attach device description data to each row. To better model and show the relationship between opposing motions, control system designers place opposing motion bars on the same row. Next, control system designers assign description information to bar-specific property fields.
To show how control applications differentiate identical states defined by sensors, control system designers add vertical lines to models to represent when control applications enable cycle-complete signals. Figure 1 shows how designers realize a machine application model using a line to signify cycle-complete, bars to describe the sequence of operations, and data assigned to property fields.
Most designers clearly understand the role of auto-enable signals when they see them integrated with command circuits. Command circuits enable output circuits using start-position, end-position, clear, mode, and auto-enable circuits. Designers then use the resulting command signal to enable an output circuit. Figure 2 is an example of an extend-and-retract locator output circuit. The assigned output circuit signals enable external circuits to cause physical movements of objects and mechanisms.
Figure 1 does not, however, show any activity or recovery bars. This keeps the subsequent circuit examples simple. Control systems designers only add activity bars to represent other asynchronous machine sequences. The use of activity bars is analogous to the way programmers use subroutine calls or standalone robot interfaces. Designers place recovery bars on motion-command bar rows to show when it is safe to move mechanisms automatically out of position. In many cases, designers need to investigate mechanical details of a machine to ensure automatic, out-of-position motions do not cause damage to machines or objects.
Figure 1 shows multiple motion-command bars that represent the movement of mechanisms. The number of bars placed on a row with different output names determines the logic needed to enable each external circuit. The circuits also show the output logic needed to extend and retract the mechanical locator. A subsequent command control section of this chapter describes the systematic application of rules needed to enable each circuit’s command signal. The need to seal each output circuits comes with knowing the mechanical design requirements.
This information is taken from a spec sheet and is shown to support personnel as assigned, bar-specific property fields. The two normally closed contacts shown are standard for back checking opposing motion outputs and commands. This prevents both outputs from coming on together. The opposing motion command signal breaks the seal of a motion, thus enabling the circuit to activate the output on the next scan of the program.
Figure 1 shows template bars that represent the standard logic needed to activate two physical robotic processes. The design method allows a developer to use template bars to represent logical processes. Based on the process type, all template input and output interlocks conform to a base set of programming and naming rules. The property fields for the cycle robot #1 template bar identify the template as a physical process needing an activation interlock signal. The sequential placement of this bar means the robot processes activates the signal after an object stops at the station, the locator extends, and all clamps close. Figure 3 shows an interlock circuit a machine application uses to enable the cycle robot #1 process. The circuit conditions represent the needed sensed position of the conveyor-stopped object and machine mechanisms.
A template that represents the control of a physical process must include an internal anti-repeat circuit. This makes the template responsible for setting anti-repeat signals that prevent the repeat activation of its own process. Since template logic has access to all movement detection triggers, designers customize them to include internal anti-repeat signals. Template logic must adhere to a standard set of rules for designing interlocks and anti-repeat circuits.
Figure 1 also includes an Interlock bar with property fields that decide the conditions needed to connect a machine application and its template modules with a conveyor application. Property fields for motion and template bars conform to unique interlock design rules. This allows designers to systematically generate all necessary interlock logic. Designers must first certify that template-based logic interacts properly with rule-based logic. Specifically, there are special case design rules that govern the generation of cycle-complete interlocks for both parallel and serial executed templates.
Figure 4 shows conveyor application interlocks with machine application model depicted in Figure 1. The circuits illustrate the design of a cycle-complete interlock and a station clear interlock for the two parallel robot template controlled processes.
The first two circuits show the logic needed to have the robot template processes interact with a machine application. The third circuit represents the cycle complete summation interlock signal used by the conveyor application. The fourth circuit represents station clear interlock signal. This circuit contains robot template and mechanism summation signals that activate when the process is completed and the robots are in a position to release the object to the next downstream station.
When the conveyor application examines both activated interlock signals, it causes the object to move out of the station. The fifth circuit shows the interlock logic resets when the departing object activates the downstream exiting station trigger.
Daniel B. Cardinal works as an engineering consultant for Insyte Inc., implementing integrated scheduling and part identification applications in the automotive industry. Edited by Chris Vavra, production editor, Control Engineering, email@example.com.
Mechanical designers develop a time-based sequence of operation charts as a way to help designers develop machine control applications.
Machine events are typically mechanism movements, standalone external processes, or special application executions.
A template that represents the control of a physical process must include an internal anti-repeat circuit and adhere to a logical system.
What applications would especially benefit from a machine application model?
See prior stories in this series by Daniel Cardinal linked below.