Function Block/ AOI Demonstration

ndzied1

Lifetime Supporting Member
Join Date
Aug 2002
Location
Chicago, Illinois
Posts
2,852
After reading the post here http://www.plctalk.net/qanda/showthread.php?t=118379 by cd36, I thought the topic would make a great platform to demonstrate Function Blocks (AOIs). :site:

So I made this video: https://youtu.be/aYwH2O_QOQo

It is a little longer than I wanted it to be and it's not intended to be a "How To" video. But hopefully, if you have been wondering what this Function Block/AOI thing is all about, it will give you some idea about why they might be useful and why you shouldn't be afraid of them.

Hopefully I'll find more time and more topics to do videos on and will hone my skills to be better in the future.
 
Not sure what you mean?

A "Function Block" in CoDeSys can use any of the IEC61131 languages. You just have to select it when you define the function block. In the video I just used ladder because it seemed to make the most sense for that particular application.

See image below.

You can also place function blocks inside of each other.

I do not have a lot of AOI experience but I think most of the functionality has analogs in both systems. The video was just a quick example (and was too long as it is... :)

fb_definition.PNG
 
Its just an AB naming convention, Function Block is a program style within AB (using objects that look like AOI's oddly enough), Ladder is another and Structured text is a third.
 
Now I understand. Yes, the CoDeSys naming convention seems to have 2 separate definitions of what "Function Block" means.

One is a POU (Program Organization Unit) and the other is a programming language.
 
Yea I guess the AB convention is actually called Function Block Diagram. Being an AB only shop it stuck out.

Good video, I use Camtasia as well, it works well enough but has its glitches, I would use something else when you become a rich and famous YouTuber. :)
 
So we all understand the Standards a bit better...

TheWaterboy said:
Its just an AB naming convention, Function Block is a program style within AB...

...Yea I guess the AB convention is actually called Function Block Diagram...

AB? Not exactly. You may need to step back a "little" further from your "AB only shop"...

International Electrotechnical Commission (IEC) 61131-3 Programmable-controller-language Standard defines five standard languages (there are others) for programming both process and discrete controllers:-

Ladder Diagram (LD)

Function Block Diagram (FBD)

Sequential Function Chart (SFC)

Instruction List (IL)

Structured Text (ST)

These are internationally recognized programming languages. As such, none of the PLC/PAC manufacturers can lay claim to them. Further, FBD is a programming language. It should not be confused with a "Function Block"...

ndzied1 said:
Now I understand. Yes, the CoDeSys naming convention seems to have 2 separate definitions of what "Function Block" means.

One is a POU (Program Organization Unit) and the other is a programming language.

Similarly, the definition of "Program Organization Units (POUs)", "Function Blocks" or programming languages are not defined by CoDeSys. They are also defined by the IEC 61131-3 Standard.

However, to clear the waters just a "little" (I have to go home soon!) -

Again, programming languages, such as FBD, are not Function Blocks. So, and contrary to your thinking, FBD in CoDeSys is not one of two types of "Function Blocks", the other of your thinking being POUs. A POU is not a type of Function Block. It's the other way around my friend...

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

1. Programs
2. Function Blocks
3. Functions

(Whisper 1: You can see these in your screenshot above)
(Whisper 2: Again, none of these have anything directly to do with programming languages)

Skipping Programs...

In lay terms -

Function: If the conditional values of the function's internal memory are fixed, then the return value (output) will always be the same, for the same input parameters.

Function Block - is any function where the conditional values of the internal memory may differ independent to the input parameters. That is, feeding the same input parameters to the function will not always yield the same return value (output).

Rockwell Automation's "Add-On Instructions (AOIs)" are their proprietary design of a Function Block, as defined in the IEC 61131-3 Standard. We don't, or should not, use the term "AOI" in general when referencing all specific versions of Function Blocks. The term "AOI" is quite specific to Rockwell Automation's version of a Function Block.

Also, and again to be clear, these "AOI" Function Blocks have nothing to do with the Function Block Diagram (FBD) programming language, of which Rockwell Automation also happen to provide, along with the other prescribed programming languages defined in the IEC 61131-3 Standard. These programming languages can of course be used within and around these AOI Function Blocks, or any other company's Function Block versions that also provide the same programming languages.

As you rightly illustrated, Function Blocks are basically the same as any other instruction that has underlying predefined logic, such as a simple Timer or complex FAL instruction. However, if we look above at my brief explanation of what a "Function" is under the IEC 61131-1 Standard, we should be able to determine that the likes of a Timer instruction is simply a Function, and not a Function Block. If you give it the same input parameters over and over it will always give you the same return value (output). The same could even be said for the more complex instructions, such as the Rockwell FAL instruction. There is no exposed mechanism for the End User to manipulate what the internal memory or logic of the instruction is doing. These are just classed as Functions. Functions are important, of course, so I'm not giving them a hard time here! Just making a slight but important distinction.

Norm, if I may, you are perfectly correct to use the reference "Function Blocks / Add On Instructions (AOI)", as that is precisely what they are.

However, and I don't want to seem to be in any way negative towards your efforts here, which are commendable; I always like to see good and relevant help being provided, and I know you were trying to be general in your demonstration. The thing is, proprietary versions of Function Blocks can be very functionally specific. You have referenced a post here on the Forum that specifically mentions using Studio 5000, and hence Rockwell's specific AOI Function Blocks. Your post here is titled "Function Block/ AOI Demonstration". All this, including your video intro, strongly suggests you are going to demonstrate AOIs in Studio 5000, but then goes on to using "Function Blocks" in CoDeSys, and not Studio 5000 Logix Designer. That is not what I was expecting to see when the video started. Also, while using CoDeSys to demonstrate, you are referencing Rockwell AOIs, products and features. In my honest opinion, I think you are muddying the waters for viewers with the "AOI" and Rockwell references in the video and what they then expected to see.

All I'm suggesting is that you could make it just a general "Function Block" overview video, using CoDeSys as an example, to outline what the fundamentals for most all Function Blocks are and how they are useful. And don't reference AOIs or Rockwell so much or at all.

But the video was generally very good and informative. So thumbs up on that. :site:

Whatever way you decide to go, I do hope you take my advice as intended - constructive criticism. ;)

Regards,
George
 
Last edited:
Thanks for the suggestion, but I really don't *need* to do anything - the description given didn't line up with expectations from my frame of reference, that's all the point I was trying to make.
 
Here's my frame of reference...

That's why I try to choose my words carefully. I intentionally said you "may need" rather than you "do need". But either way, it was intended in a light-hearted and humurous manner. So I hope you didn't take it as me trying to be smart or condescending with you. That is just not my style.

If from your point of view you feel you know what you are/were about here then of course the choice is yours to make whether or not to step back and look at a certain bigger picture I was trying to paint. But, in my opinion, your statements above, and Norm's, "appeared" (< careful word again) to display a certain leved of misunderstanding on the subject. Something I, with good intentions, tried to explain and not just for yourselves, but for other readers too. It just felt like you were a bit too focused in on AB and that they "own" FBD and that FBD is the same as a Function Block. I just tried to clarify those apparent misunderstandings. In your own words..."That's all the point I was trying to make".

If you did not take, or feel you *need* not take anything positive from what I explained, then I am sorry to hear that and to have wasted your time reading it. I certainly did not feel it was a waste of my time.

Regards,
George
 
George,

Thank you for detailing the definitions and referencing the IEC standard. I didn’t want to scare people away with a lot of standard details but of course your definitions are correct and we should all try to be as clear as we can be.

Just a couple other comments. (And I’m on a phone so please excuse any spelling errors)

- I’m sorry if I gave the impression I was trying to solve the exact system in the post I referenced. I just thought the problem statement made for a great example of a system that could benefit from using function blocks.

- I haven’t read the IEC spec (and probably never will) but I don’t think a timer is a Funcion. All of the functions I have used do not have to be declared. Things like the MOVE instruction, math things like SIN() & COS() or even a scaling instruction like the famous RSLogix500 SCP (Scale with parameters) are for sure functions. However, with timers and counters you have to declare an instance of each timer or counter you will use. It would be interesting to see if you can write a counter as a Function that works just like the built in CTU one. I think you will need to use a Function Block.

- IMO it is unfortunate that IEC chose to have the name of a language and the name of a POU type be so similar. Obviously this can be the cause of much confusion.
 
Time to rewrite the memory banks!...

Hi Norm,

I had previously read the IEC 61131-3 Standard, and had some training based on it, but it was some years ago, I will admit. So I was recalling the description of, and example of, a basic Function from memory. It was a poor passing example on my behalf of which I did not double-check. I'm just too busy these days while trying to post so I'm not always verifying my understandings in the more thorough manner I usually like to.

So thank you for the corrective prompt!

Yes, you are quite correct. A Timer, such as a TON timer instruction as we know it, is indeed a declarable Function Block, and not just a non-declarable Function, such as a Move, which is what I was more thinking of. A TON Timer is in fact a classic example of a Function Block, now that I recall a little better...

(This is in general Norm, and not assuming you do not know it)...

As I mentioned, from one invocation to the next, Function Blocks can have a different return value (output) even when the input parameter values are identical. For instance (< pardon the pun!), as the Accumulated (ACC) value for a TON may retain different elapsed times for the same input parameter values, we can say that any instance of the TON Function Block could have a unique return value for this same input condition. For a Function Block, the fact that internal memory allows them to return different outputs despite repetition of the same input; this means that, any time we wish to use the TON Function Block, we need to create a separate instance of the template for the TON. This process is known as, and as you mentioned Norm, declaration or instantiation and serves to reserve the memory needed for each instance of the TON Function Block object. In this way, each memory instance of the TON object will contain the identical variables declared at instantiation by predefinition. As each instance of the TON object is identical in memory at the variable definition level, it is also necessary to give each instance a unique identifier while being instantiated.

That's all basic enough stuff, as many of us know, and is second nature to us as we program, perhaps without considering it too often, if at all. So I suppose it probably does us no harm to rewrite it to our memory banks every once in a while, myself included.

Function Blocks of course exist in many different forms from many different software packages from many different automation companies. But they all still conform to the IEC 61131-3 Standard. Many of the main players do of course just call them "Function Blocks" or "FB", such as the age old Siemens Step 7, or Mitsubishi MELSEC, or OMRON CX Developer. Schneider's Concept software also has predefined "Function Blocks", but for user-defined they use "Derived Function Blocks (DFBs)". And of course the ever popular manufacturer-independent CODESYS development environment also simply uses "Function Blocks". But Rockwell, being Rockwell, and a little later to the party than most (2007), decided to be "different", and call theirs "Add-On Instructions" or "AOIs".

ndzied1 said:
...IMO it is unfortunate that IEC chose to have the name of a language and the name of a POU type be so similar. Obviously this can be the cause of much confusion.

Yes, if we let it be. But in the interest of better understanding, which is what I'm all about here, I would say again that we may need to take a step back here and look at the bigger picture...

Maybe, and in hind-sight as they were late to the party, Rockwell chose to use this terminology so as to avoid the very "Function Block/FBD" confusion we are concerned with here? But, to be honest, I don't believe they needed to do so and nor should any other automation company providing IEC 61131-3 programming environments. In their defense, that is the IEC 61131-3 Standard's, we should not really be looking at these terms in the singular, as though they have nothing to do with each other and have completely unrelated functions. I have mentioned several times that FBD and Function Blocks are not the one and the same and this is true to say. But in my comments I did say that they have nothing "directly" to do with each other. As in they are not defined as being the same entity within the IEC 61131-3 Standard. But, in fact, Function Block Diagram is a programming language that the Standard introduced to make the use of Functions and Function Blocks more streamlined in a simpler construct. Most of the work is done upfront by predesigning and instantiating the Function Blocks. FBD is then simply used to thread the Function Blocks together. So because we primarily use objects such as Function Blocks in FBD; hence the name Function Block Diagram. FBD is designed to compliment Functions and Function Blocks. So while we should not mix the difference between the two up, they are very much intertwined in their implementation. They go hand-in-hand. Although, while FBD does requires the use of Functions and Function Blocks in one form or another, Functions Blocks do not require FBD and can be used in more than one programming language. The Standard's intention though is that Function Blocks are best utilized within a POU using Function Block Diagram programming language.

Analogous to this terminological misinterpretation, in a simpler form, might be us saying that we should not call the object that opens a "Door" a "Door Handle", as the lower level object includes the same word "Door" as the higher level object. But because a "Door Handle" is intrinsically linked within the use of use a "Door", the term is quite acceptable. In the same fashion, the term "Function Block" is quite acceptable along side the term "Function Block Diagram" as they too are intrinsically linked.

Norm, some more of my "dispensable" advice - if I was intending making any kind of programming basic concept videos, which include IEC 61131-3 defined objects, then I would at least be mentioning the Standard that the demonstration is based upon so that viewers could access further reference material. As for never having or intending to read this particular Standard? I would best advise anyone else mildly interested in the topic, let alone making videos on it, to at least have a brief run through on it. But granted, copies of these Standards are not free and are not cheap to purchase for the average Joe. But there are many websites which reference and discuss its contents at length and should be more than good enough to educate us on the topic.

So as not to seem detractory of the thread here, I still say good on you for taking the time to dispense what you know.

Regards,
George
 
Last edited:

Similar Topics

Please see attached file. I need this program in Function Block form but I am totally lost on this. Any help would be appreciated. Thanks!
Replies
8
Views
255
Hi! I am using a TM200CE40T PLC from Schneider to write data over Modbus. I have used Memory words (%MW) before using the Write variable...
Replies
1
Views
512
Hi folks. New to the forum, but been working with PLCs for several years now. Would like some advice on whether you would keep this logic, or...
Replies
9
Views
1,037
Hi Yes, I'm stuck again. Trying to define a Function Block. What I've put in there so far has been a straight copy/paste from the code (and that...
Replies
22
Views
2,628
Hello, We have a startup valve, that has to open on startup etc. We also want to know the flowrate throughe valve. They told me that in previous...
Replies
17
Views
2,704
Back
Top Bottom