2.2. Dataflow and Synchronization

This section outlines the facilities for controlling the refresh of field data. Input data from the field devices is read into the image buffers via the hardware interface device, which may itself contain an image buffer. Output data flows via the reverse path. Typically, the output data containing the results of a calculation cycle is refreshed first, followed by the refresh of input data to be processed. This process is summarized in the figure below:

Driver Block Data Flow

Figure 2.2. Driver Block Data Flow

The driver performs the exchange of data to the hardware device, ensuring synchronization with any protocol-dependent update cycles inherent in the flow of data to/from the field devices.

Several mechanisms are available to trigger the data transfer:

The three phases of data exchange are as follows, and each is explained in detail further below.

    Transfer of data between the fieldbus and the CIF card hardware buffers (called the process image buffers).

    Transfer of data between the CIF card hardware buffers and the driver's buffers.

    Transfer of data between the driver buffers and the points (if used).

2.2.1. Data Transfer between Fieldbus and Card

Once a CIF card is configured according to the particular set of field devices, it can start up and initiate a continuous communication cycle over the fieldbus that maintains an image of the field data in the card buffers, essentially independently of the host computer (and driver software). The driver periodically interfaces to the card to exchange data between the driver's buffers and the card's buffers. This exchange can have the following characteristics:

    Buffered mode. In this mode, a second set of buffers are provided for the host (driver) to access, while the exchange of data with the fieldbus continues in the main buffers. This effectively decouples the fieldbus and host cycles, since host access has minimal impact on the fieldbus transfer. Each access by the host will then trigger the synchronization of the two buffers upon completion of the fieldbus cycle. If the data exchange is not buffered (direct data transfer mode), then the driver and fieldbus are locked together, forcing one host access for each fieldbus cycle, or vice versa depending on the synchronization mode.

    Host-controlled or device-controlled synchronization. In a host-controlled mode, the host acts as the master, initiating the access, and triggering the subsequent exchange with the buffer or fieldbus. In a device-controlled mode, the fieldbus cycle initiates itself and informs the slave host that data is available.

    None of the above. An additional mode exists without buffering or synchronization. Integrity of multi-byte values is not guaranteed.

Not all modes of data exchange are available for all fieldbus protocols. The buffered, host-controlled data exchange mode is recommended for most applications.

2.2.2. Data Transfer between Card and Driver

As stated above, the CIF Driver periodically exchanges data between its buffers (used by the application program) and the card's buffers. This can occur in either of two modes:

    Interrupt driven, where the exchange is triggered by an interrupt from the card indicating that new data is available.

    Polled mode, where the driver determines the rate at which data exchanges are attempted, and polls the card repeatedly until access is granted.

To configure a driver to use the interrupt mode, the card must be configured to generate interrupts, and the correct parameter must be used in the cardInit command. ISA cards require correct jumper settings, while PCI cards will autodetect the correct interrupt.

To configure a driver to use polling mode, the cardInit command must be setup correctly (even if the card is set up to generate interrupts), and it is necessary to generate the periodic polling trigger. This can be done two ways:

    Through the explicit use of the bufferUpdate command, via the DR_ApUpdateBuffers API call (found in the Cogent C API manual), or by issuing the bufferUpdate command of the ASCII interface.

    By creating an automatic periodic polling mechanism within the driver, through the cardPoll command.

2.2.3. Data Transfer between Card and Points

Use of either the cardPoll or bufferUpdate commands is sufficient for the user application to interface to the fieldbus using the block data model. If the point data model is used, then an additional step is required to transfer the data between the points and the buffers.

The group command is used to collect together groups of individual analog and digital points that must be updated together because they are all located in the same buffer. The group command provides for automatic periodic update by specifying a non-zero cycle time. At each cycle, all the points in the group will write or read updated data to or from the driver buffer(s). Note that the data transfer goes no further than the buffer, and one of the mechanisms described above is required to transfer data to the card. Note also that the CIF driver does not allow a cycle time to be defined for digital or analog points (must be 0).

As the period of the group refresh approaches that of the card data exchange, the interaction of the two unsynchronized cycles may create some undesirable effects. The cardGroup command is used to associate a group directly with the refresh of the buffers. The group cycle time must be set to 0 and the group point listed as a parameter to the cardGroup command. Both polled- and interrupt-drcfiven exchanges between the card and driver buffers will trigger the refresh of all the groups of points associated with the card.

The use of an independently updating group is most appropriate for points that have a relatively low refresh rate. For example, closed loop process control of a system may require a constant analog sample period in the range of 100 ms, in contrast to a fast response to digital events (as fast as the fieldbus will support, perhaps as little as 1 or 2 ms).

Use of the bufferUpdate command will not trigger update of groups associated with a card. A variation of this command, bufferUpdateGroups, is also used to update the groups. Note that data from writable group points updates the buffers first, then the equivalent to the bufferUpdate command is executed, and finally the data for readable group points is updated.