Return to the Industrial Control and Automation Index
The User Defined Function Block (UDFB) is to the Programmable Logic Controller (PLC) as the function is to the microcontroller. Both are structures used to simplify your code making it easier to write, troubleshoot, and maintain. They are also essential structures that allow the code to be reused in the future.
This article outlines the construction of a simple UDFB for use in the Arduino Opta. This UDFB was developed using the Arduino PLC Integrated Development Environment (IDE) version 1.0.3.0. The generalized UDFB ideas and procedures presented in this article are applicable to most PLCs.
What is a UDFB?
The UDFB is one type of Program Organizational Unit (POU) used to organize your PLC code as described in the IEC 61131-3 standard. From a C programming perspective, the UDFB is like a function with multiple inputs and outputs that includes the static keyword for all variables. In other words, the UDFB has memory that exists across function calls.
For clarity we should mention that there is another POU that is simply called a “function.” Unlike the UDFB, the function POU does not feature static memory. Another way of making the comparison is using the language of digital logic, the UDFB is a sequential circuit while the function is a combinational (no memory) operation.
To keep things simple, we purposely conflate the function with the UDFB. Form a programming perspective, the operation of a function can be performed by a UDFB, but not the other way around. If you can construct a UDFB you will have no problems constructing the simpler function.
Tech Tip: A mechanical and an electrical technician were working on a diesel engine. It didn’t go particularly well, as both were convinced the problem was in the other technician’s wheelhouse. So, it is with UDFB. Even the best constructed and documented UDFBs will be met with some level of suspicion, especially several hours into a troubleshooting event. The same rules for constructing a good microcontroller function apply to the UDFB. Make them simple and make them do one thing very well. Don’t be clever. Instead, be concise and clear.
How to construct a UDFB
One of the most difficult tasks is defining the behavior of a UDFB. We must understand the input parameters, the outputs, and the tasks to be performed by the UDFB. We must also understand how the UDFB will be instantiated (used or called) by the top-level program. In my opinion, this is the hardest part of the entire process, as the mechanics of writing the UDFB are relatively simple.
Tech Tip: There is an old saying attributed to Fred Brooks in his classic book “The Mythical Man-Month. Paraphrased, it says we need to plan for an iterative design process, “Hence plan to throw one away; you will, anyhow.” I wish it wasn’t like that, but often we need to build and then instantiate the UDFB as part of a learning experience. It’s only by building the first prototype that we can understand how it operates and the impact it has on the larger software project. See also wicked problems.
As an example, we will construct the UDFB as highlighted in Figure 1. This block is used as part of a state machine. Its purpose is to serve as a gatekeeper for the rung. If the machine’s uiState state variable is equal to 1, and the block is enabled, the remainder of the line is executed. From a C programming perspective this is like a switch statement with uiState as the index. Note that the prefix ui is Hungarian notation for an unsigned integer.
This particular construct results in a relatively clean ladder logic. The English description of Rung 3 goes something like this:
- If the UDFB FBuiEqual is enabled and the machine state (uiState) continue
- also if the master switch is on
- also if the momentary selector switch is in the forward position, change to state 2
- else if the momentary selector switch is in the reverse position, change to state 4
We will stop here as the states are not important to our UDFB discussion. Perhaps we can explore the state machine in a future article. Instead focus on the UDFB and the two conditions it is looking for: if enabled and if the values match.
Utility of the “Set Output Line” feature
Notice that the rung continues from the UDFB from the xEqual line and not the ENO line. This is a convenient Arduino PLC IDE feature known as ‘Set Output Line.” Had we not used this option, an intermediate variable to hold the value of eEqual would have been required along with a second rung to perform the state change operation. This would have doubled the number of rungs reducing the code readability.
Figure 1: The highlighted UDFB is instantiated on rung 3 where operates like the switch statement in a C program.
Defining the input and output interface
The first step to constructing the UDFB is to identify the input / output interface as well as the required variables. This is done using the local variables table as shown in the upper part of Figure 2. Observe that there are two unsigned integers (ui) inputs labeled uiA and uiB. There is also a Boolean (x) output named xEqual. Not shown is the implicit “rung hanging” EN and ENO I/O. These elements are apparent in Figure 1 which shown the instantiated UDFB.
Tech Tip: As you know a PLC may be programmed in several different IEC 61131-3 languages. Things get interesting when we switch between languages. For example, the default EN and ENO lines to hang a block on a ladder logic rung are not universal in all languages. Clearly, a language such as structured text has no graphical rungs. Consequently, the “rung hanging” I/O has no immediate purpose or at least we should say, the purpose and implementation is open to interpretation. The Arduino design team appears to have disregard these lines such as when the EQ function is called in structured text: OUT := EQ( TRUE, FALSE );. As you can see, the EN and ENO lines are absent as the function only analyzes the two values to be compared.
By the way, remember my comments about “build on to throw it away?” There is bug in the UDFB. You will never see it with the ladder logic implementation, but it could be a problem with structured text. I leave it to you to discover the problem. Hint: how many input parameters (implicit and explicit) are required for our UDFB.
Define the UDFB operation
The table shown in Figure 2 contains two local variables including eEN and xisEqual. On rung one, we have an instantiation of the equal function. On rung two, we ask if the UDFB is enabled and if the values are equal. Notice that there is a subtle difference between the operation of our UDFB and the original equal function. As per the Arduino documentation the EN line for the EQ block is not involved in the operation. With the UDFB, we have placed an additional constraint that requires the block to be enabled as well as the value equal for our UDFB to evaluate as true.
Figure 2: The UDFB is constructed by defining the I/O interface, variables, and code.
Conclusion
The UDFB is a powerful, must-have, technique for PLC programming. The UDFB can simplify your code and provide a valuable library of pre-built and tested modules. At the same time, I would again caution you to program for clarity. Don’t be clever! A difficult to understand UDFB can add confusion and delay to the troubleshooting process. This is highly undesirable as PLC down is extraordinarily expensive when we consider the lost production, loss of goodwill, wasted material, idle workforce, and the high cost of overtime to get back on target.
Best Wishes,
APDahlen
About the 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. LinkedIn | Aaron Dahlen - Application Engineer - DigiKey
Return to the Industrial Control and Automation Index