Step 7 FBs

hi
I currently use an FB with individual instance data blocks to perform a frequently occuring task. I have a new project where the are 50+ instances of this task and rather than use 50 DBs, I was considering using one big DB and offsetting within this instance DB using AR2.

I've created a UDT and ARRAYed this in the DB, but how do I pass my specific parameters to the FB/DB, if indeed it's possible?

Because you don't call it with CALL FB1, DB1 I'm not prompted with the list of inputs/outputs.

Hope this makes sense. Thanks

pp

Here's a snippet from STEP7 online help:

[attachment]

Seems you have to let one FB call the DB, and then let a call to another FB handle which part of the DB is active. But there arent many details though.

I would like to know what you come up with

I think I get it now:

Using the example from STEP7 online help:
You have to declare the variables for ONE motor in FB22.
Then declare "FB22" variables in FB21.
In FB21 you then "activate" each motor with a conditional call to FB22. I guess you would have to use an index to indicate which motor is the relevant one.

You would have to transfer the IN/OUT from FB21 when you call FB22.
If an IN-pin on FB21 is called #START, then you have to put that adress on a similar "START" IN-pin on FB22.

OK, now i REALLY get it.

You should NOT define similar IN/OUTs for FB21 and FB22.
In FB21 you put the calls to FB22 (which you normally would have done in an FC), and you populate the FB22 IN/OUTs in the normal way for each call to it in FB21.
What all this does, is to move all the DBs from individual instances of FB22 calls, to one instance of FB21 (the DB is moved from FB22 to FB21).

An to your original problem:
"Because you don't call it with CALL FB1, DB1 I'm not prompted with the list of inputs/outputs."
You should insert an empty "box" (use ALT+F9 in LAD or FBD), and then specify for example #Motor1 when prompted. The usual FB box will appear an you can fill in the IN/OUTs.

edit: Funny, I have been doing this for a long time allready, but I never thought of it as multiple instances.

Paraffin, there was a thread a while back that discussed this at length, and Bratt and I posted some sample code. Check it out here.

Personally, I prefer to call the FBs unconditionally without including them as stat variables(it allows me to reuse code more easily), but either approach would work.

Thanks S7Guy. I was hoping that you and Jesper would get a grip of this thread! It was after looking at the example you previously posted that got me thinking. I couldn't work out how to actually add my specific parameters.
I'll play around and post back. Thanks again.
pp

In my method, you have to do either a CC or UC call, as parameters other than STAT are not allowed. The only parameter you are allowed to include in the called block is the UDT that ar2 will point to.

Good luck!

A picture says more than ....

[attachment]

Hi,

One of the big advantages with the use of multiple-instance FBs, especially in smaller PLCs, is the reduction in Data Blocks used. NB, I don't mean the amount of memory, just the actual quantity of DBs.

Each CPU has a maxiumum number of FCs, FBs, DBs etc that it can accommodate. Let's say you wanted to use the standard IEC on-delay timer 'TON' which is embedded in the S7 firmware as SFB4. Normally every time you call SFB4 you would have to specify a DB as the instance for this. It doesn't take much imagination to see that an application could need a few hundred timers, implying a few hundred DBs. All of a sudden, the CPU spec has just jumped, purely to cater for this.

On the other hand, declare all your TONs as static variables in a single FB, (with no input or output parameters for the parent FB), use global variables for the parameters of each of the multiple instances and then effectively you have a timing resource whose values can be accessed by any other piece of code in the program.
Each static variable will occupy 22 bytes of instance DB memory, so 350 or more timers will fit easily in a single DB, even if you're working with a system with the old 8Kbyte block limit. Need more? No problem - create a second parent FB with another 350 timers as STATs etc.

You need to look at the structure of your software design to decide if this will work for you. Some people find it useful having access to all timer variables in a single DB - makes it easy for HMI interfacing etc. Others will want to see the actual SFB4 block located in the part of the code which will control it, rather than tucked away in a separate FB.

regards

Ken.

S7Guy
With the 'Conveyor' example you posted some while ago, how do I enter specific addresses to the instance DB?

thanks
pp

I'm missing something here, can't you put the logic calling these 50+ instances of the same FB (FB1) into a single FB (FB2) and using multiple instances include them into the data block of the calling FB (FB2)? I do this all the time but I may be off track in what you are doing and would like to understand it better for myself.

DesertDog's got it right. Once you have declared the STAT variables as instances of the 'child' FB1, they will create sufficient space for themselves in the instance DB of the 'parent' FB2 when it is created. There will only be one DB in this setup - the one assigned to the parent.

As each 'child' FB instance is called (whether conditionally or not), it will map its own input parameter data into its section of the parent DB, execute its code based on the contents of that section, and then prior to exiting, map all its output parameters back to the DB again. This as close to encapsulation and inheritance as you will get in the IEC1131 / PLC world.

Ken.

With the 'Conveyor' example you posted some while ago, how do I enter specific addresses to the instance DB?

Click to expand...

What do you mean by that? Are you asking how it points to a specific conveyor? If so, it just maps the UDT of the called FB to the shared data block (DB100 in this case). In fact, if you get the length of the UDT wrong, the code will still function but the wrong bits will be affected. That's why I always do a fresh compile after changing a UDT, and recalculate the AR2 index automatically on a restart.

In OB1, I just index through each conveyor, one-by-one, but if I wanted to look at a certain conveyor based on some dynamic value, you could do this (I'll assume that MW200 represents a conveyor instance that someone selects on an HMI):

L MW200
+ -1
L MW50
*D
LAR2
UC FB20

Now, FB20 will point to the conveyor that the operator selected.

Firstly, thanks for all the responses.
S7Guy - what I meant was each of the 20 conveyors has different physical i/o. How do I point conveyor 1 to Q124.0 etc?

thanks again
pp

Paraffin,

I've had a look at S7Guy's example code, and strictly speaking, according to the book, this isn't 'multiple instance' FB programming.
Multi-instance only occurs when you have a STAT variable in an FB that is in itself an FB.

Let's say you write a generic FB to deal with a Conveyor. Let's say it's FB99 and has a Symbolic Name "ConvCtrl". It has its own input and output parameters. Now let's assume you have 20 of these physical conveyors, so you need to call this generic FB 20 times. What you can do is create a new FB, say FB100, as a parent called "AllConvs" and then inside FB100 create 20 STAT variables named Conv1, Conv2, Conv3 ... Conv20. The key thing is that the data type of each of these variables should be specified as either FB99 or ConvCtrl.

You then move on to writing the FB100 code. Write the logic to decide whether to enable Conv1 control and then call Conv1 (or in ladder insert an empty box - Alt+F9 - and type the name Conv1). It will propmpt you as usual for all the physical parameters, but the key difference is it will not prompt you to identify a DB for it. Then move on to Conv2, write the calling logic and apply the parameters etc etc

Finally, when you then call FB100 somewhere (from OB1 or wherever) you will be prompted for a DB as the instance DB. When this DB is created it will have embedded in it all the data associated with the 20 STAT instances of FB99.

Regards

Ken.