Emerson Exchange 365

• Not Answered

Scan Rates: Control Module vs Unit Module vs CIOC

Hello,

I'm currently working with DeltaV v13.3.1 and SX controllers in our plant, specifically focusing on the control of pebble crusher subsystems. One of our modules requires a very fast scan rate to capture pulses from two prox switches, which determine the crusher mantle's rotation and position.

To achieve the desired fast scan rate, I'm planning to lower the scan rates of the Unit Module, Control Module, and CIOC to their maximum possible values. However, I'm seeking a better understanding of the differences between these scan rates to determine if I need to adjust all of them uniformly. Specifically, I want to know if the scan rate of the Control Module depends on the CIOC and Unit Module scan rates or if it is independent. Additionally, I'd appreciate an explanation of the purpose behind each scan rate.

Furthermore, within the Unit Module, we have approximately 32 Control Modules that interact with the field controller for valves and sensors. Some of these modules are SFCs responsible for controlling the sequence based on the control narrative.

Considering the requirement for a fast scan rate in only one of the Control Modules, I'm contemplating whether it would be more efficient to create a new Unit Module exclusively for this particular module. This approach aims to isolate the scan rate requirements, optimize performance, and simplify troubleshooting.

I would greatly appreciate any insights, experiences, or recommendations regarding the relationships between the scan rates of Control Module, CIOC, and Unit Module. Additionally, I'm open to hearing your thoughts on the feasibility and benefits of creating a dedicated Unit Module for the control module that requires a fast scan rate.

Thank you in advance for your valuable input!

Regards,

Michael Sovereign

Michael_Sovereign

• 19 Jun 2023 11:32 AM
• Cancel

7 Replies

• Michael_Sovereign

  

  • 19 Jun 2023 1:43 PM

  Hello again,
  
  Some additional information. There are two modules referencing the charm in question. The first one is the tooth counter module, which also requires the fast scan rate to accurately count pulses. The second module is a DI module, which has some dependencies that I'm currently working to sort out.
  
  My next question is regarding the scan rate when a charm is referenced by two DI functions in separate modules. Are there any implications for the scan rate? Should the scan rates of these two DI functions be the same, or is it possible to have different scan rates? I want to ensure that the charm's data is read reliably and that there are no conflicts or timing issues.
  
  Furthermore, are there any known issues or considerations when multiple DI functions pull data from the same charm? I'd like to understand any potential challenges or limitations associated with this configuration.
  
  Thanks again,
  
  Michael S

  • Cancel
• Matt Stoner

  

  • 19 Jun 2023 2:56 PM

  In reply to Michael_Sovereign:

  What kind of frequencies of the pulses are we talking about?
  
  Most likely you should change the Charm Type to Pulse Count Input which will give you a parameter COUNTER_IN that can be used in logic and this will ensure you won't miss a pulse depending on a scan rate and you shouldn't have to change any scan rates. Non-PK controllers fastest scan rate is 100 mSec which may not be fast enough to catch pulses where changing the Charm to pulse count would.
  
  Depending on the Charm type being used will determine the input frequency but 24VDC and Namur are 0.1 Hz to 10kHz requiring a 50 uSec pulse width and the 120/230 VAC are 0.1 Hz to 10 Hz. Search "pulse count input" in Books Online and you can find information on this. Note: that COUNTER_IN does have a roll over feature so your logic would need to handle this feature and/or use the RESET_COUNT at the DST.
  
  What are you using the pulses for? (i.e. Totalization)

  • Cancel
• Andre Dicaire

  

  • 19 Jun 2023 5:05 PM

  In reply to Michael_Sovereign:

  Michael, The IO data is communicated to the controller independently of the control Module IO block scans. The CIOC has a configurable reporting rate that defaults to 250ms, but is configurable to 50, 100, 250 and 500 ms. Each CHARM is assigned to a controller and communicates its data to that controller where it is made available to all modules. Different modules can scan the same Input channel at different rates.
  
  Note that IO reporting is asynchronous to control module execution. When you have two modules reading the same input, they may not see the same value on that channel as the channel may update between the execution time of the modules. As Matt points out, S-series controllers have a 100ms scan time as the fastest scan time. If the DI Pulse rate was faster than the IO scan, a new value would be reported every 50 ms. With two modules set to execute at 100 ms, there is no way to know or guarantee which module will a given value of the Count In. Module A could execute immediately before Module B or they might be executed 50 ms apart or 99 ms apart (making Module B first?). They could both see the same value or each see a different value based on when the IO updates.
  
  If you need both modules to use the same count value, then you should use one module to read the IO channel and then reference the second module to read the value in the first module.
  
  The CHARMs also have some latching filters that can help ensure a module sees a DI transition such as a Push button that is pressed but not held long enough for the module to see it. Adding a latch to the input ensures it is "TRUE" for a minimum time long enough for the module to execute. There are several options available to help condition the input to filter out false triggers and latch events, etc.
  
  By using the Pulse option, you can ensure the Module "sees" the total of pulses between executions and allows the module to act on short duration events on the IO.

  Andre Dicaire

  • Cancel
• Andre Dicaire

  

  • 19 Jun 2023 6:26 PM

  Scan rates are an interesting discussion (at least I think so). In the DeltaV controllers, the IO updates are asynchronous to the Module execution that uses the IO data. SImilarly, the Unit Module is asynchronous to the modules that it commands/manages. Executing to fast and you waste CPU resources. Executing too slow and you can affect control response.
  
  There is also a difference in closed loop analog control versus screw to screw response of discrete actions.
  - Screw to Screw measurement is dominated by the control Module execution. An Input change is reported to a controller by the IO card (Input latency) and sits in the controller's IO data map until a control Module reads it. An output response is sent to the Output channel following the module execution. The Output value will be picked up in the next IO update cycle, and is typically within 50ms with CHARMs.
  
  With CHARMs, the CHARM IO CARD update rate will impact the input latency. The default is 250 ms. For applications that have fast discrete response, the CIOC should be set to 50 ms. The total Input latency is the sum of the CHARM scan, the CIOC Bus scan and the configured reporting rate. That is, worst case, these are summed together to determine the max latency in reporting a signal change to the controller. The CIOC scans its CHARMS every 50 ms. The DI Charm has configurable input filters so these must be taken into consideration as well. The Pulse Count mode provides a new pulse count every scan.
  
  Local IO on DeltaV are scanned in a round robin cycle. The more cards with more data will affect overall scan time. The number of cards will determine the overall bus update rate, which can be seen in the diagnostics. Generally, we see the IO bus at 30 to 40 ms, but it can be as much as 60 ms. The card polling limits the cards per scan to ensure scan completion and cards with large data to transfer may require two or more scans to pass all data. DI and AI cards will update all channels in a single scan. The Card processing time is added to the scan time. Generally, local IO will report to the controller in sum 100 ms, and for a small number of IO, this can be sub 50 ms, even sub 30 ms.
  
  In discrete applicaitons, a change of state of the input is then read by a control module. The moduel scan time creates a maximum dead time from when the DI changed
  state. The DI state does not change in subsequent IO scans. In Analog Applicaitons, the Input continues to change with each input scan. The PID block eventually executes and updates the related output on a continuous basis. By reducing the Discrete module logic execution, you directly imrove screw to screw response.
  HOwever, for analog control, reducing the PID execution time means it will act on a smaller process change, and if it is too fast, the PV response to the last output adjustment has not had time to manifest.
  
  So the IO Latency works a bit in reverse for analog vs discrete. IO Latency determines the maximum speed for the PID. The PID sees the Output and Input latency as deadtime. For this reason, the PID should be set to be no faster than twice the IO latency, allowing for the process response to be seen. A faster PID will not improve loop performance if it results in a dead time dominant response due to IO Latency. Speeding up Discrete logic modules will directly reduce Screw to Screw and drive the discrete output response that much sooner.
  
  Back to scan rates, if you set the CIOC update rate to defaul of 250ms, 1 second PID loops will perform extremely well. 500 ms PID will begin to see impact of IO latency. If the Process time constant of that loop requires is 2 seconds, then 500 ms PID would be in order. If the time to steady state is long, the loop wills till perform well with 250 ms CIOC reporting. But if the look is to be tuned more aggressively, the IO scan time of the CIOC should be moved to 100 ms. Similarly, if the Time constant is 1 second, the PID block might benefit from 200ms execution, and if the loop is to be aggressive, the CIOC should be set to 50 ms.
  
  For Discrete logic, setting a module to 100 ms gives the minimum response. One should be looking at the CIOC scan rate first, getting the lowest IO latency to the controller. Then, if needed, adjust the module scan time to reach the desirable response time. This helps better manage the controller CPU speed.
  
  The Unit module sits atop the continuous control modules. This will determine the exeuction rate of the PHASE logic's continuously executed Monitor section, and the frequency at which transitions are evaluated. The complexity of the Monitor logic and number of Phases running will have the greatest impact on CPU usage. Sequences in the Phase Logic are generally waiting at transitions and evaluating confirm expressions and/or delay expressions, in the active step(s) so these have limited CPU impact. However, since MODE changes and Output changes rely on the underlying modules to execute, running Phase logic faster may not have much impact on batch time completion. Of course, this depends greatly on the actual configuration and process dynamics.
  
  I would review the module execution rates and determine which need to faster than 1 second. This will determine which IO might require an adjustment to the CIOC update rates.
  
  Note that the CIOC update rate is set for the entire CIOC. Faster CIOC update rates will reduce the controller Communication expansion value. You should monitor this diagnostic as you adjust the CIOC update rate. The actual impact is dependent on the type of CHARMS, with HART AI CHARMs having the largest impact.
  
  Once you have optimized the control module execution times and related CIOC updates, you can evaluate if the Unit Modules should be adjusted. You can use the Module EXEC_TIME parameter to guage the impact on CPU if you increase the execution rate. (reduce scan time). This value marks the time it takes for a module to execute, and reflects the module's complexity. However, the value shown can be higher than actual because of task interrupts. It is a piece of information and if it is high (> 5000), expect to see a more significant change in Control Expansion. Use Control Expansion as your ultimate guide.

  Andre Dicaire

  • Cancel
• Michael_Sovereign

  

  • 19 Jun 2023 6:44 PM

  In reply to Matt Stoner:

  Thanks for your reply Matt and Andre.
  
  So we have a pebble crusher. The mantle of the crusher is raised and lowered like a screw for gap size. The large gear that rotates the mantle has two prox switches slightly off center from each other so that we can determine rotation and do a count. The count determines mantle position with specs in the control narrative.
  
  Essentially two DI's, two PDE's, Two AND's, and two ACT. DI1 goes to PDE2 and AND1 ; DI2 goes to PDE1 and AND2. ACT1 increments an output tag called COUNTER ; ACT2 decrements COUNTER. COUNTER is used in other logic as per control narrative. Whichever prox switch triggers first sets the rotation then as the second one triggers AND is true and ACT actuates.
  
  I was trying the Pulse Input (PIN) function block, but didn't couldn't find that COUNTER_IN parameter. However, thanks to you, now I see it in the actual charm parameters using an Input block and external reference. I will test this as soon as the unit is available in the next couple days and tell you how it goes!
  
  Thanks again both of you,
  
  Michael S

  • Cancel
• Michael_Sovereign

  

  • 19 Jun 2023 6:45 PM

  In reply to Andre Dicaire:

  Excellent information so much detail, I love it!

  • Cancel
• Andre Dicaire

  

  • 19 Jun 2023 7:44 PM

  In reply to Michael_Sovereign:

  That is interesting. However, from your description, I don't think the Pulse count will help. If they both result in a single pulse, you will not be able to determine which came first if they both trigger in less than the fastest module execution time.
  
  It sounds like the proximity switches are detecting the gear teeth and you can count the number of teeth that have passed. If you have on switch a quarter distance of teeth from the other, one will trigger first depending on direction. But I don't think you can get DeltaV Module to know which came first, unless the time between the two switch triggers is > say 200 ms.
  
  If you could convert one of the counters to be a Positive direction switch, that is only true when rotating in one direction, you could use this to determine if you should add or substact the pulse count from the other switch. The state of the direction switch does not matter when is is stopped, as there are no pulses. Once the gears starts to rotate, it would either open or close this switch and hold that position until a change in direction.
  
  That will give you two inputs, one for direction, one for speed. And that will not require any extra module speed or possible wrong direction due to aliasing of signals.
  
  I would want to avoid any timing issues for a robust solution.

  Andre Dicaire

  • Cancel