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