Hi Everyone,
I am wondering what is better: putting as much as possible into one big action or splitting it up into smaller actions, when working with SFCs? E.g. I want to open 12 valves. The functionality would be the same in both implementation versions.
For formatting/debugging we would prefer to put the opening of each valve into a separate action with its own confirm. But since we are tight on controller resources, I was wondering whether this creates some overhead which might affect memory/CPU so that it would be better to put all in one action.
Thank you,
Istvan
In reply to István Orbán:
Istvan, The CPU load of either solution should not be of significant concern, as the Step does not continuously execute. Placing all assign statements in one action will complicate your confirm logic, and as long as one valve remains unconfirmed, you will be verifying all of them, and re-executing the action until it is. But once the transition is true, none of this is executing any more. With MDPlus and MX or SQ and SX, memory is not an issue.
I would go with the dedicated actions. You can easily sequence the actions if needed with the delay expression (wait for Action 1 to complete before running action 2, 3, 4 etc...). You can easily add/delete actions from the step, without affecting the transition, which waits for pending confirms to go to 0. modifying an action does not affect other logic so code is more robust.
The CPU load is transient for such a Step and since you have idle time on the CPU (per Emerson recommendations) there is really no reason to care. A step executes once per scan (if active), so if the step is active continuously, then it's CPU load is like that of an FBD module. But in a sequence, you pass through and move on. With separate actions, only unconfirmed actions would be evaluated on each scan, which I think would result in a slightly lighter load.
I think this would be hard to test but if you created equivalent modules and ran say 10 of each at 100ms, and made it such that you could control the confirm logic, you could see what happens as you confirm each "valve". What would the CPU load be for each solution when 11 of 12 valves are confirmed but one is still waiting for PV to equal SP. But, again, I'd do the individual actions as it is a much more maintainable code.
Andre Dicaire