We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.
To start, select the product of your interest in the left column. Then take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas will first be moderated before they are made visible to other users of this portal.
This page is for feedback for specific AVEVA solutions, excluding PI Systems and Data Hub. For links to these other feedback portals, please see the tab RESOURCES below.
With regards to the second problem, "Collectxfer does not keep up, RealTime collect buffer overflows", can you provide some numbers around the throughput of historical data? Like, number of points on collect, and their breakdown from sample to exception, or even better, the number of collectxfr records/min that causes the buffer to overflow. Also would help to know some details on the hardware used.
For problem #1, confirming that the existing baseline method for configuring Field Device Trend History is not sufficient. This would require that all trend history always come directly from the field, and cannot support some data also coming from collect. Bear in mind that enhancements to collect are coming such that a point's entire meta-state will be historised with every row. This includes multiple DQ flags and other state information (i.e. test-mode, etc)
From the Doc: Realtime Admin Vol 2 -> Additional Protocol Functionality -> Field Device Trend History
Field Device Trend History
When Historical point data is stored in a Remote Terminal Unit (RTU) data logger, this application enables you to configure the system such that it sends the data to the Historical database.
When analog collect records are configured with the collect type "device based history", Omnicomm sends the Historical data collected from the RTU to a spooler, which in turn calls a stored procedure in the Historical database that adds data to the TimeSeries database. This provides Controllers with immediate access to the data for the purposes of trending. The flow of data is illustrated below.
Configuring the Host to send Device-based History directly to Historical Collect
Follow this procedure when Historical point data is stored in a Remote Terminal Unit (RTU) data logger and sent to the AVEVA Enterprise SCADA host, as opposed to collected on the AVEVA Enterprise SCADA host.