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
Hi
I think it is better to use smaller actions than bigger one.
We can change qualifiker for particular actions if necessary (for example delayed actions: valve2 open when valve1 is closed) or disable actions if necessary during maintenance or test.
In reply to Roman Kostuniak:
Hi Roman,
I understand that this would be nicer. But I am also interested whether there is a difference in resource demand between the two solutions.
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
The big difference in resource demand will be all the extra mental resources required for future engineers to troubleshoot the code if you put everything in one action. Smaller actions are better, since that future engineer might be you :-)
In reply to carllemp:
Hi,
SFC modules don’t consume as much cpu and memory resources as FBD modules does. Don’t worry about cpu performance, think in future maintenance of the module instead.
If you are concerned about the cpu usage of your system, check Load estimator utility in deltav installation disk and make an analysis of your system load.
Regards
In reply to lsocorro:
Thank you for the suggestions.
We have quite a special case here, we have mutiple SFCs running all the time on every controller, sucking up lots of resources. We are using SX controllers but CPU is running low.
A new idea is that where we have parallel STEPS with few actions each, we put the actions into one step. Would that decrease overhead?
So there are two questions:
1. using multiple parallel steps VS one step with the respective actions
2. using mutiple smaller actions in a step VS pasting the code into one big action (I understand that this is more difficult to maintain, but I am still planning to run some tests)
I understand that code is code, and wherever you put it, it needs to be executed and for that, it consumes resources. But I am also wondering whether some of these changes could improve performance.
Did anyone make such experiments?
In reply to AdrianOffield:
If the issue is low memory on the controller, you may be better off optimizing at the module level rather than the detailed action level. There is some memory overhead associated with each module and that is surely much bigger than the overhead for an extra step or action within the SFC. I have never checked for stand alone SFCs but in the case of EMs and phases, that overhead is something like 2 Meg each. If it is the same for SFCs, then you would have to do a whole lot of step/action optimization to get the same benefit as eliminating even one SFC.
Buy another controller.