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:
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:
Heartbeat functions read from and/or write to groups of points at regular intervals. Groups are typically created in the configuration file, where the point names, the read/write attributes of the group, and the timing interval of the heartbeat are assigned.
Writable points that are members of writable groups will defer setting the output buffer until immediately before the buffer is written to the hardware. Changes made directly to the buffer during the heartbeat interval will be overridden by the new point value.
Points which are read-only cannot be added to a writable group.
Point data is updated whenever the driver receives a request to read or write a point. The driver will generally access the device hardware to obtain the most recent data, or cause immediate output of the new value. However, a writable point that is a member of a writable group will defer writing until the heartbeat of the group.
Update commands let you force the updating of image buffers at any time by issuing a command such as updateBuffers or updateBufferGroups. This alternative provides for synchronous buffer updates, wherein the user accesses the blocks directly, setting all the output values, then performs an update of the I/O, and continues to process the refreshed inputs.
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 Cascade 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-drcfiven, 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 updateBuffers command, via the DR_ApUpdateBuffers API call (found in the Cogent API manual), or by issuing the updateBuffers 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 updateBuffers 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 updateBuffers command will not trigger update of groups associated with a card. A variation of this command, updateBufferGroups, is also used to update the groups. Note that data from writable group points updates the buffers first, then the equivalent to the updateBuffers command is executed, and finally the data for readable group points is updated.