Creating compliant function block libraries
One of the problems with software development is that the increase in efficiency is very low. No Moore’s law here; no doubling of the efficiency every 18 months. And it is even worse: with increasing functionality, the complexity increases exponentially. To solve this one needs modern software development tools and modern development methodologies.
Part of a modern software development methodology is creating re-usable components, called function blocks, which contain part of the application software functionality. This process is called encapsulation.
The next step is to integrate these tested and documented components in a library, from which everybody in and outside the organization can make use, and in this way create extended application software faster and with fewer errors.
Edge triggering vs level-controlled function blocks
There are 2 types of function blocks. Those that are initialized (started) at a rising input and stay active till finalized or aborted; and those that are active as long as the corresponding input is high. The first are called edge-triggered, and the second are called level-triggered.
An example of edge-triggered functionality is a move-to-position command which, after being initialized via the input Execute, runs till finalized. An example of a level triggered functionality is a PowerOn function, where the power is switched on as long as the relevant input (Enable) is set. Notice that the Enable input pairs with Valid output, and that Execute pairs with Done.
Sometimes it is important to choose a level-controlled model rather than an edge-triggered model. For the detection of a rising edge in a function block, two PLC cycles are necessary. Thus, if the requirement is to be able to process a new value in each cycle, an edge-triggered model cannot serve as a solution. In this case, a level-controlled function block model is the preferred way to implement the required functionality.
Example of edge triggered
The basic function block is the Edge Triggered Etrig. This is the edge triggered functionality in its most simple form with only an Execute as input, both in textual as well as in graphical representation:
The corresponding state diagram is shown hereunder, and consists of the Dormant, Executing, and Done linked to Resetting and back to Dormant for the normal behavior, and via Error for the irregular behavior. For implementation such as state diagram can be easily converted to SFC or ST. Examples of this are included in the specification.
The corresponding timing diagrams for Etrig are shown here, where the 3rd diagram shows the behavior in case of an error.
Extending the basis with aborting
In addition to this one can add the aborting functionality to abort the process, which includes additional states Aborting and Aborted.
Also, this state diagram can be easily converted to SFC or ST, for which examples are included in the document.
Including timer functionalities
On top of the abort functionality (or even without this functionality) one can add timers to make the functionality more robust. Basically there are 3 options for timers:
- TimeOut (To): the overall operating time of the defined operation should be lower than the time (in µs) as specified by the input value udiTimeOut
- TimeLimit (Tl): here the time limit is set that the operation stays within the cycle time. In that way a longer operation can be divided over several cycles
- And the combination of both (TlTo).
What udiTimeLimitdo does
A function block could, for example, complete a complex task in a loop. The larger the task is, the more time that is consumed in the current task of this function block. The udiTimeLimit parameter can define how much time per invocation is permitted for consumption in the respective function block.
What udiTimeOut does
When processing its cycle action, a function block can be forced to wait for an external event. It can do this in an internal loop (BusyWait) or it can check in each cycle whether its task can be completed in full. The udiTimeOut parameter can define then how much time is permitted for consumption in the xBusy state.
Level-controlled function blocks
For level-controlled functionalities a similar set can be identified with similar states:
Adding the timers Time Out, To, and Time Limit, Tl, and the combination TlTo is similar. However there are 2 additional blocks for continuous behaviour, meaning it does not stop so there is no Done state: LConC for Continuous Behaviour and LConTlC, including the time limit:
Datasheets of edge triggered and level controller function blocks
Included in the specification itself are the datasheets for all the listed function blocks. This includes the state chart, the implementation and for the edge triggered FBs the timing diagrams.
Also for the LCon functionality, an example of the corresponding ST code is included with object orientation. In the appendix an ST code example for the ETrigATlTo Function Block according to IEC 61131-3 2nd Edition, meaning no object orientation added.
Users can create own libraries within the PLCopen concept, which includes both level and edge controlled functionalities, which are extended by aborting and timer functionalities. To complete this specification examples in ST are shown, both in the classical as well as in the object oriented approach.