| |
|
|
|
2 USER'S GUIDE
This part of the document provides a functional description of the module: how to use it and what to use it for.
2.1 Overview
The program controlling hardware is usually called driver, and the specific hardware to control is called a device. 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. The driver concept of VxWorks is described in [1].
The minimal hardware system consists of a CAN card, which provides a bridge from VME to CAN bus, a CAN network consisting of a two-wire connection and the CANopen analog/digital I/O module consisting of several I/O terminals and one CAN bus coupler. Several modules can operate simultaneously on a CAN network identified by a unique node address. The CAN card also supports up to two independent CAN networks. A device descriptor is assigned to each CAN node, which controls and synchronizes the simultaneous access to this node. Because different devices share one CAN card, the driver routines for sending and receiving CAN messages provided by the vendor of the CAN card must be threadsafe to allow concurrent access for different devices.
The software interface is based on the VxWorks driver model implementing all its functionalities via ioctl commands, which are the same as for acro and aio devices. The interface has been designed to be as close as possible to that of the acro and aio drivers concerning error handling and codes, ioctl commands and data types. A canio device behaves like a combination of an acro and aio device. The use of acro and aio command identifiers for ioctl calls has made it necessary to redefine the numeric values of these identifiers to be unique and to modify the include files containing these identifiers. This change does not affect any software as long as the symbolic names for these ioctl command identifiers are used. The acroxInducer and aioxInducer panels parse the include files to access these ioctl command values and are therefore unconcerned by this modification This feature allows in most cases an easy adaption of existing software by modifying only the device name leaving all other parameters unchanged. Additional commands are provided to take into account special features of the I/O module e.g. requesting device properties like the number of supported signals.
The structure of the canio driver consists of 3 software layers:
The numbering of signals is based on the following scheme:
For digital signals, a valid signal number covers the range from 0 to <number of digital signals> - 1. Digital input signals have numbers from 0 to <number of digital input signals> - 1, while digital output signals are assigned to <number of digital input signals> to <number of digital signals> - 1 ( for acro devices each signal can be configured as input or output, which is not possible for a canio device )
For analog signals, there is a clear separation of input and output signals. A valid signal number covers the range 0 to <number of analog input signals> - 1 for analog inputs and 0 to <number of analog output signals> - 1 for analog outputs.
The mapping of these signal numbers to the I/O channels on the physical device is given by the following rules:
· one I/O bus terminal can have 2 or 4 I/O channels, which have subsequent signal numbers ( the order of these signals can found in the datasheet of the bus terminal )
· an I/O bus terminal can be only of the type analog input, analog output, digital input or digital output
2.2 Driver Functions
This driver implements basically the functionality of the analog/digital I/O module The driver conforms to the VxWorks driver concept, i.e. it supports the functions open, close and ioctl.
The open and close calls are used to specify or free a channel to get and regulate access to the device. The filename is specifying the device to which the channel shall be opened and is made up of two parts:
Write accesses are only permitted to the task which has opened the device in read/write mode, while read accesses are not restricted.
The read and write calls are only empty routines to conform to the standard driver interface, [1].
All supported operations are implemented via the ioctl calls. The ioctl call has a parameter specifying the action requested by the device. Because most of the commands are derived from the acro and aio driver interface, the parameters for these ioctl calls have the same form as for acro ( if digital signals are involved ) and aio ( if analog signals are involved ) drivers. These commands are grouped into read and write commands. Read commands are used to read values or status from the board, while write commands are used to write values or perform some action.
Before a task has performed an open call it cannot send any read or write command to the driver.
The driver controls the access to the device, provided by the open/close calls giving the following possibilities (read accesses are always permitted for a task which has opened the device in read or read/write mode):
2. Exclusive read/write access: write access is granted only to the user that performed the open with this option. Requesting exclusive access to a device already opened in Exclusive or Shared access mode gives back an error.
3. Shared read/write access: write access is granted to the user that performed the open and to any other task that later on will request a similar open. Requesting Shared access to a device already opened in Exclusive access mode gives back an error.
4. Test read/write access: write access is granted to the user that performed the open with this option without limitation to the present opening status. Requesting Test access to a device already opened in Test access mode gives back an error, i.e. Test access mode is only granted to one task. This mode shall only be used by test and maintenance software. The idea is that test and maintenance software can access the driver without interfering with other users of the driver.
In addition, the driver calls are mutually exclusive, i.e. the device accessed by a task is protected from access from any other authorized task until the executing driver call has terminated. This means that if a task is executing a driver call and another task tries to access the driver for the same device, then this second task will be blocked until the driver call of the first one has terminated. The blocked task will be put on a queue. There is one queue for each device and the tasks 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 [1].
A task blocked for access of a device will have a 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-interruptible instruction. In this case there is no need for any protection as no other task can interfere during the action. Section 5.1 defines for which Ioctl commands the access checks are performed. The open call returns a file handle with which the channel is identified in any further driver calls.
3 REFERENCE
3.1 Introduction
This chapter provides a detailed description of the CANopen analog/digital I/O 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 canioErrors.h and in [8].
3.2 Functions
As mentioned above, the CANopen analog/digital I/O driver uses the standard VxWorks I/O system calls open, close and ioctl to interface to the user. These functions are described in the following sections with respect to their special meaning in the CANopen analog/digital I/O driver context. For more general information see the VxWorks Programmers Guide [1].
3.2.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 accesses are always granted for any open modes.
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 Shareable write mode returns an error.
Test read and write open mode. Write access is granted to the task using this open mode regardless of the status of the device. Requesting this mode for a device already opened in Test mode returns an error.
* A value of -1 signals a general error. The specific error reason is provided in the argument status which can be
The requested open mode is conflicting with the open modes of already existing channels. This error is caused by one of the following reasons:
* A cast to (int) for the third parameter is necessary because the declaration in VxWorks overrides the one shown here.
* Device names shall not be longer than 15 characters. They are defined by use of the function canioDevCreate at startup.
* The number of opened channels for all devices of the driver is limited to the value defined at installation-time.
* Applications can have the same device opened several times, using different file descriptors. Furthermore, open modes can be mixed according to the rules previously described.
* As only one task can open a device for Exclusive mode at any one time, and the number of 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 simultaneously open files. They are respectively defined as 20 and 50.
* 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.2.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 immediately.
3.2.3 ioctl
This function commands the driver to perform the specified operation on the device. The commands are devided 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 an integer, identifying an ioctl command to be sent to the driver. The values identifying a command are defined in the include file canioCommands.h. The numeric values of these identifiers are identical to the corresponding commands defined in acroCommands.h and aioCommands.h. The only reason why these command identifiers are redefined in this include file with different symbolic names is that the canioxInducer panel parses this file to get the numeric values.
* argument is the address of the command argument, or NULL if no argument is used. For `Write' commands, argument contains the values to be written, for `Read' commands, the value read is returned in argument.
Argument, when used, can only be an integer, or structures defined in the include files acroCommands.h and aioCommands.h provided by driver libraries and described in section "Ioctl control commands".
* lcudrvERROR_ACCESS_CONFLICT if the write command can not be executed by use of a file descriptor previously obtained with a read-only open mode.
* Other specific values returned by the driver are described for each ioctl command in section 3.3 and a full description of errors can be found in chapter 5.
* A cast to (int) for the third parameter is necessary because the declaration in VxWorks overrides the one shown here.
* This function is protected by a semaphore, and commands are queued by application priorities rather than by First-in First-out.
* A timeout is implemented to ensure the permissible maximum blocking delay of a task. This delay, expressed in ticks (currently there are 100 ticks in 1 second), is initialized at start-up, and can be read or modified at run-time by two additional commands (get/set timeout).
3.2.4 canioDrv(3)
This function is called only once at startup. It hooks up the various
I/O service calls to the driver's functions, assigns the driver number,
and adds the driver to the driver table.
devices - number of supported devices
channels - number of channels that can be simultanously be opened
timeout - access timeout value
lcudrvOK - driver successfully installed
lcudrvERROR_DRIVER_EXISTS - the driver is already installed
lcudrvERROR_NO_MEMORY - there is not enough memory for dynamic
data structures
lcudrvERROR_INVALID_ARGUMENT - the value of one of the parameters is
out of range
3.2.5 canioDevCreate(3)
This function is called at startup for each device to be installed.
It adds a device to the driver, making it available for subsequent open
operations.
devName - device name (must be "/canioX" X>=0, e.g. "/canio0")
node - unique identifier for CAN device ( 0 - 63 )
On the Beckhof module, the node ID can be set with
a DIP switch ( 0 - 6 )
dummy - This parameter is
This implies that if one uses two 2-channel CAN cards within a LCU, the available CAN network numbers are 0, 1, 4, and 5.
lcudrvOK - successful completion
lcudrvERROR - there is a general VxWorks I/O error
lcudrvERROR_NO_DRIVER - driver not yet installed
lcudrvERROR_INVALID_DEVICE - invalid device name
lcudrvERROR_INVALID_ARGUMENT - invalid parameter
lcudrvERROR_DEVICE_EXISTS - device already installed
lcudrvERROR_NO_SEMAPHORE - creation of access protection semaphore
failed
3.3 Ioctl control 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 canioCommands.h.
The supported commands can be divided into two groups: Read and Write Commands. Read Commands are allowed in each open mode, while Write Commands are allowed only in Shared, Exclusive or Test mode.
This section lists all control commands supported by the driver. The list also contains a short description of each command and its literal. The error codes sent in case of an error are described in Chapter 5.
3.3.1 Ioctl Read I/O Commands
This command is compatible to the acro command acroCMD_READ_BITS and returns the states of the specified input signal(s).
· .firstSignal (in) the number of the first signal ( the supported range depends on the number of digital input signals )
· .numSignal (in) the number of signals ( the supported range depends on the number of digital signals and must be smaller or equal than 32, because the signal values are returned as bits in a 32-bit unsigned integer value)
· .returnValue (out) the signal status, where a one in the corresponding bit indicates that the signal is active; the value is right shifted, that is bit 0 contains the state of the first signal, bit 1 the second signal etc. This parameter is returned by the driver.
This command is compatible to the acro command acroCMD_READ_CONFIG_BITS and returns the configuration of the specified signal(s).
· .firstSignal (in) the number of the first signal ( the supported range depends on the number of digital signals )
· .numSignal (in) the number of signals ( the supported range depends on the number of digital signals and must be smaller or equal than 32, because the signal properties inputOutput and polarity are returned as bits in a 32-bit unsigned integer value )
· .inputOutput (out) the input/output configuration, where a one indicates an output and a zero an input. This parameter is returned by the driver.
· .polarity (out) the active signal level, where a one indicates signal active high and a zero signal active low; the value is right shifted, i.e. bit 0 contains the state of the first signal, bit 1 the second etc. This parameter is returned by the driver.
This command is compatible to the acro command acroCMD_CHECK_PULSE_BIT. Argument: address of an integer value, containing the number of the signal to be checked ( the signal must be an digital output signal )
This command is compatible to the aio command aioCMD_READ_VALUE and returns the value of the specified signal.
· .number (in) the signal number (the supported range depends on the number of analog input signals )
· .value (out) the signal value as floating point number ( the 16-bit value is converted to a voltage )
This command is compatible to the aio command aioCMD_READ_BIN_VALUE and returns the value of the specified signal.
· .number (in) the signal number ( the supported range depends on the number of analog input signals )
· .number (in) the signal number (the supported range depends on the number of analog output signals )
· .number (in) the signal number (the supported range depends on the number of analog output signals )
This command is compatible to the aio command aioCMD_GET_INPUT_CONFIG and get the configuration ( voltage range, gain factor ) of the specified signal.
· .config (out) the voltage range. Alaways returns the value 1 corresponding to the range [-10,+10}, which is the only range supported by the hardware
· .gain (out) the gain factor for the voltage conversion. The only value supported by the hardware is 1 which corresponds to a gain of 1
· .number (in) the signal number (the supported range depends on the number of analog input signals )
This command is compatible to the aio command aioCMD_GET_OUTPUT_CONFIG and configures the specified signal.
· .config (out) the voltage range. Alaways returns the value 1 corresponding to the range [-10,+10}, which is the only range supported by the hardware
· .gain (out) the gain factor for the voltage conversion. The only value supported by the hardware is 1 which corresponds to a gain of 1
· .number (in) the signal number (the supported range depends on the number of analog output signals )
3.3.2 Ioctl Write I/O Commands
This command is compatible to the acro command acroCMD_WRITE_CONFIG_BITS ( beside the missing possibility to define if a signal is an input or output ) and configures the polarity of the signal(s) .
· .polarity the active signal level, where a one indicates signal active high and a zero signal active low. The value is used for all specified signals.
This command is compatible to the acro command acroCMD_WRITE_BITS and writes a value to the signal(s) specified..
· .numSignal the number of signals ( the supported range depends on the number of digital signals and must be smaller or equal than 32, because the signal values are stored as bits of a 32-bit unsigned integer value )
· .value the signal(s) states, where the range must correspond to the number of signals specified; bit 0 of the value shall contain the state of the first signal, bit 1 the second signal etc.
This command is compatible to the aio command aioCMD_WRITE_VALUE and sets the value of the specified signal.
· .number (in) the signal number (the supported range depends on the number of analog output signals )
· .value (in) the signal value as floating point number ( the voltage value is converted to a 16-bit integer value )
This command is compatible to the aio command aioCMD_WRITE_BIN_VALUE and sets the value of the specified signal.
· .number (in) the signal number (the supported range depends on the number of analog output signals )
This command is compatible to the aio command aioCMD_SET_INPUT_CONFIG and configures the specified signal.
· .config (in) the voltage range. Only the value 1 corresponding to voltage range [-10,+10] is supported
· .number (in) the signal number (the supported range depends on the number of analog input signals )
This command is compatible to the aio command aioCMD_SET_OUTPUT_CONFIG and configures the specified signal.
· .config (in) the voltage range. Only the value 1 corresponding to voltage range [-10,+10] is supported
· .number (in) the signal number (the supported range depends on the number of analog output signals )
This command is compatible ot the acro command acroCMD_WRITE_SET_BIT and sets a signal to its active state.
Argument: address of an integer value, containing the number of signal to be set ( must be an output signal )
This command is compatible ot the acro command acroCMD_WRITE_CLEAR_BIT and sets a signal to its inactive state.
Argument: address of an integer value, containing the number of signal to be cleared ( must be an output signal)
This command is compatible ot the acro command acroCMD_WRITE_CHANGE_BIT and changes the state of a signal.
Argument: address of an integer value, containing the number of signal to be changed( must be an output signal )
This command is compatible ot the acro command acroCMD_WRITE_PULSE_BIT and changes the state of a signal for a specified time.
· .value the time in ticks to pulse the signal; the values zero gives a short pulse, for longer pulses the driver will return before the pulse has terminated; a write access to this signal before the pulse has terminated will be rejected
This command is compatible with the acro command acroCMD_WRITE_PULSE_BIT_RESET and resets the timer of the pulse. The signal state will be changed.
Argument: address of an integer value, containing the number of signal number ( must be an output signal )
3.3.3 Ioctl General Commands
Sets all digital signals to active-low, all analog signals to gain 1 and voltage range -10/+10V and all digital/analog output signals to 0.
The purpose of this command is to freethe device when a task which has opened the device in exclusive read/write mode is blocked or has terminated without closing the device. In this case it is not possible to send a write command to the device. This command frees the device and enables another task to open the device in read/write mode. The intention is that this command shall only be used `manually' by an operator, to free the device and should not be used by tasks which wants to send ioctl write commands to the device.
The purpose of this command is to configure a range of analog input signals to use the SYNC command. When the SYNC command is sent, all signals configured to use SYNC will be transfered from the bus node to the master (LCU). Reading analog-IN signals can be significantly faster when this approach is used.
But please note that this signal reflects the latest measurement available in the local memory of the bus node, which must not necessarily be the actual measurement which might be in progress. Please also note that when this command is used, all the analog-IN signals that do not use SYNC will be reconfigured to be transmitted with (slower) SDO's on the CANBus.
After a range of analog-IN signals are cnfigured as SYNC, reading one of these signals with canioCMD_READ_VALUE will just return the value that is available in the local memory of the LCU, which is updated only when a SYNC command is sent. As long as no new SYNC command is sent, the returned value will therefore be identical.
· acroERROR_INVALID_ARGUMENT - Invalid range of signals, i.e. there are either not as many analog-IN signals available as requested to be configured as SYNC, or the number of the first signal is too large (and therefore an output signal).
This command sends a SYNC signal to the CANBus. Consequenctly, all bus nodes configured to use SYNC will send the latest available measurement to the master (LCU). Please note that this command returns as soon as SYNC was sent, not waiting for the new data to arrive. A internal semaphore is used which will cause subsequenct canioCMD_READ_VALUE commands to wait until the data is available.
3.4 Logging
The CANopen analog/digital I/O driver makes use of the common logging facility, i.e. the lculog module for debugging and tracing purposes. Therefore the lculog task must be loaded and spawned before the CANopen analog/digital I/O driver is used.
The logging facility simply prints messages to the VxWorks shell. There are several different types of messages:
The Intr-, Debug- and Trace-Option can be switched on by issuing the following commands to the VxWorks shell: LCU_intr, LCU_debug and LCU_trace. All functions should return the value 1.
To switch the logging and tracing facilities off just issue the corresponding commands again and this time they should return the value 0.
3.5 Include files
Beside VxWorks include files, driver applications must include "canio.h" to interface the CANopen analog/digital I/O driver. Board dependent, this file declares as prototypes the operations provided by the driver library, and includes other files themselves.
· "canioCommands.h" defining the literals of the CANopen analog/digital I/O driver commands and data structures for multiple argument commands as used with the ioctl procedure.
3.6 Tools
The CANopen analog/digital I/O driver includes a number of tools which can be used from the VxWorks shell. These tools are intended to be used by a system manager to ease maintenance and troubleshooting.
· canioIoctlTest("device name", command, parameter1, parameter2, parameter3, parameter4)
used to invoke ioctl commands from the shell
All the tools require that the CANopen analog/digital I/O driver is already installed and at least one device is added.
All output is made on the standard output, i.e. either to the system console or to a host terminal.
3.6.1 canioShowDriver
This command provides a way to investigate the current driver properties.
3.6.2 canioShowDevice
This commands retrieves all information about the device.
3.6.3 canioIoctlTest
Ioctl calls require special data structures like aioSignal or acroRead to supply parameter, which is inappropriate for invoking these commands from the shell. The routine canioIoctlTest provides an easy way to provide parameters to an ioctl call. Parameters returned by ioctl call are printed to the shell.
A list of valid parameters can be found in the next table.
4 INSTALLATION GUIDE
The installation of the canio driver is done at startup by script files and shall not be changed at run_time. It is composed by the installation of the driver code, common to all devices using the same board type, the installation of the devices corresponding to each driver, and the connection of interrupts, to vector numbers and interrupt service routines.
This section describes how to build the canio software, if executables are not already available. It then describes step by step the boot script file to load the software on the target. Finally test procedures to verify the installation are described.
4.1 Installation Prerequisites
The following hardware and software prerequisities must be fulfilled for a successful installation of the driver.
4.1.1 Hardware Requirements
4.1.2 Software Requirements
· If more than one CAN network is used, it is necessary to update the canstack.xml configuration file accroding to section 4.4. of this manual.
4.2 Building the Software
The canstack module is delivered as a UNIX tar file, either on disk or on CD. The file expands in a directory structure as defined in [3].
If it is required to build or rebuild the software the Makefile provided shall be used. To use the Makefile a number of environment variables must be defined. An example to set up the environment for VxWorks and the GNU-C-compiler can be found in [5].
Before using the Makefile the user should make sure that GNU make is defined before the make supplied by the vendor in the search path. This can be checked by issuing the UNIX command which make. As defined in [3] VLT software should be built using GNU make in order to avoid discrepancies between different vendors implementation of make. To build the software follow the procedures below:
b. compile and link everything. The result, the VxWorks object-modules canstack, canstackLib and the installation script canstack.boot will be stored in directory canstack/bin. Please note that canstack is a commercial product, available only in binary form. The script canstackLink will evaluate the environment variable $VXROOT to determine if the binary files for vxWorks 5.4 or 5.5 are required.
e. Copy the configuration file canstack.xml to the target directory $VLTROOT/config or $INTROOT/config. Please note that this file has to be adapted to the CAN network that you are using!
The canio module is delivered as a UNIX tar file, either on disk or on CD. The file expands in a directory structure as defined in [3].
If it is required to build or rebuild the software the Makefile provided shall be used. As defined in [3] VLT software should be built using GNU make in order to avoid discrepancies between different vendors implementation of make. To build the software follow the procedures below:
b. compile and link everything. The result, the VxWorks object-module canio and the installation script canio.boot will be stored in directory canio/bin.
4.3 Installation Procedure
This section describes the steps to install the canio driver and the first device. A script file canio.boot is prepared to perform these steps. The utility vltMan can be used to access man-page informations for the canio-functions. Install the acro module with the tool vccConfigLcu in your LCU environment (bootScript).
3. The driver is installed by invoking the function canioDrv() with the following parameters (see Reference):
4. A device is installed by invoking the function canioDevCreate() with the following parameters (see Reference):
· the device name: "/canio<unit>" where <unit> is the device unit number, starting with 0 and incrementing by one for each additional device.
· the card channel where the CAN bus is connected ( the range depends on the number of channels supported by the card. There are cards with 2 and 4 channels available. ). Please note that the assignment of CAN network numbers to the individual ESD CAN cards is hardcoded:
A device is uniquely identified by the node identifier, card and channel number and only one device with a given parameter set can be created.
IMPORTANT: the call to canioDevCreate will fail and stop the booting if the device does not exist. Therefore each user has to configure the canio.boot file according to his/her hardware configuration. Additionally, for each CAN network, one entry has to be added to the canstack.xml configuration file, otherwise the boot process of canstack will fail.
4.4 CANSTACK.XML
The CANOpen manager of canstack requires a configuration file.
The name of that file is canstack.xml, and it is searched for in the directories $BOOTHOME, $MODROOT, $INTROOT and $VLTROOT.
For each CAN network, one <Manager_Instance> block must be declared. Within each <Manager_Instance>, <Node_Instance> blocks describe attributes of the bus nodes. Please see [19] for a meaning of the individual keywords.
4.5 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:
· canioShowDevice("device name")
This command shows all properties of the installed device on the console.
If any of the procedures described above do not work as expected it may be useful to switch on the LCU debugging and tracing facility. This can be achieved by issuing the following commands to the VxWorks shell: LCU_debug and LCU_trace. Both functions should return the value 1.
Then execute the test procedures again and examine the debugging and tracing messages.
To switch the debugging and tracing facilities off just issue the corresponding commands again and this time they should return the value 0.
5 ERROR MESSAGES AND RECOVERY
5.1 Error Checking
The driver performs a number of checks that the correct conditions are fulfilled and reports an error if this is not the case. This section specifies the conditions the driver checks before or after the execution of a Ioctl control command.
An open request in exclusive read/write mode is rejected if the device is open to any other task 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 task in exclusive read/write mode.
An open request in test read/write mode is rejected if the device is open to any other task in test read/write mode.
The following list shows all possible errors which can be returned by the canio driver. There are three types of errors:
· errors from the canio driver ( these errors are identical to that acro and aio error messages, because the software interface is the same )
The errors are defined in canioErrors.h (canio specific errors with the prefix canio), canOpenErrors.h, canLibErrors.h (CAN specific errors with the prefix can) and in [8] (common errors with the prefix lcudrv). Errors corresponding to each function are depicted in the section 3.2.
The CANopen layer also performs a node guarding, where a task monitors the state of the device and looks for emergency messages. If an emergency message occurs, the device state changes to canOpenSTATE_STOPPED and writing or reading I/O signals is not possible anymore. In this case the utility canioShowDevice can be used to find out more about the emergency state. If the emergency state is OK, a connection or a power failure is probably the source of this problem. In any case, the system has to be rebooted to recover from these errors.
Note: Additional errors, not described here can be returned when the VxWorks I/O system rejects a call before invoking the driver.
5.1.1 Common Driver Errors
The following list shows common driver errors as defined in [8].
· lcudrvERROR_ACCESS_CONFLICT
The open mode conflicts with the open modes of already existing channels or the requested action is not allowed with this open mode.
· lcudrvERROR_TIMEOUT
The call is timed-out because access to the device was pending for longer than the driver timeout parameter.
5.1.2 aio specific Errors
5.1.3 acro specific Errors
5.1.4 CANopen specific Errors
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|