Support-focused enterprise controls: Control logic fundamentals

Controller manufacturers have made significant enhancements to controller programming environments. Today, programmers are using generic tag names to describe ladder logic instructions, simplifying programming, and making it easier to convert design information to control programming. Link to other parts of the support-focused enterprise controls series below.

By Daniel B. Cardinal November 11, 2015

Programmers today are using generic tag names to describe ladder logic instructions. This feature enables designers to discard the referencing of ladder logic instructions using fixed memory addresses. There have also been promises of new applications that will automatically convert design information into ladder logic applications. Like flow chart programs, these applications have had limited success creating mostly state-based ladder logic applications.

As a way to measure success, some manufacturers expected the application to regenerate the control applications automatically after someone deliberately deleted the controller’s entire program. Even if it were possible, would self-generating applications improve ongoing machine support? Some new applications have come close, but none have ever claimed real-world success for a large number of different types of machines.

What are the real obstacles to automatically producing reliable control applications for many types of machines and conveyors? If system strategists do not recognize movement detection to be the foundational building block for all control applications, designs will fail. The term "fail," in this context, means they were not able to generate all needed logic from elemental design information.

Four design terms

Once strategists recognize the importance of movement detection, they must focus on providing applications that integrate associated triggers using various design methodologies. The following terms help to describe various design methodologies:

  • Design spec sheet: a document that identifies the critical properties that are critical to a design methodology.
  • Template-based design: a development technique that relies on the repeated use of a predefined set of working logic circuits.
  • Rule-based design: a development technique that requires rules for generating the elements of logic circuits from root informational sources.
  • Table-based design: a development technique that requires rules for expanding, contracting, and formatting data access and shift-register applications.

Some automatic code generation schemes rely solely on a library of template-based design standards. Designers simply cut and paste grouped circuits from the library to assemble needed control applications. Most designers would not think that this copying process qualifies as a way to generate code automatically. Although machine suppliers practice this approach regularly, manufacturers only realize small cost savings. This copying technique does not improve operational support capabilities.

Strategists can recognize table, rule, and template-based design methodologies by how each approach produces machine controller logic. The table-based approach creates logic that is responsible for moving data between applications, systems, and stations.

Matrix structures help

Designers use matrix structures to define: 1) the order of data, 2) data field formats, and 3) where interlocks will pass data to other logic modules. The table-based technique produces logic that is nothing more than template-based logic for defining data. The template method uses a logic replication process to create applications that need connections to other logic. Controls designers produce rule-based logic applications by constructing many interdependent circuits using detailed design information described in design spec sheets.

Design spec sheets are critical to all three of the design methodologies. For rule-based designs, there is a separate spec sheet for: 1) detecting an object’s actuator, 2) specifying criteria for operating mode circuits, 3) enabling an output device, and 4) interlocking logic modules. The spec sheet used to detect an object’s actuator identifies the mechanical, electrical, and logical characteristics of an applied movement detection scheme. The spec sheet used to specify operating mode criteria identifies the conditions for constructing a mode-specific circuit. The spec sheet used to enable an output device defines the opposing motion output signal, required operating modes, and special control characteristics needed to activate and deactivate movement. For table-based designs, a spec sheet defines data pattern and structure requirements. For template-based designs, a spec sheet defines the template type, required external input and output signals, and the rules for replicating it.

Many control system strategists define control applications to be hierarchical. Some strategists use a multi-layered pyramid to represent the hierarchy of controller applications. The number of layers and their assigned application type often differ between strategists. 

Control system pyramid

Figure 1 shows a control system pyramid. It is important to recognize that the definitive boundary shown between each layer does not imply an exclusive interface. Applications in each layer have access to certain types of information found in other layers. The layered order shows the importance of each application. More importantly, the pyramid shows a foundational trigger layer.

The trigger layer in the pyramid is a rule-based design tier that includes the circuits used to arm and fire one-shot signals. The circuits in this layer are extremely important and the main topic of this article. The next highest infrastructure layer is a rule-based design layer that contains a defined set of circuits that enable external circuits and operating mode signals. The control layer is above the infrastructure layer. The control layer contains circuits produced using the rule-based design methodology. This layer includes the circuits that are in command of mechanical movements, equipment behaviors, and associated user interfaces. The rules for controlling the movement of an object and mechanism are also a topic of this article. The pyramid shows the diagnostic layer to be above the control layer. This layer also includes rule-based circuits designed to be compatible with the circuits in the control layer.

As a result, the diagnostic layer has a seamless connection with the control layer. Above the diagnostic layer is the data exchange layer. This table-based design layer contains the circuits used to control the variable nature of control and diagnostic circuits. The need to translate system-provided information that affects the circuits found in this layer. When necessary, the data exchange layer includes the circuits used to keep information synchronized with moving parts. The data exchange layer is the next highest system-based application layer. The system application layer is a template-based design layer that contains the application circuits that collect and deliver system information. Designers place the circuits that interact with readers and other devices used to enable system applications in this layer. This layer is only applicable if resident circuits can examine one-shot signals enabled in the trigger layer. The topmost communication driver layer is a template-based design layer that includes the circuits used to establish and maintain communications with upper-level system components.

Manufacturers will realize true cost savings when support personnel can interact with all layers of the control system pyramid. This is possible when support personnel have the improved abilities to change design information to affect actively running programmable logic controller (PLC) programs. The real value to manufacturers comes from minimizing chaos by having support personnel understand how to interact with all control system applications. To do this, support personnel must have the ability to change logic circuits by interacting with rules, design specifications, and table-based configuration information.

– Daniel B. Cardinal works as an engineering consultant for Insyte Inc., implementing integrated scheduling and part identification applications in the automotive industry. Edited by Joy Chang, digital project manager, Control Engineering, jchang@cfemedia.com.

Key Concepts:

  • Programmers today are using generic tag names to describe ladder logic instructions.
  • This feature enables designers to discard the referencing of ladder logic instructions using fixed memory addresses.
  • Some automatic code generation schemes rely solely on a library of template-based design standards.

Consider this

Are your support personnel able to interact with all layers of the control system pyramid?

ONLINE extra

See other parts of the support-focused enterprise controls series by Cardinal linked below.