Emerson Exchange 365

Daily Average Temperature

The site's permit requires that the incinerator is operated at a daily average temperature above "xxxx" degrees.

My thought was to utilize an INT integrator block and divide by "seconds_past_midnight" corrected to local time. I'm concerned to use a "seconds" time base though since a 10^3 magnitude temperature totaled over 86400 seconds might be quite large.

Should I be afraid? Anyone have a clever scheme for computing such an average (in real time not in arrears) that they would have a minute to share?

Thanks,

John R.

• Integrator

John Rezabek

• 29 Jan 2020 10:25 PM
• Cancel

6 Replies

• Chris

  

  • 30 Jan 2020 12:58 AM

  We have a daily average module that uses a timer (1min) to take a sample and add to a total (Calc block). It keeps track of the number of samples and does a simple divide (total divided by number of samples) in a Calc block. The reset is done by a DTE block at midnight ever day. Seems to work ok, when downloaded it starts again with first sample again.
  
  Perhaps something simple like that might work for you. I think that is what you asked for rather than a rolling 24h average.
  
  As far as the magnitude, DeltaV uses IEEE-754 which has an accuracy of 23bit or about 8,388,608 so 10,000 is not likely to be any problem. Of course IEEE-754 can represent far larger numbers but this is the limit for number of significant figures.

  • Cancel
• SBPosey

  

  • 30 Jan 2020 2:19 PM

  A cautionary note about using "seconds_past_midnight" corrected to local time: if your location uses daylight savings time, the change-over will provide significant error (at time of change-over, an actual 1000 average temp will read either 667 or 1500, depending on the direction of change). If your location does not use daylight savings time or if you provide a workaround for it, using a "seconds" time base will introduce loss of precision, but it should probably not be a significant factor in the average. Test your solution with a constant input of 1000. You know the result should be an average of 1000. See what you get. If the error is too much, then you can go to a "minutes" timebase. Going to the simple calc like Chris describes may be a better solution. It would also allow for more flexibility with resets. E.g., if the incinerator has been shutdown and starts up at noon, you can provide a manual reset.

  • Cancel
• John Rezabek

  

  • 31 Jan 2020 12:24 PM

  In reply to SBPosey:

  Thanks for the suggestions. Is there any work-around for the array size limit (I think 255) in Calc blocks (maybe for any module variable)? But I guess if I use Chris's suggestion I don't really need to maintain an array - just add to the running total and increment the "count". It would also make the result more manageable for the "not incinerating" mode i.e. startups - just don't increment the total or the counter when it's determined to be "out of service".

  • Cancel
• SBPosey

  

  • 3 Feb 2020 2:36 PM

  In reply to John Rezabek:

  Right, maintaining an array for this project is not required. For other projects, if you need to exceed to limits of an array (up to 127 by 127, max 240 elements, max 200 elements if you want the array to be redundant), you'll need to create multiple array variables. For a project in which we needed 360 elements (for a bigger deadtime block), we used 3 arrays of 120 elements each.

  • Cancel
• Daugenet

  

  • 4 Feb 2020 6:25 PM

  You could do something simple as well like the following and have it reset when you desire. This would eliminate the concern about having an array.
  
  current_average = ((current_average * previous_sample_count) + (current_sample_value)) / (previous_sample_count + 1);
  previous_sample_count := previous_sample_count + 1;

  • Cancel
• fairchdm

  

  • 6 Feb 2020 8:37 PM

  John, I have made similar integration modules like you are asking about for several years on many different processes.
  If you only need a current daily process value use the integration block as you had thought. It's simple and straight forward.
  
  The problem arises with the maintenance of these modules when they are used for environmental compliance or other regulatory bodies. Someone will ask for a report of all your collected data from 6 months ago.
  
  DeltaV was never designed to be a database system. Holding values for long periods of time is a losing games.
  
  Keep the modules as simple and clean as possible. Send any historical data to a Historian for later reporting and analysis needs.
  
  You'll be much happier. Don't ask me how I know. ;-)

  • Cancel