EPICURE Design Note 41.2<P> <b> Protocol for Data Acquisition for Fast Time Plots</b>

EPICURE Design Note 41.2

Protocol for Data Acquisition for Fast Time Plots

Kal Dabous, David M. Kline, Brian J. Kramper, Therese M. Watts

.5cm This document itemizes the parameters which we intend to support with the new Epicure Fast Time Plot (FTP) facility, and proposes a protocol for acquiring the information necessary to satisfy them.

Planning Parameters

FTP Data Collection

The present data acquisition subroutines da_add_request_name and da_add_request_di specify a single FTD which is the frequency of data collection. In order to accommodate FTP requests, similar subroutines would need to be implemented which would have the same arguments as the two previously mentioned subroutines, plus two additional arguments in the form of FTDs, specifying the start and stop times for the fast data acquisition. The maximum data collection rate obtained from the database must be non-zero (device is able to be fast time plotted) and the frequency of data collection specified by the user must be less than or equal to the maximum rate specified in the database for the particular device. The Data Acquisition Requestor (DAR) is the logical place to check that the data collection frequency is valid. Initially there would be no minimum data collection frequency. The function da_get_data will still be used, however the data returned is an array of data. The data size is calculated by the total points and the size specified in the database. See figure 1 for a pictorial representation.

To achieve the data acquisition rates required by the FTP facility, it is necessary to combine multiple data points in a single data reply at the DAE level. Since DAEs know nothing about time, a translation from frequency to number of buffered data points must be done. Although this translation could take place at the DAE or TIMER level, it is easily calculated by DAR when it verifies the frequency requested by the user. Because the update rate for the user task will be approximately 2 Hz, the number of data points returned in a buffer per device is the data collection frequency divided by 2, e.g., a collection frequency of 30 Hz yields 15 data points per device per data return buffer.

The actual data acquisition will be accomplished using three data buffers and a control buffer, created by the Data Acquisition Server (DAS). New type codes will need to be implemented to differentiate this type of data acquisition from other slower types, both at the DAR-to-DAS and DAS-to-DAE interface levels. A few definitions are necessary here to clarify the rest of the discussion.

When DAS receives an FTP list from DAR, it will create a prototype data buffer in its memory with the following initial conditions: cycle and available bit set, first time and suspend bit clear, total points set to number indicated by DAR, last point cleared, and the control handle cleared (see Figure 1). DAS will then create a prototype control buffer in its memory with the following initial conditions: cycle, first time, suspended, and available bit clear, max and total buffers set to three (3), last buffer cleared, and the data buffer table index is set to zero (0). DAS now makes three sets of calls to QVI_US_PUT (creating three data buffers in common memory) and places the returned block handle into the appropriate control buffer data buffer handle fields.

A final call is made to QVI_US_PUT to create a control buffer in common memory and the returned handle is saved.

The three data buffers are first directed to the TIMER (see flow chart in Figure 3). These data buffers are not processed until the control buffer which coordinates them is received by the TIMER. When the TIMER receives the control buffer (which contains handles to each of the three data buffers), the control buffer is placed in each of the data buffers. The TIMER then takes the first buffer, clears the available bit and either sends the buffer immediately to the DAE (if the current time lies between the start and stop times for the list) or delays it until the next occurrence of the start time. The data buffer now goes back and forth between the TIMER and the DAE until the number of points gathered matches the number of points to be buffered per data return. This full buffer is then inserted on the DAS return queue, and the next buffer on the control list is used. This process continues until the current time lies between the stop time and the start time, or the request is deleted. A data buffer becomes available again as soon as DAS has copied the contents of the buffer into its memory using QVI_US_GET. Although it is not anticipated that more than three buffers should be needed, it is possible that this process could get suspended for a period of time, but should resume as soon as a buffer is available. If under operating conditions it appears that more than three data buffers are required, the scheme is easily extended by having DAS allocate more buffers and storing their pointers in the control buffer.

Modifications, Additions and Suggestions

A new request code, DAR_C_FAST_READ, would need to be implemented for the DAR-to-DAS interface, and the request list would need to incorporate the FTDs for the start and stop time of the fast data acquisition.

More radical modifications would need to be made to the present definition of the user portion of the UMB. Two new type codes would need to be implemented, UMB_C_FTP_CTL for the control buffers and UMB_C_FTP_DAT for the data buffers. The start and stop FTDs and the control buffer handle would need to be added. In addition the data buffers would need short integers for the number of points to be collected for the buffer and the last point collected. The control buffer really has no need for the frequency DAP (presently DAP0), and an alternate structure consisting of an array of pointers to the three data buffers could be substituted.

Security, Privacy, Legal