Cascade Driver for Hilscher Fieldbus CIF Cards: Version 4.1
Prev |  | Next

# updateBuffers

updateBuffers -- triggers an I/O cycle of the buffers.

## Synopsis

    (updateBuffers [card_id [update]])

## Parameters

`card_id`

  An optional card ID (`0..3`). If not specified, the command is applied to all available cards.

`update`

  (optional) If `t`, field device data is read before the buffer update, guaranteeing that input data will be fresh when the command returns. Otherwise, input data may be stale. See the Description (below) for details.

## Returns

`OK` if successful, or one of the following errors:

        (error "updateBuffers DR_ERR_DEV_INVALID (time) invalid device: card_id")

        (error "updateBuffers DR_ERR_DEV_IO_FAILURE (time) I/O failure (error_code) on device card_id")

        (error "updateBuffers -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:

        (cifErrorDescription 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 updateBuffers 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 updateBuffers 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.

Prev | Home | Next
typeDesc | Up | updateBufferGroups

Copyright 1995-2002 by Cogent Real-Time Systems, Inc.