Help with a multi instance FB

Hello dear engineers,

i made a function block to control 3 reservoirs with different colors for a virtual blinding application, the idea was to make one single FB1 and call it 3 times with 3 instance DBs (DB2, DB3, DB4 ),but the program works in a weird way here is the code for the FB1 :

NETWORK1

OPN "CODE COULEURS" //
L #COLOR_CODE
L 0
<>I
JCN _002
A "SYSTEME MARCHE"
AN #VANNE_CUVE_DOSAGE
A "START"
FP M 200.1
S #VANNE_CUVE_PEINTURE
_002: NOP 0


NETWORK2



OPN "CODE COULEURS"
ON "SYSTEME MARCHE"
O #VANNE_CUVE_DOSAGE
O(
L #CAPTEURS_CUVE_DOSAGE
L #COLOR_CODE
==I
)
R #VANNE_CUVE_PEINTURE


the program just care about the first called instance ( so the first reservoir ) and some how it skip the two others until the value of #COLOR_CODE is 0 than he start reacting with the second one and so.

i tried the BE BEU BEC instruction but it doesnt change anything.


where you think the problem is??


thanks in advance

abdel89 said:

FP M 200.1

Click to expand...

I'm not quite sure what the block is trying to do, or what you're seeing, but I'm guessing the above is the problem. If you have multiple calls of an FB, and you read and write to the same global memory, it'll have unexpected results. I'd suggest changing that to a local stat, instead.

Dear mk42,

the FP M200.1 positive edge detection is used to "one shoot" the start push buton signal, you think the problerm is coming from this line? what shoud i do to avoid that ??

thank !

FB M200.1

Change M200.1 to static variable on FB block/variable declaration. That way when you generate DB for FB, every FB block have own bit for one shot detection

Thanks Lare ,i will try it and answer you.

What happens is that when the first instance executes the FP, checks the current value of the RLO vs the value in M200.1, and then copies the current value of the RLO into M200.1. Normally, M200.1 is never written to again, and it will contain the previous value of the RLO next time.

In your case, it is a little different. When the second instance executes, it uses the same memory location for the FP, comparing the current RLO to M200.1. However, instead of M200.1 storing the previous value of the RLO, it now holds the value that was stored in instance one.

Instead of reading the value from teh previous scan, it is now reading the value from the previous instance. What Lare said was exactly correct: create a local variable in the stat section of the FB.

Yes i just did like Lare said, i created a bit variable P_EDGE in STATIC declaration and it did the job .

It the new thing i've learned this day

Thank u guys.

Also keep in mind, that FB-blocks have also temp-area. These variables don't remember data from previous scans so you can't use them for one shots or any else where you need data also from earlier scans..

You can use these temp variables only like buffer in one network for transfering calculations or bit states to other network at same program. (you calc something in network1, put it to temp variable, and on second/later rungs you read this temp data.

Temp-data is valid only at current scan.


Also if you look DB block of FB, you notice that there is only variables of in, out, in_out and stat declarations, no temp-variables exist there.

This same qualifies also to FC temp-area.

Thanks Lare, your precious explanation was really useful and simple not like siemens manuals, i still have one last question : if i had 30 similar elements to control this mean that with one FB it will needs 30 instance DB, i've read in a manual that its possible to avoid that with use one mother FB with single DB and call FBs inside it for each element. Can you inlight us more about how to do it and how the data will be stored in one DB for many elements.

Thanks a lot!

First you need to create FB like you have done now. (ex. FB100)

then create another FB (ex FB500), on FB500 network, drag and drop from left FB100 to network. Now, right click fb100 block at network and select from pop up, change to multi instance block, after this step7 will ask name for instance.
After this static area on FB500 have this name and data type is fb100.

On other network do this same procedure, you need give only different name for block.

If you change in, out, in/out or stat parameters at fb100, then you need to update and download also FB500 and its DB-block to PLC.

But if you only make changes to code inside of FB100, you only need download FB100 to plc, because stat area of FB500 is keeped sama as earlier. (FB100 interface is unchanged)

Again a good sign to use 61131, god i hate siemens.

To avoid using 30 instance DBs you can declare 30 instances of an FBx within the STAT area of another FB e.g. Inst_1 of type: FBx Inst_2 of type FBx etc.

Then in your code, rather than call FBx you call Inst_1 and so on. All of the instance data for the 30 FBx calls will be part of the instance data for the block where the instances are declared.

If you have already called your FBs within another FB then, in the editor, you can right click on the block and convert the call to Multi-Instance.

Further to what was said above about "Temp" variables: Be careful not to structure your code to jump over segments where the value of a temp is set. If the temp is used further down the program then you can get very unpredictable results! You may find that your program works fine for weeks or even years and then suddenly starts to go wrong. Temp memory is dynamically allocated at runtime and the contents of that memory will be whatever state it was left in by the last thing that used it. So the golden rule of temps is: never rely on the value of a temp unless you have set its' value explicitly further up in your code.

Nick

Thanks Lare for giving time to my issue.

Thanks Nick for the additional explaination.