CoDeSys 3.5 - POU Types and Languages
What Is A CoDeSys POU?
A POU is an object of a specified type and language, it houses code that is called by a Task or another POU.
You can create a POU by right clicking on the “Application” object from the Device Navigation Pane and selecting Add Object >> POU
The “Add POU” window will open, from here you can create a new POU to add to your application. (Pictured above)
Name: The name of your POU
Type: The type of POU (this is covered on the next page)
Implementation Language: The language of the POU object. There are 6 options available that cover 5 different languages. The different languages have pro’s and con’s depending on what you are trying to achieve.
We will cover more on Implementation Languages later in this lesson pack.
Clicking Add will add the new POU to your Application object.
CoDeSys POU Types
There are 3 types of POU:
- The main POU type, if you’re not trying to create a re-usable code module, this is the correct POU type to use. A program type can be called by another program type or a Task and can call other programs, function blocks or functions.
- Function Block
- A function block POU is the most versatile POU type. It enables you to write a function and use it multiple times in another POU. Function blocks are declared at design time, they are given an instance in the application. This means that if a function block is used more than once, it is named, allocated memory and all instances of that function block remain separate to each other.
- A function block can be declared as a variable type
- Full object orientated programming is supported with Function Blocks using the “Extends” and “Implements” functions. These are not covered in this Lesson Pack, for now, simply ensure they are left blank. If your CoDeSys has check boxes for “Final” and “Abstract”, these should also be left unchecked.
- A POU that has a single output, declared at creation. A function is NOT created as an instance like a function block is. It can be used many times in your application, but the result is not retained in memory once executed. Your application must make use of the function and move the result to memory if it is to be retained. Functions such as timers are not suited well to functions as their elapsed time is lost every time the function completes.
CoDeSys 3.5 Languages
POUs can be written in 5 different languages, each have different strengths and weaknesses depending on the application that is being designed.
- Ladder Logic Diagram
- The most commonly used language, Ladder Logic excels at basic logic such as input / output control, timing and basic functions.
- Ladder reads from left to right, top to bottom. Each row (called a network) consists of conditions to check on the left and outputs to set on the right. Function blocks can appear either to the left or right depending on what the function block is doing.
- Complex statements such as IF, WHILE, CASE are not available in Ladder Logic, although they can be replicated if required
- Structured Text
- Commonly used for complex control, algorithms and repetitive functions.
- Structured Text is a written language and has no graphical properties. This can make it hard to read and follow, especially if proper notation is not followed
- Structured Text is harder to learn than other languages
- Complex statements are all supported
- Function Block Diagram
- Very similar to Ladder Logic
- Functions only are used to build the POU, there are not contacts / coils available
- Used often to build a sequence of calls to other POUs
- Instruction List
- Instruction list has recently been deprecated but remains for now in the CoDeSys system. The reason for its depreciation is it is difficult to write, read and follow and offers very little in value over other languages.
- Sequential Function Chart
- Commonly used for State Machine architecture, Sequential Function Chart reads like a flow diagram. Using Transitions and Steps, the program flows downwards with sequential and parallel code steps executing until either the flow finishes or jumps to the beginning again.
- It is easy to induce errors with SFC by not ensuring the flow is configured correctly
- SFC allows each step be assigned actions, these actions can be based on events such as “entry”, “exit”, “executing”. When an action is assigned, a POU is created and the option to choose a language is provided.
- Advanced users can create very complex architectures with relative ease
- Continuous Function Chart
- Similar by nature to Function Block Diagram, the POU consists of mainly calls to functions.
- The design is 100% graphical, with wires connecting inputs and outputs between functions
- Used mainly for small functions
- Is not an official IEC supported language