Programming with Siemens Step 7

[ed.kelly]

When starting a program what are the main factors in deciding what logic to put in what type of block? I mean what types of fuctions go in FB'S, and what types go in FC'S. I know that FB'S have memory, and FC'S don't.

Do you use FB's for basis discret I/O, and FC'S for all other functions.( comparisons, math functions,word logic)?

 

[L D[AR2P#0.0]]

Use FC's where you wish to process some input parameters and return a value via the RET_VAL of the block.

Use FB's for everything else.

 

[HenkieD]

There are many ways to Rome as you know, but rule of fist...

Use FB's for generic tasks which require 'memory', like motors, valves, etc. Also unique tasks which require 'memory' you put in an FB like a stepping sequence.

In your FC's you can call your FB's and generic FC's which don't require 'memory', like for example a simple analogue input processing.

 

[twu026]

I almost always use FB rather than FC.

Having the ability to declare variables locally in the function block is always handy.

Everytime I have used a FC, I almost always end up wishing I had used a FB instead.

 

[userxyz]

We make machines for tube handling, in the metal industry. I've been working for 8 years in a carpet factory, this was more process industry then machine building. I remember that I used a lot FB's back then. I used them for memory bit's (rising and falling edges) mostly and for memorising a status of something that had to do with the code written in that FB. FC's were used to make a function that could be used many times in a program, or for simplify the program a bit.

Now in the machine building, I have other methods.
The only FB's that I have are Graph-FB's, Pdiag-FB's and sometimes an FB with some SCL code, again for making rising and falling edges.

All other stuff like conditions, alarms, buttoncolors, machineobject, valves, motors, etc... is allways interfaced via shared DB's. Hydraulic logic , Pneumatic logic , positioning logic, alarm logic, etc etc... is allways written in FC's. I don't like the use of instance DB's when not needed. I only use instance DB's when I have to re-use an FB many times. So I kinda prefer FC's where I can.

 

[RobImb]

Hi Guys,
I never bother using FB's always write all the code in FC and transfer any data i need into DB's never really understood the difference myself

 

[kamenges]

I use FCs uless I have a specific reason to the instance data block (multi-instance, maintained data specific to the instance, etc).

Is there a performance benefit either way?

Keith

 

[Peter Nachtwey]

I think RobIMB has a point. One can just load the DB of interest in one of the DB registers and access the static data that way.
If I want to talk to a different motion controller I load up a different DB into the DB pointer registers. This seems to be much more flexible than assigning a DB to a FB. It does require and extra parameter to be past to the FC but I don't think this is a big deal. I much prefer to do this than to keep my FB and DBs synchronized. I hate that. It should be automatic.

Even if you have multiple instances one can use a FC and pass a DB number and instance number to a DB that has an array of UDTs where each UDT is an 'instance.'

I have found the FBs are handy for small routines that handle state where I don't need to change things much if at all. For serious work a FC is the way to go. I can keep passing on the DB number and the instance number to other helper FC subroutines.

Lets see what L D[AR2,P#0.0] has to say about this.

 

[S7Guy]

I do nearly everything in FBs, but I reference global DBs within the FB instead of using instance DBs. That way, I can write all of my code symbolically, and don't have to copy data to and from the global DB. FCs are way too cumbersome for this, and run much slower. Plus, it's a nightmare if you ever restructure your DBs.

For the most part, I reserve FCs for grouping my FB calls together, or for when I am doing absolute addressing anyway.

 

[Thim]

Don't want to say what is the best way or better way to go.
Haven't got the experience like many of you.
But i do see some differents in FB/FC.
FB you don't need to address all inputs/outputs (advantage for me)
FC you do need to address all inputs/outputs(disadvantage for me)

I think there is also a big difference in the usage of AR2.
Like l d[AR2,P#0.0] stated in a few posts before, if i didn't misunderstood it. In a FC you are free to use the AR2 they way you like (advantage for me), in a FB here it is used to keep track of the instance data so you have to becarefull using it(disadvantage for me).

 

[L D[AR2P#0.0]]

There are too many variables to give a Golden Rule for choosing FC's or FB's (number and type of parameters, number of times block is called).

I prefer to use the static data area of FB's for edge detection and persistant count storage rather than using M flags or global DB bits either referenced directly in FC's or passed as IN_OUT parameters.

 

[HenkieD]

To make the confusion complete, recently I discovered SCL, which looks a bit like a mix between Pascal and Basic, very powerfull stuff...
Once finished it compiles an FB for you...

 

[L D[AR2P#0.0]]

You can choose any type of block in SCL (DB,OB,FC,FB,UDT)