Tips for modifying and downloading an FB (Multiple-instanced) online

Hello Experts!

Can I ask for a tips and tricks in modifying and downloading an FB, with multiple instances, without stopping the PLC?

I heard that if you just modify the code of the FB but not the declaration addresses, there's no problem, you can download it online. But how about deleting or adding a declaration address? Can I download it without a stop?

I've heard it can be done, but with a correct sequence/procedure of DB->FB->FC? But I'm somewhat wondering, for if I increase or decrease an FB declaration, and download it before the FC, then the online FC (FB calls, with old addresses) is not in correspondent to the downloaded FB (with less or more addresses)? But the a more obvious problem if I download the new FC (updated FB calls) before the new FB (that which it calls)! This seems to be a dillema!

So please help!

PS:I am currently working on TIA Portal and S7-315 PN/DP, but I would also ask and appreciate any answers, on the same inquiry, for the classic Simatic Step 7.

Thanks for any response!

nicer,

some useful stuff for you here and here.

There are number of ways how to avoid stop ater download with DB interface changes, but none of them are supported nor recomended. The procedure should not be the same for classic S7 and TIA, since TIA checks consistency prior to any download.

Since your IDB has changed it's interface and timestamp, maybe the best way to perform this action is to make brand new FB with fresh IDB's. Download them (and delete the old ones) one by one to avoid memory override.

Hope this helps.

Best regards.

nicer

By this, it seems that it doesn't matter whether you first download the FB or it's instance DB, just download them first before the updated FC (FB calls), is this accurate?

I think that this observation is spot on correct. Imagine the case that you shorten your FB interface (IN, OUT or STAT area). In this scenario, you download modified FB and it's instances, while old FC (which is still online) calls FB with the old interface, trying to write (or read) from area that is not existing anymore. This would leed you to „area length error while R/W“, which, ofcourse, does not put your CPU to stop if synchronous error handling OB has been programmed, but can lead to incosistent or strange plant behaviour.

nicer

Now, I've also tried to compile the program after the FB modification without updating the FCs, and, if I still recall it well, it does not give me any warnings or errors. But, if I still recall it well, when I go back to the FCs, they are still not updated (the FB calls are red)! That means, if I download it, the PLC would stop, right? So, if I still recall it well, the compilation do not detect or update an unupdated block call/s? Or perhaps I just didn't recall it properly?

Did you compile all the blocks? I'm quite sure that consistency check (both in S7 or TIA) MUST detect outdated block calls...

nicer

"The procedure should not be the same for classic S7 and TIA, since TIA checks consistency prior to any download.", seems quite dubious.

The only reason I stated this is the fact that, in classic S7 programming, one CAN have one or more blocks with plenty of errors, but still be able to download any error-free program block. In TIA world, pressing download button always runs consistency check. If consistency check fails, no download will be performed. That's why I think this procedure, in most cases, shall not be the same for S7 and TIA.

nicer

I cannot see how to do this. To do deletion, I should first delete the FCs (FB calls), right? But surely, it is either A) I would erased first the FB call, or B) I would download my new FB call. But the two (old and new FB call) will have the same address (esp., for instance, the output command for motors). But how could I do it without stopping the motor, for if A, then the motor would stop (or at least, it's DB would be static for a while) since it's FB call is now deleted , and if B, then I would have a multiple outputs (the two would simultaneously have the same outputs. Is this confused?

This is what I actually ment:

1. Create new FB (the modified one);

2. Create new FC that will call new FB with new instances;

3. Put „BEU“ instruction at the bare beginning of the new FC (this will prevent user program from multiple I/O addresses Read/Write);

4. Download user program. Now you have new FC, new FB and new IDB's online, but not being called because of unconditional end command;

5. Open both old and new FC. Delete „BEU command“ from the new FC and put it at the beginning of the old FC;

6. Download user program and delete old FC, FB and IDBs from online and offline program folder.

And finally, you are right, deleting them one by one is possible, but DB will be static at least for a while.

Best regards :-)

nicer,

I agree with most of the tips you said in the previous two posts: in your example it really makes no difference what you download first.

But there is one more thing worth discussing: if one uses CFC in PCS7, even the smallest change in FB interface would cause compile/download procedure to request an entire download of the user program. Entire download restarts CPU, which makes me believe that recomended procedure is to perform a full download after FB interface modification whatsoever.

There are, doubtless, number of ways to avoid this in S7/TIA. As for my opinion, success of this operation (not only avoid of CPU stop, but also a good plant behaviour during this procedure) heavily depends on the sequence how you download changes, which, on the other hand, depends on how the program is written at the first place.

Best regards.