S7 FBs - Nested Multi-Instances Question

[kdcui]

I have an S7 "best practice" question (although maybe this topic is not as cut and dry).

I'm programming in an S7-1500. I'm not programming a batch process, but I'm trying to observe the concepts of S88 in my programming by using Equipment Modules and Control Modules and driving events through an S88-like state machine.

Let's say I have a EM made up of several CMs (some Valves, Analog Inputs, etc.). I want to create modular functions of the EMs and CMs so that I can build a modular library. Inside of an instance of a particular EM I would utilize the instances of the CMs. Therefore everything is (ideally) as modular and self-contained as I can make it.

I'm debating two options:
1) Put the FB instance call to all CMs inside of the EM FB.
From what I can see, this would require passing rather "large" UDTs as InOuts (parameter instances?) that contain all the information of the underlying CM instance.

2) Put the FB calls outside the EM FB, in their own routine.
I could define another FB to handle all CM calls, then pass the corresponding CM instances as InOut UDTs on a select basis to the EMs instances to "use" the CMs.

Option 2 might be easier to troubleshoot and maintain, and also seems to have the benefit of being able to be more flexible if I wanted to put CM logic into a cyclic interrupt (in Rockwell / AB world I believe they recommend putting CM logic in Fast periodic tasks - this might not be as much of an issue with a S7-1500?). But this option does not seem to be as modular to me.

Any info to help point me in the right direction is appreciated. I'm trying not to reinvent the wheel here. Most Siemens examples for S88 are all PCS 7 and the closest example I have downloaded is a PackML example which did not really help.

Thanks.

 

[L D[AR2P#0.0]]

I'd go with option 1 - when you pass UDT's as in_out they are passed by reference rather than by value so the size of the UDT is irrelevant. I suggest experimenting to see what fits best for your application.

 

[kdcui]

Thanks, appreciate the input. I'm going to experiment a bit, I'll report back for posterity's sake once I figure something out that works.

 

[kdcui]

Just an update here.

So I ended-up deciding to not nest FBs (although I am using multi-instances in certain cases). With the majority of my programming, each device will have a Global UDT structure with is pass as an InOut to various elements.

In my example:
o A higher level "Valve FB" which has multi-instances of "fbValve".
o Each fbValve passes an InOut "interface" or control structure to a Global DB (say, dbValves).
o The fbValve instances themselves can have IO tags mapped to them as In and Out parameters.
o Pass the InOut "interface" structure (from dbValves) into my "parent" modules that own the valves, which then issue commands and such - which are acted upon back in "Valve FB".

Nesting the CMs for a Valve inside another module just got too messy too quickly, especially when needing to map IO (now I need to pass that down as well). Much easier and faster to have separate routines to run the logic of each module. Also easier to read and maintain (in my opinion) - there will be non-engineer technicians who need to make sense of this in the future.

Another added benefit is if I run into scan time issues, I can isolate devices in a cyclic interrupt separate from, say, main system control or other procedural logic.

Totally possible I'm overthinking this too - but this seemed to work well for me and is consistent with some other examples I've seen elsewhere (and similar to what I've done in RA / AB Logix applications).

Cheers!