Emerson Exchange 365

Is there a reason a filter will not calculate in an AI module (PV_FTIME)?

I have it set to 600seconds and a PV change from 1.60psig to 1.65psig is not getting filtered. the output is going straight through the module without being filtered. What am I missing?

Is there a reason a filter will not calculate in an AI module (PV_FTIME)?

I have it set to 600seconds and a PV change from 1.60psig to 1.65psig is not getting filtered. the output is going straight through the module without being filtered. What am I missing?

In reply to JDWheelis:

In reply to Petrisky,
Since this is a dialogue between engineers and nobody will take offense, I will first question your data, second question your motive, and third suggest an alternative test.

What is the execution interval of the AI block? Choosing time constant = 600 seconds means the full effect will not be felt until approximately 40 minutes later. 600 seconds is 10x the largest filter I have ever used. It also means that the output will change very little on the first execution. Are you waiting enough executions to see a measurable change?

If the AI block is part of a PID loop, I recommend that you place the filter in the PID block instead of the AI block. Then the filter will be more visible to people who may need to tune this loop. A filter in the AI block is more "hidden". Also, since you might be encountering some arcane property of the DeltaV AI block (with extremely large time constant--and perhaps related to execution time) then we should entertain the possibility that the PID block's filter may have different properties.

Finally, considering my last point above, could you try a different block with the same function: the Lead/Lag block?

In reply to Mark Coughran:

Good points by J.D. and Mark! I would also question the Continuous Historian compression settings if you are using it to view the response data. Note that if you view the trends while they are recording in the Continuous Historian, the compression is "turned off". However, if you close the trend window an re-open it, the data will be compressed per the setting. Since you made such a small change (0.05) the data compression settings may distort the results.

In reply to James Beall:

To be more clear...the reason I changed the Tc to 600 seconds just to prove it was not working.... at Tc = 600 seconds and a scan rate of 1 second for the AI module, then a change in the PV should basically not be seen. However, the PV is bouncing all over the place. I really just would like to know if there is some parameter I am missing that would disable the PV_FTIME?

filter equation for AI block is x + (IN-x)*(1-e^-(dt/Tc))

if the input is 1.71 psig at T1

1.91psig at T2

and Tc=600

Then AI Output PV should = 1.71 + (1.91-1.71)*(1-e^-(1/600)) = 1.71033psig

Instead no filter is applied and the resultant PV at T2 is still showing 1.91psig.

What parameters should I examine to find out why AI block is not executing filter function?

In reply to Petrisky:

This is just a standard AI block for display. However, the output is referenced by the 3 other modules to perform various calculations.

In reply to James Beall:

PHV uses both historical data and real time data when presenting trends. Initially, the CHART retrieves history data to draw the past process behavior (if available) and updates the trend with real time data. The real time data comes directly from the workstation where PHV is running, and not the Historian. As such, it does not apply compression to the trend data. Viewing the trend with points will show a reduced number of points due to compression on the history data, but periodic points for the real time. Refreshing the CHART forces the history data to be retrieved, with real time values beginning again from that point forward.

The CHART real time settings default at 5 seconds. This can result in a drastic change in trend appearance compared to the historical data when the real time sample period is different that the history sample period and the values is dynamic. Make sure the CHART sampling is set to reflect the data being viewed so the current trend is not aliased.

By using the real time value for the current trend, all parameters in the system can be trended, even if they don't have historical data to view the past. Always set the sample period of the chart to the fastest required by the data displayed.

The history data will have compression applied based on the history collection settings. Real time data has no compression.

Andre Dicaire

In reply to Petrisky:

We are all stumped as having a filter configured on the AI block should result in a filtered value for PV and OUT.

The Filter is applied after the L_TYPE selector that applies the direct value, EU ranged value or Square root converted value.  The PV is subject to the IO OPTS which allows low cut off to be enabled. OUT follows PV in AUTO.  

Based on the simplified execution logic diagram above, PV should be affected by Filter even if value is simulated or from the defined source.  There is no option or separate parameter to enable or disable Filter time.  PV_FTIME set to 0 disables the filter.  

But you still are seeing something anomalous.  The AI block does not allow ROUT or CAS, or RCAS.  It can't really be manipulated externally. You can set it out of service and write to the OUT value, but it would have a bad status Out of Service.  That would be pretty obvious.  Setting Simulate enabled still passes value thought Filter, which is what JD demonstrated.

The FIELD_VAL is before the filter, and if this were being referenced, it would not be filtered.  This is the calculated Percent value of the incoming signal.  But if you are monitoring PV or OUT, then filter is in play.

Can you post a picture of the AI block properties and the diagram?  I can't think of anything that can explain what you are observing.  Maybe a picture would reveal something we are not seeing.  Is this a real controller or a VM controller or module running no App station? 

Are you seeing this behavior in any other AI block on your system? If not, what's different about this module?  What version are you running and what firmware is on it.  Have you tried reconfiguring the AI block and a total download?

Here is a weird and likely not valid explanation?  The module actually has an embedded block named AI1 that is built to look like an AI block and has all the parameters that an AI block looks for, but the module has been modified to have an actual AI block, which has not been downloaded.  Online view shows you data where it is supposed to be, but the running module is ignoring the filter and you don't see that.  You download the module with the native AI block and now everyting works.  (not saying this is the issue, but grasping at straws to explain this).

Find this module in the POWER UP directory  (search for module name in File Explorer) and save this file.  After the download you can compare the new version with the old version.  If it is the above, the files will be significantly different.  

Or its something much simpler that we just can't see from the information provided.

Andre Dicaire

In reply to Andre Dicaire:

Good Morning. This is only happening for a single AI module. I have re-downloaded the module. No change. The operator is bothered by how much the number is jumping around. After further investigation the lask of filter operation is not affecting any other control calculations. the change is small enough that it is inconsequential. However...It i still unnerving to not know why the filter is not working.

I am not sure how to paste an image to this EmersonExchange365 platform. Let me know how and I will past the module and the clip of the PV jumping around