Article summary
Continue our exploration of a state-machine-based UDFB for controlling a motor starter. This installment explores a Function Block Diagram (FBD) implementation that may then be compared to the previous ladder and structured text examples. The article includes a side-by-side comparison to ladder logic to showcase the similarities in logic flow and the subtle implementation differences. The article is written for intermediate PLC programmers who desire to make their programs more readable while simultaneously making their workflow more efficient.
Estimated reading time: 6 minutes
Introduction to the Function Block Diagram (FBD) UDFB for a motor starter
The User-Defined Function Block (UDFB) is a fundamental building block for the Programmable Logic Controller (PLC) code. It is used to encapsulate a discrete piece of PLC code with a clearly defined input/output interface. A collection of carefully tested UDFBs may then be assembled into a library. Collectively, these Program Organizational Units (POUs) save considerable time as the programmer may instantiate multiple UDFBs within a given project or reuse the library across multiple projects.
A UDFB may be constructed using IEC 61131-3 languages. However, not all PLCs support all languages. For example, Siemens TIA portal allows a UDFB to be programmed using:
- Ladder Logic (LD)
- Structured Text (ST)
- Function Block Diagram (FBD - the topic of this article)
- Cause and Effect (CEM - not an IEC 61131-3 language)
This engineering brief is a continuation of the Siemens TIA Portal UDFB conversation as developed and tested on the Siemens S7-1200 CPU 1215 FC as shown in Figure 1. Previous articles include:
Note that the same UDFB functionality is implemented across all three examples. This allows us to make statements about the size and complexity of the resulting code. While we won’t declare a winner, there are undeniable advantages to each method.
The reader is assumed to have experience with both ladder logic and function block diagram. The ability to fluidly translate combinational logic circuits between languages is assumed as is the ability to use functions such as MOVE.
The PDF description of the function block diagram code may be downloaded here:
UDFB_FBD.pdf (97.7 KB)
Figure 1: Image of the Siemens S7-1200 used to develop and test the UDFB-embedded state machine code.
Author’s reflections (experience):
As an instructor I led a series of classes exploring the PLC. Naturally, we started with ladder logic to bridge PLC programs to the physical field devices. Moving on, we explored structured text and function block diagram.For their final projects, students were given a set of requirements but were free to mix and match IEC 61131-3 languages. Most gravitated to function block diagram when dealing with numbers and equations. This preference suggests that function block diagram is faster and easier to understand for select programming applications.
Tech Tip: A UDFB should not be confused with Function Block (FB). While the instantiation may look the same, the UDFB and FB do not have the same operation. The primary difference is that the UDFB has memory while the FB is memoryless. The UDFB has static memory that is maintained across function calls. The distinction is like construction programs in C. The UDFB includes variable with the static keyword while the FB’s variable(s) are placed on the stack and lost each iteration.
Also don’t confuse FBD with a UDFB or FB. FBD is a programming language while the UDFB and FB are Program Organizational Units (POU).
Review of the state-based logic for the motor starter UDFB
Down arrow to open the summary
In the previous article we described the motor starter control logic in terms of states. The states and fault triggering conditions are repeated here for your convenience:
Motor starter states
There are five states incorporated into the UDFB. The rudimentary failure associated with each state may be detected by monitoring the feedback from the motor starter’s auxiliary contacts.
-
Open: The motor starter is in an inactive state with no power applied to the contactor’s coil. The UDFB will enter a fault state if the motor starter unexpectedly closes for longer than timGlitch. This could occur when a technician uses an insulated screwdriver to force the motor starter’s armature.
-
Closing: The motor starter’s contactor is transitioning from an open to a physically closed state. The UDFB will enter a fault state if the contacts fail to close within timTransition. Figure 1 shows the UDFB that has faulted from this state.
-
Closed: The motor starter on the associated motor is running. The UDFB will enter a fault state if the sensor signal is momentarily lost for a period longer than timGlitch. This fault could be caused by a loose drive wire leading to the motor starter or the feedback line. It could also be caused by an overload event which would trip the motor starter via the thermal overload block.
-
Opening: The motor starter’s contactor is transitioning from a closed to an open state. A fault is triggered if the contacts do not open within timTransition as this implies that the primary or interposing relay contacts have been welded together.
-
Fault: The motor starter is in a fault condition. It will be released when the enable signal is disabled and the reset button is pressed.
State machine encoding in function block diagram
The function block diagram state machine is nearly identical to the ladder logic machine as described in the previous article. Both implement the same state logic with the same general structure.
The function block diagram representation is included in Figure 2 and for convenience, the ladder logic equivalent is included as Figure 3. As we compare the two diagrams we observe:
-
The normally closed contacts in ladder logic are represented as an inversion bubble in function block diagram. For example, the blocks will move to state uiStOpening if NOT xEnable.
-
In ladder logic the AND operation is encoded as rung continuity while the function block diagram uses explicit blocks. As an example, consider the English statement: if we are in the closing state and if the enable signal is lost, then shift to the opening state. This is encoded in the 2nd branch of the function block diagram and the 3rd branch of ladder logic.
-
Set and reset coils (memory assignments) are used for the UDFB Boolean outputs. While the style is slightly different, the underlying functionality is identical.
-
The function block diagram has a natural waterfall flow from top left to lower right.
-
In this example, the blocks consume considerable screen area. By contrast, the ladder logic representation is compact. We are tempted to declare the function block diagram is bloated. However, this condition is program-dependent. In fact, the situation would likely reverse if we programmed to the strength of function block diagram. For example, a program to convert Celsius to Fahrenheit or a program to calculate tank volume would be compact in function block diagram. Stated another way, use each programming language to its full advantage with full consideration of size of program as well as program clarity.
-
Independent timers are used for each network in this state machine. As seen in the PDF, there are a total of four independent timers. Contrast this simplicity with the structured text example which uses additional logic to allow the use of a single timer. While a single timer instantiation may reduce memory and execution time, the resulting program may be harder to read, develop, and maintain.
Figure 2: Function block diagram representation of the motor starter’s closing state.
Tech Tip: Function block diagram uses an inversion bubble in place of a normally closed contact. We see two inversions in Figure 2. This practice will be familiar to learners who have studied digital logic.
Figure 3: Ladder logic representation of the motor starter’s closing state.
State machine program flow considerations in a function block diagram program
Recall that function block diagram programs are generally executed by the PLC in a left to right and top to bottom sequence. Hence the waterflow nature of the program. The program also reads all networks regardless of state. As seen in the PDF, there are five such networks corresponding to the states.
Both the ladder logic and function block diagram examples use a “gate” at the beginning of the network to determine if the right-hand-side logic should be executed. In these examples, the gate is implemented as an equality check to see if the current state is equal to closing.
The last-rung-wins applies to function block diagram
This is fine, but we must consider the program flow upon change of state. We recognize the classic “last rung wins” conundrum. As the program sequentially visits each state. Suppose we are in uiStClosing and the state changes to uiStClosed. Given that state closing proceeds state closed, both states will evaluate as true in a single program scan cycle.
For those who know C programming, this is a classic problem associated with omitting the case break statements from a switch-case structure. We could add unconditional jumps or a lockout variable to ensure only one case was executed per program scan.
The featured program does not suffer from the last-rung-wins (last network). It features set and reset coils to handle the Boolean outputs. It also uses a timer so that glitches such as relay contact bounce settle down before state transitions.
Helpful state machine definitions for PLC programming
Let’s reinforce this topic with a few unique definitions:
-
State lockout gate: An equality operator used to check the state condition. The right-hand-side logic will be evaluated if the condition is true, otherwise, the state network will be skipped.
-
PLC rung fall-through: A state machine hazard when two state conditions are evaluated in a single program scan. We fall from one state to another just like a C switch case without the break statement. The problem is that the second rung can overwrite the variable or action of a previous rung. It’s another way of describing the last-rung-wins argument. As seen in the previous structured text article, this can get tricky when we attempt to change variables on the state transitions (one-shot style). The alternative is to use unconditional jumps which can lead to spaghetti code.
-
State-transition stabilizer: A timer that prevents an immediate state change. A classic example is a glitch timer that accommodated contact bounce.
Tech Tip: Things can get messy when we consider the real-world implication of contact bounce. This is especially true as the closed state is expecting the sensor to remain closed. To mitigate this problem, we include the glitch timer with a PT set for longer that the anticipated contact bounce.
Troubleshooting function block diagram programs
Before we conclude, I’d like to make a quick comment about debugging function block diagram. In my opinion, it is almost identical to debugging ladder logic. In figure 4 we see the green highlights. Here are a few observations:
-
The inversion bubbles are subtle and easy to miss. In this example, both xEnable and xSensor input are TRUE (after the inversion). Yet, the AND (&) block evaluates as false as xReset is not active.
-
The series connected set and reset operators (coil) could be a source of confusion. In this example, the “wire” connector is green however the box is blue (off). This implies that variables xCoilDrive and xValid are FALSE.
-
The AND (&) function block has a little yellow star in the lower left corner. This indicates that the block is extensible. This may be used to expand the block to accommodate an additional input. It has nothing to do with the runtime status of the PLC.
Figure 4: The green highlights show the real-time status of the variables for S7-1200 PLC.
Is function block diagram preferable to ladder and structured text?
People certainly have strong opinions on this topic. Perhaps the most quoted phrase is that technicians prefer ladder logic. This implies that we should use ladder whenever possible.
Fair enough.
Yet, this article demonstrates that function block diagram and ladder logic are nearly identical—or at least so for the state-based motor controller logic. It would be disingenuous to recommend one language over the other from a program structure or a troubleshooting perspective.
At the same time, we must recognize that not all programs are state machined encapsulated into a UDFB. There will be times when program clarity is enhanced by deliberately choosing one language over the other.
Perhaps that is why IEC 61131-3 includes the five languages.
Use each to its strengths.
Parting thoughts
At this point, we have UDFBs to evaluate including ladder, structured text, and function block diagram. Each performs the same function and has the same input and output mapping. This allows us to make an apples-to-apples comparison.
Where do we go from here?
Do you have a particular application that would sway the language preference in another direction? I’d love to hear your thoughts.
Best wishes,
APDahlen
Related articles by this author
If you enjoyed this article, you may also find these related articles helpful:
- Wireless Pushbuttons for Industrial Control Panels
- What is an Ice Cube Control Relay?
- DigiKey’s Guide to the Megger Insulation Resistance Tester for Motor and Cable Testing
TL;DR
- A state machine encapsulated into a UDFB provides an excellent opportunity to compare IEC 61131-3 languages.
- Ladder logic and Function Block Diagram share a similar layout for the featured state machine. Both are easy to troubleshoot. This fact downplays the age-old recommendation to program using ladder logic.
- Function block diagram with the waterfall organization, may appear more bloated than the equivalent ladder logic. However, this is not a universal statement as analog or numeric programs may be more compact.
- Be wary of rung fall-through where consecutive states are executed in a single program scan.
About this author
Aaron Dahlen, LCDR USCG (Ret.), serves as an application engineer at DigiKey. He has a unique electronics and automation foundation built over a 27-year military career as a technician and engineer which was further enhanced by 12 years of teaching (interwoven). With an MSEE degree from Minnesota State University, Mankato, Dahlen has taught in an ABET-accredited EE program, served as the program coordinator for an EET program, and taught component-level repair to military electronics technicians. Dahlen has returned to his Northern Minnesota home and thoroughly enjoys researching and writing articles such as this.