bufferUpdate

Parameters

Returns

OK if successful, or one of the following errors:

(error "bufferUpdate DR_ERR_CARD_INVALID (time) invalid card: card_id")

(error "bufferUpdate DR_ERR_CARD_IO_FAILURE (time) I/O failure (error_code) on device card_id")

(error "bufferUpdate -1 (time) Command invalid: Card card_id using interrupt mode")

The text string corresponding to the error message code for I/O failure can be obtained by issuing an errorDescription command, like this:

(errorDescription error_code)

Description

This command triggers an I/O cycle of the buffers. Data in the output buffers is written to the field, and field data is read into the input buffers. This command is typically sent as a command and not used in configuration file.

The process of updating the buffers proceeds in several phases. First the driver/administrator gains access to the card buffer. If the I/O exchange mode of the card is 'synchronous', this may interrupt the fieldbus communication. The command then reads in the card input buffer data, containing the last data received via the fieldbus, into the corresponding input buffer. Next, the data in the output buffer is written to the corresponding card output buffer. Finally, the access to the card buffers is released, at which time the updated output data begins to make its way onto the fieldbus, and new input data arrives at the card.

This approach favours freshness of the output data, since it will have an immediate effect on the output, while the input data is said to be 'stale' since it will be the result of the last exchange. This effect is really only a factor in the 'buffered' I/O exchange modes of the card, where the card buffers must be explicitly updated with the fieldbus data, and hence the input data will be that of the last exchange.

The issue of stale input data is rarely an issue at all. If the card is interrupt driven, periodically polled (see the cardPoll command), or bufferUpdate is called periodically, then there will be a single input-output exchange per cycle. Either the read is stale or the write is delayed by the cycle period. If performance is an issue, then the cycle period should be set appropriately to produce the desired sampling period.

However, if the card is polled infrequently, then there is a real need to ensure that the read is fresh. This is addressed through the optional update parameter, which if set to t, will cause an additional read cycle to be performed first to ensure that the card buffers have the latest data from the fieldbus.

If bufferUpdate is called frequently (approaching the fieldbus cycle rate) with the update parameter set, there will be an impact on performance since twice as many exchanges as required will be made.