Collecting Remotely Logged Data

Whilst the use of the Data Acquisition (local) component can provide a very useful multi-measurement data logging facility, together with all the curve plotting and tabular display facilities being available, it is necessary for the local PC to be switched on together with ensuring that Visual VIGO is always running. In other words, if the PC loses power or the Visual VIGO application is closed, any recording of further changes in measurement data will be suspended, although all collected historical data will be retained. In addition, local data acquisition relies entirely on the choice of the Sample time, and powerful conditional processing is not possible. On the other hand, by using the Remote Data Acquisition component to communicate with a DataCollect Channel located within a DPI programmable controller elsewhere on the network, provides a powerful DAQ facility that is independent of a local PC.

DataCollect Channel

In keeping with the Object oriented structure of a P-NET fieldbus system, a DataCollect Channel provides the ability to independently configure the means of logging unrelated measurement variables, with the additional benefits of conditional data processing and the storage of logged data, without the permanent requirement for a PC to be operational. The final destination of all data collected by the DataCollect Channel is still a PC hard disc, which is structured and stored in exactly the same way as with the use of the Data Acquisition (local) component. This is because the same PROCES-DATA Databuffer Engine (PDDE), is used to obtain, store and manage the data collected by the DataCollect Channel. This means that the same Chart, Curve and Database Grid components are used to present the PC databuffer to the user.

Sampling and Communication

Unlike local data collection, it is now the DataCollect Channel that determines how and when samples are taken for intermediate storage in a DPI controller. Furthermore, due to the data processing capabilities within such pre-programmed devices, provides the capability to test various conditions before a new log is taken. Such a facility ensures that the minimum number of data logs are taken and stored, without losing the overall trend over time of a varying measurement. The DataCollect Channel functionality is configured from within the Remote Data Acquisition Component or by using the Data Collect Configuration Program. In a similar way to the Data Acquisition (local) configuration, the PhysID of the logged variable is defined (Variable Link), together with a definition of how long the data is to be stored in the PC (Data Expired Interval). However, with this arrangement, the Update Time is NOT equivalent to the Sampling Time. Update Interval now ensures that a regular request is made to the DataCollect Channel in order to synchronise the remotely held databuffer with the PC databuffer for this variable. This means it is possible to reduce the number of requests (transmissions) on P-NET without losing any of the logged data stored within the Data Collection Controller.

Data synchronisation

An innovative and dynamic technique is used to ensure that the PC databuffer is kept synchronised with the Data Collection Controller, without putting an excessive load on the network. The first situation occurs when a display component e.g. a Curve, is not in focus (cannot be seen on the screen). Here every Update Time stimulates up to 50 blocks of records to be transferred from the Controller channel to the PC databuffer. When the two databuffers eventually hold the same data (synchronised), only new samples are transferred at Update Time. The second situation occurs when the display becomes in focus (a curve becomes visible on the screen). In this case, it is very important to plot and update the display as soon as possible. Therefore, if it is found that the PC databuffer is not fully updated, then the synchronisation mechanism ignores the configured Update time and transfers blocks as fast as the network will allow. Such a situation might occur when a PC has been off-line for a significant period of time (e.g. overnight, a week-end), and where historical data up to the present time is required to be seen as soon as possible. The above-described mechanism applies to ensuring that, depending on the circumstances, logged data is always made available from each Data Collection channel in the most efficient way. This process is extended to also ensuring that no unnecessary requests are made when there is no new data to be transferred. This could occur if an Update Time is set to be more frequent than a channel’s Sample Time. In this case, if it is detected that there is no new data, the Update Time is slowed to be that of Sample Time. Whilst there is a flexible relationship between Update Time and Sample Time, it should be understood that the Update Time interval should never be set to exceed 50 times that of Sample Time, otherwise there could be an eventual situation where some logged data will never get to be transferred.

Conditions

Unlike the local data acquisition, the Remote Data Acquisition configuration enables a number of conditions to be tested within a channel before a log entry is confirmed.

Threshold

The first level of selectable conditional processing applies to configuring a specific Threshold level or range criterion, within which a particular measurement must fall for a sampled value to be logged. There are two variable values that can be tested. The first is the actual measurement value for logging and the other is a secondary measurement associated with the first. If the measurement at Sample Time falls outside the Threshold set for logging the measurement value OR outside the Threshold set for a related secondary variable, then the latest (current) sampled value is logged and a flag is raised. Samples continue to be taken but are ignored until a value is detected that falls inside the threshold criterion again. Since contiguously ascending IDNos means that when plotted, a line can be drawn between each point, a jump is induced in the sequence of IDNos to indicate that one or more sample values have been ignored and that no line can be implied to join them. The effect is that periods outside threshold criteria will not be shown on any plotted curves if displayed as a line. The use of such a facility can radically reduce the amount of irrelevant logged data, perhaps during periods of down time, or where a measurement is regarded as inactive.

Deviation Tolerance

An additional or alternative condition that can be tested, is used to determine the positive and negative limit within which the current Sample value, the previous sample value and the last logged value can all be regarded as falling on a continuous straight line. The function has two uses. The first applies when a sampled value has not changed by any significance to warrant a new log at every sample. Such a change might be caused by measurement noise or other small variation that is of no particular interest. If such small changes can be ignored by defining a deviation tolerance, then

many intermediate log points can be reduced, and the two points between this considered steady state could be joined by an optimised straight line. The second situation applies when a signal is changing at a certain rate. Again, if within a defined deviation tolerance, three points can be optimised to have the same rate of change (slope), then the intermediate point can be ignored. There are two methods for optimising the way a straight line is logged and plotted. These are set using the mode property.

Mode

Standard

This mode allows Threshold conditions to be tested if required, but no line optimisation is applied.

This means that all legitimate samples are logged.

Measured Optimisation

This mode allows a Deviation Tolerance to be defined in addition to setting a Threshold, and which can be used to further reduce the number of databuffer log entries to a level that still provides a true representation of the historical trend of a measurement. This method ensures that any logged value is derived from an actual measurement value at sample time. Such an option is used where it is important that all databuffer log entry points only relate to true measurement values. Any value derived from the line between points is guaranteed to be within the Deviation Tolerance, but will result in either a wholly positive or wholly negative deviation throughout its length.

Calculated Optimisation

This mode also enables a Deviation Tolerance to be defined to reduce databuffer log entries, but uses a calculation algorithm to ensure that any line drawn between derived log entry values more accurately follows (fits) the path of a curve at any particular point. This means that the start and end (logged) values of the line are adjusted (calculated) so that the resultant line crosses the curve at some point. This ensures that any positive deviations along one part of the line are averaged out by negative deviations on the other.

Heartbeat

The Heartbeat facility can be used when either the Measured or Calculated optimisation mode is selected. In situations where perhaps long periods may occur where no actual log entries are being recorded, a log entry can be periodically forced to ensure that not every non-deviating measurement is ignored.