Support-focused enterprise controls: conveyor application model
A support-focused control system must have the ability to enable control system designers to model conveyor applications by providing an object-oriented chart design environment. The environment would enable designs to start with a sensor-activation chart. Designers would then add layers of bars to create application charts that support trigger designs. These expanded charts, when actively integrated into a design, would enhance the ability of support personnel to monitor and interact with a conveyor control application.
The added bars and associated descriptive property fields provide support personnel with a detailed view of the conveyor’s control application, including the operational interdependencies associated with rule and table-based control applications. The following definitions explain the purpose of various types of bars used in a chart-oriented design environment:
- Movement-detection bar is an element on a chart on which vertical borders represent where a moving object activates movement detection triggers.
- Movement-command bar is an element on a chart on which vertical borders identify where an application enables and disables the movement of an object.
- Blocking bar is an element on a chart on which vertical borders identify where a trigger circuit sets and resets a signal that inhibits other logic circuits.
- Speed control bar is an element with vertical borders that identify where a control application enables and disables speed control outputs.
- Shift-register bar is an element on a chart with vertical borders that identify the points in the process where index triggers move register data.
- Interlock bar is an element on a chart that identifies the need to communicate with a machine control application.
- Template bar is an element that identifies the existence of a template-based application that must execute when an object moves between two critical stations or points in the process.
Figure 1 shows a conveyor application model that includes blocking signals, shift-register data, movement commands, speed-change zones, special template-based applications, and interlock applications. The model shows the layers of bars added to a trigger-firing chart for the three consecutive conveyor stations. The application model shows movement-command bars with names that cause the object to "enter station 2" or "exit station 2." This same model shows speed-control bars with names that depict an object entering or exiting at high speed.
Control system designers place bars and arrows on a trigger-firing chart to produce a conveyor’s application model that acts as a real-time interface tool for support personnel. For enhanced interactive designs, movement-command bars fill from left to right like progress bars to animate the process, while other bars simply change color to show signal state changes. However, animated bars by themselves do not provide the full picture most support personnel need. To get an accurate picture, support personnel must have the ability to see design and logic details associated with charted triggers and bars. Figure 2 shows a legend that describes a subset of property fields for each charted bar.
Figure 1 shows the movement detection bars denoted with an "M." These bars represent the root movement-detection arming circuits for the logic at each station. Like the previously described trigger logic, an arming is enabled when an in-position trigger fires and is disabled when an exit-position trigger fires. Bar-specific properties dictate the need to place command or other optional signals as extra preconditions for firing each trigger.
Figure 1 includes four blocking bars that represent special signals that disable circuits when objects move between trigger points. Each bar logically represents a physical zone that starts when an object moves and ends when the object reaches a downstream trigger position. If designs have an increased emphasis on movement detection, there is no need to overlap blocking-bars with movement-detection bars. Regardless, control applications use one trigger to set or latch a block signal on and another downstream trigger to reset or unlatch it off.
With the four blocking bars, notice how the "exit station 2" movement-command bar in Figure 1 extends to the right from the stop position to an adjacent blocking bar. This means the control application enables the forward motor on output and later disables it when the object reaches the trigger-enabled blocking signal. Each conveyor station in the model has one common machine controller motor on output for entering and exiting each station. The application model requires two movement-command bars for each station. The enter station 2 and exit station 2 movement-command bars represent the forward motor on output for the second station.
This means the single output signal that enables the station’s motor will have two parallel conditions. Similarly, each movement-command bar shares one high-speed output, so there are two speed control bars. One bar represents an object entering and the other represents an object exiting. In the model, each speed-control bar starts at the stop position of a station and ends at a blocking bar. Regardless, the need for multiple movement-command and speed control bars to enable one controller output signal drives the need for the circuits shown in Figure 3. The forward motor on high-speed output circuits reference the movement-command bars for "entering" and "exiting" the modeled second station. A subsequent section of this chapter describes the rules needed to enable these movement command signals.
Figure 1 includes shift register bars that represent the need for an application to shift data when objects move from station to station. A designer stretches a shift-register bar between two trigger points where the downstream trigger is responsible for shifting data. When movement occurs, the shift-register application starts by copying source data from the source registers of one station to the target registers of the next. After copying data, the shift-register application clears the source register data.
Figure 4 shows the shift-register circuits that move data from station 1 through to station 3. Each circuit copies data from one station to the next before clearing the first station’s data.
Figure 1 also shows an interlock bar that represents the need to interlock the conveyor application with the second station’s machine application. The property fields for an interlock bar define the input and output signals enabled by each application. The design assumes that the machine application can examine any trigger signal enabled by the conveyor application.
Figure 5 shows a conveyor to a machine interlock circuit. The enabled signal identifies the presence of a stopped object at the second station.
Figure 1 shows a template bar that represents the existence of a special application that has access to shift-register information and three movement-based triggers. Designers customize template-based applications to react to triggers while they interact with shift-registers and/or high-level process control applications.
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.
Control system designers need to model conveyor applications by providing an object-oriented chart design environment.
Designers customize template-based applications to react to triggers while they interact with shift-registers and/or high-level process control applications.
What challenges have you encountered with conveyor applications and how have you overcome them?
See prior stories in this series by Daniel Cardinal linked below.