Building a User-Defined Function Block (UDFB) Using Siemens TIA Portal

Automation and Control Industrial Automation and Control
1

What is a User Defined Function Block?

The User-Defined Function Block (UDFB) encapsulates your Programmable Logic Controller’s (PLC’s) code into a single testable Program Organization Unit (POU). This POU may then be instantiated multiple times from within a program or used as part of a larger library. The UDFB is like a function in the C programming language.

This engineering brief presents a Siemens TIA Portal UDFB designed to control and monitor a motor starter. We will also highlight some of the TIA Portal functionality that makes the numeric state machine easier to develop and troubleshoot.

The reader is assumed to have a basic knowledge of the Siemens PLC with a good understanding of ladder logic up to and including operation of the move function block.
Also, note that the code was developed and tested on a Siemens S7-1200 CPU 1215 FC.

TL;DR: The UDFB is an essential building block for your PLC program as a properly constructed UDFB can save time. It makes your code modular and robust with the potential to reuse of your tested code as a library across multiple projects. The Siemens TIA Portal software facilitates UDFB-based state machine development using high-level programming techniques such as constants (abstraction) for state names.

Figure 1: The motor starter is instantiated with time-based test values set for human interaction.
Figure 1: The motor starter is instantiated with time-based test values set for human interaction.975×671 94.5 KB

Figure 1: The motor starter is instantiated with time-based test values set for human interaction.

Tech Tip: The UDFB may be classified as either edge-sensitive or level-sensitive. An edge sensitive UDFB will be triggered (start) on a rising or falling edge while a level-sensitive block will be active while the input is active. Identification of the UDFB type is essential to understand and to then troubleshoot the block:

  • Edge triggered: Activates on a pulse (rising or falling edge depending on the design) and runs to completion or until aborted.

  • Level-sensitive: Actives only when the enable signal is present.

The UDFB featured in this article is level-sensitive. The motor starter’s xCoilDrive signal will be active when the xEnable signal is present.

Control of the motor starter

There are many ways to control a large industrial motor starter from the PLC’s perspective. They range from simple open loop control via an output pin all the way to network-based solutions that control and then monitor individual phase currents.

In this note, we will close the loop to verify that the motor starter has activated. This is done using the UDFB as seen in Figure 1. Specifically, upon receipt of the xEnable signal, the UDFB’s xCoilDrive output line is activated. An auxiliary contact from the motor starter is then fed back to the UDFB’s xSensor input.

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.

  1. 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.

  2. 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 timClose. Figure 1 shows the UDFB that has faulted from this state.

  3. 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.

  4. Opening: The motor starter’s contactor is transition from a closed to an open state. A fault is triggered if the contacts do not open within timClose as this implies that the primary or interposing relay contacts have been welded together.

  5. 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.

Ladder logic state encoding

There are several different ways of encoding states in ladder logic ranging from latches, set reset coils, all the way to numeric representation of the state. Our 5-state example could be constructed using any of the three methods. However, in my opinion the numeric method as shown in Figures 2 and 3 is the easiest to understand. I’ll admit that this could reflect my background in embedded programming where I prefer to encode states in a tree structure using the C programming’s switch-case statement.

Enumerated data types in ladder logic

It is easy to lose track of numeric states if we rely entirely on numbers. For example, referring to the closing state as the decimal number 1 has no intrinsic meaning. However, if we add abstraction, we can substitute a meaningful keyword for the number.
The Siemens TIA Portal provides a convenient enumeration method using constants as highlighted in Figure 2. Here we see that each state has a meaningful name. An example is the mapping of uiStClosing to the value of 1. In this example we are using Hungarian notation with prefix unsigned integer (ui) and state (st).

Figure 2: State encoding used for the UDFB states.
Figure 2: State encoding used for the UDFB states.1033×558 154 KB

Figure 2: State encoding used for the UDFB states.

The power of these enumerated states is shown in Figure 3 which shows the ladder logic network for the closing state. The network begins with a comparison operator to determine if uiState variable is equal to the uiStClosing constant—are we in state 1? Assuming we are in the closing state, there are three ways to exist including a jump to:

  • state closed: This is the natural progression as the motor starter transition from open to closed.

  • state fault: This occurs when the motor starter feedback is not asserted before timClose.

  • state opening: This transition occurs when the operator quickly changes their mind and attempts to open the contactor before it has fully entered the closed state.

Note that the logic includes a string move function (S_MOVE) that will copy “failed to close” to the strFaultCondition character array. This provides the technician a clear explanation for condition leading to the UDFB’s fault condition. This information may also be used for a larger HMI alarm system if additional code is used to consolidate the fault strings.

Figure 3: Network for the UDFB’s closing state with state next logic on the first three branches and the output logic on the last branch.
Figure 3: Network for the UDFB’s closing state with state next logic on the first three branches and the output logic on the last branch.975×399 52.7 KB

Figure 3: Network for the UDFB’s closing state with state next logic on the first three branches and the output logic on the last branch.

Tech Tips: Figure 3 includes several series connected set and reset coils. This provides a convenient and compact way to incorporate the output logic into each network. Please refer to this TechForum post for additional considerations for series connected coils and placement of set/reset coils. As described in the article, many people have strong feelings against the series-connected coils and the set/reset coils.

State machine symmetry and design overview

The numeric-based state machine is surprisingly compact and symmetrical with each state being closely related to other states. Each state closely follows Figure 3 (the closing state) with clear conditional jumps to other states with emphasis on clarity through enumeration.
If you can follow Figure 3, I am confident that the other states will be easy to follow. Further exploration of the remaining states is left as a homework assignment. Also, you are encouraged to download this PDF copy of the motor controller.

UDFB.pdf (88.1 KB)

Fault state logic

Before departing, we will briefly examine the fault state as shown in Figure 4. As before, we begin with a test for equality—are we in the fault state. This is followed by two branches:

  • If the motor starter is turned off (not enabled) and the reset button is pressed, we jump to the open (idle) state.

  • The last branch updates the UDFB’s blocks using series-connected set and reset coils.

Note that the motor starter must be turned off before the system can be reset. This prevents unexpected motor starts as the operator or technician must deliberately turn the system off.

Figure 4: Logic for the fault state.
Figure 4: Logic for the fault state.975×223 34.4 KB

Figure 4: Logic for the fault state.

Parting thoughts

A state machine may be constructed using a numeric state variable. This yields compact code perfect for UDFB encapsulation. In the featured example, each network encapsulates the state next transition as well as the output logic for each state.
While the featured code is still relatively simple, the method scales well when compared to alternatives such as latches and the set/reset coils. For example, a reversing motor starter would double in size. Yet, it is easy to follow the logic for each state network.

We would love to hear from you. Do you have a preferred programming method? Please leave your thoughts in the comments section. Also, give a like if you learned something from this post.

Best wishes,

APDahlen

Related articles by this author

If you enjoyed this article, you may also find these related articles helpful:

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.