Step7 - program organisation

I'm at the beginning of a project and have opportunity to develop the code from scratch. The control system consists of instruments (pressure, temperature, etc.), ON/OFF valves, Control Valves, simocodes, etc. Not a complicated one but quite a few devices is to be used.
For practical reasons (easier to test, maintain and connect with SCADA) basic operation of each device will be programmed in its FB. Of course the same FB will be used for the same type of device. The process logic will be done in FCs and FBs 'above' devices level.
I'm bit uncertain how to approach and organise Control Valve FB where PID control is to be implemented as well. As SFB41 must be called from OB3x, is it better to store PID parameters in CV FB and pass it to PID each time or all the parameters store in DBs relevant for SFB41? The answer would be simpler if only one set of parameters was used for one CV. In this project few modes are available for one CV, each mode forces different PID settings, setpoints, process values, etc. There should be manual mode on top of this as well as fixed position mode forced by a system.
I'm sort of half way and cannot make decision what solution would be better - could you please share your experience and describe the way your codes are organised when it comes to a similar system?

Thanks!

Maybe you should embed SFB41 into the valve control FB. This is called "multiple instance" in Siemens lingo. Simply add SFB41 as an entry in the STAT declaration of the FB.

The disadvantage is that any modification of the FBs declaration, will require the instance DBs to be updated and downloaded. That will mean the initial values will be downloaded to the IDB, including the SFB41 part.
So it is only recommended if you are sure to have made fully debugged FB code with all the functionality you might want to have. Online change of the declaration part is really not possible. Code part yes, declaration part no.

Otherwise, split into separate IDBs for the valve part and the PID part.
I would not create a big IDB for all PIDs. Same again, any modification that require download of the IDB will reset all PIDs to the initial values.

Todays S7 PLCs have lots of memory and can address lots of DBs, so there is little reason to group all DBs together, unless there are other advantages - such as maintaining a common code base.

Your own argument is quite valid:

As SFB41 must be called from OB3x

Click to expand...

The non-PID part of the valve FB is probably called cyclically via OB1.
The PID part should be called in update intervals, for faster processes definitely via a timed interrupt OB.
That is also an argument for splitting the IDBs.

Thanks Jesper. Have been thinking about it the whole morning and decided to split it. Too many problems and disadvantages might occur if I don't stick to the rule where every PID loop has its all parameters stored in separate IDB.

For what it's worth, I have done exactly as Jesper describes when implementing PID control - encapsulate the valve functions as an FB called in the normal OB1 program, and called the PID function only in OB3x. Essentially, the valve part of the program does alarming, interlocks and manual control and only the automatic setpoint comes from the PID block. You may also find it helpful to put each PID block into a "wrapper" FB if you want to add functions or a HMI interface to the parameters.