Digital Trends and Trend Storage on Data Change

Hello,

We trend a lot of Digital tags, set to 2-byte storage method, but it would be so much better to storage them at a single bit. Also, we use the Wonderware Historian with the connector utility, all of our tags are configured as Analog with the 8-byte Trends stored as doubles and the 2-byte Trends stored as Integers. We have to set the engineering units to T/F and the range 0,1 to help sort them.

We run very fast trending, 100-250ms and it uses a lot of storage, we typically save about 13 months of data per site and I thought it might be possible to use the trigger in the Trend tag configuration to only store when the Variable tag data has changed. Has anybody done this? If so, what was your methods, workarounds and pitfall?

Thanks,

Chris

Parents
  • Oliver,

    We are using V2.1 of the connector and currently the 2-byte tags are stored in the Historian as 32bit INT same data size as a float. There doesn't seem to be any clear documentation on what would happen if we upgraded the connector to V3.0, hence the reason we stuck with V2.1. By the way, we have had nothing but trouble at first with the connector and found that we needed to move the Citect API .dll files from the Citect installation to the connector's bin directory, solve all of our issues.

    Back to the trends, my colleague just pointed out that there is a deadband parameter that can be set when configuring a trend tag. We have not used this and wonder if this would work. The docs state that...

    "A deadband allows the value of a variable tag to fluctuate within a defined threshold without updates being sent through to the trend tag. This may be useful if a tag produces many small, insignificant value changes. The threshold is represented as a percentage of the tag's engineering range. The default value is 0 (zero), which captures every value change."

    I assume that the "percentage of the tag's engineering range" is the variable tag not the trend tag, and that it might do what we need, even setting the trend type to "TRN_PERIODIC".

    Any experience with using the deadband on trend tags?

    Thanks,

    Chris
Reply
  • Oliver,

    We are using V2.1 of the connector and currently the 2-byte tags are stored in the Historian as 32bit INT same data size as a float. There doesn't seem to be any clear documentation on what would happen if we upgraded the connector to V3.0, hence the reason we stuck with V2.1. By the way, we have had nothing but trouble at first with the connector and found that we needed to move the Citect API .dll files from the Citect installation to the connector's bin directory, solve all of our issues.

    Back to the trends, my colleague just pointed out that there is a deadband parameter that can be set when configuring a trend tag. We have not used this and wonder if this would work. The docs state that...

    "A deadband allows the value of a variable tag to fluctuate within a defined threshold without updates being sent through to the trend tag. This may be useful if a tag produces many small, insignificant value changes. The threshold is represented as a percentage of the tag's engineering range. The default value is 0 (zero), which captures every value change."

    I assume that the "percentage of the tag's engineering range" is the variable tag not the trend tag, and that it might do what we need, even setting the trend type to "TRN_PERIODIC".

    Any experience with using the deadband on trend tags?

    Thanks,

    Chris
Children
No Data