Unable to load FB error despite FB no longer being called

[RMA]

Somewhere along the line I created an FB512 (and FB513) as S7-GRAPH programs. This then caused me some problems with my standard nomenclature because I also used a Timer in the program and wanted the number to be the same as the FB - which of course wasn't possible. So I renamed (not deleted and re-created) the programs to FB508 & FB509.

Now I'm getting an error in the diagnostic buffer that called FB512 is not loaded. By removing OB121 and allowing the CPU to go into STOP, I discovered that the calling program is FC72, the Standard support FC for S7-GRAPH programs. Evidently it has noted the creation of the FB as an S7-GRAPH program, but since I renamed rather than deleting the FB, it is still trying to monitor it.

Anybody got any ideas how I can convince FC72 that FB512 no longer exists?

 

[danpantea]

Conpile, check block consistency, download and hold your breath.

 

[SimonGoldsworthy]

Looks like Step 7 stores the FB/DB number in the instance DB created for the Graph block. See variable M_FBDB in the instance DB. FC72 must read this area. I guess I would have done a "save as" to rename the FB number and then deleted the one I didn't want.

By changing M_FBDB to an FB number that doesn't exist, I get the same diagnostic buffer entries as you. (Note that the FB address is the lower part of the DWORD). You could try changing it to the correct FB number and then do a save as and then re-create the instance DB.

 

[S7Guy]

Another thing to check (in case you are using symbolic priority representation) is whether the mystery FB is still defined in your symbol table. If so, maybe you are calling it symbolically, and Step 7 won't alert you that it is invalid. You might want to try deleting the orginal FB from the symbol table.

And as Dan mentioned, do a consistency check. I do one almost every day.

 

[RMA]

Thanks guys, that got it. It wasn't in the Symbol Table and the actual value in the IDB was correct, however the initial value was wrong (i.e. unchanged). How this affected the program so that it still gave an error every cycle (checked using the update button in the diagnostic buffer) is a minor mystery, but deleting and recreating the IDB solved the problem.

As far as the consistency check is concerned, ever since Simon corrected my misapprehension that the consistency check in HW-Config was checking the Block consistency, I now do regular consistency checks (usually more than once a day and certainly before every new backup (Save as)). Curiously enough, the consistency check didn't find the problem.