Tried all kinds of variations - 2 buckets, 1 bucket, DTOPT on/off, FOLLOW on/off (I was OK with averaging the input and passing directly to the output, etc) but it seemed like it either didn't average the inputs, or the output would decay to near zero by the end of the dead time, even if the input had good values coming in. I finally concluded that the DTIME I was working with had bugs. Instead I used 4 calc blocks (to provide a generous amount of "smoothing") to generate a running 24 hour average: CALC 1 - 12 samples taken every 5 seconds into a mem swap ladder and averaging those for a 1 minute running average updated every 5 seconds CALC 2 - use 10 @ 1 minute outputs from CALC 1 as 10 input samples taken once a minute into a mem swap ladder and averaging those for a 10 minute running average updated every minute CALC 3 - use 6 @ 10 minute outputs from CALC 2 as input samples taken once every 10 minutes into a mem swap ladder and averaging those for a 1 hour running average updated every 10 minutes CALC 4 - use 24 @ 1 hour outputs from CALC 3 as input samples taken once every hour into a mem swap ladder and averaging those for a 24 hour rolling average which updates once an hour I could also have done this in 3 or 4 lines in an IND block with 1440 1 minute grabs or even 86400 1 second samples, updating continuously, but am religious about following Alex's advice to avoid sequence code wherever possible. Maybe this should be the exception. I have done 1 hr, 4 hr, 24 hr and even 30-day rolling averages this way. Not proud of it, but if you use enough blocks, there is a way. Rick Guercio, P.E. RG Consulting 918 E Desert Shrub Drive Washington, UT 84780 713-805-8742 cell In a message dated 2/14/2013 9:29:46 A.M. Eastern Standard Time, Robert.Putman@xxxxxxxxxxxxxxxxx writes: Not sure if this is helpful but this is what I found on the DTIME block in BO193AX. When DTOPT is not set, the incoming measurement samples at each block execution period are averaged over the shift time period, for example to avoid loss of signal resolution. The average measurement values are shifted through the bucket brigade. To avoid rapid change of the output signal at each shift time, the output undergoes linear interpolation between the last two "oldest" stored values during each block execution time. When DTOPT is set, the averaging of incoming measurement samples is disabled and, at each deadtime block execution, the current measurement value (MEAS) is directly stored into the "newest" bucket, while the block output is updated each deadtime block execution with the value from the "oldest" bucket. Looks like the averaging is done on the 1st 2 buckets only. What is your delay (DT) set to? Did you try with DTOPT not set and 2 buckets (NUMBKT = 2)? Bob -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Rguercio@xxxxxxx Sent: Thursday, February 14, 2013 9:12 AM To: foxboro@xxxxxxxxxxxxx Subject: [foxboro] DTIME block Has anyone else had trouble with the DTIME block not functioning as advertised? We are running V7.1.1 on the Unix side and 8.3 on the mesh side. Can't seem to get the running average out of the block (yes, I know it's averaging the input, but I'd be happy with that - we tested it by simulating an input and can't get that feature to work). Have tried with FOLLOW on and OFF, DTOPT 0 and 1, BKTS from 1 to 10, varying the DT, etc. I'm thinking it's buggy (at least for our Rev) and there might be a QF I'm unaware of. Anybody? Rick Guercio, P.E. RG Consulting 918 E Desert Shrub Drive Washington, UT 84780 713-805-8742 cell _______________________________________________________________________ This mailing list is neither sponsored nor endorsed by Invensys Process Systems (formerly The Foxboro Company). Use the info you obtain here at your own risks. Read http://www.thecassandraproject.org/disclaimer.html foxboro mailing list: //www.freelists.org/list/foxboro to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave ________________________________ The information contained in this message and any attached files may be privileged and/or confidential and protected from disclosure. If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is strictly prohibited. If you have received this transmission in error, please so notify the sender immediately without reading it. Also, please promptly destroy the original transmission and its attachments. Any views or opinions presented in this message or attachments are those of the author and do not necessarily represent those of KapStone Paper and Packaging Corporation or its subsidiaries. _______________________________________________________________________ This mailing list is neither sponsored nor endorsed by Invensys Process Systems (formerly The Foxboro Company). Use the info you obtain here at your own risks. Read http://www.thecassandraproject.org/disclaimer.html foxboro mailing list: //www.freelists.org/list/foxboro to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave _______________________________________________________________________ This mailing list is neither sponsored nor endorsed by Invensys Process Systems (formerly The Foxboro Company). Use the info you obtain here at your own risks. Read http://www.thecassandraproject.org/disclaimer.html foxboro mailing list: //www.freelists.org/list/foxboro to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave