Jennifer Dunn , Angelic Ebbers

assemblyControl/02

This document describes the assemblyControl record created by the Herzberg Institute of Astrophysics.

Introduction

This document describes the assemblyControl record created by the Herzberg Institute of Astrophysics team for integrated control of the deviceControl record See deviceControl Record Reference Manual (deviceControl/01), William Rambold that controls DC and Stepper Motors. This design is expected to evolve as the development of the record proceeds.

Scope

This document defines the interface to the assemblyControl record only. For a list of EPICS records created by and for the GEMINI project see the Gemini Record Reference Manual See Gemini Record Reference Manual (spe-c-g0070/02), Bret Goodrich and Andy Foster. For a complete list of the standard EPICS records, and a description of the field summary tables, refer to the EPICS Input Output Controller Record Reference Manual See EPICS Input Output Controller Record Reference Manual, Janet B. Anderson and Martin R. Kraimer, Argonne National Laboratory, Dec 1, 1994..

Definitions

Following are some broad definitions of concepts used throughout this manual:

Assembly: An assembly is a collection of devices that must work together to perform a specific instrument function. The assemblyControl record abstracts the actual details of assembly operation from higher level control layers. The record support level interactions are standard for all assemblyControl records while the details of assembly operation are implemented in a custom device support layer.

Device: A single moving component in an assembly. It is controlled by a deviceControl record.

References

EPICS Input Output Controller Record Reference Manual, Janet B. Anderson and Martin R. Kraimer, Argonne National Laboratory, Dec 1, 1994.
ICD 1b The Baseline Attribute/Value Interface (gscg.grp.024/04), Kim Gillies, Steve Wampler, Bret Goodrich.
Gemini Record Reference Manual (spe-c-g0070/02), Bret Goodrich and Andy Foster
deviceControl Record Reference Manual (deviceControl/01), William Rambold

Revisions

Version 01, January, 1999. Document Created.

Version 1.1, April, 1999.

Overview

The section to follow is a record overview which includes a field summary for the record and configuration instructions for the record. The next section will detail the operation of the record. Next are the typical scenario's of the a record and finally details of the support modules that make up this record.

Record Overview

An assembly provides a method of coordinating the actions of one or more devices in a synchronous or asynchronous manner. The devices are controlled and represented by the deviceControl record, and the assembly will be controlled and represented via the assemblyControl record. This document describes the design of the assemblyControl record.

The assemblyControl record communicates directly with the deviceControl record(s) via custom device support and at the database level. The deviceControl record is defined in See deviceControl Record Reference Manual (deviceControl/01), William Rambold.

For any record type there are record and device support modules. The record support module will handle all record specific details that are common for all assemblies. The device support module must be configured for the needs of each individual assembly.

General features of the assemblyControl record include:

Take as input up to 5 different attribute values of variable data type with configurable high and low limits.
Allow up to 5 different deviceControl records to be connected.
Control and read up to 5 sensors.
Independent control of each device's position and velocity for the individual deviceControl records.
Validation of input parameters.
Full error and exception handling and reporting.
Built-in simulation modes.
Built in debugging modes.
Similar CAD/CAR interface values.

Possible inputs are:

Directives (DIR) are: CLEAR, MARK, PRESET, START and STOP.
Returned values (VAL) are: VAL_ACCEPT, and VAL_REJECT.
Command responses (BUSY) are: IDLE, ERR, and BUSY.
Modes are: INIT, MOVE, TRACK, INDEX, TEST, PARK, CHAR
Simulation levels are: NONE, VSM, FAST, FULL
Debug levels are: NONE, MIN, FULL

Any errors detected in the above will generate a diagnostic message explaining what happened.

Field Summary

Assembly Control Record

assemblyControl Record

See Assembly Control Record shows the assemblyControl record fields available from a configuration tool (e.g. CAPFAST). See assemblyControl Record States is a diagram of possible states that the assemblyControl record can enter.

assemblyControl Record States

See assemblyControl Record Field Summary is a summary of fields for the record instance. All of these fields, plus additional standard fields (see See Additional Standard Record Fields) defines the record structure that is accessed via the module code. The field, brief description and type are included. Column 4 (DCT) indicates if the field will appear in a configuration tool, column 6 (Access) indicates if the field can be read, column 7 (Modify) indicates if a field can be written to, column 8 (Rec Proc Monitor) indicates if the field can raise a monitor, and column 9 (PP) indicates that changes to the field cause the record to be processed if set to Yes.

A few notes about some of the fields:

Arrays are not supported for A-E at this time.
DBGL field is expected to be fed into a fanout record and then to each deviceControl record. It is also expected that whatever connects to this assemblyControl record puts the debug level into the DBUG field. The same goes for the SIMM and SIML fields. The default is a debug and simulation level of NONE.
Connections to the deviceControl record are:
output to deviceControl Records are: ODR1-ODR5, MOD1-MOD5, POS1-POS5 and optionally to the sensors out, SOR-SOV.
input from deviceControl Records are: ACK1-ACK5, BUS1-BUS and optionally from the sensors in, SIJ-SIN

assemblyControl Record Field Summary
Field	Desc	Type	DCT	Initial	Access	Modify	Rec Proc Monitor	PP
AAHL	Attr A High Limit	FLOAT	No	0	Yes	Yes	No	No
AALL	Attr A Low Limit	FLOAT	No	0	Yes	Yes	No	No
ABHL	Attr B High Limit	FLOAT	No	0	Yes	Yes	No	No
ABLL	Attr B Low Limit	FLOAT	No	0	Yes	Yes	No	No
ACHL	Attr C High Limit	FLOAT	No	0	Yes	Yes	No	No
ACK1	Command Stat from dev. 1	INLINK	Yes	0	No	No	Yes	No
ACK2	Command Stat from dev. 2	INLINK	Yes	0	No	No	Yes	No
ACK3	Command Stat from dev. 3	INLINK	Yes	0	No	No	Yes	No
ACK4	Command Stat from dev. 4	INLINK	Yes	0	No	No	Yes	No
ACK5	Command Stat from dev. 5	INLINK	Yes	0	No	No	Yes	No
ACLL	Attr C Low Limit	GLBCHOICE	No	0	Yes	Yes	No	No
ADEL	Archive Deadband	FLOAT	No	0	No	No	No	No
ADHL	Attr D High Limit	GLBCHOICE	No	0	Yes	Yes	No	No
ADLL	Attr D Low Limit	GLBCHOICE	No	0	Yes	Yes	No	No
AEHL	Attr EHigh Limit	GLBCHOICE	No	0	Yes	Yes	No	No
AELL	Attr ELow Limit	GLBCHOICE	No	0	Yes	Yes	No	No
ASTA	Assembly Rec State	RECCHOICE	Yes	0	Yes	Yes	Yes	No
A	Attribute A	NOACCESS	Yes	0	Yes	Yes	Yes	No
B	Attribute B	NOACCESS	Yes	0	Yes	Yes	Yes	No
C	Attribute C	NOACCESS	Yes	0	Yes	Yes	Yes	No
D	Attribute D	NOACCESS	Yes	0	Yes	Yes	Yes	No
E	Attribute E	NOACCESS	Yes	0	Yes	Yes	Yes	No
BSYL	Busy Link	OUTLINK	No	0	Yes	No	No	No
BUS1	Device Action from dev. 1	SHORT	Yes	0	Yes	Yes	Yes	Yes
BUS2	Device Action from dev. 2	SHORT	Yes	0	Yes	Yes	Yes	Yes
BUS3	Device Action from dev. 3	SHORT	Yes	0	Yes	Yes	Yes	Yes
BUS4	Device Action from dev. 4	SHORT	Yes	0	Yes	Yes	Yes	Yes
BUS5	Device Action from dev. 5	SHORT	Yes	0	Yes	Yes	Yes	Yes
BUSY	Action State	RECCHOICE	No	0	Yes	Yes	Yes	No
DBGL	Debug Link	OUTLINK	Yes	0	No	No	No	No
DBUG	Debug Mode	RECCHOICE	Yes	0	Yes	Yes	No	No
DIR	Directive	RECCHOICE	Yes	0	Yes	Yes	Yes	Yes
ODR1	Directive to dev 1	OUTLINK	Yes	0	No	No	Yes	No
ODR2	Directive to dev 2	OUTLINK	Yes	0	No	No	Yes	No
ODR3	Directive to dev 3	OUTLINK	Yes	0	No	No	Yes	No
ODR4	Directive to dev 4	OUTLINK	Yes	0	No	No	Yes	No
ODR5	Directive to dev 5	OUTLINK	Yes	0	No	No	Yes	No
EGU	Engineering Units	CHAR	No	0	Yes	Yes	No	No
FTA	Attr A Data Type	GLBCHOICE	No	0	Yes	Yes	No	No
FTB	Attr B Data Type	GLBCHOICE	No	0	Yes	Yes	No	No
FTC	Attr Data Type	GLBCHOICE	No	0	Yes	Yes	No	No
FTD	Attr D Data Type	GLBCHOICE	No	0	Yes	Yes	No	No
FTE	Attr E Data Type	GLBCHOICE	No	0	Yes	Yes	No	No
FTSJ	Sensor In data type for J	GLBCHOICE	No	0	Yes	Yes	No	No
FTSK	Sensor In data type for K	GLBCHOICE	No	0	Yes	Yes	No	No
FTSL	Sensor In data type for L	GLBCHOICE	No	0	Yes	Yes	No	No
FTSM	Sensor In data type for M	GLBCHOICE	No	0	Yes	Yes	No	No
FTSN	Sensor In data type for N	GLBCHOICE	No	0	Yes	Yes	No	No
FTSR	Sensor Out data type for R	GLBCHOICE	No	0	Yes	Yes	No	No
FTSS	Sensor Out data type for S	GLBCHOICE	No	0	Yes	Yes	No	No
FTST	Sensor Out data type for T	GLBCHOICE	No	0	Yes	Yes	No	No
FTSU	Sensor Out data type for U	GLBCHOICE	No	0	Yes	Yes	No	No
FTSV	Sensor Out data type for V	GLBCHOISE	No	0	Yes	Yes	No	No
HHSV	HiHi Severity	GBLCHOICE	No	0	No	No	Yes	No
HIGH	High Alarm Limit	FLOAT	No	0	No	No	Yes	No
HIHI	Hihi Alarm Limit	FLOAT	No	0	No	No	Yes	No
HLSV	HW Limit Violation Svr	GBLCHOICE	No	0	No	No	Yes	No
HLTH	Health	RECCHOICE	Yes	0	Yes	Yes	No	No
HSV	High Severity	GBLCHOICE	No	0	No	No	Yes	No
ILCK	Interlock Fault	SHORT	Yes	0	Yes	Yes	Yes	Yes
INDX	Is assembly indexed	SHORT	Yes	0	Yes	No	No	No
INIT	Is assembly initialized	SHORT	Yes	0	Yes	No	No	No
LLSV	Lolo Severity	GBLCHOICE	No	0	No	No	Yes	No
LOLO	Lolo Alarm Limit	FLOAT	No	0	No	No	Yes	No
LOW	Low Alarm Limit	FLOAT	No	0	No	No	Yes	No
LSV	Low Severity	GBLCHOICE	No	0	No	No	Yes	No
LTHP	Lookup Table Ptr	NOACCESS	No	0	Yes	No	No	No
MDEL	Monitor Deadband	FLOAT	No	0	No	No	Yes	No
MESS	Message	STRING	Yes	-	Yes	Yes	Yes	No
MOD1	Oper. Mode to dev 1	OUTLINK	Yes	0	No	No	No	No
MOD2	Oper. Mode to dev 2	OUTLINK	Yes	0	No	No	No	No
MOD3	Oper. Mode to dev 3	OUTLINK	Yes	0	No	No	No	No
MOD4	Oper. Mode to dev 4	OUTLINK	Yes	0	No	No	No	No
MOD5	Oper. Mode to dev 5	OUTLINK	Yes	0	No	No	No	No
MODE	Operating Mode	RECCHOICE	Yes	0	Yes	Yes	Yes	No
MSGL	Error Msg Link	OUTLINK	No	0	Yes	No	No	No
NMDV	Number of dev attached	SHORT	No	0	Yes	Yes	No	No
PARK	Is assembly in park	SHORT	Yes	0	Yes	No	No	No
POS1	Position to dev 1	OUTLINK	Yes	0	No	No	Yes	No
POS2	Position to dev 2	OUTLINK	Yes	0	No	No	Yes	No
POS3	Position to dev 3	OUTLINK	Yes	0	No	No	Yes	No
POS4	Position to dev 4	OUTLINK	Yes	0	No	No	Yes	No
POS5	Position to dev 5	OUTLINK	Yes	0	No	No	Yes	No
PP	Post process command	SHORT	No	0	Yes	Yes	No	No
PREC	Display precision	SHORT	No	0	Yes	Yes	No	No
SIJ	Sensor In for J	NOACCESS	Yes	0	Yes	Yes	No	No
SIK	Sensor In for K	NOACCESS	Yes	0	Yes	Yes	No	No
SIL	Sensor In for L	NOACCESS	Yes	0	Yes	Yes	No	No
SIM	Sensor In for M	NOACCESS	Yes	0	Yes	Yes	No	No
SIML	SIML	OUTLINK	Yes	0	No	No	No	No
SIMM	SIMM	RECCHOICE	Yes	0	Yes	Yes	No	No
SIN	Sensor In for N	NOACCESS	Yes	0	Yes	Yes	No	No
SOR	Sensor Out for R	NOACCESS	Yes	0	Yes	No	No	No
SOS	Sensor Out for S	NOACCESS	Yes	0	Yes	No	No	No
SOT	Sensor Out for T	NOACCESS	Yes	0	Yes	No	No	No
SOU	Sensor Out for U	NOACCESS	Yes	0	Yes	No	No	No
SOV	Sensor Out for V	NOACCESS	Yes	0	Yes	No	No	No
TDIR	Translation Directory	STRING	No	-	Yes	Yes	No	No
TFIL	Translation File Name	STRING	No	-	Yes	Yes	No	No
VAL	Response to Command Request	RECCHOICE	Yes	0	Yes	No	Yes	No
VALA	Output attrib A	GLBCHOICE	Yes	0	Yes	No	Yes	No
VALB	Output attrib B	GLBCHOICE	Yes	0	Yes	No	Yes	No
VALC	Output attrib C	GLBCHOICE	Yes	0	Yes	No	Yes	No
VALD	Output attrib D	GLBCHOICE	Yes	0	Yes	No	Yes	No
VALE	Output attrib E	GLBCHOICE	Yes	0	Yes	No	Yes	No
VEL1	Velocity for dev 1	OUTLINK	Yes	0	No	No	Yes	No
VEL2	Velocity for dev 2	OUTLINK	Yes	0	No	No	Yes	No
VEL3	Velocity for dev 3	OUTLINK	Yes	0	No	No	Yes	No
VEL4	Velocity for dev 4	OUTLINK	Yes	0	No	No	Yes	No
VEL5	Velocity for dev 5	OUTLINK	Yes	0	No	No	Yes	No
VERS	Code Version	STRING	No	0.1	Yes	No	No	No

Additional Standard Record Fields
Field	Type	Description
General Record Fields
name	char[]	Name of record instance
desc	char[]	Descriptor
asg	char[]	Access Security Group
scan	ushort	Scan Mechanism
pini	ushart	Process at oicInit
phas	short	Scan phase
evnt	short	Event Number
tse	short	Time Stamp Event
tsel	struct link	Time Stamp Link
dtyp	ushort	DeviceType
disv	short	Disable Value
disa	short	Disabled
sdis	struct link	Scanning Disable
mlok	FAST_LOCK	Monitor fastlock
mlis	ELLLIST	Monitor List
disp	uchar	Disabled putField
proc	uchar	Force Processing
stat	ushort	Alarm Status
sevr	ushort	Alarm Severity
nsta	ushort	New Alarm Status
nsev	ushort	New Alarm Severity
acks	ushort	Alarm Ack Severity
ackt	ushort	Alarm Ack Transient
diss	ushort	Disable Alarm Severity
lset	short	Lock Set
lcnt	uchar	Lock Count
pact	uchar	Record active
putf	uchar	dbPutField process
rpro	uchar	Reprocess
asp	void*	Access Security Pvt
ppn	void *	addr of PUTNOTIFY
ppnn	void *	next record PUTNOTIFY
spvt	void *	Scan Private
rset	void	Address of RSET
dset	struct deset *	DSET address
dpvt	void *	Device Private
prio	ushort	Scheduling Priority
tprio	uchar	Trace Processing
bkpt	char	Break Point
udf	uchar	Undefined
time	TS_STAMP	Time
flnk	struct link	Forward Processing Line

Configuration

Each assemblyControl record must have device support code written for it. The functions that need to be written are shown in See Function List under "Device Support Module Function List.". Each assembly will have different functions and needs. For example, an assemblyControl record may be controlling 2 motors (via the deviceControl record), that can act independently, which means they can both be told to move at the same time or sequentially with the second waiting for the first to complete. Configuration of the custom device support code is indicated through the `DTYP' field in the record.

assemblyControl Record Operations

assemblyControl record operation is controlled by the DIR and MODE and can use any and/or all of the input attribute fields (A-E) and input sensor fields (SIJ-SIN). In normal operation, attribute parameters are written to the appropriate fields and the START directive is issued to begin execution of the command. If a sequence involving more than one assembly is being prepared it will be possible to check the validity of the attribute information via the PRESET directive for all assemblies prior to starting the motions. If there are no changes in the attribute fields, then the MARK directive must be issued prior to any PRESET, START or STOP directive being issued. Any operation can be halted, at the next reasonable interrupt point, via the STOP directive. Though these attributes are interpreted, it is up to the custom assemblyControl code in the device support package to implement them. This section will discuss generally the DIR and MODE fields and their proposed functions.

The DIR field

Commands to the attached devices are sent via the DIR fieldSee ICD 1b The Baseline Attribute/Value Interface (gscg.grp.024/04), Kim Gillies, Steve Wampler, Bret Goodrich.. Possible values are STOP, MARK, CLEAR, PRESET and START. The following section details each. The general sequence of events are:

While a command is being processed the BUSY field is set to BUSY.
When a command has completed the BUSY field is set either to IDLE (if all went well) or ERR (if something went wrong).
In some cases, a command in progress can be updated with new information as described in See assemblyControl Record States.
A directive that requires no asynchronous processing (such as a STOP when the device is already idle) will be acknowledged by setting the BUSY field to BUSY for a short period of time then returning it to IDLE.

STOP

This directive terminates a command in progress. The record support routine simply calls the device support routine: stopDirective(). The following is a suggestion of what the device support should do.

The directive should be passed on to any attached devices which will be stopped in a controlled manner. (For example: Consider a case with multiple devices attached which are controlled asynchronously. If the devices are currently executing a "MOVE" command and 2 of the 5 have completed, then the remaining 3 would be sent to the STOP command. Once all 3 devices have set their BUS* field to IDLE or ERR, then the BUSY field will be set to IDLE.) The STOP directive should simply be acknowledged if the attached devices are not currently executing a command.

MARK

This directive indicates that, should the PRESET/START/STOP directive be issued, functions should be executed. If there is no change in attributes A-E, or the MARK directive has not be issued, then the PRESET/START/STOP directive will be ignored.

CLEAR

This clears the mark directive, thereby cancelling an execution enable.

PRESET

This directive validates all of the input attribute fields by calling the device support routine checkAttributes(). CheckAttributes() returns a success or failure which the record support code handles as follows:

The ACK field should be cleared if all arguments are within limits and it is safe to start or update a command.
If the command is rejected a diagnostic message appears in the MESS field to explain why.
The PRESET directive does not affect the state of the record BUSY field, only the VAL field.

START

This directive either starts a new command action or updates the control parameters for a command in progress. All input attribute fields are validated prior to executing the command (see See PRESET, See PRESET). If it is safe to proceed the record is set to BUSY and the control information is processed according to the MODE selected. The record will remain BUSY until either the command has completed or an error is encountered. A timer may be used to deal with the completion of each device and ultimately the entire command. A timeout is used to catch when a device has not completed within a specific time, which may indicate a problem with the device.

The MODE field

When a START directive has been received, the operating mode field is consulted to determine how to process the command.

INIT

Initialize the assemblyControl record. The record support routine will:

ensure the record is currently idle
reset internal variables
call the device support routine initMode()

The device support routine, initMode(), should consists of:

Issuing the INIT command to all devices.
Re-load any translation table information.

The INIT command should be rejected if any device is currently in motion. That means a STOP directive should be issued prior to doing an INIT. Also, an INIT does not automatically perform an INDEX command.

MOVE/PARK

The MOVE command calls for synchronous or asynchronous movement of the attached devices. A new MOVE command can be issued while a MOVE command is currently active. The PARK command is a specialized move command to a device dependant safe storage position. The record support routine will:

Ensure current state is IDLE, TRACKING or MOVING

The device support routine called is moveMode(). The general sequence of events is:

If a command is currently active, the active flag is set to false and the command timer is stopped.
The device finished flag is cleared for each attached device. As each device completes the device finished flag is set for it.
POS1-5, MO1-5 and ODR1-5 are set according to translations made in the validation routine. The order and completion of the commands is dependent on the assemblyControl records device support code.
A timer may be used to deal with the completion of each device and ultimately the entire command. (see startTimer() and stopTimer()).

Any command that involves moving of a device (MOVE, PARK, TRACK, INDEX, STOP) cannot be interrupted and have the simulation mode changed. For example, if currently performing a MOVE command, the assemblyControl record cannot be put into VSM simulate mode and then receive a STOP.

TRACK

TRACK mode calls for devices to be powered up, unlocked, moved to a position and remain powered on. This mode is useful when the device must follow a series of target positions with the minimum delay. A new TRACK command can be issued while the device is still in motion and will be acted upon immediately. A track command is meant to be executed quickly and should involve no limit checking or translation of input attributes. The sequence of events is similar to MOVE and not repeated here. The device support routine called is trackMode().

INDEX

In INDEX mode all devices are sent to find their home or reference point. The general sequence of events is essential the same as MOVE and will not be repeated here. The device support routine called is indexMode().

TEST

In TEST mode, all devices should be tested, and a check is made to see if the lookup table pointer is valid. This should be enough to indicate that the assembly is in good working order. The device routine called is testMode().

UPDATE

This mode is used for assemblies that require characterization of some sort (e.g. masks, filters). In all other cases it will perform no operation. The bulk of this routine will be contained within the device support modules. The device support routine called is updateMode().

Scenarios

The following section describes typical scenarios and the sequence of events that occur to handle the events. All functions/routines are listed in See Function List and the record support entries are detailed in See Support Entry Tables. See Scenario's lists all scenario's shown in the remainder of this section. Each scenario will include a brief description and then show the sequence of events that will occur to process the events. Please note that the device support code is described is in a VERY general sense as this code will be unique for each instance of the assemblyControl record. Only typical examples are given.

Function List
Function Name	Function Description
Record Support Module Function List
alarm()	Raise an alarm.
busyReceivedFromDevice()	Response to a change in BUSY from a device.
commandFinish()	Set status for a complete command.
cvtDbaddr()	Called when dbNameToAddr() is called.
executeState()	Execute a generic command.
getAlarmDouble()	Returns alarm information for a field.
getControlDouble()	Returns control related information for a field.
getGraphicsDouble()	Returns graphics information for a field.
getPrecision()	Returns the precision for display purposes.
getUnits()	Return engineering units for display purposes.
getValue()	Return current value.
idleState()	Change state to idle.
initDevLinks()	Initialize device record links.
initFields()	Initialize fields that require allocs.
initLinks()	Initialize input and output links.
initRecord()	Initialize an instance of the assemblyControl record.
initTimer()	Initialize timer functions.
linkSet()	Generic initialization of passed in links.
monitor()	Raise monitor on selected record fields.
process()	Process the assemblyControl record.
processDirective()	Process the current directive.
processFault()	Process an interlock fault occurring.
processState()	Process a change in state.
readInputLinks()	Read values from input links.
setFields()	Set room for field values.
setFlags()	Set output flags.
special()	Special processing due to changes of an input value.
startTimer()	Start the timer.
stoppingState()	Execute a stop of a command.
stopTimer()	Stop timer.
unsetFlags()	Unset output flags.
writeOutputLinks()	Write values to output links.
Device Support Module Function List
ackReceived()	Deal with a change in BUSY from a device.
checkAttributes()	Check input variables.
devInit()	Initialize record type.
indexMode()	Handle an INDEX command.
initDeviceSupport()	Initialization of device support code.
initMode()	Handle an INIT command.
moveMode()	Handle a MOVE or PARK command.
stopDirective()	Handle a STOP directive.
testMode()	Handle a TEST command.
trackMode()	Handle a TRACK command.
updateMode()	Handle an UPDATE command.
Task Function List
timerCallback	Task to handle the timing of events.

Initialization of the Record Type assemblyControl

Scenario's
Scenario Number	Description
ac001	Initialization of the record type assemblyControl
ac002	Initialization of a single instance of the assemblyControl record.
ac003	DIR command of MARK received.
ac004	DIR command of PRESET received.
ac005	DIR command of START received with device attached
ac006	Acknowledgement received from deviceControl record
ac007	MODE of INIT received
ac008	MODE of MOVE while TRACKING received
ac009	MODE of INDEX received
ac010	MODE of TEST received
ac011	MODE of UPDATE received
ac012	Invalid MODE received while MOVING
ac013	Timeout of a command.
ac014	deviceControl record returns an Error
ac015	Interlock occurs.

ac001 - Initialization of the record type assemblyControl.

Initialization of the record type assemblyControl. This will only be executed once at startup of the IOC.

ac002 - Record Initialization

This shows the sequence of events to occur upon initialization of a single instance of the assemblyControl record. This will initialize links and watchdog timer and the device support code. If successful, then the state of the assemblyControl record is IDLE.

ac003 - DIR command of MARK received

In this scenario the DIR directive of MARK is received. This record must be MARKED before further changes in the directive (e.g. to PRESET or START), are acted upon. Any changes in the attributes A-E will also cause the record to be marked.

ac004 - DIR command of PRESET received

In this scenario the DIR directive has been changed to PRESET. A check of all input attributes will occur. Possible input attributes are MODE, A-E and the sensors SIJ-SIN. The actual checking of these fields it assembly dependent and could involve translation of the attributes to a named position and velocity. The VAL field will reflect the success or failure of this directive. Upon error, a message will also be supplied.

ac005 - DIR command of START received with devices attached

There is an assemblyControl record with 1 to 5 deviceControl records attached. The assemblyControl record receives a directive of START. The individual MODE's will execute different code and are shown in the proceeding sections, just the general receipt of the command is shown here. The directive, mode, position and potentially velocity are passed on to the devices. This assemblyControl record will set its BUSY field to BUSY and not complete until all device records have indicated that they are complete or one of them return an error.

ac006 - Acknowledgment Received from deviceControl Record

In See ac005 - DIR command of START received with devices attached, a command has been passed on to a deviceControl record(s). This scenario details what happens when one of the attached deviceControl records makes a change in their BUS* field that is attached to this assemblyControl record.

ac007 - MODE of INIT received

This scenario details the portion of See ac005 - DIR command of START received with devices attached that has the label "dependent on MODE". For this example the assemblyControl record is currently in an IDLE state and an INIT command is received. Input attributes have already been checked and the device support code initMode() is expected to pass the directive, mode, position and potential velocity on to the attached deviceControl record. A timer should be started to indicate when a command has taken too long to complete by the attached deviceControl records. If the timer runs out before all devices have responded to the command, then an associated error should be generated and the BUSY state changed to ERR.

ac008 - MODE to MOVE while TRACKING received

This scenario will not have an event trace as it is identical to "See ac007 - MODE of INIT received", except that the routine "initMode" is replaced by "moveMode".

ac009 - MODE of INDEX received

This scenario will not have an event trace as it is identical to "See ac007 - MODE of INIT received", except that the routine "initMode" is replaced by "indexMode".

ac010 - MODE of TEST received

This scenario will not have an event trace as it is identical to "See ac007 - MODE of INIT received", except that the routine "initMode" is replaced by "testMode".

ac011 - MODE of UPDATE received

This scenario will not have an event trace as it is identical to "See ac007 - MODE of INIT received", except that the routine "initMode" is replaced by "updateMode".

ac0012 - Invalid MODE received while MOVING

In this scenario the assemblyControl record has started a directive of START and mode of MOVE. The command has not completed, as indicated by the BUSY field indicating BUSY. The directive of PRESET is given with a MODE of TEST. Since the BUSY field does not indicate IDLE or ERR, the VAL field is set to "VAL_REJECT" in response to this request.

ac013 - Timeout of a command

In this scenario the assemblyControl record has previously started a MOVE command, and started a timer. This time is the maximum amount of time allowed for the deviceControl records to complete the command. In this scenario, that time has reached and the record will indicate failure to complete the command.

ac014 - deviceControl Record returns an Error

This scenario assumes there are 2 deviceControl records connected to an assemblyControl record. The assemblyControl record has passed on a MOVE command to the 2 device records. If the first device record responds with an ERR then the command is considered to be complete, regardless of the response of the second deviceControl record.

ac015 - Interlock Occurs

An interlock switch is set high. This will causes any current movement to stop immediately. The only case this is ignored is if currently simulating.

Support Entry Tables

The following sections will define the support routines for both the record and device support modules and then describe the function algorithm. All functions have been listed in See Function List.

Record Support Entries

The record support routine, as defined by assemblyControlRSET, is the same for every record of this type. The associated functions are:

report (Not defined),
initialize (Not defined),
initRecord (See init_record),
process (See process),
special (See special),
getValue (See getValue),
cvtDbaddr (See cvtDbaddr),
getArrayInfo, (Not defined),
putArrayInfo (Not defined),
getUnits (See getUnits),
getPrecision (See getPrecision),
getEnumStr (Not defined),
getEnumStrs (Not defined),
putEnumStr (Not defined),
getGraphicDouble (See getGraphicsDouble),
getControlDouble (See getControlDouble),
getAlarmDouble (See getAlarmDouble)

Only these functions and a few additional ones are described here, as the rest are considered trivial.

init_record

This routine is called twice at iocInit. On the first call it returns immediately. On the second call, it does the following:

Check for the device support entry table and associated functions.
Initialize any database links.
Count the number of deviceControl records are connected via the input/output links.
Create an internal private structure and attached it to the record's device private field.
Initialize required variables.
If present, then initialize the device support code.

special

This routine is called for user specified fields. This routine is called twice, before and after any changes are made for the associated field. On the first call it returns immediately. After the value changes of

the fault status (FLT),
any of the device busy fields (BUS1-BUS5),

A change in device busy fields causes the record to call the record support routine busyReceivedFromDevice(). ( See busyReceivedFromDevice).

process

The most important record support routine is process. It determines what record processing means. Before calling this routine it is determined if the record is enabled and not currently active, then the following algorithm is processed:

Set PACT to TRUE.
If the processing was caused by an external command such as a change in:
the fault status (FLT) then call faultProcessing (See processFault);
the command timed out (See busyReceivedFromDevice),
else the processing was due to a directive change, so process the directive command request (See processDirective);
In all cases:
Write selected output links
Trigger selected monitors
Raise alarms.
If command is finished save processing time and trigger forward link
Clear PACT field.

Following are descriptions of routines called from within process:

processFault

The following will occur if a fault occurred:

If current state is not IDLE and we are not in a simulate mode then
Stop what we are doing, by calling device support routine stopDirective(), and set internal fault flag
Set health to BAD, and current state to ERR and unset fields INDEX, INIT and PARK.
Please note that once a FLT occurs the only possible directives accepted are STOP and START with MODES of INIT, INDEX, and TEST. The only case where a fault is ignored is in simulate mode of VSM.

busyReceivedFromDevice

The following will occur if there was a change in BUS1-5:

Set some internal flags.
Call the device support module (See ackReceived)

processDirective

This function will process directive commands, which include: START, MARK, PRESET, CLEAR and STOP. The START command will have an associated MODE which has possible values of: INIT, MOVE, TRACK, INDEX, TEST, UPDATE, and PARK.

This function will:

Clear the error message field
If our current state if not IDLE or ERR, return a failure to process the directive otherwise set our BUSY output to BUSY. The exception to this is:

-If currently tracking and are given another tracking command or a move command,

-If currently moving and get another moving command.

-If the directive is STOP.

If our current simulation level is VSM then toggle the BUSY and ASTA field and return.
Read the input links;
For Directive of CHECK:

-call a device support routine to check input values (See checkAttributes)

For Directive of START:

-call a device support routine to check input values (See checkAttributes),

-Call device support routine that must act upon the mode set (See The MODE field).

For Directive of STOP

-call a device support routine to stop (See stopDirective). The simulation mode cannot be changed while the BUSY field is not IDLE or ERR.

cvtDbaddr

This routine is called if the field has special processing indicated (SPC_DBADDR) and allows update of the field type, size and data type. This is especially important for the attributes A-E where the datatype is definable.

getValue

Fills in the values of struct valueDes (as defined in epics/base/include/recSup.h):

struct valueDes {

long field_type;

long no_elements;

void *pvalue;

};

so that they reflect the VAL field.

getUnits

Returns the engineering units string for display purposes. It returns the value in the EGU field.

getPrecision

This routine gets the precision, i.e. number of decimal places, which should be used to convert the field value to an ASCII string for display purposes. The precision is determined via the Epics routine recGblGetPrec().

getGraphicsDouble

This routine fills in the graphics related fields by calling recGglGetGraphicDouble for the related field.

getControlDouble

This routine fills the control related field by called recGblGetControlDouble for the associated field.

getAlarmDouble

The alarm double structure values are updated using the routine recGblGetAlarmDouble routine.

Device Support Entries

The device support routine, as defined by assemblyControlDSET, is not the same for every record of this type. There will be a standard set of functions that must be available, regardless of their contents. The contents of these functions are configurable. The next section will describe the general functions:

devReport (Not defined.)
devInit (See devInit)
initDeviceSupport (See initDeviceSupport)
getIoIntInfo (Not defined.)
checkAttributes (See checkAttributes)
stopDirective (See stopDirective)
initMode (See Modes)
moveMode (See Modes)
trackMode (See Modes)
indexMode (See Modes)
testMode (See Modes)
ackReceived (See See ackReceived)
updateMode (See Modes)

devInit

This function is called twice during initialization of the IOC. On the first pass (before records are initialized) it should do any initialization required. The second pass (after records are initialized) should be ignored.

initDeviceSupport

This routine is unique for each assemblyControl record. This function is called once for each assemblyControl record in the system. The general function should be to:

Create and initialize a private structure for the record's device support.
(re)read any lookup tables.
Set any necessary variables.

checkAttributes

This routine, unique for each assemblyControl record, will check the validity of input attributes and do any translation necessary given the lookup table.

stopDirective

This routine will perform whatever is necessary to stop any action currently being performed.

ackReceived

This routine gets called when one of the deviceControl records connected to the BUS1-BUS5 changes in values. It should:

If we are not expecting a change in BUS1-5, then this could be a minor error or, it may be because the last command resulted in one of the devices erroring, which would complete the command. In either case, a warning message is printed but nothing is done.
If we are expecting this change then look at the value:
For ERR then the current command failed, therefore the command timer should be stopped, set the BUSY field to ERR, and fill in an appropriate message. If the command that failed was test, index or init then set the HLTH field to WARNING.
For BUSY ignore the value.
For IDLE then that device completed the requested command, check that

-If we already received an IDLE from this device then ignore it

-If this is the last device to acknowledge then the command is completed then stop the timer and fill in all appropriate status's to indicate the command is completed

-else this is not the last device to complete the command so just flag that this device is complete and continue on.

Modes

For initMode, moveMode, trackMode, indexMode, testMode, and updateMode the code for this is very heavily dependent on the assembly's needs. As a minimum they all should:

Pass the MODE, POS, DIR and potentially the velocity on to the attached deviceControl records.
Set any necessary flags to indicate a command has started
Start a timer to be woken up within a specific amount of time to indicate that the command did not complete correctly.

Timer Tasks

timerCallback

This is a function used by EPICS when a watchdog timer times out. It will be able to set a flag in the private structure of a record and then cause the process function of the record to be called.

Communications structure definition

All command and status information is passed via the record's device private structure. This communications structure defined in the header file recAssControl.h as follows:

typedef struct

{

int bus1; /* If set, change in BUS1. */

int bus2; /* If set, change in BUS2. */

int bus3; /* If set, change in BUS3. */

int bus4; /* If set, change in BUS4. */

int bus5; /* If set, change in BUS5. */

int cmdFinished; /* Indiciates cmd is finished. */

SEM_ID cmdLock; /* Timer semaphore. */

int cmdTimedOut; /* Indicates a cmd timedout. */

int debug; /* Current debug mode. */

int fault; /* Indicates a fault occurred. */

int faultCleared; /* Indicates fault not cleared.*/

int lastCommand; /* Last command requested. */

double position; /* Position to move to. */

void *pPrivate; /* Ptr to private dev supp. */

int simulation; /* Current simulation mode. */

long timeout; /* Private timeout flag. */

void *timer; /* Timer callback info. */

double velocity; /* Velocity to move at. */

} ASS_CONTROL_PRIVATE;

Health and Simulation

The health and simulation of the assemblyControl record is important enough to warrant discussion. Changes in simulation mode are only registered when a command has been initiated and the BUSY field is IDLE. The FULL and FAST simulate modes have been implemented in the deviceControl records and as a result all commands are passed on to the deviceControl records as usual. For VSM simulation mode, commands are not passed on, instead a toggling of the BUSY field is done.

A change in health occurs when an interlock occurs and will not be reset until an INIT command has been issued.

A change in health will occur when an INIT, INDEX or UPDATE command fails.