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
  • Hi Chris,

    I understand now. You want to be able to backfill all available data from the SCADA system and send it to your Historian. By default, the Connector will try and backfill 7 days of data. The reason it is set to 7 days is the time it takes to request all trend data for that range. It might take hours if no days to get this data backfilled on a large system. Some customers expect the Connector to catchup quickly and start getting data in real-time. The mechanism it uses (TrnQuery) to get the data is not super efficient either. The request is sent per Trend Tag for a defined period of time, which the Trend Server then needs to process, read data (either from memory or disk) then respond. I don't think there will be an easy way for the existing Connector to achieve this functionality. I will discuss it with some of the developers and pass on this information to the Product Management.

    From what I have learnt through other exchanges with customers and project delivery teams, is that the bulk of the data is transferred manually using custom code or export data from the SCADA system, then imported into the Historian. The Connector is then started with the default settings (7 days backfill) to get the remaining data + real-time data. It sounds like you did everything right, it just isn't a seamless experience.

    With regards to duplicate data, I believe the Historian should be capable of handling this, but it is probably worth checking this with a WW Historian expert.

    Kind regards
    Olivier
Reply
  • Hi Chris,

    I understand now. You want to be able to backfill all available data from the SCADA system and send it to your Historian. By default, the Connector will try and backfill 7 days of data. The reason it is set to 7 days is the time it takes to request all trend data for that range. It might take hours if no days to get this data backfilled on a large system. Some customers expect the Connector to catchup quickly and start getting data in real-time. The mechanism it uses (TrnQuery) to get the data is not super efficient either. The request is sent per Trend Tag for a defined period of time, which the Trend Server then needs to process, read data (either from memory or disk) then respond. I don't think there will be an easy way for the existing Connector to achieve this functionality. I will discuss it with some of the developers and pass on this information to the Product Management.

    From what I have learnt through other exchanges with customers and project delivery teams, is that the bulk of the data is transferred manually using custom code or export data from the SCADA system, then imported into the Historian. The Connector is then started with the default settings (7 days backfill) to get the remaining data + real-time data. It sounds like you did everything right, it just isn't a seamless experience.

    With regards to duplicate data, I believe the Historian should be capable of handling this, but it is probably worth checking this with a WW Historian expert.

    Kind regards
    Olivier
Children
No Data