Gareth Smith

DELPHI 94-13

DAS-150

The document describes the Delphi G64 skeleton program along with the associated VAX programs VAXSKELETON and INIT. These programs have existed for some years. However, it is only in 1994 that this document has been released as a DELPHI note.

Revision/Update Information Revised 6th. May 1998.

Contents

Index

This document describes the skeleton software that has been prepared for use in Delphi Slow Control G64 Crates. This software is used by many of the sub-detector groups within DELPHI, and in some cases has been extended or modified by them.

1.1 Overview of Delphi Slow Controls.

More complete descriptions of DELPHI Slow Controls are available elsewhere ^{1 2} so only a brief overview is included here.

The monitoring and control of the Delphi apparatus - the Slow Controls - makes use of G64 based systems. The standard G64 systems used are the MAC crates which have a dual card frame. The lower card frame has a standard G64 backplane whilst the upper card frame takes the MAC cards that were designed by CERN EF division. The G64 crates themselves are driven using the paging processor card designed by the CERN SPS division using the the Motorola 6809 CPU.

Only the lower levels of the monitoring and control functions are done in G64 systems. The overall control and user interaction is done in VAXstations which are linked to the G64 crates by an ethernet local area network. A detector partition typically has one or two VAXstations and several G64 crates.

The elementary processes in the VAXstations communicate with the G64 crate(s) to get monitored data and possibly to control equipment. They also handle such things as forwarding error messages, updating a database to record changes in the detector, and user interaction. There is one elementary process for each subsystem being controlled or monitored, for each detector partition. For example, there may be an elementary process for high voltage control and another for temperature monitoring. The elementary processes make Remote Procedure Calls (RPCs) to the G64 crates to exchange this information. (The details of RPC are given in the RPC manual ³). The RPC system itself runs on top of networking software which uses the International Standards Organisation's (ISO) protocols over the ethernet/cheapernet. However, the sub-layers of the networking software are transparent to the application program and are not detailed here.

The Delphi G64 crates use Flex as an environment for program development. Flex enables a single program to be loaded and run; it does not provide multi-tasking. The emphasis has been to make the G64 skeleton program as simple as practicable, with any complex operations being done in the VAXStations. The G64 skeleton is a program loop that has been written in Pascal and was compiled using the Omegasoft compiler. The extensions to standard Pascal provided in the Omegasoft version mean that it was not necessary to write any code in assembly language.

1.2 The Scope of the Skeleton Program.

The G64 skeleton program was designed to co-operate with an elementary process. The G64 system can be regarded as an intelligent input-output system that allows the elementary process, via remote procedure calls, to read or set the hardware and receive notification of any unsolicited changes in the state of that hardware. A simple user interface is provided for debugging purposes.

The skeleton program loops, performing the following operations:

• Accepts RPC calls, which usually come from an elementary process running in a VAXStation. The call may:
  • Define a channel to be monitored or set. Following receipt of such a call some initial parameters (such as error limits) are set up in the G64's memory. The hardware is initialised corresponding to the channels defined. (E.g. PIA channels set to input or output as well as setting the channels to an initial state.)
  • Request, for example, a read or write of a particular channel. Any requested values are returned to the caller.
• Reads any channel that is to be monitored. The value read is compared with error limits. If the error condition has changed a message is displayed on the G64 terminal screen and, optionally, a user specified error routine may be called. If the address of an alarm server on a VAX has been defined an error message (implemented as an RPC call) is sent to the VAX.
• Takes commands from a keyboard attached to the system. These are then processed as if they were RPC requests from the VAXStation, but any response is sent to the G64 terminal.

Any requests to the skeleton program must address the hardware channel by referring to a slot and channel number (this is referred to as the physical address of the channel). The slot number is the number of the slot in the MAC card frame. The standard MAC crates have 12 MAC slots. Some hardware is interfaced directly to a G64 card - without a MAC card interface. To allow for these the skeleton software allows for up to 32 slots to be defined. Slots 13 to 32 are available for these channels without a MAC card. The channel number is the number of the channel within the slot (the first channel being numbered 0). The skeleton software allows for a variable number of channels to be defined for each slot, up to a maximum of 1000. The number of the last channel for a given slot is given in the RPC call that initialises the slot. The MAC cards typically have 16 or 32 channels per slot. However, the interface to the CAEN high voltage system has the capability to connect up to 4000 channels via a single interface although only 1000 channels are supported by the skeleton program.

The addressing mechanism described in the previous paragraph is basically a physical description of the channels on the interface cards. The elementary process allows the use of a logical channel description (called the logical address) which is mapped onto the physical address using data stored in the CARGO database.

For all channels using an analogue to digital converter (ADC) card the skeleton program only uses integer values which correspond to the output of the ADC card. No conversion is done to 'real' values such as temperatures. This also applies to the values provided during initialisation (see Chapter 6) when the desired values, error limits and switch limits are also given in ADC counts. Any conversion to real numbers must be done in the VAXStation (typically by the elementary process). Real numbers are passed between the VAX and the G64 only for those routines that communicate with the CAEN high voltage system interface.

1.3 Compatability with the elementary process.

A common numbering scheme for versions of the elementary process and G64 skeleton has been adopted. Compatibility between EP and Skeleton versions is indicated by the major version number. I.e. version 4.x of the elementary process is compatible with version 4.y of the G64 skeleton.

This chapter assumes you have a working copy of the skeleton on your G64 system's 'working' disk drive (taken to be drive 2 in the examples). To run the program give the Flex command:

+++2.DM_MAIN

The program assumes a VT200 compatible terminal is connected to the G64 system. The screen is cleared, and the program title displayed. During the running of the program a clock marker is be displayed in the top right hand corner of the screen. (Note: By changing a constant and recompiling a version of the program for a standard terminal can be produced.)

The RPC system is initialised. The full address string required to access the skeleton program running on your G64 system from a VAX system is shown on the G64's terminal at program startup. For example:

Crate address "0@skel_07@080030001000.ieee"

Refer to the RPC User Manual for details of RPC addressing.

The program will accept RPC calls or keyboard input. Details of the channels to be monitored or controlled are downloaded from a VAX host via RPC calls. These RPC calls will be made on the VAX either by an elementary process or by running the program init (see appendix Appendix C for details) which reads in a data file on the VAX.

Once channels have been declared they are monitored during the program loop. The program continues to also check for further RPC calls or keyboard input. To enter commands from the G64 keyboard the skeleton> prompt must be obtained. This is done by pressing the escape key followed by the return key. Commands may then be entered. A full list of the commands available is given in chapter 4. Commands can be entered in upper or lower case. e.g.

skeleton> rdmpar 2 3

will return the monitoring parameters for digital channel slot 2, channel 3.

To terminate the program enter the command finish.

This chapter details the Remote Procedure Calls that can be made to the G64, and thus defined the interface as seen from a VAX system.

3.1 Calls to Set or Read Multiple Channels

Some routines have been provided to allow the reading or setting of more than one channel in a single RPC call. Up to 10 channels may be accessed in a single call. The calls are flexible in that up to 10 different channels (in the same slot) can be accessed, or different data may be requested for the same channel (e.g. with RCCM_Read_Caen_Chan_m), or some combination of the two. These calls make use of 'sequences' in the RPC calls. The array of values is followed by a number indicating how many elements of the array are used during this call. This can reduce the size of the packets sent over the network if the array is not full. (See the RPC manual for details).

Also added is a sequence returning an error return status for each channel that was set/read. (For details of the format of the error codes returned and a list of them refer to Appendix A.) The overall function return will return g64__normal if all the requested channels were successfully read or set. In the case of a read function, if any of the reads produced an error, then the function return will contain the error corresponding to the last of the channels that gave an error. Note that if, say, the third channel out of 5 gives an error, the G64 skeleton carries on and tries to read the 4th and 5th requested channels. However, in the case of a set function (i.e. for SACm_Set_Anal_Chan_m, SCCm_Set_Caen_Chan_m, SDCm_Set_Dig_Chan_m, SMm_Set_Monitoring_m) the G64 skeleton stops processing the request when it encounters an error. The function return then contains the error return for the channel that failed. There will be no return parameters for any channels that were not processed in this case. The sequence count (s_count in the examples of calls to these routines) will indicate the number of the channel that failed.

3.2 List of Functions Provided

Below is a list of the RPC callable functions provided by the skeleton.

Declares one or more analogue monitoring channels (up to a maximum of 10). This creates the appropriate data structure for subsequent accesses to the channel. If an error occurs during the declaration of a channel, the remaining channels in the array are not declared, and the function return will show the error return for the failed channel. If the channel is already declared, then the status return for that channel will be g64_already_exists (with severity warning), and processing continues to declare any remaining channels in the array.

Format

error = DAMCm_Dec_Anal_Mon_Chan_m

(ep_no, slot_no, chan_no, cn_count, err_rtn_flag, ern_count, des_val, dv_count, err_lim, el_count, swit_lim, sl_count, gain, g_count, mon_stat, ms_count, status, s_count)

Arguments

ep_no

VMS usage:
type:	integer
access:	IN
mechanism:

The number of the elementary process which is used to monitor this channel, and must be in the range 0 to 7. It is used by the G64 skeleton to determine to which address (i.e. which alarm server or elementary process) to send any alarm messages for this channel. See Section 5.2 for details.

slot_no

VMS usage:
type:	integer
access:	IN
mechanism:

The slot number of the card for the channel(s) being defined.

chan_no

VMS usage:
type:	array(10) of integer
access:	IN
mechanism:

The numbers of the channel(s) (in the range 0 to the last channel for this slot). The channels do not have to be given in order (although this is advisable for clarity). However, each channel must only be defined once.

cn_count

VMS usage:
type:	integer
access:	IN
mechanism:

Number of items in array chan_no.

err_rtn_flag

VMS usage:
type:	array(10) of integer
access:	IN
mechanism:

Error routine number for this channel. This is an integer that will be passed to the user--provided error routine (see Section 5.1) and can be used to select an an action resulting from an error condition found during monitoring. If 0 the user--provided error routine is not called.

ern_count

VMS usage:
type:	integer
access:	IN
mechanism:

Number of items in array err_rtn_flag.

des_val

VMS usage:
type:	array(10) of integer
access:	IN
mechanism:

The value the channel is expected to be have. This is an integer and corresponds to the integer value read out of the analogue to digital converter.

dv_count

VMS usage:
type:	integer
access:	IN
mechanism:

Number of items in array des_val.

err_lim

VMS usage:
type:	array(10) of integer
access:	IN
mechanism:

The error limit on the desired value, an integer in counts from the ADC.

el_count

VMS usage:
type:	integer
access:	IN
mechanism:

Number of items in array err_lim.

swit_lim

VMS usage:
type:	array(10) of integer
access:	IN
mechanism:

The switch limit on the desired value, in counts from the ADC. If the channel is already in error, the error condition will be removed when the value read differs from the desired value by less than the switch limit. The switch limit must be less than the error limit. See Figure 5-1 for an illustration of the use of these limits.

sl_count

VMS usage:
type:	integer
access:	IN
mechanism:

Number of items in array swit_lim.

gain

VMS usage:
type:	array(10) of integer
access:	IN
mechanism:

Gain (for each channel) to be set on the MAC analogue multiplexer card, NB9016 or on the Corylus 12 bit ADC card. For analogue channels not using this parameter it should be set to 0. A check is made on permissible values of the gain, i.e. 1, 10, 100 or 0 (i.e. not used).

g_count

VMS usage:
type:	integer
access:	IN
mechanism:

Number of items in array gain.

mon_stat

VMS usage:
type:	array(10) of boolean
access:	IN
mechanism:

Whether the channel(s) should be monitored. If true the channel will be monitored.

ms_count

VMS usage:
type:	integer
access:	IN
mechanism:

Number of items in array mon_stat.

status

VMS usage:
type:	array(10) of longinteger
access:	OUT
mechanism:

Error return for this channel.

s_count

VMS usage:
type:	integer
access:	OUT
mechanism:

Number of items in array status. This is usually the same as cn_count, i.e. the number of items in the array sent. However, if processing stops because of an error then s_count indicates the number of the failed request, and only this number of elements are filled in the returned array status.

Declares one or more analogue setting channels (up to a maximum of 10). This creates the appropriate data structure for subsequent accesses to the channel. The channel is then set to its initial requested value. If an error occurs during the declaration of a channel, the remaining channels in the array are not declared, and the function return will show the error return for the failed channel. If the channel is already declared, then the status return for that channel will be g64_already_exists (with severity warning), and processing continues to declare any remaining channels in the array. Note that an argument ep_no is supplied. At the moment this is not used within the skeleton. It is included in the RPC for possible future extensions to the program and for compatability with other calls that declare channels.

Format

error = DASCm_Dec_Anal_Set_Chan_m

(ep_no, slot_no, chan_no, cn_count, ini_val, iv_count, status, s_count)

Arguments

ep_no

VMS usage:
type:	integer
access:	IN
mechanism:

Not used. Must be specified and in range 0 to 7.

slot_no

VMS usage:
type:	integer
access:	IN
mechanism:

The slot number of the card for the channel(s) being defined.

chan_no

VMS usage:
type:	array(10) of integer
access:	IN
mechanism:

The numbers of the channel(s) (in the range 0 to the last channel for this slot). The channels do not have to be given in order (although this is advisable for clarity). However, each channel must only be defined once.

cn_count

VMS usage:
type:	integer
access:	IN
mechanism:

Number of items in array chan_no.

ini_val

VMS usage:
type:	array(10) of integer
access:	IN
mechanism:

the value(s) to which the channel(s) should be initially set.

iv_count

VMS usage:
type:	integer
access:	IN
mechanism:

Number of items in array ini_val.

status

VMS usage:
type:	array(10) of longinteger
access:	OUT
mechanism:

Error return for this channel.

s_count

VMS usage:
type:	integer
access:	OUT
mechanism:

Number of items in array status. This is usually the same as cn_count, i.e. the number of items in the array sent. However, if processing stops because of an error then s_count indicates the number of the failed request, and only this number of elements are filled in the returned array status.