Trending - a simple way

[tmalone]

I like the drag-and drop trends, I like the trend system that is built into the demo apps. Both work well, but they are much more than a simple application needs.

I would like to build a trend panel that has some buttons on the side that map pens to historial data when you press the button. I have discovered that you can't just change the DataSource, and that you most removeCurve and then addCurve to get new ones. I can't seem to get the rest of the properties of the pens to work.

I can't quite understand the details for getting this done. Does connectDirectly use the archive? That sounds like a runtime only trend?

Can someone share some scripting that a button can change a pen on a chart?

Thanks

Todd Malone
HMI CoC

[leoknipp]

Hello,

if you want to change the data-source for a trend curve you have to use the functions disconnectDirectly and connectDirectly. After the disconnect you have to call the function curveRemoveData for the given curve to delete the values which are already displayed.

Best Regards
Leopold Knipp
Senior Support Specialist

[aorange]

This is just an example of some code I have in one of our panels displaying a trend... just create a trend object in your panel and name it "TREND1", use the trend editor to remove all curves from the object and set your default display preferences e.g. 7 days and 30% of visible area.

The code snippet below needs to be in the panel ScopeLib;

Code: Select all

int iCurvesOnTrend;

void drawOnTrend(string dp)
{
  // Remove any curves already on the trend
  for(int i = 1; i  0)
    {
      setMultiValue("TREND1", "curveAutoscale", "CURVE" + iCurvesOnTrend, FALSE,
                    "TREND1", "curveMin",       "CURVE" + iCurvesOnTrend, 0,
                    "TREND1", "curveMax",       "CURVE" + iCurvesOnTrend, (dynMax(dfChHist) * 1.1));
    }
    
    else
    {
      setValue("TREND1", "curveAutoscale", "CURVE" + iCurvesOnTrend, TRUE);
    }
     
    setMultiValue("TREND1", "curveLegendName",      "CURVE" + iCurvesOnTrend, dpSubStr(dp, DPSUB_DP_EL),    
                       "TREND1", "curveScaleVisibility", "CURVE" + iCurvesOnTrend, TRUE,
                       "TREND1", "curveScalePosition",   "CURVE" + iCurvesOnTrend, SCALE_LEFT,
                       "TREND1", "curveLegendFormat",    "CURVE" + iCurvesOnTrend, "%6.2f",
                       "TREND1", "curveColor",           "CURVE" + iCurvesOnTrend, "red");
        
    // Look for unit
    string strUnit = dpGetUnit( dp );
    if(strUnit != "")
      setValue("TREND1", "curveLegendUnit", "CURVE" + iCurvesOnTrend, strUnit);
  }
}

The function call can be put in the button Clicked event, the function only needs to have the parameter dp passed to it and will delete any existing curves on the trend and draw the received dpe;

Code: Select all

drawOnTrend("myDpExample.value");

There is alot of stuff you can remove from the code above if you don't need it, the function connectDirectly() gets the DPE data from the archive and connects to it at runtime. It is the easiest way to get dpe data on a trend using CTRL scripts.

[leoknipp]

Hello,

I had a look at the code.
Why aren't you using autoscale also when historical values are saved for the timerange of the last 7 days? There is no need to deactivate it and set the range manually.

In your case data will be read twice which could take some time if unsolicited values are read for a timerange of 7 days.

Also you have to think about the data-amount for unsolicited values for 7 days.
E.g. the value changes every 3 seconds.
For 7 days you'll get more than 200.000 values.

Reading the values and drawing them in the trend-widget will take some time. Also it is not possible to show all the values due to the limitation of the screen resolution, especially when several curves are shown in one trend-widget.
On normal screens you have a range of about 1000 pixels to show the trend curves. The other pixels in x-orientation are used for the scales, other objects at the panels, borders, .....

If you want to show values for this timerange you should use compressed values, e.g. 1-minute-values, 5-minute-values, .....

Best Regards
Leopold Knipp
Senior Support Specialist

[aorange]

Hi Leopold,

All valid points... there are some good reasons however;

Why aren't you using autoscale also when historical values are saved for the timerange of the last 7 days?

When autoscaling is used it is not possible to set a max or min range which is handy when trying to depict the water level in a reservoir which is rarely allowed to go completely empty, i.e. it is easier for the user to see that the reservoir is half full if the min range is set to zero. I suppose another way to achieve this is by setting the min and max ranges explicitly but I use $parameters extensively and some of my panels are used for literally thousands of sites.

Also the trend will not attempt to autoscale when I use the ruler to look further back in time which can be annoying.

There is no need to deactivate it and set the range manually. In your case data will be read twice which could take some time if unsolicited values are read for a timerange of 7 days.

Also you have to think about the data-amount for unsolicited values for 7 days.
E.g. the value changes every 3 seconds.
For 7 days you'll get more than 200.000 values.

We log data at 15 minute intervals and use time smoothing to ensure that we have 96 values per day.

Reading the values and drawing them in the trend-widget will take some time. Also it is not possible to show all the values due to the limitation of the screen resolution, especially when several curves are shown in one trend-widget.
On normal screens you have a range of about 1000 pixels to show the trend curves. The other pixels in x-orientation are used for the scales, other objects at the panels, borders, .....

If you want to show values for this timerange you should use compressed values, e.g. 1-minute-values, 5-minute-values, .....

Yes, it does take a little longer to connect the trend object like this but until we are able to set the min range in combination with autoscaling, it is the best way I can think of. I have used a user value range on my dpe's in the past to set the max and min ranges on the trend object at runtime but this has to be set manually on each dpe which is quite labour intensive.

[leoknipp]

Hello,

if you you know the valid range, e.g. read from the _pv_range-config, you could use these value instead of reading all historical values for the visible time-range to detect the min/max-value.

Best Regards
Leopold Knipp
Senior Support Specialist