2 USER'S GUIDE

This chapter provides a functional description of the module: how to use it and what to use it for.

2.1 Overview

The VLT hardware shall be interfaced by software drivers and only be accessed through the software driver. The purpose of the driver is to provide a homogeneous interface between application software and the hardware. Another purpose of the driver is to control access of the hardware from different programs so that no conflicts arise.

The motor control software consists of two parts: a generalized motor control library containing hardware independent routines to:

controlling high level functions such as filter wheels, slits, guide probes etc.

The second part contains drivers controlling the process I/O boards used by the motor control library. Normally a motor controller is interfaced via a motion controller board and a power amplifier and sometimes also a special encoder interface board. Each of these boards will have its own driver for interfacing to application software.

The motion controller is not directly connected to the motor it shall control. There is a servo amplifier board supplying the current needed by the motor. This board also contains the velocity loop. The velocity feedback is given by a tachometer and the velocity loop can be optimized on this board by selecting and exchanging some discrete components. The servo amplifier board also makes it possible to set the velocity reference directly from the LCU processor and it is possible to connect a handset. The amplifier board and its connection to the controller is described in [6] and [7]

The MACCON controller can also be used with other types of servo amplifier boards. The figure on page 11 shows the configuration for the motor control concept.

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 [3].

One MAC4 can drive up to four axes. The four axes are in general independent of each other, but the command interface is partly common. However, each axis can be regarded as one device.

The interface to the MAC4 consists of a dual-ported RAM on the controller board with two queues for commands and replies, which are used for all axes controlled by the board. When a request for an axis is placed in the command queue, the controller will execute it. After completion a reply together with a return value is available in the reply queue. Some data can also be passed directly trough the dual-port memory.

The driver supports several MACCON motion controller boards in the same system. These devices share the same driver code and only have different sets of data (device descriptor tables).

The figure does not show the complete data flow between the different modules. The CPU can for example also send other commands to the motion controller and the servo amplifier and also read the status of the modules.

2.2 Driver Functions

This driver implements the functionality of the motion controller board, 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 conforms to the VxWorks driver concept, that is it supports the functions open, close, read, write and ioctl.

The open and close calls are used to specify or free a channel to get and regulate access to a 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 a 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.

All functions performed by the MACCON controller are activated with the ioctl call. The ioctl call has a parameter specifying the action requested by the driver. This parameter is in this document called ioctl control command. The ioctl control commands can be 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 shall not send any ioctl read or write command to the driver.

The driver controls the access of 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 task 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 task 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 task 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 tasks using the driver.

In addition, 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. This means that if a task is executing a driver call and another task tries to access the driver for the same resources, 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. 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 and task-deletion safety, see reference [3].

A task blocked for access of a device will have a timeout. The task could be waiting for access to the device when another task is already accessing it, or it could wait for the controller to finish executing a ioctl control command or returning a requested status or parameter.

Ioctl commands which are handled inside the driver or which are directly accessing a location in the controller's dual-port memory normally do not have any protection from simultaneous access as the command acts on task-private data or is executed in one non-interruptable instruction. In this case there is no need for any protection as no other task can interfere during the action. Section 5.2 defines for which Ioctl commands the access checks are performed.

2.3 Initialization Sequence

In order to make the Maccon controller operational, one could use the following initialization sequence. The listed command-literals are described in section 3.3.

The actual values for these parameters depend on the given hardware, and can therefore not be stated here.

3. Setup the parameter for the various modes (accelleration, deceleration, speed), unless the deaults listed in [2] are already appropriate for the application, e.g.:

6. There may be further parameters to initialize, this list does not contain all possible parameters. For specific controller-types (SSI and STP) are special parameters available, which are also not included in this list. Refer to section 3.3.

As an exception, where commands need an explicit activation or acknowledge, this is automatically appended by the driver.