Emerson Exchange 365

• Not Answered

Continuous comparison

Dear community.

i hope you are doing good.

i would like to compare continuously the PV of the temperature at time to the Value at (t= -1 Hour ), in order to generate an alarm if the deviation is higher than 2°C.

what is the best way to do it without using the DeltaV reporter ?

Many thanks.

Best regards.

Butler faith.

• DeltaV

Butler faith

• 28 Oct 2023 5:54 PM
• Cancel

2 Replies

• Matt Forbis

  

  • 30 Oct 2023 1:13 PM

  To do something like this, you need to store values in an array. I have created a composite in the past to do this rolling average sort of logic (whether you average or not, the same basic algorithm is followed). An array in a DeltaV control module can have up to 120 elements in one direction with a total of 240 elements. Use a calc block with an internal variable as a pointer. Each scan of the module, increment the pointer, read out the value pointed to, store the new value and then do the math you need to such as average or difference. Then, add a bit of logic for the pointer to roll over and you'll have what you need. (You can easily find a rolling average the same way, just by adding new value and subtracting old value and dividing by number of samples. If you do a rolling average, don't forget to add a bit of logic while the array is filling up).
  
  To figure out how long / what to set your scan rate to, 1hr=3600 seconds / 240 elements = 15 second block scan rate (you can have a block scan slower than a module). If you need more resolution, you can either add more array parameters which complicates the logic or what we have done quite a bit is average a smaller group (say over a minute) and then use the small averages stored together to make a bigger difference / average.
  
  I don't have a way to attach a composite here, but if you send me an email, I can send you a copy of what I've used before to just drop into an existing module.

  • Cancel
• Andre Dicaire

  

  • 30 Oct 2023 3:50 PM

  In reply to Matt Forbis:

  The DT block (deadtime block) also gives you a first, first out stack with 30 values and their status. BOL has more.
  
  How many values do you need to store in a FIFO stack? If you ran this at 1 second and stored the PV every scan, you'd need 3600 for an hour. But if your process has a 10 second Time constant, you could use that to your advantage and only store 360 values. To avoid Aliasing, you would put a filter ahead of the FIFO and set this to 1.35 times the sample rate, or 13.5 seconds. You could try even fewer values and see what that looks like. Build a separate module and create a couple of FIFO's, one with 10 Deadtime blocks (300 values)and the other with one block (30 values). The FIFO with 10 blocks uses a deadtime of 30 seconds in each block, for a 300 second deadtime. The single block uses a 300 second deadtime. Set the anti aliasing filters appropriately (1.35 and 13.5 respectively) and feed the PV to both and compare the outputs. The outputs would be the same with larger stacks, just delayed longer. So this is a quick test of the impact of having more or less values.
  
  If you decide to use fewer values, like 360 values for one hour, you will get a step wise value on the output. You can smooth that out by delaying the last DT out for one scan, so that you can compare the DT Out and the previous value so you can ramp to the current value.
  - To create a last scan value, use an Input parameter with internal reference to the DT out value. On module execution, the Input parameter reads the DT out at the beginning of the module, storing what is
  effectively the value from the last scan.
  
  The function blocks then execute and DT out updates for this scan. Now you can compare the two values, divide by ten and add this value to the last scan value to ramp to the current value. I'd finish this last part in a CALC block. It's optional.
  
  If you decide to build your own FIFO stack as Matt suggested, you can get away with fewer blocks, but you have to figure out the initialization, the stack pointers, and whether status needs to propagate.
  
  In either case, building this in a composite keeps your module top layer clean. But you can start with a test module or even run this permanently in a separate module and pull the results back to the main module with external reference once your satisfied you have the right algorithm. This avoids you making repeated downloads to the current module as you tweak and optimize the solution.

  Andre Dicaire

  • Cancel