• Not Answered

building trends

I know some of my questions are basic in nature, but there are things I was never made aware of. when I build trends, once I move on and days later I pull the trend up, and it is not archiving in the historian (I believe this to be correct term) the trend is there but it hasn't been capturing the trend its fresh? how do I properly build a trend and save it so it monitors and keeps data?

3 Replies

  • Hi Tom,

    Check to make sure that the parameters that you have plotted on the trend are in the history collection. Right click on the module in Explorer and select History Collection, add new parameters if needed. Next, in Explorer, expand the station that contains the historian , click on the Continuous Historian and ensure the areas are assigned to it. Finally download the Continuous Historian. If all of this has already been done and you're still not seeing the historical data, check to make sure PHV has its Historical Data Server set to the station that contains the Continuous Historian.
  • Tom, As Trista mentions, the data must be assigned to a historian for collection in order to view the data historically. When you build a trend, you are (likely) in Process History View, or PHV, which is the history visualization tool. The PHV trend can included runtime data and or historical data so that you can build a trend for non-historized data that provides on demand trends as well as historical trends.

    So history collection is a different configuration task than history data display (with PHV).

    Things you should know (I think anyway).

    * Difference between History and real time trend lines.

    PHV trends combine history data with real time data. When a Trend is opened or initialized, it makes a call to the history server to retrieve any history for the configured pens based on the time window of the chart. Then, it begins reading the runtime data via the local OPC server on the workstations. With the Trend active, over time, the trend will replace the history data with this OPC real time data.

    Why is this important? The PHV trend has a scan interval that defaults to 5 seconds. It samples and stores the OPC value at this rate. The History server will have a scan time for each tag that may be faster or slower than this. Also the History server applies compression and evaluates for Min/Max inflections to store a very efficient data set that will accurately reproduce the trend. Even if they both sample at 5 seconds, the values can be taken at different times. The result is you history data may look like a smooth curve while the real time data looks like a say tooth or choppy set of lines. And if you initialize the trend, the data "changes", as the realtime data is replaced with history data.

    To minimize this, set your Trend to scan at 1 second. Much of these data points are discarded by the historian, but the real time and history trends will look the same. If you display with data points, you'll see way more points in the real time area, but that's OK. As for communication impact, it's only 8 points per trend, and you are likely communicating these values to the Operator screen, so the data is already reporting to the console at 1 second updates. So this has no additional impact on network communications.

    * Workstation default History servers:

    In additional to configuring the tags into a history server, you also have to point the PHV application to retrieve data from the correct History server location. Each workstation can have up to 250 history tags configured in a local Continuous Historian, so the PHV app could be looking at the Local Host for history, and if not there, it gives you real time data. You can set this in PHV app under File Default hosts, and you set the Continuous Historian and Event Historians to point to the Application station hosting these. If not set, you'll only see real time data on that Workstation. I believe you can set this in the User Settings file so it is consistent for the system.

    * Default Trends files:

    The DeltaV System contains a set of preformatted Trends designed to work with the default Faceplate displays, which by design work with the Out of Box Module templats. (i.e. Loop_fp.grf works with the PID modules, and by extension, a PHV file is created called Loop_fp.PHVE) The faceplate file has an icon that calls up a PHV trend that shows the main parameters of the module. If these paths are historized, you will also see history data for the loop.

    Note that the default configuration looks for the same parameter paths as the Faceplate, such as PID1/PV, and PID1/SP etc. If you used an other name for the PID block, rather than PID1, the faceplate and Trend files would not work. You would need to modify the Faceplate references to the right block name, and also the Trend file.

    Some users have added module level parameters such as /PV, /SP and /OUT, and configured these to be historized. The expected history path of MODULE/PID1/SP.CV is replaced by MODULE/SP.CV. The default trend file is designed to look for MOD/PID1/SP.CV. MOD is a wildcard and is substituted with the Module Name from the faceplate. This will result in no history data in the trend if the Trend pen path is different than the History tag (path).

    DeltaV uses the parameter path as the history tag, so if you do create a shortcut parameter for history collection, you will need to update your default files, or create new ones. The faceplate and dynamos would still be happy as they link to the PID1 block parameters. You can open the library trends and edit them (with correct user privilege) and adjust the path to match the configured History Collection paths. Since the Trend file name must match the Faceplate File name, you should create your own set of faceplates and trends with different names and leave the default files alone. You simply change the Faceplate file defined in the module Display properties to use the new Faceplate, and this will use the new PHV file, aligned with your history tag paths.

    Or use the default history configuration paths.

    * Elevated parameters need Scaling information:

    If you do create a module level /PV parameter, you'll also need a Scaling parameter so that PHV and the Historian can get Engineering Unit and range at run time. When PHV opens a trend for say PIC-101/PV.CV, it wants to assign a scale to the Y axis. Although you can set this manually when you configure the trend, that does not work with default trends that are used for many different loops. Also, you don't want to have to update custom trends every time you change the scale of an input.

    Note that in the PID block, there is a scale parameter called /PV_SCALE. By default, the Trend display is configured for /PID1/PV.CV and will find /PID1/PV_SCALE as the associated Scale to use. If you elevate PV to a module level parameter, you must also create a PV_SCALE scaling parameter to match or else PHV will default to 0-100 %.

    PHV will look for a Scaling parameter based on the Parameter name first, then it will look for a few standard options (PV_SCALE, SP_SCALE, OUT_SCALE) and then default to 0-100% if none is found. Since a PID typically has different scaling for the PV and OUT, you should have a PV_SCALE and OUT_SCALE parameters in the same path as the PV, SP and OUT parameters you create in a module. Note that SP will use PV_SCALE as it is not explicitly defined, just like in the PID block.



    (every DeltaV workstation has an OPC Server for the purpose of providing real time trend data to PHV. The Excel Add-in License can unlock the Workstation OPC Server for 500 tags for use with Excel or other apps. )

    Andre Dicaire