Table of Contents
The Cascade Driver architecture is shown in the figure below. The device driver interfaces to the specific hardware (typically a network interface card) and offers a choice of user interfaces:
The most common and powerful interface is the ASCII command interface. By sending ASCII commands, the entire command set of the driver is available. The driver interprets the command and returns an ASCII message with the requested response data (if any). This command set is available from a user application, interactive interface, or through a configuration file. In addition to commands, point data is also sent in ASCII format.
While the command interface provides the maximum flexibility and ease of use, better performance can be achieved by transferring blocks of data, using the binary interface. The binary interface uses a message header that identifies the command code to be executed. Data to be transferred is packaged directly (in binary format) with the message packet.
Another class of interface is designed to provide an optimal interface to the Cascade DataHub. Field points which have been configured as such will initiate an unsolicited transfer of data to the datahub when the point changes value. This capability allows the driver, in combination with the datahub, to immediately provide the underlying mechanism for event driven applications.
Data from the device is modeled in two ways: as named points, and as blocks. Named points model the individual field devices, such as switches, indicators, etc, and allow the user to interact with them using only their names, completely independently of the hardware configuration. Blocks model the physical reality, in that the data from field devices is actually accessed in blocks, and is therefore generally a more 'raw' or direct representation of the data. However, to access specific field devices requires knowledge of the address, type, and format.
The philosophy adopted by the Cascade Driver is that the configuration information should originate from only one place: the driver's configuration file. The driver makes all of this information available, so that a user's application can 'discover' the system configuration and make use of it as required.
Named points allow the user to interface with the device on a named-point basis. The user does not need to be concerned with the details of how the data is read or written. The relationship between a point and its physical attributes is configured through an appropriate command (via the ASCII command interface), typically from the configuration file.
The driver models point addresses as follows:
|-e0||Swaps the number of bytes determined by the width of the data. This is determined by the sum of the bit_offset and the bit_length.|
|-eN||Where N specifies 1, 2, 3, or 4 bytes, or 8, 16, 24, or 32 bits.|
The group command must specify an address of 0, since there is no address information associated with the group.
All point data has a type. The user needs to know a point's type in order to pass the correct type of data variable. The following types are currently supported:
A point may have a real type (double) even though it is based on a physical field type that is fixed-point (such as a 12 or 16 bit analog I/O point) if the point is given an engineering unit conversion as part of its configuration.
In addition to reading or writing a point, the list of available points and the configuration data for a point can be obtained at any time, if necessary, by the user through the appropriate commands.
The following provides some examples of valid point addresses:
|Access the third 16-bit word as an analog from the input buffer of card 0 (provided point is NOT defined as writeable)|
|Access the third 16-bit word as an analog value from the output buffer of card 0 (whether or not point is defined as writeable)||0:0:2|
|Access the upper 12 bits of the third 16-bit word as an analog value from the output buffer of card 0||0:0:2.4.12|
|Access the lowest order bit (a digital) in the third 16-bit word from the output buffer of card 0|
|Access the upper byte of the third 16-bit word (as a digital or analog value) from the output buffer of card 0.||0:0:2.9.8|
|Treat the buffer data as 32-bit words. Access the upper byte in the second 32-bit word from the output buffer of card 0.||0:0:2.25.8|
|Treat the buffer data as 32-bit words. Access a 24-bit signed analog value in the low order three bytes of the second 32-bit word from the output buffer of card 0.||0:0:2.0.24;-s|
|Treat the buffer data as 32-bit words, organized in Motorola format (high byte first). Access the 24-bit signed analog value in the lower 24 bits (upper 3 bytes) of the second 32-bit word from the output buffer of card 0.||0:2.0.24;-e32,-s|
Most fieldbus protocols 'pack' the input or output data from a slave device, independently of the actual physical arrangement of the I/O. For example, an I/O rack with a selection of single, dual and quad digital input and/or output modules, will typically simply pack together the bits into separate input and output groups. Modules with both inputs and outputs are not even guaranteed that a particular I/O point will be mapped to the same bit position. In some cases analog I/O will be mapped to the beginning of the buffers, followed by digital.
The point to remember is that there is a mapping from the physical device installation to the buffer address. This mapping is dependent on the protocol and manufacturer of the equipment, and you must determine this mapping for your particular installation. Neither the CIF card nor the CIF Driver is involved in this mapping.
Blocks allow a user to acquire or modify entire sets of input or output values with a single data transfer to the driver. The user is responsible for determining where the data of interest lies within the block.
The driver models block addresses as follows:
card : buffer
Access to buffer blocks typically requires offset and size parameters, permitting sub-blocks within the buffer to be read or written. The user can inquire from the driver how many buffers are available (numbered consecutively from 0), and of what size.
When blocks of data are read from or written to the hardware device, only the 'active' portions of the buffers are transferred. The 'active' portion of a buffer always starts at zero, and grows as points are defined to form a contiguous block that includes the highest point address, up to the maximum buffer size.
If block transfers only are being used, the length (upper address) of the 'active' portion of the buffer must be set with the bufferActiveLength command.
In some cases, it is important to know what type of point data is contained within a buffer. Buffers will often contain sub-blocks of data of differing types, and the user may actually only require, for example, the analog input sub-block. Or the user may require access to all analog input sub-blocks, which may be spread over multiple buffers. These sub-blocks are termed segments. In keeping with the philosophy of the driver as the single source of configuration information, a buffer may have its segment attributes configured and queried by the user's application.
Segment attributes provide a mechanism for documenting and disseminating information about the type of data contained by a data buffer, as defined in the driver. Each buffer may have any number of segment attribute descriptions, where each defines the attributes of a block of data within the buffer. A buffer can have any number of such attributed segments, of any size, and possibly overlapping. A segment attribute description contains the following:
The API defines a set of functions which provide an easy-to-use interface to the driver ASCII commands and the binary block transfer mechanism.
Copyright © 1995-2006 by Cogent Real-Time Systems, Inc. All rights reserved.