Emerson Exchange 365

• Not Answered

SX controller's control expansion is less than 10

Current DeltaV version V13.3.1

Planning to upgrade to 14.3.1

issue: SX controller is having control expansion less than 10. as per Emerson recommendation it should be more than 10. to resolve this issue we are planning to split the controller into 2 SX controllers.

when we checked the cross controller communication there are more than 300 parameters (interlocks, external references) will there be any problem in this or these numbers will be ok to split the controller? 

Vithal Modak

• 10 Sep 2020 7:30 PM
• Cancel

2 Replies

• Andre Dicaire

  

  • 10 Sep 2020 10:00 PM

  The SX Controller Control Expansion indicates the remaining CPU available for control. Some people have a fear of 1% Control capacity and somehow the recommendation of 10 % minimum is put out there. The Control Index remains at a value of 2 all the way down to 1%, and goes to 1 at 0% expansion.
  
  In the M series controllers, the Freetime parameter was calculated based on an implied allocation of CPU, but there was no hard fence. As the Control CPU increased, so did other tasks like communication, redundancy processing and other tasks. When the Freetime dropped below 20%, the algorithm considered overall Idle time, and so the actual "Freetime" could drop suddenly and indicate total Idle time, and if that dropped to 0, the controller was starved for Processing power.
  
  The SX (starting in v12) has protected CPU for control, communications and such, and has a 100 to 0% validity. A controller is completely happy at 2% CPU capacity as it is at 20%. So the recommendation to maintain 10% available is more of a best practice than a requirement.
  
  When an SX or a PK or MX in v14 reach 0% Control Expansion, the control modules are not necessarily CPU starved, but you don't know if you are. The secondary indicator is the ONTIME percent indicator that shows how many modules are ontime (100%) and how many are slipping (<100%). A module is considered to be slipping if it is more than 10% off its scheduled execution rate. So you want o maintain 100% ontime.
  
  The other consideration is if your configuration has significant variability in module complexity. that is, there are a lot of conditional expressions that only run under certain conditions. If conditions are write, Control Expansion could drop to accommodate these functions, so the minimum control expansion number you wan to tolerate is 1%. Since trying to avoid 0% is the goal (you could be -10 and you won't know), stopping at 10% control CPU is not a bad recommendation, but it is not because bad things will happen from 10 to 1%, or even at 0%. But once you reach 10% resources, you need to consider the controller "Full".
  
  If you calculate the number of modules that used up 90% of the CPU, you can extrapolate that adding 10% more modules will take you to 1% expansion. But that assumes those additional modules have similar complexity and execution rates. You have to be cautious in deciding to add any more. You probably want to start that caution when the Control Index drops from 3 to 2. Index of 2 means watch what you add as CPU resource is limited. OS used in all controllers in v14 provides significant benefits in robustness and has built in resource allocation that did not exist in the previous OS of the controllers.
  
  As for Inter controller communications, this should be established as "Reads". That should happen naturally as typically interlocks read a value to determine the state of the condition. The system capacity charts indicate SX, MX and PK controllers to support 500 unsolicited values per second. There could be many more parameters mapped, but due to the exception reporting, the number of values sent per second could be very low. Out of 300 parameters, if most are discrete values, the number of unsolicited values per second would be low. If values are mostly Floating Point variables, the number of Unsolsent attributes will be higher. A value cannot send date faster than the source module execution rate, and the requesting module will request it at its execution rate, so a 1 second module asking for data from a 1 second module will get data every second, if it changes.
  
  Most function blocks manage the change state or flag of their parameters for efficient unsolicited sends. If you wire the parameter to a "holding" parameter, the wire effectively writes the value from the source connection to the destination. This will set the Change Flag on that parameter. This type of configuration has little impact on locally refererenced parameters, but if that parameter is sent via Unsolicited, even if it is Boolean and not changing, the wired connection will drive a change flag and cause a value to be sent every scan of the module.
  
  My recommendation is that if you wish to expose a block parameter, such as MOTOR_MODULE/EDC1/SP to a Module level parameter of MOTOR_MODULE/SP, make this an internal reference to the EDC1/SP parameter, and the Change flag will be managed by the EDC block and you will maintain efficient Unsolsent numbers to both the peer controller and to every console and historian tracking this value.

  Andre Dicaire

  • Cancel
• Dragonfly

  

  • 26 Jan 2021 11:13 AM

  In reply to Andre Dicaire:

  Thank you for the complex post. I have one more question. I have SQ controller which has control expansion on 9%. The plant is running and I do not expect to add Big amount of new logic. Is it possible to say how the control expansion will be changed after upgrade DeltaV from 12.3 to 14.3? Does upgrade have any significant affect for control expansion?
  Thank you

  • Cancel