IEC 61131-3 Function Blocks

Join Date
Oct 2012
Location
Richfield, Ohio
Posts
465
I am looking for some expert advice. I have always made function blocks both with inputs and outputs and without inputs or outputs. I make the ones without inputs and outputs as a way to organize code. I have a program that is called from a task, and within the program I call these function blocks. I have been told that this isn't good practice, and that I should make each of these function blocks a program, and then call multiple programs from the same task. I have also made function blocks(with inputs and outputs) that can only be used within the project. In other words, there are globals within the function block. I know this isn't recommended, but it is a good was to organize code. CoDeSys can use macros to make the code more compact, but Multiprog doesn't allow that. Please let me know your thoughts.
 
They said that function block should be "universal" and able to be used in multiple projects.
That is all nice and peachy when you have all the time in the world and make a lot of the same stuff. At 2 am in a dark factory, you're not gonna spend time making clean and easy to reuse function blocks. If it's specific code for that heap of cra... that nice customer's fantastic machine, go ahead and use global data. No one is going to be able to use any of that one-off code anyway.

But if you can, cut up your code into smaller bits that are useful in other projects. Like custom string-operations or calculations.
 
They said that function block should be "universal" and able to be used in multiple projects.

That is a sentence straight out of a textbook which isn't necessarily true.

Also, I would say that his view on transforming into programs should be based on how deep your code would go and not necessarily doing it automatically as he implies.

Also, outside of the process industry, it's very hard for your functions to be usable in several different places unless the company makes variations of systems.
 
The concept behind using function blocks is really about using multiple instances of the block in your program. In a perfect world the block would be abstracted enough that it could be used in other projects without modification but using more than 1 instance is enough. If you only need to use the code once you might as well use a program. I don't know if there is greater or lesser cost to running fb or programs.

Making a function block without any parameters would be functionally identical except that programs need to scheduled rather than instantiated and called on demand.
 
They said that function block should be "universal" and able to be used in multiple projects.


The function blocks must be "universal" and useable in multiple projects argument is b.s.

Function blocks are to arrange code in a useful manner. They are best used when you intend to use the same code repeatedly in different places in the program but can be useful just to compact a section of code or to write a section of code in a more appropriate language. Like an ST function block in a ladder program to manipulate arrays.

As far as changing global variables inside a function block is concerned, do what works for you. I personally lean toward function blocks that are self contained and all vars "enter and exit" through the inputs and outputs of the block. Its helps in code readability as there are no surprises happening. Also, your less likely to operate on variables from several places with unpredictable results. But there are times where a function block that works on the global vars to access another program is the cleanest way to do it.


Cheers
 
Subroutine v Function Block?...

Highland Controls said:
I am looking for some expert advice. I have always made function blocks both with inputs and outputs and without inputs or outputs. I make the ones without inputs and outputs as a way to organize code. I have a program that is called from a task, and within the program I call these function blocks. I have been told that this isn't good practice, and that I should make each of these function blocks a program...

...I have also made function blocks...that can only be used within the project...I know this isn't recommended, but it is a good was to organize code...

As you have rightly referenced the IEC 61131-3 Standard, I will too...

I posted this not too long ago here on the Forum...

Geospark said:
...The IEC 61131-3 software model defines three types of Program Organization Units:

1. Programs
2. Function Blocks
3. Functions

...

Programs, Function Blocks and Functions are designed to facilitate the organization of a logical "Task" i.e. series of instructions which performs a Task, or part of a Task. Therefore, Programs, Function Blocks and Functions are all classified under the Standard as a POU - Program Organization Unit. This is what the Standard intended them to be used for and that they be complimentary to each. The above are listed in descending order of functionality where the Program is the higher-level organizational unit which contains the Subroutines or Function Blocks and Functions required to perform the given Task.

Function Blocks are primarily used for bespoke, tailored and unique blocks of repetitive or convoluted code, whether small or large, to be used or called from within Programs, where the Programs more so tend to contain the higher level logical structures for the given Task. Function Blocks are often used to perform relatively smaller, but still important, sub-tasks or Subroutines within a Program, within a given Task, but may also be used to contain the equivalent of whole Subroutines. Function Blocks and Subroutines are generally interchangeable or comparable with notable similarities and differences. For instance, Function Block calls are often more efficient in their execution than Subroutines, but Function Blocks may often use more memory than comparable Subroutines.

My own breakdown of the three types of POU above, and how they are primarily implemented, would be -

1. Programs - used for high-level organization of Function Blocks and/or Subroutines for a given Task

2. Function Blocks - used for mid-level organization of logic for a given Program for a given Task

3. Functions - used for low-level organization of logic for a Function Block and/or Subroutine for a given Program for a given Task

There is nothing right or wrong with the use of Function Blocks as a relatively large or complex alternative to a Subroutine within a Program. Users have found good and varied uses for Function Blocks in consolidating repetitive, multi-call Subroutine equivalence within Programs. However, the use of Function Blocks to organize whole Programs to perform a given Task, or part of a larger Task, or even multi-Task projects, is not really advisable and not really what they were designed to do. They are intended to be used as a POU for organizing functional blocks of logical code rather than entire Programs.

But, is that what you have been doing, or?...

If the individual(s) advising to use a "program" (as underlined in your above quote) instead of using a Function Block actually means or meant that you should use a "Subroutine" instead of a Function Block, then in all essence Subroutines and Function Blocks at the programming level are pretty much the same thing and they are really just advocating one type of "Subroutine" over another. While that is a healthy debate in itself (which to use, when and where?), I cannot agree with anyone blanket advising that you should always use one or the other method of encapsulating blocks of logical programming code.

The only blanket advise I always give is this -

Neither is correct until you carefully consider the application at hand and which program organizational method may suit best. And knowing which may suit best is only possible once you know at least some of the differences between each method i.e. when to use a Subroutine and when to use a Function Block and when might it not matter either way?

For some, they don't necessarily follow that application dependency "rule" and may tend more to have a personal programming preference. That's fine too, if it suits the types of applications they tend to work on, or if it really does not matter either way.

So I cannot really say if the individual(s) advising you are firstly, actually referring to using Subroutines over Function Blocks, and if so then secondly, basing that advice on their personal and general preferences, or if they are actually advising you based on a specific application of yours, or type of application you tend to develop?

In a nutshell...

Subroutine v Function Block may be a valid debate here, but Program v Function Block is not valid, in my book, and the Standard's book for that matter.

Regards,
George
 
cardosocea said:
...why muddle the waters with Subroutine?

I didn't think I was muddling the waters by mentioning Subroutines? I was doing what I often do or have to do, based on the amount of info the OP has thus provided and the manner in which they contextualised that info. I was surmising that the apparent adviser here, whether it was through certain reading or a face-to-face discussion, may have been using the term "program" when they may have actually meant "subroutine", as opposed to an entire Program, as we would know it.

Advising to convert Function Blocks to Programs would not be good advice and would display a certain level of ignorance on the subject. So I didn't think that was the case here. I was thinking it's more likely they were using the term "program" loosely where they actually meant "subroutine", as that is an often advised way to go - either Subroutine or Function Block.

But again, a Function Block is essentially a Subroutine. So I do not generally see it as "out of place" to mention them in the same sentence, let alone a "write up".

POUs of type Function and Function Block constitute “Subroutines”, whereas POUs of type Program build the PAC's higher level “Main Program” routine.

It should not be too confusing.

G.
 
have a look at www.oscat.de for a very big library usable in any program. Most of them are FB, and they all call other Functions.
It will explain when you can use FB, And the main plus is they are tested.
 
Great write up, but why muddle the waters with Subroutine?

It's a bit of semantics.

Since function blocks are called via an instance, essentially running a copy of code, I see this as being different than a subroutine which, as commonly understood, is a jump into a section of code. Function blocks can be used like a subroutine but also have the potential for being much more powerful when used in multiple calls.

Cheers
 
It is not "Black and White" or "Black and Black" or "White and White"...

kvogel said:
It's a bit of semantics...

Perhaps, but it is lexical semantics we are talking about here. Taking my idiomatic expression above...

It is not Black or White - I've not ever stated that Subroutines and Function Blocks are wholy indifferent. I said they have both similarities and differences, of which we should be aware of, if choosing between using one over the other.

It is not Black and Black - I've not ever stated that Subroutines are Function Blocks and are instantiated, variable-declared and called in the same way.

It is not White and White - I've not ever stated that Function Blocks are Subroutines and are logically prioritised, parameter-assigned and executed in the same way.


kvogel said:
...Since function blocks are called via an instance, essentially running a copy of code, I see this as being different than a subroutine which, as commonly understood, is a jump into a section of code...

Platform independently - if we, for example, create a "Program" within a "Task" and add several Subroutines with logical functions all being executed in the sequence required to perform the "Task".

If we create another "Program" and instantiate several Function Blocks within the "Program", and call them according to the logical functions required to perform the "Task".

The Function Blocks are effectively, or in essence, performing the same logical role as the Subroutines. That is not me saying that a Function Block is a Subroutine or vice versa. It is me saying that, apart from how they are actually implemented within the Task, they may be used to execute blocks of code in a similar fashion while performing a similar Task.

So at the implementation level we can state that they are quite different, but at the programming level we can state that they are quite similar.

kvogel said:
...Function blocks can be used like a subroutine but also have the potential for being much more powerful when used in multiple calls...

I know where you're coming from here but don't forget that Subroutines may also be called or not called from several other sources. Parameters associated with a Subroutine may be manipulated to "reinstantiate" the Subroutine prior to execution. This can effectively make a Subroutine, containing intended reusable code, actually reusable. These methods exist and are in use as we "speak".

So that I am still being clear because people often think I'm choosing a side in these matters - I am not saying that Subroutines are as good as or better than Function Blocks. Again, I would point out, or advise, that deciding which or when to use either method of code encapsulation, to achieve certain Tasks, should be an application-dependant decision.

I've been keeping my comments as general as possible so as to focus more on the structural heirarchy of POUs and not really get into brand specifics. However, your last comment here would also prompt me to point out that the apparent power that Function Blocks may have traditionally appeared to hold over Subroutines has somewhat diminished in recent years. On certain platforms, such as Allen Bradley's Logix 5000, the power of the Subroutine has been increased to level the playing field somewhat with Function Blocks (AOIs). For instance, the introduction of Public Parameters at Logix Designer v24 allows Program parameter tags now be globally exposed within a project so Subroutines can reach and be reached beyond the local Program.

Subroutines and Function Blocks, while comparable at certain levels, are indeed separate entities. And we can say with certainty that they are not in the main functionally or logically used for the same thing. Subroutines tend to be used more for either one-off code within a Program, or reusable code across Programs or projects, but not usually reused within the same Program. Whereas Function Blocks tend to be used for reusable code either in or across Programs or projects, and reused within the same Program.

But again, and even if the lesser, there are and will continue to be applications out there using these methods where Subroutines are being used more than once in a Program and Function Blocks are being used to execute substantial one-off blocks of code, never to be used again.

Regards,
George
 

Similar Topics

Hello, I have a small programming task that I need help solving. I have to: * Create an analog input (4-20v)and a digital output * The analog...
Replies
45
Views
24,976
I was poking through the Stackoverflow PLC Tag when I saw this answer to a question about converting a Real to a DWord and back again. What...
Replies
8
Views
2,863
Hello and happy new year! I would like to further understand who needs to design by this standard and is it a requirement for everyone or only...
Replies
3
Views
1,751
So Ladder is easy to read graphically, most everything can be coded in ladder, and it represents wiring diagrams the closest. SCL and ST are good...
Replies
5
Views
1,672
Hello, I have been looking at the Yaskawa website for documentation on G-code sample programs. I was unsuccessful at finding any IEX 61131-3...
Replies
9
Views
2,737
Back
Top Bottom