Emerson Exchange 365

• Not Answered

Accurate measuring time in DeltaV

Hello everyone,

I have a problem.I need to measure time as accurate as possible, i have used Retentive timer block but it measures time only every second, so i have accuracy +/- 1s. What can i do to improve accuracy of this measure?

izeusz

• 12 Dec 2015 9:59 AM
• Cancel

3 Replies

• Andre Dicaire

  

  • 14 Dec 2015 1:39 PM

  The DTE Block gives access to system time. But since you have not described what you are.attempting to do, not sure if this will be helpful.

  Andre Dicaire

  • Cancel
• solodiver2

  

  • 6 Jul 2017 11:25 AM

  In reply to Andre Dicaire:

  Does DeltaV specify accuracy of the timing functions in a module. Something analogous to the specs on a physical time delay relay.
  
  For example if I have a 15 second "Time Pulse" or "Delay Off" and a one second execution rate I would expect the elapsed time to be in the range of ~15-16 seconds. But is there a specification in seconds and/or percent.

  • Cancel
• Andre Dicaire

  

  • 6 Jul 2017 3:27 PM

  In reply to solodiver2:

  I'm not aware of a stated accuracy for the Controller clock. As with any computer the clock crystals have some variation between processors and likely vary with operating temperature. To address this, the DeltaV controllers are time synchronized. Time synchronization accuracy is stated in BOL based on whether a windows computer (pro plus or App station) is providing the synchronization, or if a Time Server is installed on the DeltaV network. This synchronizes all controllers to each other.
  
  As you point out, the execution period of the module creates a "window" where the timer will be detected and an action is taken. DeltaV modules are scheduled based on their configured execution period into time slices to ensure all modules are executed on time. However, since module logic can vary from scan to scan (If statements, SFC actions, Block scan multipliers) so there is some movement in time as to when a given module executes within its time slice. The controller monitors this and reports On Time execution through the combination of module "ONTIME" parameters and the diagnostic Percent On Time parameters. If a module is executing within 10% of its configured execution period, it is considered "On Time".
  
  So if a module is executing at 1 second intervals, it could be pulled forward or pushed back slightly from scan to scan. This behavior is not cumulative, and over time, will average out. But it is possible that a timer of 15 seconds might time reach 14.9 seconds on the 15th scan of the module, and so the timer will reach 15.9 or so on the next scan. The shorter the timer and the larger the execution period, the greater the percent impact on the timer accuracy. A timer's accuracy will always be dependent on those two factors, and the overall accuracy of the clock chip is insignificant.
  
  The Counter function can be used to create short repeatable delays, such that for 15 seconds on a 1 second module scan rate, the counter reaches the desired value in 15 scans, whether that is 14.9 or 15.1 seconds. If the module scan rate is changed, the counter value must also be changed. You can also increase the module scan rate, but this consumes more CPU. So in general, the timers are easiest to use. Counters can help in specific applications, increasing scan rate should be considered where appropriate.
  
  For longer time periods, such as daily accumulators, the DTE Block uses the system clock which can also adjust for Daylight Savings time. The Seconds past Midnight is also available, but this value is based on UTC, so if the system clock is adjusted using time zones, the Sec_P_MID value will reset at some other time than Midnight (except for Timezone = 0).

  Andre Dicaire

  • Cancel