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 an ioctl control command.

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.

The driver performs the following sequence on a call of the ioctl() function. If a check fails or a timeout is exceeded, then the function is aborted and it returns an error:

1. Check if the command is known to the driver. Because the driver can be used with several controller version, this check does not necessarily mean that the command is supported by the controller.

2. Check the access rights for this command compared to the mode specified at open().

3. If the command is declared as `protected', then the driver tries to get exclusive access to the controller board, to ensure that no other task is executing any driver request on the same controller board. Steps 4 to 9 will then be executed exclusively by this task. The driver waits up to the specified timeout. Additionally a timer will be started to check the total command execution time. Up to four times the specified timeout value is allowed. However, this is only to check for a command-timeout condition and inform the caller, not to break the command on a timeout.

4. Then the command is put into the controller's command queue, if it is not full. This access is independently protected against simultaneous access by other tasks. Checks for legal parameter values are done by the controller, not by the driver.

5. The driver waits for the reply from the controller for the specified device, up to the specified timeout.

6. The reply is fetched from the controller's reply queue, which is again independently protected against simultaneous access by other tasks.

7. The reply is checked for error conditions which might be detected by the controller.

8. If the controller detected an error condition which has to be acknowledged, then an automatic CLEAR command is appended. This will also clear the error status flags of the controller.

9. If an automatic EXECUTE is requested for the command, then it will be issued now.

10. If the command is declared as `protected', then the driver releases the board-wide protection now and checks the timer for a timeout-condition.

11. Any values returned by the controller are passed to the caller.

5.2 Command-dependent Behaviour

Several `behaviour-flags' are defined for each command, which define ...

· if a task shall have mutual exclusive access to the controller board (`protected'). This is the case for all commands, except for:

· mconCMD_EMERGENCY_STOP

· mconCMD_WRITE_ENCODER_VALUE

· mconCMD_CONFIG_INTERRUPT_DRIVE_FAULT

· mconCMD_CONFIG_INTERRUPT_MOTION_END

· mconCMD_CONFIG_INTERRUPT_EMERGENCY_STOP

· mconCMD_GET_TIMEOUT_TICK

· mconCMD_READ_DRIVER_VERSION

· if an automatic EXECUTE shall be appended to the command in order to activate the changes immediately. This is the case only for:

· mconCMD_MODE_SPEED

· mconCMD_MODE_BRAKE

· mconCMD_MODE_POSITIONING

· mconCMD_MODE_HOME

· mconCMD_MODE_SEARCH_INDEX

· mconCMD_MODE_DISABLE_AXIS

· mconCMD_MODE_ENABLE_AXIS

· mconCMD_MODE_SEARCH_INDEX_COA_ADJUST

· mconCMD_POSITION_TRACKING

· mconCMD_SPEED_TRACKING

· mconCMD_MODE_FIND_EDGE

· mconCMD_FLY_MODE_ON

· mconCMD_FLY_MODE_OFF

· mconCMD_STP_TURBO_MODE

· mconCMD_SET_TEST_MODE

· if a command is executed by a special routine. This is true for commands which are handled completely inside the driver:

· mconCMD_READ_DRIVER_VERSION

· mconCMD_SET_TIMEOUT_TICK

· mconCMD_GET_TIMEOUT_TICK

· mconCMD_BLOCK_SEMAPHORE

· mconCMD_FREE_DEVICE

· mconCMD_CONFIG_INTERRUPT_DRIVE_FAULT

· mconCMD_CONFIG_INTERRUPT_MOTION_END

· mconCMD_CONFIG_INTERRUPT_EMERGENCY_STOP

and for commands which require special handling of the controller:

· mconCMD_RESET

· mconCMD_EMERGENCY_STOP

· mconCMD_WRITE_ENCODER_VALUE

· mconCMD_ENABLE_INTERRUPT_DRIVE_FAULT

· mconCMD_DISABLE_INTERRUPT_DRIVE_FAULT

· mconCMD_ENABLE_INTERRUPT_MOTION_END

· mconCMD_DISABLE_INTERRUPT_MOTION_END

· mconCMD_ENABLE_INTERRUPT_EMERGENCY_STOP

· mconCMD_DISABLE_INTERRUPT_EMERGENCY_STOP

· mconCMD_ENABLE_INTERRUPT_ANSWER_READY

These flags cannot be changed.

5.3 Hints for Error Recovery

· Limits:

The controller rejects a command if it would move the axis in positive direction and it is already on the upper software limit or on the upper hardware limit or if positive motion is inhibited or if it would move the axis in negative direction and it is already on the lower software limit or on the lower hardware limit or if negative motion is inhibited.
To go out of limit, enable the axis and move into the negative direction if the axis is on the upper limit, or in the positive direction if the axis is on the lower limit.

· Disabled axis:

The controller goes to the disable-mode, if one of the following events occurs:

· the axis reaches the hardware- or software-limit

· drive fault

· emergency stop

· maximum following error exceeded

· Change of mode:

The controller allows a change of mode only in enable-mode.

· Setting of controller-parameters:

Some parameters can only be set in specific modes. More information can be found in the controller manuals ([2]).

5.4 Error Messages

The following list shows all possible errors which can be returned by the mcon Driver. There are three types of errors:

· VxWorks system errors

· Errors from the common driver library lcudrv

· Errors from the mcon driver

The errors are shown in alphabetical order by their literals as defined in mconErrors.h (mcon specific errors with prefix mcon) and lcudrvErrors.h (common errors with prefix lcudrv) together with a description of their meaning and reason. Errors corresponding to each function are depicted in section 3.3.

Note: additional errors, not described here, can be returned when the VxWorks I/O system rejects a call before invoking the driver.

5.4.1 Common Driver Errors

The following list shows all common driver errors as defined in [10].

· 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_CHANNEL_NOT_OPEN
The requested channel is not open.

· lcudrvERROR_DEVICE_EXISTS
Attempt to create an already existing device a further time.

· lcudrvERROR_DRIVER_EXISTS
Attempt to install an already existing driver a further time.

· lcudrvERROR_INVALID_ARGUMENT
The value of one of the arguments was not in a valid range.

· lcudrvERROR_INVALID_COMMAND
The ioctl command code matches no valid command.

· lcudrvERROR_INVALID_DEVICE
The device name does not specify a valid device.

· lcudrvERROR_INVALID_OPEN_MODE
The requested open mode is unknown.

· lcudrvERROR_NO_CHANNEL
No more channel to a device can be opened.

· lcudrvERROR_NO_DRIVER
Attempt to create a device without having the driver installed yet.

· lcudrvERROR_NO_MEMORY
Not enough memory available to allocate internal data structures.

· lcudrvERROR_NO_SEMAPHORE
Failed to create the access protection semaphore.

· lcudrvERROR_TIMEOUT
The call is timed-out because access to the device was pending for longer than the driver timeout parameter.

5.4.2 MCON Specific Errors

· mconERROR_COMMAND_TIMEOUT
Timeout on command execution. The driver internal watchdog timer has detected that the execution time of a command exceeded the pre-defined limit. However, the command has not been cancelled by the driver.

· mconERROR_NO_EXCLUSIVE
The device specified was not opened in exclusive mode.

· mconERROR_NO_REPLY
Failed to read reply from the controller reply-queue, although the controller indicated via interrupt that a reply is available.

· mconERROR_QUEUE_FULL
failed to send command to the controller because the controller's command queue was full.

· mconERROR_STATUS_COMM
Controller detected a communication error, i.e. a controller watchdog timeout.

· mconERROR_STATUS_DRIVE_FAULT
The controller detected that the drive-fault signal is active (e.g. amplifier not in normal-mode)

· mconERROR_STATUS_ENCODER_FAULT
Controller detected that the read encoder value was out of limits.

· mconERROR_STATUS_FOLLOWING_ERROR
Controller detected that the maximum following error was exceeded.

· mconERROR_STATUS_INVALID_AXIS
Controller detected invalid axis number.

· mconERROR_STATUS_PARAM_RANGE
controller detected invalid parameter, e.g. value/position out of limits.

· mconERROR_STATUS_SYNTAX
Controller detected invalid command number.

· mconERROR_STATUS_UNEXP_COMMAND
Controller detected unexpected command, e.g. wrong sequence in initialisation.

· mconERROR_START_TIMER
Cannot start the VxWorks watchdog timer to check for command timeout.

· mconERROR_STOP_TIMER
Cannot cancel the currently running VxWorks watchdog timer.

· mconERROR_SYNC_TIMEOUT
Timeout on waiting for the controller's reply to a command. That means that no interrupt was given by the controller within the specified timeout. This is a severe error because the reply-queue can get into an inconsistent state. When the controller actually gives the reply at later time, a `dead' reply entry is in the queue which will confuse the driver. This situation can only be solved by the command mconCMD_FLUSH_QUEUE. When switching the `On-Fly' mode off, the timeout-value should be high enough, otherwise this error will occur.

· mconERROR_WRONG_REPLY
Reply contains not the same axis number or command code as the command had (maybe interrupt vectors are not properly assigned). This error could also indicate that the reply-queue is corrupted because of a mconERROR_SYNC_TIMEOUT or any other unknown reason.

Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com