TIA portal - use of FB how do you do

Hi!

Just a curiosity question. How do you use FBs and FCs? What do you write directly in the ladder and when do you use FBs or FCs instead? And why?

/Tim

Hi Tim,

When using an FB, all the inputs/outputs/stats/temps you declare are put in an DB. So if these values are not changed between two cycles, they will be stored in the DB (except for the temp).

FC does not have it's own storage, so all values are reinitialized for every call.
You also have to assign signals to all inputs/outputs.

So in essence, if you want to store data, you better of using FB's.

I think this may be opinionated, but those are my thoughts at least.

https://support.industry.siemens.co...-between-fb-and-fc-s/18334?page=0&pageSize=10

Thanks for the clarification bone
However I ment how do people organize its programs, when do they write the code in the organization blocks and when they use fb or fcs. How they organize and layout the program

rQx said:

Thanks for the clarification bone
However I ment how do people organize its programs, when do they write the code in the organization blocks and when they use fb or fcs. How they organize and layout the program

Click to expand...

OBs just for calling the others.. Maybe some simple isolated stuff like read time etc...

FCs for
a) grouping stuff - different FBs or commands but connected in a way..
b) simple reusable functions with no need for memory

FBs
a) sigle instance - copied tested FBs for whatever
b) multiple instance in another FB for multiple copies of tested FBs for whatever (motor, valve, measurement..)

Something like that

I keep OB1 as small as possible and as easy to understand how the program works. Pretty much everything else is in FBs and FCs as required to store or not store data. So as you read OB1 there is very little code in it, just calls to appropriately named FB/FCs that then tells the story of the program. If there is something that needs to run all the time but doesn't tell the story of the program it goes in to a 'Continual' FC.

I have separate DBs for:
Factory Settings,
Data that the operator enters that needs to be stored,
Data that the operator enter that doesn't need to be stored,
Timers DB,
Counters DB,
Data that is displayed on an HMI,
Data that is just used within the program,
Data that is shared with other PLCs,
Date and Time.
etc, etc.

Different types of program need different structures. Something that runs Step by Step, if different from something that takes data in, processes it, and passes data out.

Sorry for the mix up

OB's to call my FC's and to make sure PLC does not go in stop.
For every branch of the program I make an FC. So usually the scaling, limit checking and controlling of one analog value and the actuator that may belong to that is in one FC.
All my pumps are in one FC as well as the alarm handling.
I use FB's for my scaling, curves, alarm block, motor starter, PID (Standard) etc.

And I have a couple of DB's for general settings.

Thanks alot for all the replies ! Seems like FCs and FBs is the way to go, as little as possible in the OBs. I was also told by a programmer at one of our suppliers that I should never use PLC inputs in FBs and FCs , I should make local inputs instead.

I did the same when working in Simatic Manager. Move all inputs to a DB -> program -> move DB to all outputs, this way it is easy to see the status of all inputs/outputs and it is relatively easy to simulate your program, without having to use the funky SIM inputs.

I usually don't do this any more for TIA, since it is sooo much easier to use the symbolic addressing. Some of my co-workers do it tho.

I've never fully understood why this is done but I can imagine that if I use a input all around my program and want to add a time delay to it it's pretty easy.

But it was not really what i ment. I ment that he said that when orogramming inside a FB I should not use plc inputs. I should make local inputs instead in the FB and then add the plc inputs to them when I place the FB in the OB. Also only to use multi instance timers

Would you say a program that is written directly in the OB is completely wrong or is it just a matter of how you organize the program. Since Ive never taken any class or education in programming Ive never been tought what is the "correct" way

he said that when programming inside a FB I should not use plc inputs

Click to expand...

I guess that he is a classically trained computer programmer where you always pass variables to a function and receive an answer back as a Return Value. You are never supposed to use Global variables inside a function no matter how awkward that makes the programming.

I say that so long as you program is easy for the next guy to understand then you don't need to worry. PLC programming is different to PC, you don't have to follow PC rules. We know that the state of an input is read at the start of PLC cycle and that value doesn't change during that program scan. So there is no harm in using an input many times in a program. It can be a very good idea to map an input to a memory bit as the first step in the OB. Then if you have a hardware problem and need to use a different input you only have to change one reference. To be honest TIA makes it so easy to change IO in the Tag List that it doesn't matter any more.

Putting all you code in to an OB is OK if it is easy to read and follow. For me I always have analogue IO that must be scaled, so I use a Scaling FC because it makes the OB easier to read, and shorter. Calling one FC that is called ScaleValue is easier to read than NORM_X and SCALE_X, not that I use those, they fall over too easily.

Code should be easy to read and debug. I hate code that has been optimised with clever programming that makes it very short, but very hard to follow. In these days of plenty of memory, easy beats smart pretty much every time. If you run out of memory, then you have an excuse to get creative.

I like to map inputs and outputs to DB-addresses. It is easy to copy blocks to different program and if there is need to change real IO address whole program don't need modifications. (On Siemens it helps also that you need to only load couple FC blocks instead of many different program blocks if there is IO changes.)

Also it helps if outputs are located on one program block. That way I allways can go one FC, see the staus of outputs and no need to make animation tables.
Also that way it isn't necessary to use cross references of program to know where inputs/outputs are used on PLC program. I only go to IO mapping FC, select output and choose go to from right click selection menu.