FC vs FB, DB

[RMA]

Depending on the circumstances I use both of the tricks mentioned above.

Either make a copy of the FC which is called multiple times and substitute it in one call for the original FC or else create and open a dummy DB (so as to be able to easily define the View path) before calling the particular instance of the FC you want to monitor - this is dead easy in STL, possibly not quite so easy in ladder, but as you may have noticed, STL is much more widespread this side of the pond!

 

[Jeebs]

Attached screen shot shows you how to do it.

If in doubt, press F1, the info is in there. (somewhere)

 

[dahnuguy]

I got half of it.............

"Either make a copy of the FC which is called multiple times and substitute it in one call for the original FC or else create and open a dummy DB"

After looking all the posted responses over I now understand the veiw part and using the test call and that only the first instance is displayed.

However, I am unclear about the above statement.

"Make a copy of the FC."

Does this mean to insert a copy of the one you want to watch as the first one and then it will be the one with veiwable data?

"or else create and open a dummy DB"

Not sure about this one. If these are FCs, why do we need a dummy DB? and what would go in this DB?

Almost there.


Thanks again,

 

[dahnuguy]

Attached screen shot shows you how to do it.

If in doubt, press F1, the info is in there. (somewhere)

Thanks,

The issue I have with searching the "help" is knowing what to ask. Before I read this , I would never have imagined such a thing was possible or necessary. I have never seen such layers of obscurity.

And I tried asking "What should I search for help on to answer my question" angle, but had a difficult time interpreting the help answer anyway.

It is too easy to just ask in the forum and get lazy, and I am trying not to do that, but the system is just so cumbersome.

I think I am on the verge of getting somewhere like "the next level" or about to completely get lost.

Fun place to be.

Oh I am trying to use the info you included without success. Not sure why yet, still working on it.


Thanks again.

 

[RMA]

"Make a copy of the FC."

Does this mean to insert a copy of the one you want to watch as the first one and then it will be the one with veiwable data?

Sort of, simply make a copy of the original FC with a new number, for example if the original FC is FC74, then you might call your copy FC1074. Then substitute this new FC for the call of the original FC that you want to view. Since the new FC by definition is the first (and only) instance of the FC then you can be sure that the data that you see when viewing it is correct.

"or else create and open a dummy DB"

Not sure about this one. If these are FCs, why do we need a dummy DB? and what would go in this DB?

The dummy DB is purely used to define the path for viewing your multiply called FC as shown in the example Jeebs posted. You don't need to put anything in it (just leave the dummy placeholder in it) and then on the line before the FC call you want to view, insert the command OPN DBxyz - if you're working in Ladder, insert a new Network directly before the FC call you want to view and add the OPN DBxyz command there.

The DB is purely used to assist with the trigger definition as shown above and can be deleted when you're satisfied everything is working correctly.

The issue I have with searching the "help" is knowing what to ask. Before I read this , I would never have imagined such a thing was possible or necessary. I have never seen such layers of obscurity.

I know exactly what you mean here! I sometimes think my brain must work differently from the guys who write the help files - and that's not just the case with Siemens!

 

[Jeebs]

Sort of, simply make a copy of the original FC with a new number, for example if the original FC is FC74, then you might call your copy FC1074. Then substitute this new FC for the call of the original FC that you want to view. Since the new FC by definition is the first (and only) instance of the FC then you can be sure that the data that you see when viewing it is correct.

Just be careful with this. Don't pick a number greater then the max nr of FC's the PLC can handle.

 

[Money4Nothing]

You guys seem to be making this a bit more complicated than it really is, in my opinion.

An FC is just a function, a re-usable set of code. You can use it over and over again, call it as many times as you need to. You give it a set of inputs every time you call it, it operates on them, and gives you a set of outputs. Any information about what goes on inside the FC is lost after the programs operates on it.

An FB is used in a similar way, but is much more powerful. It's a reuseable set of code with inputs and outputs just like an FC, but it also has its own memory area. Every time you create an FB, you create a DB, which is the memory area for that FB. What's nice about S7 is that every time you use that FB in your program, Step 7 creates a new version of its DB memory area for that particular instance of the FB. This is called an Instance Data Block. In this way, you can use the same FB 100 different times, without having to manage 100 memory areas, one for each call of that FB. There are more powerful consequences of this when you do complicated things like indirect addressing, udts, or nested function blocks.

You get to view information about what is happening inside each instance of an FB, unlike an FC, because the FB has its own memory area for each call, or each time its used in the program. If you looked online at an FC that was being called in several places, you wouldn't know which version of it you were looking at. But for an FB, you could look at the Data Block for that specific instance of that FB, so you knew exactly what part of the code you were looking at.

That's the main difference between an FC and an FB.

$

 

[PeterW]

You guys seem to be making this a bit more complicated than it really is, in my opinion.

Yes we did detour into how to see 'live' data. Apart from that you over simplify it in an incorrect way.

An FC is just a function, a re-usable set of code.

So can be an FB, but neither is limited to that. For instance both can be a main block calling other blocks.

You can use it over and over again, call it as many times as you need to. You give it a set of inputs every time you call it, it operates on them, and gives you a set of outputs. Any information about what goes on inside the FC is lost after the programs operates on it.

Yes, you can also give it no inputs and no outputs, it can be simple it can be complicated, you may need to see the status in one instance of a call and disregard others, which is what the last few posts have been about, you may send data to different DB's from within (so data not lost).

An FB is used in a similar way, but is much more powerful. It's a reuseable set of code with inputs and outputs just like an FC, but it also has its own memory area. Every time you create an FB, you create a DB, which is the memory area for that FB. What's nice about S7 is that every time you use that FB in your program, Step 7 creates a new version of its DB memory area for that particular instance of the FB.

Not if its a shared instance (called from within the block with the FB's embedded).

This is called an Instance Data Block. In this way, you can use the same FB 100 different times, without having to manage 100 memory areas, one for each call of that FB. There are more powerful consequences of this when you do complicated things like indirect addressing, udts, or nested function blocks.

You can do indirect addressing in FC's and use UDT's, I'll concede that you cannot embed a FB.

You get to view information about what is happening inside each instance of an FB, unlike an FC, because the FB has its own memory area for each call, or each time its used in the program.

erm.... no you can't... you'd have to look at the DB not the FB to see what's happening, looking at the FB status gives you the same problems as an FC UNLESS you specify the DB, which is what the last few posts have been describing.

If you looked online at an FC that was being called in several places, you wouldn't know which version of it you were looking at. But for an FB, you could look at the Data Block for that specific instance of that FB, so you knew exactly what part of the code you were looking at.

ONLY in debug mode and if you specified the DB. As has been explained similar can be done in an FC.

That's the main difference between an FC and an FB.
$

Apart from one or two bloomers, spot on

 

[Money4Nothing]

Yes, thanks for the corrections and clarifications, I was actually typing a bit too fast and thinking ahead of myself because I've been debugging online a bunch today. Then after I posted, my edit button was missing

I can edit this post, but not that other one still...weird.

$

 

[PeterW]

sorry, I'm in a playfull mood

 

[Money4Nothing]

Well I certainly don't want to throw anything out there that would mislead anyone into an incorrect idea.

$

 

[Paul B]

Old thread, but just found.

I'm an old-school ladder logic guy born and bred on GE and AB. That said, I've been programming S7-300 full time since 1999. I don't use FB's in the way most people use them. Simple reason: you don't get cross-references. I have had to follow many other programmers that used FB's and it is nearly impossible to track stuff down. The HMI can write to the Instance DB and affect the process. The programmer could have used the Instance DB addresses elsewhere in the program. When you are inside the FB and right-click and do "Go To..." there is no way that I have found to get a cross-reference to back track. It's true that you can execute a cross reference for the Instance DB but you have to know to do this - not intuitive. If there is a workaround for this: educate me. Final thing: you are in an FB and you see the logic. All addresses are local data preceded with a pound sign. What's the address? Contrast this with the way I do it, to be explained now.

What I do in all my programs is use an FC as a subroutine, the same way we'd use a subroutine in GE or AB. Then when I need to do logic for a process or a machine within a program I will choose a group of FC numbers and one DB. I do all the logic in the group of FC's and use the one DB. I say a group of FC's because its a good idea to break code up that is larger than 2kb for online monitoring purposes, as well as downloading the FC for program changes. My code practice is very portable and cross-references are available for me and those that follow. To explain, if I have 8 identical processes then I can simple copy my FC (s), copy my DB, and then search and replace within the FC. Boom Bam, code replicated. I don't see what the big deal is about FB's. I'd also much rather edit variables within a DB than deal with the editor in the top of the FB... And back to the last question of the preceeding paragraph. In my FC that uses a DB, you see the address. Right-click and do Go To... and get a cross reference.

I don't use FB for machine code. I do use FB for limited applications but always keep in mind the lack of global cross-reference and use that as my deciding factor. So I do use FB's, but not like most Siemens programmers seem to.

Caveat: I did not read every post in the four pages of this thread before I posted. I did read most of them.

 

[Nick B]

Paul,
So I take it your using S5 timers and replacing the Timer numbers or passing them in? This is where the FB approach really wins outs. Need a timer. Bingo go declare one and your good. Further to this TONs (SFB4) are far superior timers. Run for 28 days and you get 1 mSec res.

 

[L D[AR2P#0.0]]

If you want to use SFB4 from a FC using Paul B's approach, declare the SFB4 interface in the global DB, set up AR2 to point to it and make the instance DB number the same as the global DB number. You have to call SFB4 using UC SFB4 and manipulate the timer data via the global DB.

Simple example attached.

 

[Paul B]

Paul,
So I take it your using S5 timers and replacing the Timer numbers or passing them in? This is where the FB approach really wins outs. Need a timer. Bingo go declare one and your good. Further to this TONs (SFB4) are far superior timers. Run for 28 days and you get 1 mSec res.

Yep... If I have a machine called Tipper 1 then all tag names for this machine have "Tip1" in them. The global Data Block DB21 for Tipper 1 is "Tip1" and the timers for Tipper 1 are "TMR_Tip1_xxxx". To create the logic for Tippers 2-8 I would copy and paste the original global DB21 and call it DB22 with symbol name "Tip2". I'd copy the timers for Tipper 1 & rename Tip1 with Tip2 in Excel and then paste them into the Symbol table. Then copy the FC's for Tipper 1, renaming them with appropriate names. Then open in the ladder editor and search and replace Tip1 with Tip2 and it's done.

I understand the IEC timers are awesome but what I don't like is having an instance DB associated with each timer. That makes too many DB's in Simatic Manager. Can you post example code of a timer declared in an FB?

If you want to use SFB4 from a FC using Paul B's approach, declare the SFB4 interface in the global DB, set up AR2 to point to it and make the instance DB number the same as the global DB number. You have to call SFB4 using UC SFB4 and manipulate the timer data via the global DB.

Simple example attached.

Thank you very much for this! I am working with this now. My question for you is what does this line mean:
UC SFB 4
The instruction UC does not appear in STL instruction help.

Your global data block has timers declared with the UDT "sfb4Interface". I did not know this was possible and I am working on how to use this. Your example is very much appreciated. I have not used SFB4 because I did not like having to assign a DB every time I used a timer. I'd have 500 instance DB's in some programs... Your way is very interesting.