Advanced Methods of State Machine Programming in Ladder Logic

A previous article discusses state module definition and documentation. This article will build upon that existing information to discuss module implementation, and the potential for advanced users to construct software tools which are capable of automatically generating the appropriate ladder logic from a high-level state language description.

 

Module Implementation 

Given a well-defined set of module documentation, it then becomes a relatively straightforward task to produce a  ladder logic implementation satisfying that module’s requirements. Each module may be contained within a single  PLC program routine and consists of at least the following three ladder logic sections: 

1. Event Conditions - Implements the logic specified by the “Events” section of the module documentation

2. State Transitions - Implements the state transition logic specified by the state transition diagram.

3. State Actions - Implements the logic specified by the “States” section of the module documentation.

This organization is motivated by the natural sequence of first evaluating conditions leading to state changes,  potentially performing the state change, then acting on the outputs affected by the current state. Additional sections containing ladder logic associated with the module, but non-sequential in nature, can appear above or below the sections listed above. Alarm and scaling calculations are examples of non-sequential or “continuous” logic. 

As mentioned earlier, associated with each module is a set of command, state, and event bits. In most cases, a single 16-bit word is sufficient for each of these, however complex modules may require additional words to contain the states and events. Bit 0 within each state word has a special meaning and is referred to as the “one-shot” bit. This bit is “false” during a scan in which a state change has occurred within that module, otherwise, it will be “true”. The one-shot bit serves two purposes. Firstly, it provides a means for ladder logic to be written in such a way that a state action occurs only once upon entry into a state. Secondly, it facilitates the synchronization of state changes, within the state transition ladder logic, so that only a single state change for a given module can occur within a single scan. This is desirable so as to prevent the actions of a state from ever being skipped. The use of this bit will readily become apparent. 

Listing 2 depicts the ladder logic required to implement the event conditions for the conveyor. The output of each rung triggers an event bit. Events are named symbolically, the symbol constructed as the concatenation of the subsystem mnemonic “CV1” (for Conveyor #1), followed by an underscore “_”, an “E” for “event”, and finally the event number as specified in the state transition diagram. A similar naming convention is used for the command and state words as well, substituting instead the letter “C” for command, or “S” for state.

In many cases, an event may simply track an input such as a push-button or a photoeye. Notice that those event condition rungs triggered by a command, are responsible for unlatching the respective command bit. This allows an external entity to simply set the command bit to initiate a module function (it does not have to synchronize clearing the bit with the module).

In effect,  the behavior is much like a momentary push-button. The initiator simply latches the command bit on, the receiving module triggers the event, then immediately unlatches the command. Most events are momentary and therefore remain true only for a single logic scan. However, if an event is considered a “fault” event such as the case for  CV1_E4, it is latched so that when the associated fault state is entered, the operator can determine the cause of the fault (as many faults conditions can lead to a single fault state). Upon exiting the fault state, the associated fault condition bits are cleared. 

Listing 3 depicts the ladder logic required to implement the state transition logic. Each rung defines a state transition corresponding to an arc connecting a pair of states on the state transition diagram. For example, the first rung implements a state transition from state S1 to state S2 on event E1. Semantically, this can be expressed in structured  English as: 

 

IF

Currently in state S1 (CV1_S1 is “true”),

AND no other state transition has yet occurred during this scan (CV1_1SHOT is “true”),

AND event condition E1 is TRUE (CV1_E1 is “true”)

 

THEN

Exit our previous state S1 AND clear the one-shot bit

(note that both of the above actions are accomplished by performing the CLR instruction on the entire state word)

AND enter state S1 (latch CV1_S2)

 

Listing 2. Event Condition Ladder Logic. 

 

Listing 3. State Transition Ladder Logic.

 

Listing 4. State Processing Ladder Logic. 

 

Finally, Listing 4 depicts the ladder logic implementing the state actions. For example, the first rung turns on the conveyor motor when initially entering the “Running “state S2 or the “Unloading” state S5. The use of the one-shot bit causes these actions to be edge-triggered. 

The third rung runs the position timer when in the “Running” state S2.  Since the one-shot bit is not used here, the rung is level triggered and therefore runs continuously while in state S2. Finally, the last rung sets the one-shot bit (remember it was cleared by the CLR instruction when transitioning into the current state) since a full scan of the module has occurred.

 

Automatic Generation of Ladder Logic Programs from a State Machine Description via a Translation Tool

Typically, ladder logic programming environments provide the ability to produce ladder logic programs by “importing” a textual representation of the ladder logic code. This capability allows for external software tools to generate these ladder logic project files from high-level descriptions. 

Although the details are not presented here and may vary across PLC vendors, a formalized description of the state logic suitable as a machine-readable document is the input to the translation tool. Essentially, the input format should include distinct sections capable of defining states, events, and the conditions for transitioning among states. 

Naturally, the definition would need to be precise enough to produce the data (commonly referred to as "variables" or “tags) and code corresponding to the ladder logic rungs. Leveraging existing compiler support tools such as “lex” and “yacc” can significantly reduce the effort required to develop a translator (open source versions of these tools do exist). 

By eliminating much of the routine effort involved in generating the desired ladder logic, a translator can provide an order of magnitude increase in productivity.

 

The main benefits offered by a translator are:

• Provides a high level, problem-oriented, language that hides the specific details of the underlying ladder logic implementation. 
• Provides a pure symbolic programming environment.  If required, the allocation of named variables to memory addresses can be performed by the tool.
• Auto address assignment for tags.  If an address is omitted, the next available address is auto-assigned to the tag.
• Since it is textually based, the high-level description can be edited using standard text editing and manipulation tools.
• Performs a set of error and consistency checks on the state transition specification.
• Support “special cases” by allowing arbitrary ladder logic code to be entered into the specification via its textual representation.
• Generates correct state transition code.  Also, a change to the underlying ladder logic implementation requires only making a change to the translator.  Existing user application work is preserved.
• Additional features may be added, such as file inclusion, free form commenting, etc.

 

In addition to the usual syntax checking, a translator could check for and warns of the following conditions:

• A state with no transitions entering it.
• A state with no transitions leaving it.
• An unreferenced variable.
• States and events not used in the transitions section.
• A transition with no supporting event condition.

 

The need for sequential control logic is frequently required for machine control. State machine programming is a powerful technique that can be layered on traditional ladder logic to satisfy this need. 

A structured methodology that begins with a functional breakdown of the process into specific modules can provide a standard development approach. Each module specifies the requirements for a self-contained sequential logic function. The approach has the benefits of aiding productivity by providing a “cookbook” methodology, and also leads to enhanced project documentation. Advanced users can further leverage this approach by automating the manual aspects of the development process by creating a translation tool.