MOOC Vacuum Documenation

Hardware Components

Overview

CIA Vacuum Cards

CIA Crate Controller

Digital Write Cycle:
1. Write data to the low byte of the data register.
2. Write module select, address, and cycle type to address register.
3. Poll the status register for DRDY or wait for DRDY interrupt.
4. Check status register for errors.

Digital Read Cycle:
1. Write module select, address, and cycle type to address register.
2. Poll the status register for DRDY or wait for DRDY interrupt.
3. Read the data register.
4. Check status register if error flag is set.

Analog Read Cycle:
1. Write module select, address, and cycle type to address register.
2. Poll the status register for DRDY or wait for DRDY interrupt.
3. Read the data register.
4. Check status register if error flag is set.

The datway controller holds its interrupt line active until the status register is read. The address and dataway write-data registers are locked while a dataway cycle is in progress. 

Front End

Software Components

Arcnet Communications

The VIOB needs to be configured based on the configuration of the crates the front end is communicating with. The configuration information need by the VIOB is the card type in each slot of each crate. This configuration information is stored in the static variable crateConfig, which is defined in the front end source code file viob_create.c. Therefore reconfiguring the VIOB requires a edit-compile-reboot cycle. The VIOB for each crate controller is configured dynamically using the static configuration information from the front end. When a crate controller boots it requests that the front end send it an expectation table which contains it its crate configuration. The VIOB uses unique integers to indentify board types in the expectation table. The controllers and the front end must agree on the correspondence between integers and board types. This correspondence is defined by the BOARD_TYPE enumeration in the boards.h header file. Both the front end and controller source code have a boards.h file, the definition of the BOARD_TYPE enumeration must be the same in both files. However, the boards.h files contain other differences which prevent using a single file for both the front end and crate controller software. Note that the enumeration constant ENDM is the number of board types; it does not correspond to a board type. The boards.h files and viob_create.c would needed to be edited if a new board type was to placed in a crate, otherwise reconfiguration only requires modifications to viob_create.c.

Due to the need to convert ion pump readings to engineering units the front-end must be configured with what conversions are to be applied to each ion pump channel. This configuration information is in mivdev.c which must be updated when the ion pump configuration is changed.

Each controller and the front end has a special section of memory, which holds values received over the VIOB and values to be transmitted over the VIOB. The format of this memory depends on the configuration but is otherwise static. That is, for a particular configuration the value at a particular offset in this memory will always be the value of a particular data item. On the front end one does not directly read or write this special memory, but instead uses the routines vset_data and vread_data, which sets or reads data items from this memory based on the calling arguments which specify crate, slot, channel, etc. On the crate controllers one directly accesses this special section of memory. The data items from each card occupy a contiguous section of this special memory both on the front end and on the crate controller for that card. The amount of memory depends on the card type. In order for the front end VIOB to know how much space a card uses it must know the total number of analog and digital readings, the number of digital settings, and the total number of status readings. This information is made available to the front end VIOB software via the static variable boards defined in boards.h. The controller software also needs to know how much memory each card type requires. The controller software file dwc.c has arrays which provide the software with the list of data items for each card type. From these arrays the number of data items can be computed. The global variable boards is then initialized with the computed values. Therefore, since the controllers and the front end come up with the number of data items for each card type independently, one must insure that the front end's boards array in boards.h is consistent with the arrays in the controller's dwc.c file.

CIA Crate Controller

The order of data items in dwc.c's data item arrays determines the association of each data item to a VIOB channel. The sequence of readings and settings is the same as in the arrays. The sequence of status values is the same as in the arrays with the digital setting statuses first and the reading statuses next. There is some special logic involved with the setting data items. So that a controller does not try to set a setting with an unintialized value from the the VIOB memory, a setting value must have its most-significant bit, the valid bit, set to indicate it has been initialized from the front end. In addition the controller will only set a setting if the value has changed or a reset bit of the setting is set. Which bits the controller considers to be reset bits is defined in dwc.c's data item arrays.

Front End