FC vs FB, DB

I have a real problem to understand the difference between: FB & FC. HELPPPPPPPPPPPPPPPPPPPP

I REALLY NEED URGENT HELP (YES/NO answers will help also) ...

i'm a beginner in siemens 300/400 & i came from computer programming background and i made some simple applications on the S7-200.

Now, what i know / & what i'm confused about????

1. FC does not have memory / FB has memory -> DB? Confusions:
   1. FC has inputs & outputs - why?
   2. what are the cases that it makes me use the FC's I/O
   3. can i assign "Q's/PLC outputs" to the FC outputs?
   4. if YES then if the FC call is conditioned, that means if the conditon is not fulfilled the Q-output will turn to ZERO - Yes/No?
2. FB has memory and i can assign different DB's to it, e.g. motor control. fine that what i always read... Confusions:
   
   1. Does the DB works as a Memory Variable or to be more specific & clearer to me does it work as a Memory-Bit SET/RESET?
   2. if YES (in conditioned FB) means: if i assign an output-Q to an FB output and it was not called in another read-cycle => the output-Q will still be ON (ONE) - Yes/No?
   3. if NO then if a used a STAT variable within a DB, will it hold the values?
3. does anyone really have this motor control - as an example project.
4. if i make a code and i'm not sure of it, how can i try it without a real PLC (same like RUN is other programming languages)
5. WHAT IS THE REAL DIFFERENCE BETWEEN FB & FC IN TERMS OF USES, please give example. in other words how can decide for this operation i definatly need an FC or FB ????

THANKS FOR YOUR HELP,

Confused Person

1. FC does not have memory / FB has memory -> DB? Confusions:

When you call an FB it asks for a IDB to link with it, in this all IN/OUT/IN_OUT/STAT parameter values gets saved into the IDB. The IDB is just a DB at the end of the day, but its format is fixed to the FB data above. You cannot change the format of an IDB, at least not without changing the FB parameters.

The only difference in parameters between FC's and FB's are STAT's, as an FC does not have an IDB to store them in.

1. FC has inputs & outputs - why?
2. what are the cases that it makes me use the FC's I/O
3. can i assign "Q's/PLC outputs" to the FC outputs?
4. if YES then if the FC call is conditioned, that means if the conditon is not fulfilled the Q-output will turn to ZERO - Yes/No?

An FC like a FB can be called as a sub-routine, so for example, you can have a motor control FC and then call it 20 times for 20 motors, the IN and OUT parameters would be how you distinguish between different motors.

3 above is yes and 4 is no, it would remain in its last state when the FC was called.

1. FB has memory and i can assign different DB's to it, e.g. motor control. fine that what i always read... Confusions:

The STAT's are the real memory here, yes it includes the IN/OUT etc in the IDB, but the STAT's are individual for the call and these are remembered. Remember the IDB is just a DB, so you can access this memory anywhere in DBx.DBx.x format (also bytes, words etc)

1. 
   
   Does the DB works as a Memory Variable or to be more specific & clearer to me does it work as a Memory-Bit SET/RESET?
2. if YES (in conditioned FB) means: if i assign an output-Q to an FB output and it was not called in another read-cycle => the output-Q will still be ON (ONE) - Yes/No?
3. if NO then if a used a STAT variable within a DB, will it hold the values?

DB's are memory locations to store any valid data type. BOOL, BYTE, WORD, REAL, etc. You can set/reset bits in DB's as you wish, you can also read and write words into DB's. As per FC the output will retain the last state when the block is called. STAT's also hold their values, these are in fact the with memory that is associated with FB's.

1. does anyone really have this motor control - as an example project.
2. if i make a code and i'm not sure of it, how can i try it without a real PLC (same like RUN is other programming languages)
3. WHAT IS THE REAL DIFFERENCE BETWEEN FB & FC IN TERMS OF USES, please give example. in other words how can decide for this operation i definatly need an FC or FB ????

Fraid I'm working with that awful AB stuff now

PeterW said:

Fraid I'm working with that awful AB stuff now

Click to expand...

Thats how i used to feel about siemens !

504bloke said:

Thats how i used to feel about siemens !

Click to expand...

Back to the questions, testing can be done without a PLC if you can afford to buy S7 professional, which includes a PLC simulator. I'm not sure what other simulations are available.

No real difference in using FB's and FC's, its just how you wish to organise your data. As shown in another thread FB's can be imbedded to share the IDB.

Here I'll try and make it simple

FC = Simple Subroutine. Example I want the average of two numbers.
Inputs Needed: Value1 and Value2
Outputs Needed: Result
Result = (Value1+Value2)/2
Once I work out the Function...do I need to see intermediate steps? No? Do I want to copy code over and over and replace Value1 & 2 with new variables? NO. I simply want to use the FC like it was a internal instruction. Pass data in...get result out.

FB = Like above but I need STORAGE MEMORY or I need the intermediate results from outside block.
Motor Block.
Inputs Needed: Start & Stop, On Delay Preset
Storage Needed (STAT Area): Run_Start_Flag, On_Delay_Timer
Outputs: Run_Coil

What does it use for storage? a DB. Do I need a DB for each FB call yes and no. Once you figure out how to use the power of multi-instance...you'll never go back to checkers once you play chess. It can hurt your head until you understand the concept. The beautiful thing about it is you don't have to generate reams of datapoints. The FB's do it for you.

Nick

Thanks + questions

thanks peter, without u giving time, i would have been still "lost in space, same like miss piggy" - LOL

my god, the main difference the specific STATIC variables attached with every FB call

thank u nick, ur answer was clear ... but it emerges some questions:

multi instancing: i came from a programming bacground so i'm familiare with the concepts but not with the methodlogy ...

so if we consider multi instancing, (in a motor control example as usual)that would be done by defining 10 DBs for 10 motors and 1 FB for the functionality and then i will call the FB 10 times and i'll pass the 10 DBs each at a time...

1. this is the methode of multi insatncing - YES/NO ???
2. there are other ways, YES/NO ???
3. u said it will save my time in defining of variables, but i'll repeat the DBs, YES/NO ???

thanks & less confused,
Michael

For an instance DB you don't define it, you cannot chang it, the IDB is created by Step 7 when you add the call to the FB, it asks you for a DB address.

If I change an FB in a manner where the IDB will change, I comment out the FB call and delete the IDB, then uncomment the FB and it re-creates the IDB.

Multi instancing is where a single DB is used for more than one FB, there are a few ways this can be achieved, simplest being where you may have an FB that will be called from within another FB, you simply add the one to be called in the STAT area of the main FB.

You can share IDB's by calling FB's unconditionally and ensuring 1. The parameters are exactly the same (some can be longer, just as long the part up to the additional data is the same), this would mean IN, OUT and IN_OUT would have to be identical and the STAT area identical up to that point. Usually when this is done the STAT's tend to be UDT's. [EDIT: ensure the IDB is created from the FB with the longest parameter area].
2. The IDB is open when each is called.

When you define the STAT area, these are automatically created in the DB, therefore saves you time in doing so, much more powerful when you create UDT's.

hello, thanks peter ...

i checked the simatic manager help on multiple-instancing, but i guess i didn't really get it ...
can u explain with an example if possible, motors r okay with me

if anyone also might help, i would be greatfull.

Michael

I am not familiar with Siemens programming but I have been following the thread with interest.

Could the differenece between a Function Block (FB) and a Function (FC) be defined as follows: the first one has static memory while the second one doesn't?

I suppose the easiest way to explain, they both can function similarly, except, if you want to save the status with the FC, you have to do it with the parameters you pass to the block on calling.

A bit like the Input_Par sends info in and the Return_Par passes the information back when you call a routine in ControlLogix.

The difference with an FB is it has additional internal parameters called STAT's, which is stored in a data area you specify when you first program the block call. You can still pass data in and out, but that data and the STAT's get stored. That way on the next scan the block 'remembers' the state from the last scan.

If you call the same block a number of times in the code, you would normally specify individual data areas to store the memory for each call, like 20 calls for 20 different motors for example.

To michael, I only have ControlLogix at the moment, to give you an example I would need step 7.

mico207 - As you have mentioned you come from a computer programming backgound, here's another description for you.

In a Function Block - all accesses to IN, OUT, IN_OUT and STAT variables are performed by reading/writing data to/from the instance data block associated with the FB. The sequence of events for processing is as follows:
1. The calling block writes parameter values into the instance data block.

2. The function block is called and acts upon the data in the instance data block and writes result data into the instance data block.

3. Upon return to the calling block, the calling block copies results from the instance data block into parameters defined in the calling block.

Implications of the above:

As described by LadderLogic, all of the IN, OUT, IN_OUT and STAT variables are stored in static memory - the instance DB.

If you call a function block and choose not to copy a value to an input parameter (leaving it blank for example), the function block will use the last value that was copied to the input parameter - it has to because all it can access is the data in the instance data block.

If the processing in the function block jumps or skips some processing where some outputs are written, the outputs will remain at the value last written.

In summary, in a function block all parameters are passed by value.

In a Function - all accesses to IN, OUT and IN_OUT variables are performed using area pointers.

The sequence of events is as follows:

1(a) If the parameter is a simple parameter e.g. M0.0, the area pointer P#M0.0 is used in the argument list for the function

1(b) If the parameter is a complex parameter e.g. DB1.DBX0.0, then logic is generated which will assign the value of DB1.DBX0.0 to a temp local variable is performed e.g.
and then the area pointer to the temp local variable is used in the argument list for the function, P#L10.0 in my example)

2. The function is called and the area pointers used in the argument list are used to access the IN, OUT and IN_OUT parameters.

3. Upon returning to the calling block, any complex parameters of type OUT or IN_OUT that were assigned temp local variable pointers are copied to their required destination. Say DB1.DBX0.1 was used as an OUT parameter, then the following type of processing will be done:

Implications of the above:

Function parameters cannot be left blank - a pointer is required for each.

When using simple parameters, e.g. M0.0 a function has free access to read/modify this variable no matter what type of parameter it is, for example an IN parameter called bData is parameterised with M0.0, the following code will reset M0.0 to zero.

When using complex parameters e.g. DB1.DBX0.0 the function is operating on a pointer to a local copy of the value of DB1.DBX0.0, so the same code will not change DB1.DBX0.0

In summary, all Function parameters are passed by pointer.

Regards, Simon

SUM UP:

------------



Hello, I’d like to put an objective sum up so everyone will benefit easily from this thread.

Properties / Difference – FC vs FB, DB…

• FC: variables are passed by REF. (Pointers) which means any change of the value the same variable along the program will have an effect on the FC functionality.
• FC: which also leads to – HAVE NO MEMORY – as it refers to variables whatever their value
• FC uses: can be used in mathematical operations, organizing of the program ex. Call different FBs depend on some input values and return flags …

• FB: where as FB is similar in nature but with additional options that give it its power.
• FB: variables are passed by VALUE, which means whatever changes that happen to that variable in your program the FB will not sense it.
• FB: ex. same as what Mr. L D said: if u made and FB to add 2 numbers & return the sum (selected mathematical operation for simplicity) and u call it 2 successive time. 1st u passed 5 , 4 then the result is 9. 2nd time u passed only 1 value 6 (in the place of the 1st input) then the result will be 10.
• FB: also have the amazing STAT variables which are used as memory. Example the M+ button that u find on ur calculator.
• FB: DB, it is just an amazing concept – the DBs they have the inputs, outputs, In/Out, Stat variables stored in it and assigned to the FB. I was confused about it in the beginning why they have to do that ??? the answer is simple it gives the programmer the power to know the values at any time along the code.
• FB: also it differentiate between the values/variables and the code to do the action. Finally what affects any system are the values, the logic is just a mean to reach the desired outputs/values.
• FB: multiple DB, i.e. FB200 (for ex.) is assigned to it DB200, DB201, DB202 (Typical DBs, assigned each at a time on each call of FB200) another amazing concept. As long as the logic of FB200 will do the same job every time it is called, and what we need is on the values (bec. That’s what really do the control) so it very clear to assign typical DBs on successive FB200 calls that will control identical instrument in the same manner (eg. Motor – as usual).
• FB: one more thing here, due to the property of the DB to retain data will lead to keep the output status stable if it depend on a DB value (ex. RunMotor)
• FB: finally we r left with 1 concept we didn’t discuss is MULTI-INSTANCING and as Mr. Peter said: u can define FB in the STAT of another FB … which I check the simatic manger help n I found what he told exactly … so I guess I’ll open another thread dedicated for this topic.
• FB uses:
  1. same operation on multiple machines.
  2. operations where machine status have to be saved (maybe breakdown/recover scenario, car move/stop on different stations).

PLEASE CORRECT ME IF ANY INFORMATION IS WRONG, NOT QUITE CLEAR OR NOT COMPLETE.



Regards,

Michael

I would not put up a summary until you have spent (at least) six months using FB's and FC's. As with most things, there are more layers to be peeled on this onion (and the associated tears to be shed as well)!

this is a good one.
yeahhh u r right i know. but a sum up reflects here my understanding to the topic & leave holes (that i didnt understand) which gives others the opertunity to fill those holes, maybe we will reach a full subject at the end...
or that what i hope for.

OK - your sum up for FC's says the following:

mico207 said:

• FC: variables are passed by REF. (Pointers) which means any change of the value the same variable along the program will have an effect on the FC functionality.

Click to expand...

I clearly stated there are two cases for FC's, (a) for simple parameters and (b) for complex parameters. You have ignored this fact in your sum up.

Note also that (almost) anything you can do in an FB, can be done in an FC if you want to.