| |
|
|
|
2 OVERVIEW
This manual covers the device-specific part for the Heidenhain IK320 Encoder I/F. For a general overview about drivers and devices, refer to the Driver Development Guide [8].
2.1 The Hardware
The Heidenhain IK320 Encoder I/F provides two counter-channels which are connected to external encoder-heads. The board provides the counter values and performs interpolation of encoder signals to calculate high-precision 48-bit position values. The two channels can additionally be calibrated by use of a board-internal correction value table, which further improves the accuracy. Optionally the two channels can be combined to yield the sum, difference or mean value of the two, in addition to each single value.
The board occupies address-space for its Dual-Port RAM in the VMEbus A24 standard space, and some ports in the A16 short I/O space.
See the hardware manual [3] for details.
2.2 The Driver
This driver implements the functionality of the Heidenhain IK320 Encoder I/F, that is it gives the same functionality as the board and does not combine elementary functions to more complex functions. This is left by purpose to the software using the driver in order to achieve the maximum flexibility.
The driver concept of VxWorks is described in [4].
2.3 The Devices
The whole board is regarded as one device. As recommended in [8], the device-names are derived from the module-name "ikon", i.e. the devices must be named "/ikon0", "/ikon1", etc.
The driver can control several devices simultaneously, where each device consists of the same type of hardware, using the same code but with different sets of data for each device. The set of data defining the device and containing the status of the device is called device descriptor table.
2.4 Device Access
The driver conforms to the LCU software specification [2], particularly in the following respects:
· The driver conforms to the VxWorks driver concept, that is it supports the functions open, close, and ioctl. It also provides the recommended installation functions. See section 3.
· The driver controls the access of the device, provided by the open/close calls giving the possibilities:
· There is a possibility to force the release of a channel opened in EXCLUSIVE mode (Free Device command)
· The driver calls are mutually exclusive, that is the device accessed by a task is protected from access from any other authorized task until the executing driver call has terminated. They will be blocked and put on a queue. There is one queue for each device and the processes on the queue will be scheduled according to their priority. The implementation of the driver uses the VxWorks mutex semaphore for this functionality and to provide priority inheritance, see reference [4].
· A task blocked for access of a device will have a timeout. An error will be returned upon exceeding the timeout.
Ioctl commands directly accessing a register do not have any protection from simultaneous access as the command is executed by an immediate action, that is in one non-interruptable instruction. In this case there is no need for any protection as no other process can interfere during the action.
2.5 Interrupts
The Heidenhain IK320 Encoder I/F occupies one interrupt-vector and can be assigned to one out of seven interrupt-levels. For hardware reasons, the interrupt-vector cannot be freely chosen, but depends on the setting of the short-I/O (A16) base-address.
All types of interrupts are served within the driver, i.e. the board-interrupts are hidden to the user of the driver. The following types of interrupts can occur:
· in response to a local interrupt generated by the master on the board, upon completion of a requested operation (specified in parameter P81).
· in response to a local interrupt generated by an external signal, upon completion of a requested operation (specified in parameter P80.1, P80.2).
· in response to a direct latch operation, either by software request, or by external hardware triggering.
· in case of anomalous conditions indicating that the latched position value is questionable, e.g. when a mismatch between incremental track and reference marks is detected. Those anomalies will be reported to the user with the next position readout by an error code.
· Fatal errors of the internal firmware. The device will be marked as `unavailable' by the driver in such a case. It can only be recovered by HW reset.
2.6 Special Features
The simultaneous direct latching of multiple IK 320 boards in the same group is possible, see Group Position Sampling ("Einspeichern VMEbus direkt innerhalb einer Gruppe", [3] p 33). The same operation in different groups - Multiple Group Position Sampling ("Einspeichern VMEbus direkt über mehrere Gruppen", [3] p 34) - must be accomplished by external hardware, but uses the same driver commands. 1
The interrupt-driven handling of external functions, i.e. External Function Execution (e.g. "Einspeichern extern indirekt", [3] p 32), connected to parameter P80 ([3] p 33), and External Position Sampling ("Einspeichern extern direkt", [3] p 33) is in principle supported, provided the higher-level software takes care of the side-effects. 2
2.7 Include files
Applications using the ikon must include ikon.h. The ikon.h include file includes everything required to use the procedures described in the previous section.
· "ikonCommands.h" which defines literals of the ikon Driver commands and the data structures for multiple argument commands as used with the ioctl procedure.
3 DRIVER FUNCTIONS
3.1 Introduction
This chapter provides a detailed description of the ikon Driver module interface to the user, namely functions, commands, include files and tools.
The functions are described in UNIX man-page format and are organized in a functional order. Below is an index of the routines in the same order.
Each of these calls returns a status code which signals the success of the call. A zero value always means "successful completion" while a negative value indicates an error. The value -1 stands for "general error" and origins in VxWorks while other values signal a specific error reason and are returned by the driver itself. Literals of all error codes can be found in the include file ikonErrors.h and in [8].
3.2 Driver and Device Installation Functions
The installation of the IK320 driver is according to the VxWorks driver concept described in [4] and [5]. Two functions are provided:
Except for the device-name and the value for P30.1, all these values are not programmable, but are inherent resp. must be chosen corresponding to the jumper settings made on the board.
The driver performs the following steps at device installation during ikonDevCreate and reports any error or exceptional situation to the caller:
· validate the given device-name. Exit with lcudrvERROR_INVALID_DEVICE if it fails, e.g. if it already exists.
· verify if the base-addresses are correct and something (i.e. not necessarily the correct board) is present at that address, and exit with lcudrvERROR_INVALID_ARGUMENT if not. 5
· check that the interrupt-vector is correctly specified with respect to the A16 base-address (both are dependent on each other), exit with lcudrvERROR_INVALID_ARGUMENT if not.
· issue a "Power On Self Test" (POST) command to the board. The board will then test its internal HW, write default values into the DPRAM parameter area, and determine CRC/check-sums and the versions of hardware and firmware.
n.b.: the duration of POST is specified in [3] with ~5 seconds.
· verify the result of the POST and exit with an error if it failed. Possible CRC errors in the correction-values or invalid parameter values are ignored here.
· if requested so, verify the HW and SW versions of the board, and if they are different from the values given to the function exit with lcudrvERROR_INVALID_ARGUMENT.
· if requested so, the parameters and correction tables are downloaded from the given core-file. Depending on which exact operation failed, this can yield several error-codes.
After an OK return, the device is therefore tested in its main functions, and prepared to detect the reference-point automatically when it is reached. See the man-pages in the Reference chapter 9 for detailed information.
3.3 Tool Functions
The following tool functions are provided (they are covered in more detail in chapter 7):
· ikonDevShow [<device>] to print a list of all installed IK320 devices with their respective installation parameters to the LCU console. More detailed information can be displayed when a specific <device> is given as parameter.
· ikonDataShow <device> to print the contents of the DPRAM data area of a specific device to the LCU console
· ikonParamShow <device> to print the contents of the DPRAM parameter area of a specific device to the LCU console
· ikonPosShow <device> to issue a command to the board in order to query the encoder values and print the resulting position values with their counter status to the LCU console
See chapter 7 and the man-pages in the Reference chapter 9 for detailed information.
The symbolic names used in ikonDataShow for the data values are:
positionX1, positionX2, positionCombi, intrStatus, crcEprom, checksumEprom1, checksumEprom2, versionHW, versionSW, systemStatus1, systemStatus2, presetX1, presetX2, presetCombi, analogSinX1, analogCosX1, analogSinX2, analogCosX2
The symbolic names used in ikonParamShow for the parameters are (some may be postfixed with X1, X2, or Combi):
P01: direction, P02: axisType, P03: validBits, P04: refDistance, P05: sigPeriods,
P06: corrEnable, P07: corrRange, P08: corrCount, P09: corrWidth, P10: latchDisable,
P19: refOffset, P21: combiMode, P30: corrParam6, P70: extPreset, P71: vmePreset,
P72: axisOffset, P80: extFunction, P81: vmeFunction
Refer to the hardware manual [3] for a description of data area and parameters and their possible values.
3.4 Support Functions
While all tool functions are mainly foreseen for interactive use from the VxWorks shell, the following routines to load and save parameters and correction tables make also sense for programmatic use:
· ikonCoreSave <device> [,<file>] to write the complete parameter set and both correction value table of a device to a file, respectively stdout when <file> is omitted.
· ikonCoreSaveX1/X2 <device> [,<file>] to write the correction value table of a device and channel X1/X2 to a file respectively stdout.
· ikonCoreLoad <device> [,<file>] to read the parameters and correction value tables of a device from a file, respectively stdin when <file> is omitted. The format must be the same as produced by ikonCoreSave.
These routines work on top of the basic ioctl commands described in section 4. Therefore they do not implement any new functionality, but make common operation much easier. No additional access rights verification are performed further to those of the ioctl calls. It is up to the user to make sure that only one task is reading or writing data at a time. Furthermore, it is obvious that these calls should not be used during normal operation of the encoder board, but only when it is idle, e.g. during system start-up.
See the man-pages in the Reference chapter 9 for detailed information, particularly for the required format of the files. Section 8.5 gives an example core-file.
3.5 Device Access Functions
The standard VxWorks functions as described in [4] and [5] are used to request and release access to an IK320 device. Driver-specific functions are connected to these calls upon driver installation:
4. read and write - as well as other standard VxWorks driver functions - are not necessary and not supported.
These functions are described in the following sections with respect to their special meaning in the ikon context.
See also the man-pages of the internally used device-specific routines in the Reference chapter 9 for detailed information, especially for an exact errors reference. For more general information see the "VxWorks Programmers Guide" [4].
3.5.1 open
This operation opens the device corresponding to deviceName in read-only mode or in one of the read/write modes described below. The read access is granted in all open modes. The argument status receives the completion status of the routine.
Shareable read and write mode. Write access is granted to a defined number of tasks to use this open mode. Exceeding this number or requesting this mode for a device already opened in Exclusive mode returns an error.
Exclusive read write mode. Write access is granted to the task using this open mode. Requesting this mode for a device already opened in Exclusive or Shared mode returns an error.
Test read and write open mode. Write access is granted to the task using this option mode regardless of the status of the device. Requesting this mode for a device already opened in Test mode returns an error.
* status is a pointer to the error-code to be returned. If it is NULL, then nothing is returned. Note that this value is only valid when the function's return-value actually indicates an error.
* A value of -1 signals a general error. The specific error reason is provided in the argument status , as stated in the device-specific man-page 9.1.6.
* Device names shall not be longer than 15 characters. They are defined by use of the function ikonDevCreate at startup.
* This function is not queued by the driver, it always returns immediately with the file descriptor or an error code.
* Applications can have the same device opened several times, using different file descriptors and with different open modes.
channels is limited, applications should issue a close call if no more action on the device has to be performed.
* The VxWorks include file "configAll.h" contains two literals used by iosInit function: NUM_DRIVERS which defines the maximum number of drivers allowed, and NUM_FILES, the maximum number of simultanously open files.
* The VxWorks command "iosDrvShow" shows all drivers of the system and their basic I/O function entry-points. The command "iosFdShow" shows all currently used file descriptors, and "iosDevShow" (or "devs") all installed devices.
3.5.2 close
This operation closes a channel to an opened device and frees the file descriptor. fileDescriptor must correspond to one of those obtained previously be an open call.
* This function is not queued by the driver, it always returns on of the above two status codes immediatly.
3.5.3 ioctl
This function commands the driver to perform the specified operation on the device. The commands are divided into read and write commands. Read commands are allowed in each open mode while write commands will be rejected if the channel was not previously opened in Shared, Exclusive or Test mode.
* command is a number, identifying the operation to be performed by the driver. Literals of all commands are provided in ikonCommands.h. and described in section 4.
* argument is the address of the command argument, or NULL if no argument is used. For commands, needing multiple arguments it is the address of a data structure which contains those. All argument data structures are defined in the include file ikonCommands.h.
* errors as stated in the device-specific man-page 9.1.5 and in each command's description in chapter 4.
* This function is protected by a semaphore, and commands are queued by application priorities rather than by First-in First-out.
4 DRIVER IOCTL COMMANDS
This section describes all control commands which can be invoked by use of the VxWorks ioctl function. The parameter command specifies which operation has to be performed by the driver while the parameter argument passes the address of an argument to the command handler. In cases where multiple arguments are needed the address of a structure which contains those is passed.
All command literals and argument data structures are defined in the include file ikonCommands.h.
Each ioctl-command can have an argument, which can consist of one scalar or a struct of more values of type integer resp. double, other types are not allowed. The following rules apply for conversion of data other than integer:
· Bigger numerical entities (i.e. 48-bit-position) are signed and are converted to type double10 by the driver. Portability of the driver to machines not applying IEEE-754 for double values is not guaranteed.
Multiple instances of integers and/or doubles are always grouped with C structures.
A pointer to the argument is passed in the ioctl call, never the argument value itself. The ioctl function returns values through this pointer.
Commands that require a response-interrupt from the board have a build-in command-specific timeout while waiting for the response-interrupt. This timeout value corresponds to the inherent duration of the command.
All ioctl calls return lcudrvOK on successful completion, otherwise one of the stated error-codes.
The following ioctl-commands are available, ordered in functional sections:
4.1 Access to DPRAM Data Area
No direct user access is foreseen to the data values in the board DPRAM. All accesses to this area are handled within the driver, i.e. the data values are passed indirectly to the user by calling one of the commands described in sections 4.3 or 4.4.
However, the tool-functions of section 3.3 perform a direct read-access of this area to display the data values.
4.2 Access to DPRAM Parameter Area
For all parameters described in board DPRAM there are two ioctl-commands to read resp. write the value. The argument/result is always a structure containing members for name-specification and value, both of type double. Type-conversion is done as appropriate.
· Read Parameter
Reads one parameter from the device.
Literal: ikonCMD_READ_PARAMETER
Argument: pointer to a struct of type ikonARG_PARAM with the members:
.spec - numerical parameter-specification as stated in [3], e.g. `71.1'
.value - parameter value, returned by the call (signed format)
Return Value: parameter-value, in the .value member of the argument struct.
Errors:
· Wrong parameter-value (e.g. out of range): ikonERROR_INV_PARAM_VALUE
(The driver reads the value from the board and tests if it is in the valid range. This error is reported if this is not the case.)
· Write Parameter
Writes one parameter to the device.
Literal: ikonCMD_WRITE_PARAMETER
Argument: pointer to a struct of type ikonARG_PARAM with the members:
.spec - numerical parameter-specification as stated in [3], e.g. `71.1'
.value - parameter value to be written (signed format)
Return Value: -
Errors:
The following command initializes the whole parameter area with default values, as it is done during the device installation:
· Write Default Parameters
Fills the parameter area with driver-defined default values.
Do not use this command during normal operation!
Literal: ikonCMD_WRITE_DEFAULT_PARAMS
Argument: -
Return Value: -
Errors: as in ikonCMD_WRITE_PARAMETER
(should always return OK, since all parameters are defined internally)
The board does not immediately update it's internal parameter settings from the DPRAM. An explicit command must be issued in order to achieve this:
· Update Parameter Values from DPRAM
Writes the whole parameter area from DPRAM into the internal board status.
Literal: ikonCMD_UPDATE_PARAMS
Argument: -
Return Value: -
Errors:
The following table summarizes the available board parameters, and states the valid ranges checked by the driver, as well as the default values set at device installation:
circular · (3), circular 180º (4)
4The "combined direction" parameter P1.3 has been dropped, but is still silently accepted by the driver.
5The inversion applies only to the read position, it does not affect any internal operation like correction values.
6The firmware "246 118 02" apparently handles inverse direction not correctly for linear axis (no effect)!
7Possible encoder-compliant values are: 0, 500, 1000, 2000, 5000. Should be set to zero for NTT, and non-zero for VLT applications.
8This is a special parameter for NTT applications without distance-coded marks. Should be zero for VLT.
4.3 Position Commands
4.3.1 Command Arguments
The user argument passed to most of the position commands is a structure named ikonPOS_ARG; it has following members:
· .status (int): position info/error bits (I/E) as described in [3], plus additional warning bits (W):
The calculation is done according to: pos = scaleFactor * (counter * 216 + interpolation)
Note: The full 48-bit position value (32-bit `counter' and 16-bit `interpolation') in raw binary format is always returned. If the current scaling factor is different from 0.0, then the scaled position is additionally returned in `pos' as an entity of type double. The conversion and scaling "integer <-> double" is done numerically inside the driver.
The status error bits (E) are set as long as the faulty condition lasts, and indicate that the position is definitely invalid. The warning bits (W) are automatically cleared after each occurence, and only indicate that the returned position is questionable, but not necessarily completely wrong. It is up to the application to decide whether the value must be discarded or not. Both status events are accompanied by the respective error return value (see below). Info bits (I) are not flagged as error.
4.3.2 Command Options
The following commands must be used before any position reading to change the behaviour of the related driver commands, unless the default settings are suitable.
Defines whether or not the commands ikonCMD_LATCH_POSITION_X1/X2/COMBI perform an implicit readout of the latched position to return it.
Default is enabled.
Literals:
The scaling factor can be used for unit conversion (e.g. degrees/meters), and it applies to all channels of the device. It is multiplied with the latched position before it is returned in the `.pos' member of the argument struct with the respective command. A value of 0.0 means that the position is not needed in double type by the user, and has the effect that it will never be returned in that format! This selection is recommended to save calculation time, when only the raw binary values (members `.counter' and `.interpolation') are needed, which are always returned, and never scaled.
Default scaling factor is 1.0, i.e. the 48-bit value is converted one-to-one.
4.3.3 Position Reading
The following commands are used to latch and read the position from the encoder, respectively to set the position to a specific value.
Performs a direct synchronous latch of all channels on all devices within the same address group as the accessed device. After that the position can be read from each of the latched channels with `ikonCMD_READ_POSITION_X1/X2/COMBI'.
It is recommended to use this command instead of `ikonCMD_LATCH_POSITION_X1/X2/COMBI' whenever possible, since it is faster and allows - unlike the others - exactly synchronous latching of multiple channels without unpredictable software delay. Note, however, that this command affects all devices in the same address group, not only the one specified in the ioctl argument!
Channels that shall not be queried can be disabled with the parameter P10 to avoid unnecessary interrupts. Note that even disabling both channels X1/X2 still allows to read the combined channel position, but not the individual X1/X2.
Performs an indirect software-triggered latch for the specified channel. Only one position can be returned, even if in case of `Combined' both channels are latched. By default the command waits, reads and returns the resulting position, but it can also be configured to return immediately without waiting. The behaviour can be specified by the user, see `Enable/Disable implicit Read within Latch' above.
Argument: pointer to a struct of type ikonARG_POS (same as for `Read Position')
Return Value: as for `Read Position' if `Latch with Read' is enabled, otherwise no return value!
Errors: same as for `Read Position' if `Latch with Read' is enabled, otherwise only:
After a channel has been latched, the resulting position must be read. These commands read, and return the position. Note: after device installation the position read-out should always yield the error "POS_STATUS" until the reference-point has been detected.
Literals:
Argument: pointer to a struct of type ikonARG_POS with the members returned by the call.
Return Value: Scaled Position (optional!), Position Status, Binary Counter and Interpolation
Errors:
· Set Position X1/X2/Combined
Modifies parameter P71 so that the current position is overloaded with the argument value, and updates the internal preset.
Literals:
Argument: new position value (type double)
Return Value: new internal preset value (type double)
Errors:
4.4 Initialization Commands
For each board-function described in [3] there is a corresponding ioctl-command that performs the respective actions.
· Execute Power-On-Self-Test (POST)
Performs board-internal tests. Note: This command is automatically executed during device-installation, but can be invoked again by the user. A "Move to Reference Point"command must follow.
Literal: ikonCMD_POWER_ON_SELF_TEST
Argument: -
Return Value: Error-bits in the format: (Bits 0-2 are ignored during device-installation!)
Bit 0: CRC error in correction values X1
Bit 1: CRC error in correction values X2
Bit 2: Invalid parameter found
Bit 3: CRC error in EPROM
Bit 4: Checksum error in EPROM 1
Bit 5: Checksum error in EPROM 2
Bit 6: Hardware failure
· Move to Reference Point X1/X2 or both 11
Initiates the detection of the reference-point of the specified channel, respectively both channels. The axis must be moved in a corresponding way. The completion of the command can be checked by examining the counter status returned by the "Latch and Read Position X1/X2" command .
Note: this command is usually only internally used during device-installation, but still available for the user to be used after a POST command to initialize the counters.
Literals: ikonCMD_REF_MOVE, ikonCMD_REF_MOVE_X1, ikonCMD_REF_MOVE_X2
Argument: -
Return Value: -
Errors:
4.5 Correction Value Commands
· Record Correction Values X1/X2
Initiates the recording of correction values for the specified channel. The axis must be moved in a corresponding way. The command returns immediately, so that the completion must be checked by repeated calls, until lcudrvOK or an error is returned. Section 4.8 explains the operation in more detail.
Literals: ikonCMD_RECORD_CORR_X1, ikonCMD_RECORD_CORR_X2
· Command has already been started, but not finally completed (hence this code does not indicate an error, but is a normal code during phase 1 of the operation):
ikonERROR_CORR_IN_PROGRESS
· Command started, measurement is completed, but internal calculation still running (hence does not mean an error, but only indicates that the drive can be stopped now):
ikonERROR_CORR_CALC_IN_PROGRESS
The driver also supports reading and writing of the records in the correction value memory. A record consists of eight (16-bit) coefficients, the complete table contains always the number of records specified with parameter P08 (corrCount) plus two. Hence, the index of the record number to be given as argument can range between zero and (P08)+1.
Checks on the validity of the data are performed for each record based on the block-check-character (BCC), which is formed by an EXOR operation over the eight values and the record number itself (all as 16-bit items). The over-all CRC-sum is calculated by the IK320 and available in the DPRAM. It is always returned as member of the argument-struct, but a check is not performed on this level (only the support function ikonCoreLoad checks it, see section 3.4). During write operations, the CRC is only updated by the IK320 after the last record has been written.
These commands read one record of the correction value table of the specified channel. Although the records can be read in any order, ascending order is recommended.
Checks on the validity of the data are performed by the driver based on the block-check-character (BCC) provided by the IK320 for each record.
These commands write one record of the correction value table of the specified channel. Due to an IK320 requirement, the records must be written in ascending order, and channels X1/X2 must not be intermixed until all values are written for one channel.
Checks on the validity of the data are performed by the IK320 based on the user-provided block-check-character (BCC) for each record. In case of any error, all values must be written again starting from record number zero.
crc: CRC of the whole table, as provided by IK320 after the operation. This will only be meaningful after the last record has been written.
See also section 4.8 for more details about correction values.
4.6 Auxiliary Ioctl Commands
These auxiliary commands fetch the position without any access to the hardware device. It can therefore be used to determine the latest latched position for informational purpose without disturbing a more important controlling task. It is strongly recommended to use these commands ONLY for purposes where the validity of the returned position is not critical!
Argument: same as for `Read Position'
Return Value: same as for `Read Position'
Errors: same as for `Read Position'
4.7 Driver-Related Ioctl Commands
These ioctl-commands are handled completely within the driver and not forwarded to be board.
· Get Driver Version: returns an integer value derived from the module's version. Bits 31..16 contain the major version number, bits 15..0 contain the minor version number.
Literal: ikonCMD_GET_DRIVER_VERSION
Argument: none
Return Value: version (integer)
Errors: none
· Set Timeout Value: Modifies the timeout-value to be used for semaphore-waits.
Literal: ikonCMD_SET_TIMEOUT
Argument: timeout value in ticks (integer)
Return Value: none
Errors: none
· Get Timeout Value: dto. for read.
Literal: ikonCMD_GET_TIMEOUT
Argument: none
Return Value: timeout value in ticks (integer)
Errors: none
· Free Device: forces a close of a channel opened in exclusive mode.
Literal: ikonCMD_FREE_DEVICE
Argument: none
Return Value: none
Errors: no channel in exclusive mode opened: ikonERROR_NO_EXCLUSIVE
4.8 Special Considerations for Correction Value Recording
Parameter P30.1 (corrParam) - which must already be specified at device installation with ikonDevCreate - has an important meaning for the Correction Value Recording, that is invoked with the command ikonCMD_RECORD_CORR_X1/X2 (section 4.5). The lower two bits of this parameter must be set corresponding to the frequency range on the encoder input lines, that is expected during the movement for the recording (see the hardware manual [3] for details). These two bits can only be set once - namely during device installation - and not changed afterwards! Only the `direction' bits #2 in P30.1 and P30.2 are handled like any other parameter by the board, and can therefore be changed at any time (note that an update command must always follow!).
During the recording, this pre-defined frequency range (which corresponds to the velocity) must not be exceeded in either direction, otherwise the operation will be aborted.
The parameters P07, P08, P09, and P30 have to be set before the operation can be invoked. Refer to the hardware manual [3] for preconditions and side-effects of the operation.
Note that the accelerations during the correction value recording should be linear and as low as possible (ideally zero). The quality of the obtained correction values depend on that.
The order of step can be summarized as follows:
b. P7 to the starting position (counter value only). It can be negative. If movement is in (internally) negative direction, then this actually marks the end of the interval, while the start of the interval depends on P8/P9 and lies in the more positive direction.
Note that an incorrect parameter setup, e.g. setting P7 to an impossible position, will cause that the device can possibly not be recovered after start of the command!
2. Setup the drive to the correct starting position sufficiently outside the interval and start moving. If the current position conflicts with parameter P7, then CORR_INV_POSITION will occur. The nominal velocity must be constant, otherwise CORR_MEASURE_FAILED will occur. It must also be in the correct range specified with parameter P30.1, otherwise CORR_INV_SPEED will occur. A movement direction mismatch will cause CORR_INV_DIRECTION.
3. Send ioctl command ikonCMD_RECORD_CORR_X1/X2. It should return immediately with CORR_IN_PROGRESS. If not, something in the setup might be wrong.
4. Send repeatedly (e.g. after a pre-calculated time, but not more than once per second) the same ioctl command. It should return CORR_IN_PROGRESS to indicate that the measurement is still running.
5. Depending on the movement, the same ioctl command should at some point return CORR_CALC_IN_PROGRESS to indicate that the measurement has been completed, but now the internal calculation is running. This process can take up to four minutes according to [3]. However, if the calculation time is short, then this step might not come to the attention of the user, in which case only the next step will be present.
If any other error code is returned, the operation shall be regarded as failed.
During correction value recording no position values can be queried from either channel until the measurement phase is completed. In the subsequent calculation phase it is possible again, and bit #7 in the position status will be set until also this phase is completed.
Once the recording has been done, the parameters P07, P08, P09 must not be changed, respectively they must be restored to their original values after each hardware-reset. Note also that the contents of the correction value memory will be lost after power-off, unless there is a battery backup available. However, the tables can be saved and loaded together with the parameters from a file to restore the situation before power-down, see section 3.4.
Example for movement in positive direction:
Example for movement in negative direction:
5 ERROR MESSAGES AND RECOVERY
All driver functions make use of the errors defined in the common driver library as described in [8]. Driver-specific errors have been added.
The driver performs a number of checks that the correct conditions are fulfilled and reports an error if this is not the case.
Checks for installation functions include the points already mentioned in section 3.2, and tests for insufficient memory or other system resources.
No checks are done for tool functions of section 3.3, except those that are already included in other driver calls.
Checks for the open and close calls use the common driver library as defined in [8]. This results in the following behavior:
· An open request in exclusive read/write mode is rejected if the device is open to any other process in exclusive or shared read/write mode.
· An open request in shared read/write mode is rejected if the device is open to any other process in exclusive read/write mode.
· An open request in test read/write mode is rejected if the device is open to any other process in test read/write mode.
Checks for the ioctl call also make use of the common driver library as defined in [8] for validation of the channel-number and access-rights. Errors which are specific to each ioctl-command are described in the respective sections of chapter 4.
Access-rights for the respective ioctl-commands are assigned as follows:
Semaphore protection of the device is performed for all ioctl-commands. An ioctl call exits with an lcudrvERROR_TIMEOUT error when the executing task is blocked for longer than the current driver-timeout-value for semaphore-waits, as defined with the driver installation or with the SET_TIMEOUT command.
An ioctl call exits with a ikonERROR_COMMAND_TIMEOUT error when the executing task is blocked for longer than the command-inherent timeout-value while waiting for a response-interrupt from the device. This might indicate a malfunction of the board.
An internal driver error is reported with ikonERROR_INTERNAL. The occurence of this error must be regarded as a driver malfunction; submit an SPR in this case.
A fatal error of the device is reported as ikonERROR_DEVICE_DEAD, e.g. an illegal exception was detected by the board firmware. This indicates definitely a complete breakdown of the board due to some hardware problem, e.g. too much noise on the power supply or when disconnecting the encoder cables during operation. Only a hardware reset can recover from this situation, a software reboot is not sufficient. See the hardware manual [3] for more.
Summary of all driver error codes in alphabetical order:
6 CODE EXAMPLES
6.1 Programmatic Parameter Loading
The following code writes some application specific parameters to the board:
static ikonARG_PARAM ikonParams[] =
{
/* Spec Value */
/* ----- ------ */
{ 1.1, 1 }, /* inverse direction */
{ 2.1, 2 }, /* circular axis */
{ 3.0, 12 }, /* 12 bit interpolation */
{ 4.1, 0 }, /* ref distance */
{ 5.1, 46520.0 }, /* lines per revolution */
{ 19.1, 0 }, /* ref offset */
{ 21.0, 0 }, /* no combined mode */
{ 72.1, 0 } /* axis offset */
};
int i, fd, error;
fd = open("/ikon0", lcudrvOPEN_EXCLUSIVE, (int)&ioerr);
if (fd < 0) ...
for (i=0; i<NELEMENTS(ikonParams); i++)
{
error = ioctl(fd, ikonCMD_WRITE_PARAMETER, (int)&(ikonParams[i]));
if (error != lcudrvOK) ...
}
error = ioctl(fd, ikonCMD_UPDATE_PARAMS, 0);
if (error != lcudrvOK) ...
close(fd);
Note however that the driver also directly supports to load the parameter set from a file with the function ikonCoreLoad.
6.2 Move to Reference Point
The following code example waits until the reference point has been reached. This can be used after the device has been installed, and the axis has been started in order to search for the reference point:
int fd, ioerr;
fd = open("/ikon0", lcudrvOPEN_EXCLUSIVE, (int)&ioerr);
if (fd < 0) ...
do
{
ikonARG_POS ikonPos;
taskDelay(10);
ioerr = ioctl(fd, ikonCMD_LATCH_POSITION_X1, (int)&ikonPos);
} while (ioerr != lcudrvOK);
close(fd);
6.3 Record Correction Values
The following code performs the correction value recording for channel X1. The parameters must have been already setup correctly.
int status;
int fd = -1;
fd = open(devName, lcudrvOPEN_TEST, 0);
if (fd < 0) return ERROR;
printf("opened %s (fd=%d)\n", devName, fd);
printf("Starting RECORD_CORR_X1\n");
printf("NOW ONE SHOULD START THE DRIVE ...\n\n");
FOREVER /* or some reasonable timeout */
{
printf("."); fflush(stdout);
status = ioctl(fd, ikonCMD_RECORD_CORR_X1, 0); /* repeat command */
if (status == lcudrvOK)
{
break; /* completed OK */
}
else if (status == ikonERROR_CORR_CALC_IN_PROGRESS)
{
/* first phase of measurement completed, */
/* drive can be stopped, but still waiting */
/* ... */
printf("Measurement OK, IK320 calculates. STOP THE DRIVE!\n\n");
}
else if (status != ikonERROR_CORR_IN_PROGRESS)
{
printf("ERROR: got error status = %d\n", status);
close(fd);
return status; /* aborted with error */
}
taskDelay(500); /* or some other reasonable delay */
}
/*
* dump values:
*/
ikonCoreSaveX1(devName, NULL);
printf("Completed OK. Above is the correction table:\n\n");
close (fd);
return OK;
7 DIAGNOSTICS
This chapter describes the diagnostic facilities of the driver under the VxWorks shell.
7.1 ikonDevShow
Invoked with no argument, this function show a brief list of all installed devices:
lte33->ikonDevShow
Device Base-A24 Ba-A16 Vec Lev P30 verHW Version-SW
------- -------- ------ --- --- --- ----- ------------
/ikon0 0xcfc000 0x8000 143 3 3 0 246 118 01
/ikon1 0xcf8000 0x8000 142 3 3 0 246 118 02
total number of devices: 2
With a device name as argument, it show more detailed information of this specific device, divided into addresses, control values, and status values including a list of serviced interrupts:
lte33->ikonDevShow "/ikon1"
Device Base-A24 Ba-A16 Vec Lev P30 verHW Version-SW
------- -------- ------ --- --- --- ----- ------------
/ikon1 0xcf8000 0x8000 142 3 3 0 246 118 02
ADDRESSES:
dpramAddr = 0xf0cf8000
dpramData = 0xf0cf8000
dpramParam = 0xf0cf8100
intrPort = 0xffff801c
groupPort = 0xffff8000
posDataPtr[X1] = 0xf0cf8000
posDataPtr[X2] = 0xf0cf8008
posDataPtr[XC] = 0xf0cf8010
CONTROL VALUES:
scaleFactor = 1
withScaling : enabled
latchWithRead : enabled
STATUS VALUES:
latchDisable = 0 (bit 0..2: channel X1/X2/Combi)
Interrupts last-status count
$01: X1 latched: 0x0106 47
$02: X2 latched: 0x0206 47
$03: Combi latched: 0x0306 8
$07: POST completed: 0x0700 1
$0a: Parameter-update completed: 0x0a00 2
(all other interrupts have a zero-count)
refPending1/2 = 0/0 (1: REF_MOVE not yet completed)
corrPending1/2 = 0/0 (1: RECORD_CORR not yet completed)
fatalException = 0x0000 (0=OK, else last intrStatus)
devStatus = 0x0001 (initialized and OK)
The refPending and corrPending flags indicate that the corresponding command has been issued, but has not been acknowledged yet by the user through a repeated call of the same command.
The fatalException flag indicates that the device's firmware entered an unrecoverable state. The corresponding interrupt status is given in this line, so that the exact reason can be determined with [3].
The devStatus flag indicates the global device status. It is `not initialized' (zero) as long the device has not passed the DevCreate funtion successfully, after that it is set to `OK' (one). Upon a fatal exception it is set to `dead' (-1). Any asynchronous error interrupts from the device are also saved here in form of a bit-field, and displayed one per line if they have occured.
The amount of displayed information can even be increased by giving a second argument-flag. Then also all internal semaphore addresses are printed, and the whole list of interrupt statuses, whether serviced or not:
The devStatus flags and interrupt counts can be reset by giving a third non-zero argument-flag:
7.2 ikonPosShow
This function performs a latch of all channels and displays the positions togehter with the status. When everything is OK the display should be like:
lte33->ikonPosShow "/ikon1"
Chan. Decimal Hex (48-bit) Sig Ctr Ampl Freq Ref Corr
----- ---------------- -------------- ---- ---- ---- ---- ---- ----
X1 161048384 0x000009996740 norm run ok ok - -
X2 161048352 0x000009996720 norm run ok ok - -
Combi 321991056 0x000013313190 norm run ok ok - -
Depending on the parameter configuration a position can be marked as `unavailable'. If the position cannot be converted for some reason, `conversion err' is displayed. The `status err ->' is shown when the status bits described below indicate that the position is not valid. Any other reason for not displaying a valid position is marked with `cannot read'.
Sig indicates whether a correction has took place (corr) or not (norm), i.e. correction is enabled and position within corrected range. Whether the counter has been started or not is displayed with Ctr.
If Ampl indicates LOW or Freq is ERR, then the encoder signal is presumably not within the specifications listed in [3], or there is nothing connected at all.
The Ref flag shows if the channel has found the reference point or is still searching (WAIT). During internal calculation after a correction value recording (but not during the measurement before that) the Corr flag is set to REC, otherwise not.
An example with some error indications is shown below (X2 not connected):
lte33->ikonPosShow "/ikon1"
Chan. Decimal Hex (48-bit) Sig Ctr Ampl Freq Ref Corr
----- ---------------- -------------- ---- ---- ---- ---- ---- ----
X1 161048400 0x000009996750 norm run ok ok - -
X2 0 status err -> norm STOP LOW ok WAIT -
Combi 160995504 status err -> norm run LOW ok WAIT -
Here the combined mode is disabled by P21:
lte33->ikonPosShow "/ikon1"
Chan. Decimal Hex (48-bit) Sig Ctr Ampl Freq Ref Corr
----- ---------------- -------------- ---- ---- ---- ---- ---- ----
X1 161048400 0x000009996750 norm run ok ok - -
X2 0 status err -> norm STOP LOW ok WAIT -
Combi (unavailable)
7.3 ikonParamShow
This tool functions displays the complete contents of a device's parameter set in the DPRAM in decimal and hexadecimal format, including a textual interpretation of numeric flags:
lte33->ikonParamShow "/ikon1"
Spec Name Offset Size Value
----- --------------- ------ ---- --------------------
P01.1 directionX1 0x102 1 = 0x01 = 1 (inverse)
P01.2 directionX2 0x103 1 = 0x01 = 1 (inverse)
P01.3 (directionCombi) 0x104 1 = 0x00 = 0 (normal)
P02.1 axisTypeX1 0x106 1 = 0x02 = 2 (circular (0..360))
P02.2 axisTypeX2 0x107 1 = 0x02 = 2 (circular (0..360))
P02.3 axisTypeCombi 0x108 1 = 0x01 = 1 (linear)
P03.0 validBits 0x10a 2 = 0x000c = 12
P04.1 refDistanceX1 0x10c 2 = 0x0000 = 0
P04.2 refDistanceX2 0x10e 2 = 0x0000 = 0
P05.1 sigPeriodsX1 0x110 4 = 0x0000b5b8 = 46520
P05.2 sigPeriodsX2 0x114 4 = 0x0000b5b8 = 46520
P05.3 sigPeriodsCombi 0x118 4 = 0x00000000 = 0
P06.1 corrEnableX1 0x11c 1 = 0x00 = 0 (off)
P06.2 corrEnableX2 0x11d 1 = 0x00 = 0 (off)
P07.1 corrRangeX1 0x11e 4 = 0x00001388 = 5000
P07.2 corrRangeX2 0x122 4 = 0x00000000 = 0
P08.1 corrCountX1 0x126 2 = 0x000a = 10
P08.2 corrCountX2 0x128 2 = 0x1000 = 4096
P09.1 corrWidthX1 0x12a 2 = 0x0064 = 100
P09.2 corrWidthX2 0x12c 2 = 0x0010 = 16
P10.0 latchDisable 0x12e 1 = 0x00 = 0 (none)
P19.1 refOffsetX1 0x130 4 = 0x00000000 = 0
P19.2 refOffsetX2 0x134 4 = 0x00000000 = 0
P21.0 combiMode 0x138 1 = 0x01 = 1 (X1 + X2)
P30.1 corrParamX1X2 0x13a 1 = 0x07 = 7 (80-5Hz,downwards)
P30.2 corrParamX2 0x13b 1 = 0x00 = 0 (upwards)
P70.1 extPresetX1 0x13c 6 = 0x000000000000 = 0
P70.2 extPresetX2 0x142 6 = 0x000000000000 = 0
P70.3 extPresetCombi 0x148 6 = 0x000000000000 = 0
P71.1 vmePresetX1 0x14e 6 = 0x000000000000 = 0
P71.2 vmePresetX2 0x154 6 = 0x000000000000 = 0
P71.3 vmePresetCombi 0x15a 6 = 0x000000000000 = 0
P72.1 axisOffsetX1 0x160 6 = 0x000000000000 = 0
P72.2 axisOffsetX2 0x166 6 = 0x000000000000 = 0
P72.3 axisOffsetCombi 0x16c 6 = 0x000000000000 = 0
P80.1 extFunction1 0x172 1 = 0x00 = 0 (none)
P80.2 extFunction2 0x173 1 = 0x00 = 0 (none)
P81.0 vmeFunction 0x100 2 = 0x0003 = 3 (latchX1X2Combi)
Offset means the byte-offset of the parameter location in the DPRAM from the device's A24 base-address as shown with ikonDevShow.
Size is the number of bytes that the parameter occupies in the DPRAM.
7.4 ikonDataShow
This tool functions displays the complete contents of a device's DPRAM data section
lte33->ikonDataShow "/ikon1"
DPRAM data area of /ikon1:
positionX1 (0x000) = 0x000009996730 [st=0x04 xf=0] = 161048368
positionX2 (0x008) = 0x000009996730 [st=0x04 xf=0] = 161048368
positionCombi (0x010) = 0x000013313190 [st=0x00 xf=0] = 321991056
intrStatus (0x018) = 0x0000
crcEprom (0x01a) = 0xef09/0xef09 (nominal/actual)
checksumEprom1 (0x01e) = 0x013d0304/0x013d0304 (nominal/actual)
checksumEprom2 (0x026) = 0x013cdd29/0x013cdd29 (nominal/actual)
versionHW (0x02e) = 0x0000
versionSW (0x030) = "246 118 02"
systemStatus1 (0x03c) = 0x05
systemStatus2 (0x03d) = 0x04
presetX1 (0x03e) = 0x000000000000 = 0
presetX2 (0x044) = 0x000000000000 = 0
presetCombi (0x04a) = 0x000000000000 = 0
corrDataRead (0x050) = ffff dfff fffd ffff bfff 73ff d6ff feff ffff 3eff
corrDataWrite (0x050) = ffff ffff ffff ffff dbff beff 7fff cfff edff 8eff
corrCrcX1 (0x090) = 0xcb00
corrCrcX2 (0x092) = 0xcb00
analogSinX1 (0x0f8) = 0xfffff2d0 = -3376
analogCosX1 (0x0fa) = 0xffffed10 = -4848
analogSinX2 (0x0fc) = 0xfffff008 = -4088
analogCosX2 (0x0fe) = 0xffffe914 = -5868
In the position display, st means the 8-bit status word, and xf the access-flag, which should normally be zero (i.e. not permanent non-zero) to allow the IK320 to write to the DPRAM.
The intrStatus should always be shown as zero, since it is always immediately reset at interrupt level after the interrupt has been serviced. If a non-zero is permanent, then a device error can be assumed (see also section 7.5).
The CRCs and checksums can be used the verify the integrity of the board. They are not implicitly checked by the driver.
The analog values can be used to determine the input level from the encoder. Refer to [3] for details.
The remaining values are given for completeness, but do not serve for diagnostic purposes.
7.5 Trouble Shooting
+ Check the intrStatus word in the DPRAM with ikonDataShow. It should always be zero, since otherwise the device will not accept any master-interrupt function, so that the driver will always encounter a COMMAND_TIMEOUT error.
This situation might indicate a hardware problem, since it would occur when a vectored interrupt got lost and was never serviced by the CPU.
" Send a POST ioctl command. Resetting the intrStatus manually (e.g. with the VxWorks `m' command) might eventually also recover the device.
+ It is normal that the device does not respond as long the measurement is running. The LED on the board is constantly on or off during that time. When the position range configured with the parameters has been passed, the device should be accessible again.
" There seems to be no way to recover the device when it does not return by itself from the operation, even POST does not work. Do a hard reset of the whole system.
+ Be sure to update the parameters after any change, otherwise the values will not be recognized by the device.
+ This is a reaction to a board interrupt indicating that the firmware has crashed in an unrecoverable way. Disconnecting the encoder cables during operation might cause this.
8 INSTALLATION
The installation of the ikon driver is done at system start-up time by script files and shall not be changed at run-time. It is composed by the installation of the driver code, the installation of the devices for that driver and the connection of the device to the driver.
8.1 Installation Prerequisites
The following hardware and software prerequisities must be fulfilled for a successful installation of the driver.
8.1.1 Hardware Requirements
The following hardware and software environment is required to run the software described:
8.1.2 Software Requirements
8.2 Building the Software
The make procedure follows VLT standards, as described in [6] and [7]. In short:
The loadable binary file ikon will be stored in "$INTROOT/vw/bin/" (if defined) respectively "$VLTROOT/vw/bin/".
8.3 Installation Procedure
This section shows an example to install the ikon driver and the first device. The utility vltMan can be used to access man-page informations for the ikon-functions.
4. Restore parameter set and correction tables, if necessary:
-> ikonCoreLoad("/ikon0", "/tmp/ikonCore.dat")
8.4 Installation Verification
Functions performed during installation phase always log OK or ERROR messages to the console.
The tools described in a previous section can be used to test that the driver and the device have been installed correctly. From the VxWorks shell issue the following commands:
· ikonPosShow 0
should print the current position (which yields zero if no reference point has been detected).
8.5 Sample Core File
The driver has built-in functions to load and save the device's core-data, see section 3.4. The detailed format of this file is described in the man-page of ikonCore, see section 9.
This is an example of a file as produced by ikonCoreSave:
#******************************************************************************
# E.S.O. - VLT Project
#
# THIS IS A GENERATED FILE - DO NOT EDIT
#
# Tool: $Id: ikonCore.c,v 1.27 1996/03/06 08:58:51 ssandroc Exp $
# Device: /ikon1
# File: /tmp/x1.core
#=====================================================
# Parameters
#
# spec value comment
# ----------------------------------------------------
P 1.1 0 # directionX1: normal
P 1.2 0 # directionX2: normal
P 1.3 0 # *directionCombi: normal
P 2.1 1 # axisTypeX1: linear
P 2.2 1 # axisTypeX2: linear
P 2.3 1 # axisTypeCombi: linear
P 3.0 12 # validBits:
P 4.1 0 # refDistanceX1:
P 4.2 0 # refDistanceX2:
P 5.1 46520 # sigPeriodsX1:
P 5.2 46520 # sigPeriodsX2:
P 5.3 0 # sigPeriodsCombi:
P 6.1 1 # corrEnableX1: on
P 6.2 0 # corrEnableX2: off
P 7.1 -5000 # corrRangeX1:
P 7.2 -5000 # corrRangeX2:
P 8.1 10 # corrCountX1:
P 8.2 10 # corrCountX2:
P 9.1 100 # corrWidthX1:
P 9.2 100 # corrWidthX2:
P 10.0 0 # latchDisable: none
P 19.1 0 # refOffsetX1:
P 19.2 0 # refOffsetX2:
P 21.0 0 # combiMode: none
P 30.1 7 # corrParamX1X2: 80-5Hz,downwards
P 30.2 4 # corrParamX2: downwards
P 70.1 0 # extPresetX1:
P 70.2 0 # extPresetX2:
P 70.3 0 # extPresetCombi:
P 71.1 0 # vmePresetX1:
P 71.2 0 # vmePresetX2:
P 71.3 0 # vmePresetCombi:
P 72.1 0 # axisOffsetX1:
P 72.2 0 # axisOffsetX2:
P 72.3 0 # axisOffsetCombi:
P 80.1 0 # extFunction1: none
P 80.2 0 # extFunction2: none
P 81.0 33 # vmeFunction: writeCorrX1
U # update parameters
#=====================================================
#=========================================================================
# Correction Table X1 (12 records)
#
# record coeff1 coeff2 coeff3 coeff4 coeff5 coeff6 coeff7 coeff8 bcc
# ------ ------ ------ ------ ------ ------ ------ ------ ------ ------
C1 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
C1 0x0001 0xff52 0xf7e6 0xfe54 0xfd85 0x002c 0xfe8e 0x0072 0xff70 0x0ac4
C1 0x0002 0xf9f7 0xed8c 0xfd67 0xf957 0x0058 0xfd5d 0x012c 0xfe92 0x12f2
C1 0x0003 0xfa6e 0xeb04 0xfdad 0xf820 0x006c 0xfcea 0x00dc 0xfe65 0x16db
C1 0x0004 0xfa54 0xec40 0xfdd7 0xf957 0x00d0 0xfd66 0x012d 0xfe4d 0x1046
C1 0x0005 0xf929 0xe5a8 0xfd45 0xf673 0x015c 0xfe22 0x0102 0xff55 0x169b
C1 0x0006 0xf770 0xed17 0xfd7d 0xfac2 0x0185 0xfe83 0x01bc 0x01bc 0xe2d8
C1 0x0007 0xf73c 0xeed7 0xfd77 0xfab9 0x00fe 0xfe2c 0x01ca 0x01ca 0xe0f0
C1 0x0008 0xf7dd 0xf25d 0xfdc3 0xfc54 0x009e 0xff05 0x0177 0x0177 0xfb84
C1 0x0009 0xf9c6 0xf5e7 0xfe4e 0xfde0 0x00ed 0xff73 0x011b 0x011b 0xf018
C1 0x000a 0xfa76 0xf83d 0xfe66 0xfeab 0x0103 0xffc8 0x00e3 0x00e3 0xfc47
C1 0x000b 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x000b
C1 CRC 0x4457
#=====================================================
# Correction X2 disabled, no data saved
3The interrupt-vector is dependent on the selection for the A16 base-address. The exact address in the A16 space, on which the local board interrupt can be invoked, is internally calculated from the A16 base-address and the interrupt-vector.
4This parameter can only be set once after power-on (see [3]). It must be set correctly before the first invocation of the Power-On-Self-Test (see [3]). It cannot be changed after power-on, not even by HW reset.
5Note that the base address check includes a test of the direct group-latch port. Since the driver does not use address-only cycles, it is required that one IK320 board in each address group has to be configured such that an access is acknowledged with a DTACK signal. See the hardware documentation [3] for more (jumper J3).
6Portions of this parameter can only be set once after power-on, see [3], hence they cannot be changed after device-installation as described in section 3.2 until the next power-on.
7Note that the third parameter is declared as (int) in VxWorks. A cast with (int) will therefore always be necessary when this function is called.
8Note that the third parameter is declared as (int) in VxWorks. A cast with (int) will therefore always be necessary when this function is called.
9Exception: the ioctl-commands for read/write correction tables use 16-bit entities in the argument struct.
1064-bit floating point values according to IEEE-754 have a 52-bit mantissa, so that conversion of 48-bit integer values is possible without loss of precision.
11As described in [3], multiple reference-points are not supported. Each channel can have only one ref-point.
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|