Siemens S7 TIA Portal - FC / FB

Hi All,

Relatively new to Siemens after years and would like some input from and experienced Control Engineers on here who could explain their decision making process when it comes to the choice between using a Function or Function Block at the concept stage of program development?

I am fully aware that FC's have no memory (although can read/write to a Global DB) and that FB's have Instance DB's as memory areas.

However, I have seen a variety of programs which include combinations of either function, or even made up of only FC or Only FB (obviously aside from the required OB).

I know that FB's are generally assigned to repetitive / standard logic with one general FB supporting specific Instance DB's, but again, I've seen FC's implemented to control several devices of the same specification (fieldbus motors for e.g).

Any advice with maybe a practical example(s) would be great thanks!

If starting with a clean sheet of paper, functions should be given input parameters and return a value. Use function blocks for everything else.

There does seem to be slight variations in some PLC manufacturers in the difference between FC (FUN) & FB (FUN BLOCK), in the case of Siemens I suggest you read this it may explain it a little better.
https://instrumentationblog.com/dif.... It helps in maintenance and troubleshooting.

Summary

It boils down to what OP has already written: FBs have internal per-instance persistent memory; FCs do not. When the former is convenient or necessary, then use the FB. Otherwise the FC can do the trick.

TL;DR

Sorry this is long-winded, but that is how I roll.

Both FCs and FBs are useful where a certain sequence of logic needs to be repeated and/or re-used in multiple places, but with different inputs and outputs. An example would be level control of several otherwise identical tanks, where the control algorithm involves more than a Start/Stop Circuit pattern or a PID block, such as lead/lag logic to run multiple pumps.

Even singly, they are useful to encapsulate a sequence of logic that can be easily understood in the calling program, and so make the calling program easier to read and understand with a single instruction block with a descriptive name e.g. "Average." A related benefit is reliability, where a well-tested and well-reviewed FC or FB is known to do its one thing correctly, so when debugging one can usually skip over the internals. This is also related to something called "separation of concerns", which is a principle used in programming to separate an application into units, with minimal overlapping between the functions of the individual units.

To get to the question asked, OP has already stated the primary difference, and the reason to choose, between the two: the FB has per-instance internal memory; the FC does not. That is

• per-instance and internal - each instance of an FB carries with it the data for the part of the process it models. So it is a convenience to the programmer to not have to declare those data separately, e.g. in the global DB, for each instance of the FB. An other advantage to this is the separation of concerns principle mentioned above: if nothing else can interact with the internals of the FB, then there is increased reliability and confidence that the FB will do what it is programmed to do without interference by the rest of the program.
• memory - PLCs are about time; on each scan they operate on a snapshot (i.e. of the input inputs) of the real process taken at a discrete time, but that input snapshot only represent the current time (scan). "Memory" maintains a snapshot of the model's data from previous or earlier times (scans).

Simple examples

Averaging two more external numbers' current values requires only those values, so an FC, with those tags as inputs, the average as an output, and no internal memory, can do the job.

However, if we wanted to also filter that average over time, then the code would need memory of previous value(s), and that would be a reason to move the algorithm into an FB.

An algorithm that includes evaluation of a one-shot (edge trigger) on an input bit requires an extra bit that remembers, i.e. maintains memory of, the state of the input bit from the previous scan. This would be suitable for an FB with a per-instance internal persistent memory Boolean (bit) for the one-shot.

That said, using external parameters that are both inputs and outputs ("InOut" parameters in some languages) could make something work with an FC, where those external persistent memory parameters become proxies for the internal memory of an equivalent implementation in an FB. The advantage might be easier access to the parameters e.g. for an HMI. The disadvantage as noted above is the requirement for the programmer to declare those parameters explicitly in global memory for each FC "instance," as opposed to having them declared implicitly with each instance of an FB.

kreskin said:

Hi All,
I am fully aware that FC's have no memory (although can read/write to a Global DB) and that FB's have Instance DB's as memory areas.

Click to expand...

You can also bring in pointers to DB's as a parameter to an FC.

One aspect no one mentioned here but has been raised in the past is modifications. You can modify an FB "online", but anything that touches the Instance DB will required the DB to be redownloaded and that may not be possible with the plant you have. On the other hand it's easier to achieve this with an FC that operates over a normal DB. This isn't a normal use case, but a while back one user here has laid down a very good example of why you'd go down this route. I think he worked in glass.

L D[AR2 said:

If starting with a clean sheet of paper, functions should be given input parameters and return a value. Use function blocks for everything else.

Click to expand...

This is the approach I take.

parky said:

There does seem to be slight variations in some PLC manufacturers in the difference between FC (FUN) & FB (FUN BLOCK), in the case of Siemens I suggest you read this it may explain it a little better.

Click to expand...

Yes, some don't have the concept of Function or even Function Block. An AOI is not a Function Block as stated in the name.

To all of you that replied to my post, thanks a lot, much appreciated, really useful input that has cleared up some of the things I was unsure of.

Still a little unclear on the statement that an FC has no memory.
While I accept this (and the example provided bydrbitboy made sense), as I understand, an FC can write to a Global DB and so does this not provide the required, accessible memory that an FB offers anyhow?

One other question I have is the InOut tags.
Ive worked with Rockwell and used these this parameter type within the AOI blocks.
I've never fully understood the definition of these versus a pure Input / Output, and only really used them based on the "rule of law" that a UDT structure has to be InOut type, rather than really knowing how they process data.
Anyone have a simple explanation?

It is by many considered a no-no to access the internal instance-DB data from outside the associated FB.
Meaning that the static instance data shall be local to the FB.
If you need to share data with other program blocks, or with an HMI (most likely you will), these data are not 'local' but 'public' and should be passed to and from the FB or FC via IN/OUT pins.
These shared datas are then stored in 'shared' DBs.
It is very common to organise these shared datas by user defined data types. So you declare both the data structurs in the shared DBs as well as the IN/OUT pins by the userdefined data types.

kreskin said:

Still a little unclear on the statement that an FC has no memory.
While I accept this (and the example provided bydrbitboy made sense), as I understand, an FC can write to a Global DB and so does this not provide the required, accessible memory that an FB offers anyhow?

Click to expand...

If the FC is only called once then yes, you could use a global db, but the point of FC's is for them to be passed parameters and return values and you should be able to call them multiple times, this wont work if you have a global DB access hardcoded in the FC.

S7 InOut parameters/UDT's. A UDT can be passed as an IN, OUT, IN_OUT in FC's and FB's, the return value from an FC can be a UDT.
All FC parameters are passed by pointer rather than by value so it doesn't matter if it's a bool or a UDT, the processing is the same. For FB's simple variables (BOOL, INT etc.) are passed by value so a copy of the variable will exist in the instance DB. UDT's are also passed by value for FB IN and OUT parameters. FB's with UDT IN_OUT's are passed by pointer so a copy of the variables does not exist in the instance DB

L D[AR2 said:

If the FC is only called once then yes, you could use a global db, but the point of FC's is for them to be passed parameters and return values and you should be able to call them multiple times, this wont work if you have a global DB access hardcoded in the FC.

Click to expand...

Ok, but what I mean is if maybe some of the inputs and outputs to/from the FC are read from, and written to a global DB, after which would allow data in the global DB to be used elsewhere?

kreskin said:

...
One other question I have is the InOut tags.
Ive worked with Rockwell and used these this parameter type within the AOI blocks.
I've never fully understood the definition of these versus a pure Input / Output, and only really used them based on the "rule of law" that a UDT structure has to be InOut type, rather than really knowing how they process data.
Anyone have a simple explanation?

Click to expand...

[@LD beat me to it]

What this usually* means is pass-by-value (pure Input/Output) vs. pass-by-reference (InOut).

* this is by no means universal, but it is fairly common.

"Pass-by-" here means how an argument (pin) is "passed" between (from or to) the calling program and (into or out of) the FC/FB:

• Pass-by-value for a pure Input means the FC/FB receives a copy of the entity that is tied to the Input pin. So all elements and/or values of an Input are initially copied from the external calling program. And if the FC/FB changes the value of its copy of an Input during execution, those changes do not update the value of the original entity passed by the calling program to the FC/FB, i.e. the entity from which the copy was made, i.e. the entity in the calling program's scope.
• Pass-by-value for a pure Output means that the FC/FB creates the output entity from scratch and modifies them during execution according to the FC/FB logic, and then finally copies that FC/FB-internal entity to the calling-program-external entity. So if the calling program changes any part of the output entity external to the FC/FB, those changes will not be reflected internally the next time the FC/FB is called.
• Pass-by-reference for InOut means there is no copying, but the FC/FB gets (a reference to) the external entity itself, and any changes made by the FC/FB are reflected in the external calling program's instance of that entity, and vice versa i.e. any changes to the entity made by the external calling program are available to the FC/FB internally the next time it is called.
  • N.B. the functionality of InOut can be in some environments be replicated by making a single entity both a pure Input and a pure Output to an FC/FB, and having the FC/FB initially duplicate the internal Input into the internal Output before running its internal logic that changes the Output (or run the logic on the internal Input and duplicate the modified internal Input into the internal Output). Pass by value handles the rest i.e. passing the external entity's value in and out of the FC/FB.

kreskin said:

Ok, but what I mean is if maybe some of the inputs and outputs to/from the FC are read from, and written to a global DB, after which would allow data in the global DB to be used elsewhere?

Click to expand...

Yes of course it will work, but it's not a best practice.

Specifically, if such an FC was used in several places, then any one of those could be overwriting a global variable, and if you needed to do some debugging, then you would not know where or when that overwriting was happening. Also, multiple versions of the FC could be writing different values to the global variable, which would make following what is happening even more complex.

Look up the principle of "separation of concerns."

A usually desirable metric is clean, reliable code, and having FC/FBs write to global memory can be best described by "here be dragons."

Again, I am not saying it cannot be convenient or made to work, e.g. say there is a units preference made via HMI that defines the interpretation of all values used by the program; that would be convenient to keep in a global variable, and all FCs/FBs could read that global setting to avoid adding a pin to each FC/FB.

L D[AR2 said:

S7 InOut parameters/UDT's. A UDT can be passed as an IN, OUT, IN_OUT in FC's and FB's, the return value from an FC can be a UDT.
All FC parameters are passed by pointer rather than by value so it doesn't matter if it's a bool or a UDT, the processing is the same. For FB's simple variables (BOOL, INT etc.) are passed by value so a copy of the variable will exist in the instance DB. UDT's are also passed by value for FB IN and OUT parameters. FB's with UDT IN_OUT's are passed by pointer so a copy of the variables does not exist in the instance DB

Click to expand...

Ok, thanks, appears different than the way Rockwell process the UDT parameters.

kreskin said:

Ok, but what I mean is if maybe some of the inputs and outputs to/from the FC are read from, and written to a global DB, after which would allow data in the global DB to be used elsewhere?

Click to expand...

That's ok as the global DB references are not in the FC itself.

drbitboy said:

[@LD beat me to it]

What this usually* means is pass-by-value (pure Input/Output) vs. pass-by-reference (InOut).

* this is by no means universal, but it is fairly common.

"Pass-by-" here means how an argument (pin) is "passed" between (from or to) the calling program and (into or out of) the FC/FB:

• Pass-by-value for a pure Input means the FC/FB receives a copy of the entity that is tied to the Input pin. So all elements and/or values of an Input are initially copied from the external calling program. And if the FC/FB changes the value of its copy of an Input during execution, those changes do not update the value of the original entity passed by the calling program to the FC/FB, i.e. the entity from which the copy was made, i.e. the entity in the calling program's scope.
• Pass-by-value for a pure Output means that the FC/FB creates the output entity from scratch and modifies them during execution according to the FC/FB logic, and then finally copies that FC/FB-internal entity to the calling-program-external entity. So if the calling program changes any part of the output entity external to the FC/FB, those changes will not be reflected internally the next time the FC/FB is called.
• Pass-by-reference for InOut means there is no copying, but the FC/FB gets (a reference to) the external entity itself, and any changes made by the FC/FB are reflected in the external calling program's instance of that entity, and vice versa i.e. any changes to the entity made by the external calling program are available to the FC/FB internally the next time it is called.
  • N.B. the functionality of InOut can be in some environments be replicated by making a single entity both a pure Input and a pure Output to an FC/FB, and having the FC/FB initially duplicate the internal Input into the internal Output before running its internal logic that changes the Output (or run the logic on the internal Input and duplicate the modified internal Input into the internal Output). Pass by value handles the rest i.e. passing the external entity's value in and out of the FC/FB.

Click to expand...

Thank you for that, so in effect, the parameters passed by value are copied into the corresponding, internal (local) tags and then based on the FC/FB logic, the value is copied to the corresponding Output parameter.
Whereas the InOut parameters are passed by reference and can still fluctuate in value even during the logical processing within the FC/FB?

Was trying to think of a practicable example.
Maybe feedback from a drive on a fieldbus where the FLC of the motor is likely to rise and fall slightly.
So passing this information to the FC/FB input parameter would be copied, whereas alternatively using the InOut data type means that the FLC fluctuations will still be captured during manipulation within the FC/FB's logic?