IEC 61131-3 Function Blocks

kvogel · Jan 17, 2019

Geospark said:
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.

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.

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

I agree with your detailed analysis but I don't think it's a case of one or another however. A function block is a subroutine but I tend to reserve the term subroutine when referencing fixed code that is called by a jump & return type command usually internal to the main code. The term function blocks is used for code implemented with instances and often contained in a separate vessel from "main" code (POU). Maybe it's an incorrect usage for all platforms, but with what I'm familiar with it's a valid way of differentiating.

Geospark · Jan 17, 2019

These terms are not interchangeable...but their logical Functions are...

kvogel said:
I agree with your detailed analysis but I don't think it's a case of one or another...

I'm sorry, not "a case of one or another" when it comes to what - using these "terms" interchangeably or using these "methods" interchangeably?

kvogel said:
...A function block is a subroutine but I tend to reserve the term subroutine when referencing fixed code that is called by a jump & return type command[/B] usually internal to the main code. The term function blocks is used for code implemented with instances and often contained in a separate vessel from "main" code (POU). Maybe it's an incorrect usage for all platforms, but with what I'm familiar with it's a valid way of differentiating.

This is the distinction I keep trying to make here with regards using these two "terms" and using these two "methods"...

A Function Block is not a Subroutine and a Subroutine is not a Function Block. They are separate entities, using separate terms and separate implementations, as I have suggested and explained. However, you may use one or the other to logically encapsulate code in a similar manner. Logically, they are functionally similar, but that is where their similarities end.

I do not ever use the term "Subroutine" to describe or reference a Function Block and I do not ever use the term "Function Block" to describe or reference a Subroutine, while typing or speaking of the subject.

Again, I am not, or have not ever said that one "is" the "other" and that we may use either/or "term" for either/or "method". I am not muddling these two together. I am clearly describing, I hope, their uniqueness at all other levels except their logical implementation within a Program.

How you describe reserving these two terms for certain usage scenarios is how I would also use them, but not because I choose to. I use these terms this way because that is what they actually are. A Function Block is instantiated and called either within a Main Program or a Subroutine. A Subroutine is prioritized within a Main Program and sequentially scanned. So we cannot, or should not really say that a Function Block is a Subroutine or vice versa. Again, they are separate methods of achieving similar results, but not to be thought the same.

For me, the "valid way of differentiating" between the two is to understand them. Once we understand them, the terms become just that, simply terms, and then we are just into logical semantics.

Regards,
George

kvogel · Jan 17, 2019

From Wikipedia

In computer programming, a subroutine is a sequence of program instructions that performs a specific task, packaged as a unit. This unit can then be used in programs wherever that particular task should be performed.

Subprograms may be defined within programs, or separately in libraries that can be used by many programs. In different programming languages, a subroutine may be called a procedure, a function, a routine, a method, or a subprogram. The generic term callable unit is sometimes used.[1]

I can and do write a function block and call it only once in one place in a program. The function is enabled true all of the time so it s being run sequentially. The main code jumps to the function block, the function block runs and then the main code resumes.

We are basically saying the same thing, I'm not being overly strict with the terminology because it isn't that clearly defined. A function block is clearly a subroutine, but a subroutine can be many things other than a function block.

Cheers

Geospark · Jan 17, 2019

I agree that we are saying pretty much the same thing but I keep seeing you reference a Function Block as "being" a Subroutine. That, and only that, is what I am questioning here.

kvogel said:
...In different programming languages, a subroutine may be called a procedure, a function, a routine, a method, or a subprogram...

Good old Wikipedia...

"Computer" programming language terms are somewhat different to "PAC" programming language terms. A Subroutine being traditionally called, among other things, a "Function" in computer programming languages does not mean that within the PAC programming languages, as defined by IEC 61131-3, a Function Block "is" a Subroutine. A Subroutine here being a very specific entity within the PAC World.

A Function Block may be used to, or referred to, as executing what we would traditionally have called a "Subroutine" of logical code. But that is not the same as saying that a Function Block "is" a Subroutine, especially in the PAC World. In the PAC World, Subroutines and Function Blocks are clearly defined as being different things. But they may both perform a similar task, which could be classified as executing a traditional "Subroutine" of logical code.

Within the PAC World - when I create and instantiate a Function Block, I could say that I know that my Function Block is executing a block of code. I could also refer to this block of code in the traditional sense of being a Subroutine of code. But either way, I do not refer to the Function Block itself as "being" a Subroutine by virtue of its existing. A Subroutine in the PAC World is a higher-level object residing beneath and serving the Main Program POU. In this sense, a clear distinction can be made between the two in the PAC World.

That is my honest understanding of it based on what I know and have worked with for many years.

I'll probably leave it at that as we could probably keep going around in circles here while splitting already sparse and thinned hairs!

G.

AutoMax · Jan 18, 2019

Personally, I don't see it as a huge problem in MultiProg (and I've troubleshot and edited applications written by the OP.) Fuji Micrex are also MultiProg based, and Fuji factory programmers do the same thing.

I dislike it in the Rockwell world, but that's for a host of different reasons...

Highland Controls · Jan 19, 2019

Yes, I was a bit of a cowboy before, but now I have to get in line with the corporate guidelines. This will become a debating point soon as to if I should use this style(called function blocks whose only purpose is to organize code).

Geospark · Jan 20, 2019

Highland Controls said:
Yes, I was a bit of a cowboy before, but now I have to get in line with the corporate guidelines. This will become a debating point soon as to if I should use this style(called function blocks whose only purpose is to organize code).

In my experience, "Corporate" governance, especially over automation related aspects of a business's production processes, should only stipulate general rules to be adhered to, such as the IEC 61131-3 Standards. Apart from that level, it should not be focusing in as far as how logical data is actually organized within projects following the Standards. Unless you mean Engineering guidelines more so than Corporate, I would find it unusual for them to be so hyper-focused?

Our multinational company has such general rules on how we implement automation within our Engineering Departments, but they are based on US norms, which is not really the best way to approach it, in my opinion. It's too generalised for plants based literally all over the Globe. It should be regionally controlled. I've had discussions with my counterparts in various parts of the World on the matter and some of us have had further discussions with the powers that be. Sometimes we can make them see sense and allow a change in the requirements but there's usually months of Red tape involved. Probably to dissuade us, I'd imagine?

Although, once I'm trained and certified, my Plant Manager pretty much trusts me to do whatever is necessary to improve and sustain our business (shhh!).

To reiterate my earlier assertion - if someone is advising to replace an IEC 61131-2 Function Block with an IEC 61131-2 Program, then you are welcome to send them to me and I'd be more than happy to discuss it with them.

Regards,
George

IEC 61131-3 Function Blocks

kvogel

Member

Geospark

Lifetime Supporting Member

kvogel

Member

Geospark

Lifetime Supporting Member

AutoMax

Lifetime Supporting Member

Highland Controls

Member

Geospark

Lifetime Supporting Member

Similar Topics