PINCER System Guide

• 1. Introduction
  • 1.1 Intended Readership
  • 1.2 The Pincer Document set
  • 1.3 Getting Help
• 2. Technical Overview of XRD Stations
  • 2.1 General Description of Stations
  • 2.2 Data Acquisition and Control
    • 2.2.1 Schematic Overview
    • 2.2.2 Details of CAMAC Configuration, Usage,
      and Modules Required
    • 2.2.3 Control of CAMAC using the Station PC
    • 2.2.4 The Motor Control System
    • 2.2.5 McLennan Motors General Information
    • 2.2.6 CAMAC Motors General Information
    • 2.2.7 Acquisition of Data from the Detectors
      - Use of Pulse Counting
• 3. System Software Configuration and Installation
  • 3.1 Arrangement of directories on the PC Hard Disk
  • 3.2 Installation on a repaired or new system
  • 3.3 Backup Procedure for Station PC
• 4. The PINCER Data Acquisition Software set-up
  • 4.1 Environment Variables
  • 4.2 PINCER Directory Structure
  • 4.3 PINCER Macro Search Procedure
  • 4.4 Hardware configuration file search
  • 4.5 Hardware configuration file naming
  • 4.6 Adding a new motor to the system
  • 4.7 Switchable I/O mechanisms
  • 4.8 Enabling Graphics Output
  • 4.9 Procedure for Modifying PINCER Code
  • 4.10 The PD Macros
• 5. TFILE32 File Transfer to Netstor
  • 5.1 Netstor Option
  • 5.2 General Option
• 6. Other Software Utilities Available
• 7. Troubleshooting
  • 7.1 During Data Acquisition
    • 7.1.1 No response from CAMAC or faulty data obtained
    • 7.1.2 Theta or Twotheta (McLennan) motor will not drive
    • 7.1.3 Other motors (CAMAC) will not drive
  • 7.2 SRS File Transfer Fails
  • 7.3 PC Related Problems
    • 7.3.1 PC will not respond
    • 7.3.2 PC will not reboot
• 8. Glossary
• 9. Appendices
  • 9.1 Example PC System Hardware Set-up
  • 9.2 Listings of Important Files
    • 9.2.1 PINCER Hardware configuration file MOT_GEN.DAT
    • 9.2.2 PINCER Hardware configuration file MOT_IDB.DAT
    • 9.2.3 PINCER Hardware configuration file MOT_CAM.DAT
    • 9.2.4 PINCER Hardware configuration file MOT_HW.DAT
    • 9.2.5 PINCER Hardware configuration file MOT_MIC.DAT
    • 9.2.6 PINCER Hardware configuration file CTR_GEN.DAT
    • 9.2.7 PINCER Hardware configuration file CTR_QCR.DAT
    • 9.2.8 PINCER Hardware configuration file CTR_TFC.DAT
    • 9.2.9 PINCER Hardware configuration file CTR_HWC.DAT
    • 9.2.10 PINCER Hardware configuration file CTR_MCC.DAT
    • 9.2.11 PINCER Hardware configuration file MCA_GEN.DAT
    • 9.2.12 PINCER Hardware configuration file MCA_CAN.DAT
    • 9.2.13 PINCER Hardware configuration file MCA_CIO.DAT
    • 9.2.14 PINCER Hardware configuration file MCA_LHM.DAT
    • 9.2.15 PINCER Hardware configuration file MCA_MXI.DAT
    • 9.2.16 PINCER Hardware configuration file MCA_PDL.DAT
    • 9.2.17 PINCER Hardware configuration file MCA_TCA.DAT
    • 9.2.18 PINCER Hardware configuration file TEM_GEN.DAT
    • 9.2.19 PINCER Hardware configuration file TEM_ITC.DAT
    • 9.2.20 PINCER Hardware configuration file TEM_EUR.DAT
    • 9.2.21 PINCER Hardware configuration file PRE_GEN.DAT
    • 9.2.22 PINCER Hardware configuration file PRE_HYD.DAT
  • 9.3 Procedure for Checking the Station Computer for Viruses
• 10. References

In the absence of Mike Miller, please contact another PC Working Party member of the Synchrotron Radiation Computing Group for software problems, e.g. Dave Love or Marion Bowler. For OS-9 Systems please contact Paul Stephenson or Geoff Mant.

2. Technical Overview of XRD Stations

2.1 General Description of Stations

The XRD stations are involved in various types of Powder Diffraction using slightly different combinations of instruments depending on the particular technique. There are two types of powder station and technique used as follows :
1. Angle dispersive type scanning with high resolution twotheta arm detector scanning through monochromatic diffraction peaks in small steps, taking several hours
2. Energy dispersive type using white beam and a solid state detector in a fixed twotheta position collecting data in a multichannel analyser MCA memory. This is quite rapid and may involve large quantities of data being collected in kinetics experiments.
In addition there are single crystal diffraction stations being developed on 16.4 and 9.8 (incorporating also 9.7). This type of work involves scanning in reciprocal space (diffraction units) and converting to and from the four real space angles provided by the four circle diffractometer. For further details see the PINCER Configuration Guide.
Most of the systems are PC controlled with the Pincer software running under a 32-bit Windows operating system such as Windows 95 or Windows NT. A specific example will give enough information to get started with solving problems elsewhere. The chosen system is the SRS 2.3 Angle Dispersive Powder station.
Station 2.3 provides high resolution Powder diffraction data collection facilities on X-ray beamline 2. Flat plate powder samples diffract the incident X-rays producing a diffraction pattern which is generated by scattering from the constituent atoms in the material in the form of concentric cones of count maxima or diffraction peaks. The data is collected by scanning a scintillation detector through these peaks from low to high angle and measuring the X-ray counts for a fixed period at each sample point. The detector arm is called 2theta and is controlled by a McLennan DC servo system giving a typical scan movement of .01 degrees. A typical scan takes a few hours and requires the theta axis, on which the sample is mounted (concentric to twotheta) to be scanned with twotheta at half the increment angle.
Other station operations include setting the wavelength and varying the sample environment with various cells, including the use of a cryostat.
Software control is provided by the PINCER (Portable Instrument Control Interpreter) program with its rich suite of internal building block commands. Normally the PD Powder Diffraction macros are run as a front-end , which provides a more user-friendly menu system to drive the station. Full details of the PINCER program can be found in a separate user guide.

2.2 Data Acquisition and Control

2.2.1 Schematic Overview

2.2.7 Acquisition of Data from the Detectors - Use of Pulse Counting

This is a composite device made up of three Camac modules but treated as a single logical counter timer unit. The elements are as follows :-
* Clock Pulse generator (CPG) - Hytec 95 or NE9088
* Scaler Inhibitor (SCI) - EC524
* Quad counter scaler (QCR) - Hytec 350A or NE709
The wiring of these modules is shown in the diagram below.

The CPG is not accessed by software but must be present to provide the timing pulses which are used by channel 0 of the QCR. It provides TTL pulses of varying frequencies but 1khz is used by PINCER as the standard. This provides a resolution of 1msec for timing. The signal is taken from a LEMO cable to the QCR via the controlling SCI. The SCI is required to control the QCR so that it does not count continuously and can also provide gating. The OUT LEMO signal(s) of the SCI GP1, 2 or 3 should be connected to the INHIBIT inputs or INHIBIT ALL input of the QCR so that counting is started/stopped under software control of the SCI from PINCER. The OVERFLOWs of the QCR channels should be connected to the STOP INPUTS of the SCI. This ensures that when a QCR channel overflows, counting is immediately stopped in hardware by the GP1-3 STOP signals all becoming active (low). The QCR channel 0 i.e. the timing channel address 0, must be placed in the 1st STOP INPUT socket. This is because PINCER monitors the SCI status register for an end of timing bit 1 set which is generated by the 1st STOP INPUT signal having become active. To ensure that the QCR counting all starts on the 1st negative going pulse received from the CPG, the CPG 1khz pulses are fed to the SYNC START input as well as into channel 0 INPUT connector of the QCR.
The QCR has 4 24-bit registers which count negative going edges of TTL pulses at the INPUT sockets. Internally channels may be set to NIM logic but at least channel 0 must be set to TTL for counting the timing pulses. PINCER on 2.3 does not use cascaded counters and so after 24 bits worth (~16 million) of counts the registers overflow and the OVERFLOW's become active (low). Before a count, PINCER loads channel 0 with the negative 2's complement of the dwell time required in milliseconds and once enabled, will count this number of timing pulses before channel 0 overflows and the counting of all channels is halted by the SCI. Channels 1 - 3 have user defined signals set to TTL or NIM as defined by the QCR hardware configuration which connect directly to the INPUTs. PINCER on 2.3 normally does not allow a pre-set to be loaded into the non timing channels at present and so they start counting from 0 each time. A pre-set value can be loaded into QCR's non-timing channels before the count as defined by the last value of the pre-set command. In any case the count time in milliseconds is always loaded to channel 0.

set rampath=c:\srs\pincer\rampath\
While the CLISYS variable is set with
set clisys=c:\srs\pincer\pr\

setenv RAMPATH /dd/macros/
setenv CLISYS /h0/users/srs/pincer/pr/

<hw_type> rdparam <device_name>
e.g. mot rdparam twotheta

e.g. tfile32 n 1 10

&SRS
SRSRUN= 608,SRSDAT=930930,SRSTIM=130807,
SRSSTN='EDS3',SRSPRJ='POWDERDF',SRSEXP='12345432',
SRSTLE='zeolitwe x p marker at 0 ',<
SRSCN1=' ',SRSCN2=' ',SRSCN3=' ',
&END

18
tth 2 1. 0. 0. steps
th 3 -5. 0. 0. mdegrees
ome 3 1. 0. 0. mdegrees
chi 1 1. 0. 0. mdegrees
phi 4 1. 0. 0. mdegrees
an 3 1. 0. 0. mdegrees
andet 3 1. 0. 0. mdegrees
mono 2 1. 0. 0. mdegrees
slits 2 -1. 0. 0. mdegrees
slitl 2 -1. 0. 0. mdegrees
slitr 2 -1. 0. 0. mdegrees
slitt 2 -1. 0. 0. mdegrees
slitb 2 -1. 0. 0. mdegrees
exit 2 1. 0. 0. mdegrees
table 2 -17. 0. 0. mdegrees
rot1 2 -4. 0. 0. mdegrees
rot2 2 -4. 0. 0. mdegrees
trans 2 1. 0. 0. mdegrees
----------------------------------------------------------
This is mot_gen.dat generic motor parameter file read by the motor_controller layer. Contents in user units ("units") :-
no_of_generic_motors_in_file
Name motor_type* gear_ratio offset rnding_fctr unit
string integer float float float string [Data types]
* motor type index : 1 = Harwell 6000 motors (mot_hw)
2 = PC Hytec i/face and NE9100 CAMAC Mux (mot_cam)
3 = IDB300 McLennan DC-servo (rom5.02+) (mot_idb)
4 = Minicam GPIB motors (Bede systems)
----------------------------------------------------------
Generic Motors General Information
-----------------------------
This generic motor file provides parameters for the conversion of user-units from the cli to hardware units used by the specific motor controllers and back again for values which are returned to the cli from the hardware
layers.
Also it provides an index of the specific motor hardware type which controls the real motor and so results in code for that specific type being called by the mot_gen code. The specific controller is then responsible for carrying out all motor operations for that motor.
The unit conversion equation h/w units = (user units - offset) * gear_ratio is used but precision errors are possible. Thus a rounding factor also is present to add if +ve or subtract if -ve and so round up/down).
mot_gen.dat parameters
-----------------------
Name info
----- -------------------------------------------------
no_of_generic_motors_in_file No. of generic motor entries in this file
Name User name string of motor
motor_type Index of h/w type of motor (specific controller)
gear_ratio Gearing ratio for motor for calc user-h/w units
offset User unit position offset for calc user-h/w units
rnding_fctr Rounding factor to fix precision errors -> " "
unit Single string of user-unit name (for info only)

7
tth 2 0 3 0 -360000 360000 0 OA OS MA MR AP ST ! 3 3
th 1 0 3 0 -360000 360000 0 OA OS MA MR AP ST ! 3 3
ome 3 0 1 0 -360000 400000 0 OA OS MA MR AP ST ! 3 3
chi 4 0 1 0 -360000 360000 0 OA OS MA MR AP ST ! 3 3
phi 5 0 1 0 -360000 360000 0 OA OS MA MR AP ST ! 3 3
an 6 0 1 0 -360000 360000 0 OA OS MA MR AP ST ! 3 3
andet 7 0 1 0 -360000 360000 0 OA OS MA MR AP ST ! 3 3
----------------------------------------------------------
This is mot_idb.dat - McLennan PM3xx servo/stepper motor parameter file read by the idb_controller layer. Contents in hw units (steps) :-
no_of_idb_motors_in_file
Name Axis gpib_no! port chan# l_limit h_limit blash* pos_cmd stat_cmd ..
string string int int int long long long string string
[data types ..]
adrv_cmd rdrv_cmd pset_cmd stop_cmd err_char stat_st posr_st
string string string string char int int [data types]
! if the gpib no. is set to zero, the interface is the pc com port while a +ve number is the even address of iotech 4 port gpib device in dual address setup mode
The port nos are PC 0-3 com1-com4, GPIB 1-4 port 1-4, OS-9 0-5 ports 1-6
(NB the port(s) must be enabled for pincer i/o outside the program).
# PM381 channel select index. Set to zero for PM300/PM341 or >0 for value of channel of each motor driven from a single PM381 IDB axis no.
If a negative value is set, it reverses the sense of the busy/idle bit of the status which McLennan have a habit of mixing up without sending the change channel commands for the PM381.
* backlash value is treated as follows :-
+ve value : motor driven always in +ve hardware direction (on -ve drives
overshooting by value then driving +ve in 2nd drive by value.
-ve value : motor driven always in -ve hardware direction (on +ve drives
overshooting by value then driving -ve in 2nd drive by value.
0 value : no backlash correction applied
----------------------------------------------------------
McLennan Motors General Information
-----------------------------
This has been written primarily for the McLennan IDB PM300/304 DC servo motors but has the flexibility to also drive steppers of the PM 301/341 series using suitable parameters.
To select the PM381 channel select motor, set a non-zero "chan" value corresponding to a channel select axis no. With PM381 set, a
"<axis>CH<chan>" command is sent to the IDB before each operation where a
new channel is required. Also the busy/idle status bit operates in the
opposite logical sense (why??).
Each motor is operated by a dedicated McLennan IDB controller.
This carries out the interfacing to the motor using servo PDIF parameters in
a servo loop. Position feedback is gained from an encoder set on the motor
shaft or on the target instrument itself for highest resolution. The drive
parameters are not set by Pincer but are battery backed up and set either
manually, by the IDB program (by M.C.Miller) or by Kermit if need be. The
station master is normally responsible for deriving suitable optimised
system parameters in consultation with McLennan.
Pincer operates the motors by sending command strings to the IDB using
an RS232 interface. All motors are normally driven daisy-chained from a
single serial port. Either a system port is used (PC COMx, OS-9 port x) or
a PC GPIB Iotech 4-port RS232 interface is used as set by the parameters
gpib_no and port in combination. The idb also returns reply strings if
information is requested or a simple "ok" otherwise. No reply is generated
unless specifically asked for so an end of drive is determined by checking
the current status for the busy/idle bit value.
Commands supported by the McLennan are move_absolute and move_relative
in units of encoder pulses (or steps with a stepper motor that has no
encoder in place). The Pincer cli operates in user-units and so the generic
layer provides conversion factors to ensure that the mot_idb software always
works with the correct h/w units. H/w units = (user units - offset) * gear_ratio
basically but precision errors are possible. Thus a rounding factor also is
present to add if +ve or subtract if -ve and so round up/down.
Pincer supports synchronous and asynchronous drives characterised by a
wait for completion or possible early return. If there is backlash correction
set then in some moves which are asynchronous return cannot be made until the
final anti-backlash move is initiated. Fortunately the IDB's generally have
little or no backlash if recently installed.
The actual command strings are set by parameters in this file and the
position and status reply string start character offsets are also variables
since different versions and types of motors have been known to change in this
respect.
mot_idb.dat parameters
-----------------------
Name info
------------------------------------------------------
no_of_idb_motors_in_file Total no of IDB motor entries in this file.
Name Name string of motor (must be mot_gen.dat too).
Axis IDB axis no. set by h/w switches
gpib_no if 0=RS232 port, else =IOTECH 1st prim. GPIB addr
port RS232 port # - see notes at ! above
chan index of PM381 channel selected : 0 specifies PM300/PM341
l_limit low limit in h/w units checked before drives
h_limit high limit in h/w units checked before drives
blash backlash correction in h/w units - see * above
pos_cmd IDB command string for query current position
stat_cmd IDB command string for return current status (quick)
adrv_cmd IDB command string for drive to abs h/w posn
rdrv_cmd IDB command string for drive relative to current pos
pset_cmd IDB command string for redefine current posn
stop_cmd IDB command string for stop a current drive
err_char 1st character in reply indicating IDB error message
stat_st posn of busy/idle bit in stat_cmd reply (1st char=0)
posr_st offset of posn reply from pos_cmd (1st char=0)
Pincer MOT functions supported
-------------------------------
Kernal :
stop halt a driving motor
getpos return current position
getstat return current status
movabs move to absolute posn returning after completion
movrel move by relative posn returning after completion
movabsa move to absolute posn returning before end if possible
movrela move by relative increment returning before end if possible
chkpos check whether desired posn is a valid target
setpos redefine current position as new (no drive)
init check name & set GPIB Iotech RS232 box up if needed
trace list current active mot_idb parameters set
rdparam load mot_idb.dat parameters to memory
Extension :

12
mono 1 1 0 15 1 1 1 -360000 360000 0 0 1 0
tth 1 1 0 15 1 1 1 -360000 360000 0 0 1 0
slits 3 0 0 13 1 1 1 -360000 360000 0 0 1 0
slitl 4 0 0 13 1 1 1 -360000 360000 -10 0 1 0
slitr 4 0 0 13 1 1 1 -360000 360000 -10 0 1 0
slitt 4 0 0 13 1 1 1 -360000 360000 -10 0 1 0
slitb 4 0 0 13 1 1 1 -360000 360000 -10 0 1 0
exit 5 0 0 13 5 5 1 -360000 360000 10 0 1 0
table 6 0 0 13 50 50 1 -360000 360000 -10 0 1 0
rot1 7 0 0 13 10 10 1 -360000 360000 -10 0 1 0
rot2 8 0 0 13 10 10 1 -360000 360000 -10 0 1 0
trans 9 0 0 13 10 10 1 -360000 360000 10 0 1 0
---------------------------------------------------------------
This is mot_cam.dat - PC CAMAC motor parameter file read by
the camac_controller layer. Contents in hw units (steps) :-
no_of_camac_motors_in_file
Branch/
Name Him GPIB Crate Stn MaxSpeed SSspeed Acc min_hw_limit [cont]
string long long long long long long long long [cont]
max_hw_limit backlash* locked_flag@ file_flag@ backoff
long long int int long [data types]
* backlash value is treated as follows :-
+ve value : motor driven always in +ve hardware direction (on -ve drives
overshooting by value then driving +ve in 2nd drive by value.
-ve value : motor driven always in -ve hardware direction (on +ve drives
overshooting by value then driving -ve in 2nd drive by value.
0 value : no backlash correction applied
@ flags are set true if 1, false if 0.
----------------------------------------------------------------------------
CAMAC Motors General Information
--------------------------
The camac motor control system consists of the Camac NE9100 / EC531
steppper motor multiplexer module (mux), a highway interface which daisy
-chains the motors together and a highway interface module (HIM).
The him may be a freestanding die-cast box (EC566) or positioned in the
same rack as the translators (power supply + amplifier for each motor). In
either case, there are switches which allow a him address to be set for
each motor (0-255) which can be addressed by the mux. Only the addressed him
passes on the drive steps to its motor which are otherwise ignored. The him
address in s/w is set here as the him parameter.
The mux under s/w control sends step and direction information to a
motor selected by its unique him address and retains status info on limits,
error lines and drive end. The pulse frequency variations define the drive
profile and the software sets this up via start-stop, acceleration and max
speed registers in the mux. The acceleration parameter also defines the
deceleration if there is time for it to occur during a drive. The drive
parameter registers are as follows :-
1) Address (HIM) 8-bit
2) Rate 8-bits with 9th bit toggling range
3) Start-stop/Acceleration 12-bits with upper 8 Accel.
An important point to note is that two ranges are defined for Rate,
Start-stop and Acceleration based on bit9 of the Rate register. Thus
if the Rate is > 256 (i.e. bit9 set) then the values for Start-stop
and Acceleration assume much higher values as seen in the table.
a) Low Speed Range
--------------------------------------------------------------
PARAMETER MIN-VALUE MAX-VALUE MIN-SPEED MAX-SPEED UNITS
--------------------------------------------------------------
Rate 1 255 20 5100 Steps/sec
Acceleration 1 255 1000 250000 Steps/sec2
Start/stop 1 15 20 300 Steps/sec
--------------------------------------------------------------
b) High Speed Range
--------------------------------------------------------------
PARAMETER MIN-VALUE MAX-VALUE MIN-SPEED MAX-SPEED UNITS
--------------------------------------------------------------
Rate 257 511 320 81600 Steps/sec
Acceleration 1 255 16000 4000000 Steps/sec2
Start/stop 1 15 320 4800 Steps/sec
--------------------------------------------------------------
Operations supported by the steppers are move_relative only drives in
units of h/w steps. The Pincer cli operates in user-units and so the
generic layer provides conversion factors to ensure that the mot_idb
software always works with the correct h/w units. H/w units = (user units
- offset) * gear_ratio basically but precision errors are possible. Thus a
rounding factor also is present to add if +ve or subtract if -ve and so
round up/down.
Pincer supports synchronous and asynchronous drives characterised by a
wait for completion or possible early return. If there is backlash
correction set then in some moves which are asynchronous return cannot be
made until the final anti-backlash move is initiated.
GPIB CAMAC is supported and can be easily switched to it on PC's by
setting the branch number for the device to a non-zero positive value
which is then taken to be the crate controller primary address "n". The
usual setting for n is 1. The device for the GPIB CAMAC must be set in
National Instruments AT-GPIB driver software to dev<n>. With a zero branch,
the CAMAC is Hytec 1330 on PC's or type A2 on OS-9 systems.
mot_cam.dat parameters
-----------------------
Name info
----- ----------------------------------------------------
no_of_camac_motors_in_file Total no of CAMAC motor entries in this file.
Name Name string of motor (must be in mot_gen.dat too).
Him Camac HIM address set in switches (0-255)
Branch /GPIB Camac system branch number (0 usually) but if not
zero is KS3988 GPIB CAMAC with this primary address
Crate Camac crate number (0=PC, 1=OS-9)
Stn Camac station of Multiplexer module NE9100/EC531
MaxSpeed mux index of max speed (see above)
SSspeed mux index of start-stop speed min=1 (see above)
Acc mux index of acceleration rate (see above)
min_hw_limit Low limit in h/w units checked before drives
max_hw_limit High limit in h/w units checked before drives
backlash Backlash correction in h/w units - see * above
locked_flag If set true the motor cannot be driven
file_flag If true posn saved to binary file <clisys>motfle.dat
backoff Not used at present
Pincer MOT functions supported
-------------------------------
Kernal :
stop halt a driving motor
getpos return current position
getstat return current status
movabs move to absolute posn returning after completion
movrel move by relative posn returning after completion
movabsa move to absolute posn returning before end if possible
movrela move by relative increment returning before end if possible
chkpos check whether desired posn is a valid target
setpos redefine current position as new (no drive)
init check name, set internal posn store & reset camac crate / mux
trace list current active mot_cam parameters set
rdparam load mot_cam.dat parameters to memory
Extension :

0
7
96
4
ome A 301 -2 2 0
tth B 302 -2 2 -10
chi C 303 -360000 360000 10
phi D 304 -4 4 10
---------------------------------------------------------------
This is mot_hw.dat - harwell motor parameter file read by
the harwell_controller layer. Contents in hw units (steps) :-
pc_rs232_port # (e.g. 0=com1, 1=com2)
rs232_data_bits (dummy - a DOS mode command is needed outside program)
rs232_baud_rate (ditto)
no_of_harwell_motors_in_file
Name Axis Speed min_hw_limit max_hw_limit backlash*
string string int long_int long_int long_int [data types]
* backlash value is treated as follows :-
+ve value : motor driven always in +ve hardware direction (on -ve drives
overshooting by value then driving +ve in 2nd drive by value.
-ve value : motor driven always in -ve hardware direction (on +ve drives
overshooting by value then driving -ve in 2nd drive by value.
0 value : no backlash correction applied
----------------------------------------------------------------------------
Harwell 6000 Stepper Motors General Information
-----------------------------------------
The Harwell 6000 is a crate based instrumentation system which includes
simple support for stepper motors. The type supported here depends on
the X-ray Spectrometer Control System 36415-2 which has an RS232 link
to the host computer (PC) for command writes and position and status reads.
Up to 4 motors can be driven with 2 internal (A&B) and 2 external (C&D) via
a TTL i/face to Berger Lahr controllers and drivers but all appear the same
to the host.
The baud rate is fixed at 1200 (slow) and other params are no parity,
7 data bits and 1 stop bit. The handshaking is s/w only.
The motor commands are as follows :
INCR motor n drives motor relative by +/- incr between 0-10^8
LOAD motor n loads the position register with a step posn
READ motor reads current step posn
SPEED motor n loads current speed (no ramp profile supported)
STOP motor stops a driving motor (may lock it up too!)
STATUS motor returns current status 1=busy, 0=stopped
One of the few nice things is that all motors can be driven at once and
status checks performed to synchronise the completion. In addition a manual
overide switch allows motors to be jogged but the position will not then
correspond to what is in the posn register so must be reset from Pincer.
Nasty Bugs in the Harwell system :
a) 1st drive after switch-on or setpos should be small +ve drive then
back or 1st -ve drive will never end !!
b) A drive by 0 steps will never end !!
c) If display wraps round to 0 (> 90000000) i.e. negative posn it
will get confused (I haven't fully sussed this out yet)
d) Hard limit switches work but lock up the Harwell if hit !!
e) No error messages appear if anything goes wrong e.g. limit hit !!
f) I/face locks up if RS232 is unplugged - hard reset needed which
loses all the positions !!
Commands supported by the Harwell are move_relative in nature in units
of steps (normally a millidegree per step). The Pincer cli operates in
user-units and so the generic layer provides conversion factors to ensure
that the mot_hw software always works with the correct h/w units. H/w units
= (user units - offset) * gear_ratio basically but precision errors are
possible. Thus a rounding factor also is present to add if +ve or subtract
if -ve and so round up/down.
Pincer supports synchronous and asynchronous drives characterised by a
wait for completion or possible early return. If there is backlash
correction set then in some moves which are asynchronous return cannot be
made until the final anti-backlash move is initiated.
mot_hw.dat parameters
-----------------------
Name info
----- --------------------------------------------------
pc_rs232_port Index of PC com port (all motors) 0=com1, 1=com2
rs232_data_bits Not used. A DOS mode command is needed to set it
rs232_baud_rate Not used. A DOS mode command is needed to set it
no_of_harwell_motors_in_file No. of motor entries in this file
Name User name string for motor
Axis Actual Harwell device name used in commands
Speed Single speed value (no trapeziod ramps supported)
min_hw_limit low h/w pos limit - checked before drives
max_hw_limit high h/w pos limit - checked before drives
backlash backlash value in operation - see * notes above
Pincer MOT functions supported
-------------------------------
Kernal :
stop halt a driving motor (however can lock up Harwell !!!)
getpos return current position
getstat return current status
movabs move to absolute posn returning after completion
movrel move by relative posn returning after completion
movabsa move to absolute posn returning before end if possible
movrela move by relative increment returning before end if possible
chkpos check whether desired posn is a valid target
setpos redefine current position as new (no drive)
init check name, settle with dummy read & set speed value
trace list current active mot_hw parameters set
rdparam load mot_hw.dat parameters to memory
Extension :

5
mono dev6 32 33 2 -360000 360000 3 0 1
slits dev6 34 35 1 -360000 360000 0 0 1
slitl dev6 36 37 1 -360000 360000 -10 0 1
slitr dev6 38 39 1 -360000 360000 -10 0 1
phi dev6 38 39 1 -360000 360000 -10 0 1
----------------------------------------------------------
This is mot_mic.dat - PC MINICAM motor parameter file read by
the minicam_controller layer. Contents in hw units (steps) :-
no_of_minicam_motors_in_file
Name gpib_name neg_mic_addr pos_mic_addr MaxSpeed min_hw_limit [cont]
string string int int long long [cont]
max_hw_limit backlash* locked_flag@ file_flag@
long long int int [data types]
* backlash value is treated as follows :-
+ve value : motor driven always in +ve hardware direction (on -ve drives
overshooting by value then driving +ve in 2nd drive by value.
-ve value : motor driven always in -ve hardware direction (on +ve drives
overshooting by value then driving -ve in 2nd drive by value.
0 value : no backlash correction applied
@ flags are set true if 1, false if 0.
----------------------------------------------------------
MINICAM Motors General Information
----------------------------
This is the Bede Scientific Instrument Minicam Microcomputer Interface
system, known as "minicam" (short for minicamac though totally different in
every respect!). It consists of a controller and a crate of various modules
such as motors, counter-timers, ADC's etc. It is used widely at Strathclyde
University, Dept. of Pure and Applied Chemistry. The main features are
descibed below.
The mincam normally has a single GPIB primary address which is used for
all motor (and counter-timer operations, see file ctr_mic.dat) operations.
In this mode, only 1 device in the whole minicam rack can be driven at any
one time. It is possible to have > 1 controller which would then allow
modules to be driven in parallel. The minicam controller status is returned
as a GPIB serial poll which is converted to the pincer BUSY or IDLE status.
No other status information is available and steps will be lost if e.g. a
limit is hit so this should be avoided - set min_hw_limit and max_hw_limit
to a sensible range.
The GPIB commands sent to the minicam are 7 binary bytes as follows :-
USR A% N% T%
1 byte 2 bytes 2 bytes 2 bytes
where USR = a function number for the required operation, for motors = 1
A% = module minicam (mic) address LSB,MSB
N% = steps to drive in range 0 - 65535 LSB,MSB
T% = index of speed as number of 100usec intervals between pulses
LSB,MSB
The motors have 2 addresses for negative and positive drives and in either
case the steps requested are positive only. Pincer will drive greater distances
and take up backlash provided that (as expected) the drive is synchronous or
asynchronous with a check for end of drive with a "getstat" command until
an IDLE status is found. Unfortunately a BUSY status can result from another
minicam module such as a counter-timer.
The motors are driven in overlap mode to ensure that Pincer is not tied up
while the minicam bus is busy. This involves setting the MSB of the module
address to 1 in bit 0. In this mode the reply comes back immediately as a
dummy in the following 3 byte binary form which Pincer ignores :
A STATUS
2 bytes LSB,MSB as 0 1 byte as 0
Operations supported by the steppers are move_relative only drives in
units of h/w steps. The Pincer cli operates in user-units and so the
generic layer provides conversion factors to ensure that the mot_idb
software always works with the correct h/w units. H/w units = (user units
- offset) * gear_ratio basically but precision errors are possible. Thus a
rounding factor also is present to add if +ve or subtract if -ve and so
round up/down.
Pincer supports synchronous and asynchronous drives characterised by a
wait for completion or possible early return. If there is backlash
correction set then in some moves which are asynchronous return cannot be
made until the final anti-backlash move is initiated.
mot_mic.dat parameters
-----------------------
Name info
----- ----------------------------------------------------
no_of_minicam_motors_in_file Total no of MINICAM motor entries in this file.
Name Name string of motor (must be in mot_gen.dat too).
gpib_addr Minicam controller NI GPIB device name (usually dev6)
neg_mic_addr minicam address for negative drives of this axis
pos_mic_addr minicam address for positive drives of this axis
MaxSpeed mic speed index as inter-pulse time, units of 100usec
min_hw_limit Low limit in h/w units checked before drives
max_hw_limit High limit in h/w units checked before drives
backlash Backlash correction in h/w units - see * above
locked_flag If set true the motor cannot be driven
file_flag If true posn saved to binary file <clisys>motfle.dat
Pincer MOT functions supported
-------------------------------
Kernal :
stop halt a driving motor
getpos return current position
getstat return current status
movabs move to absolute posn returning after completion
movrel move by relative posn returning after completion
movabsa move to absolute posn returning before end if possible
movrela move by relative increment returning before end if possible
chkpos check whether desired posn is a valid target
setpos redefine current position as new (no drive)
init check name, set internal posn store & reset minicam crate / mic
trace list current active mot_mic parameters set
rdparam load mot_mic.dat parameters to memory
Extension :

11
ch1 2 1. 0. 0. counts
ch2 2 1. 0. 0. counts
ch3 2 1. 0. 0. counts
ch4 2 1. 0. 0. counts
timer 2 1000. 0. 0. sec
mcs 3 1. 0. 0. counts
mcs5 3 1. 0. 0. counts
hw1 1 10. 0. 0. 0.1sec
hw2 1 10. 0. 0. 0.1sec
mcc1 4 1. 0. 0. pulses
mcc2 4 1. 0. 0. pulses
----------------------------------------------------------
This is ctr_gen.dat generic counter-timer parameter file read by
the ctr_controller layer. Contents in user units ("units") :-
no_of_generic_ctrs_in_file
Name ctr_type* gear_ratio offset rnding_fctr unit
string integer float float float string [Data types]
* ctr-tim type index : 1 = Harwell 6000 counter-timer (ctr_hwc)
2 = PC Hytec CAMAC + qcr chain (95/350/EC524) (ctr_qcr)
3 = PC Hytec CAMAC + EC728/EC727 units (TFG/MCS)(ctr_tfc)
4 = Bede system minicam ctr-timers via NI GPIB i/f
----------------------------------------------------------
Generic Counter-timer General Information
-----------------------------------
This generic ctr-tim file provides parameters for the conversion of user-
units from the cli to hardware units used by the specific ctr-tim controllers
and back again for values which are returned to the cli from the hardware
layers. This is actually only used by the timer devices for the conversion
of timer intervals allowing sensible user-units to be chosen.
Also it provides an index of the specific ctr-tim hardware type which
controls the real ctr-tim and so results in code for that specific type being
called by the mot_gen code. The specific controller is then responsible for
carrying out all ctr-tim operations for that ctr-tim.
Some devices have distinct timers and counters (scalers) while others do
not but at this generic level all that is needed is inclusion of all devices
which are needed at the specific level.
Where needed unit conversion equation h/w units = (user units - offset) *
gear_ratio is used but precision errors are possible. Thus a
rounding factor also is present to add if +ve or subtract if -ve and so
round up/down).
ctr_gen.dat parameters
-----------------------
Name info
-------------------------------------------------
no_of_generic_ctrs_in_file No. of generic ctr-tim entries in this file
Name User name string of ctr-tim
ctr_type Index of h/w type of ctr-tim (specific controller)
gear_ratio Gearing ratio for ctr-tim for calc user-h/w units
offset User unit position offset for calc user-h/w units
rnding_fctr Rounding factor to fix precision errors -> " "
unit Single string of user-unit name (for info only)

5
ch1 0 0 0 6 0 0 0 1
ch2 1 1 0 6 0 0 0 1
ch3 2 0 0 6 0 0 0 1
ch4 3 0 0 6 0 0 0 1
timer 0 0 0 4 0 16000 1 1
---------------------------------------------------------------
This is ctr_qcr.dat - PC CAMAC counter-timer parameter file read by
the ctr_qcr_controller layer. Contents in hw units (pulses) :-
no_of_qcr_ctrs_in_file
Branch/
Name Addr GPIB Crate Stn min_hw_limit max_hw_limit timer_dev* active!
string long long long long long long flag flag
* timer in qcr code refers to the scaler inhibitor which controls the timing.
! only 1st element is actually used as a flag for all.
timer_dev : 0=normal qcr channel
1=timer channel (qcr channel 0)
2=cascaded channel (name matches existing channel)
flags are set true if 1, false if 0.
----------------------------------------------------------------------------
CAMAC counting chain (95/350/EC524) Counter-Timers General Information
----------------------------------------------------------------
This is a composite device made up of three Camac modules but treated as
a single counter timer. The elements are as follows :-
a) Clock Pulse generator (cpg) - Hytec 95 or NE9088
b) Scaler Inhibitor (sci) - EC524
c) Quad counter scaler (qcr) - Hytec 350A or NE709
The cpg is not accessed by s/w so does not appear in this file. It must
be present to provide the timing pulses which are used by chan 0 of the
cqr. It provides TTL pulses of varying frequencies but 1khz is used by
Pincer as the standard. This provides a resolution of 1msec for timing. The
signal is taken from a lemo cable to the qcr via the controlling sci.
The sci is required to control the qcr so that it does not count
continuously and can also provide gating. The OUT lemo signal(s) of the sci
GP1, 2 or 3 should be connected to the INHIBIT inputs or INHIBIT ALL input
of the qcr so that counting is started/stopped under s/w control of the sci
from Pincer. The OVERFLOWs of the qcr channels should be connected to the
STOP INPUTS of the sci. This ensures that when a qcr channel overflows,
counting is immediately stopped in h/w by the GP1-3 stop signals all
becoming active (low). The qcr chan 0 i.e. the timing channel address 0,
must be placed in the 1st STOP INPUT socket. This is because Pincer
monitors the sci status register for an end of timing bit 1 set which is
generated by the 1st STOP INPUT signal having become active. To ensure that
the qcr counting all starts on the 1st negative going pulse received from
the cpg, the cpg 1khz pulses are fed to the SYNC START input as well as
into chan 0 INPUT connector of the qcr.
The qcr has 4 24-bit registers which count negative going edges of TTL
pulses at the INPUT sockets. Internally channels may be set to NIM logic
but at least chan 0 must be set to TTL for counting the timing pulses.
Pincer does not support cascaded counters and so after 24 bits worth (~16
million) of counts the registers overflow and the OVERFLOW's become active
(low). Before a count, Pincer loads chan 0 with the negative 2's complement
of the dwell time required in millisecs and once enabled will count this
number of timing pulses before chan 0 overflows and the counting of all
channels is halted by the sci. Chans 1 - 3 have user defined signals set
to TTL or NIM as defined by the qcr h/w configuration which connect directly
to the INPUTs. Pincer does not allow a pre-set to be loaded into the non
timing channels at present and so they start counting from 0 each time.
A pre-set value can be loaded into qcr's before the count as defined by
the last value of the pre-set command. If this has not been carried out, the
pre-set defaults to zero.
Now cascaded scaling is supported which means 2 selected qcr channels
are hardware wired and software set to act as a single 48-bit counter. In
hardware the carry lemo of qcr1 is fed into the input of qcr2 and the
overflow of the qcr2 is used to feed into the input of the scaler inhibitor.
In software a 2nd qcr is specified in this file having the same name as the
1st qcr but having a device type of 2. By this means a cascaded scaling
unit can be set up either in the same CAMAC module or between 2 different
CAMAC modules. The max counts of a cascaded scaler is 31 bits i.e.
up to ~2*10^9 counts. The pre-set is set correctly if a device is found to
be cascaded.
After a count, the data remains in the qcr channels (0 for the timer) and
so can be read out when required and even during actual counting. The
channels are not cleared until the next timing period is started.
GPIB CAMAC is supported and can be easily switched to it on PC's by
setting the branch number for the device to a non-zero positive value
which is then taken to be the crate controller primary address "n". The
usual setting for n is 1. The device for the GPIB CAMAC must be set in
National Instruments AT-GPIB driver software to dev<n>. With a zero branch,
the CAMAC is Hytec 1330 on PC's or type A2 on OS-9 systems.
ctr_qcr.dat parameters
-----------------------
Name info
----- ----------------------------------------------------
no_of_qcr_ctrs_in_file No. of devices entered in this file
Name User name string of device (in ctr_gen.dat also)
Addr Subaddress of qcr scaler channels (unused by timer)
Branch /GPIB Camac system branch number (0 usually) but if not
zero is KS3988 GPIB CAMAC with this primary address
Crate Camac crate number (OS9=1, others=0)
Stn Camac station of device
min_hw_limit Low h/w unit limit used by timer in msec units
max_hw_limit High h/w unit limit used by timer in msec units
timer_dev Index of device type - timer must be 1, normal chan=0
and cascaded chan=2 with name matching existing 1st chan.
active Internal flag for now - set to 1 for all devices
Pincer CTR functions supported
-------------------------------
Kernal :
stop halt counting and timing
rdparam load ctr_qcr.dat parameters to memory
counta enable timer & counter and return immediately
counts enable timer & counter & wait for completion
getstat return current status
rdscaler read the scaler contents (active or not)
init check name, reset Camac crate and disable LAM's
trace list current active ctr_qcr parameters set
Extension :
pre-set load a pre-set value (limit) to scaler before count starts (not timer)

3
tfg 0 0 0 1 0 2560 1 1023
mcs 1 0 0 2 0 0 0 10
mcs5 5 0 0 2 0 0 0 1
---------------------------------------------------------------
This is ctr_tfc.dat - PC CAMAC counter-timer parameter file read by
the ctr_tfc_controller layer. Contents in hw units (pulses) :-
no_of_tfc_ctrs_in_file
Name Addr Branch Crate Stn min_hw_limit max_hw_limit timer_dev* nframes
string long long long long long long flag int
* timer in tfc code refers to the CAMAC TFG EC728 which controls the timing.
others are channel(s) in the CAMAC multichannel scaler EC727 which can
be addressed individually or in groups of frames if required, where
addr is the starting frame number and nframes specifies the channel size.
flags are set true if 1, false if 0.
----------------------------------------------------------------------------
CAMAC Time-Frame Generator/Multi-Channel Scaler Counter-Timers General Information
----------------------------------------------------------------------------
The hardware was designed and built at Daresbury and consists of 2 coupled
Camac modules :
a) Time Frame Generator tfg (EC728), Ian Sumner
b) Multi-channel Scaler mcs (EC727), Garath Derbyshire
These are linked via a private address bus and TTL control signals to
allow asynchronous counter-timing in real time to a microsecond resolution
with fast on-board data acquisition of the scaler counts to local memory.
The tfg is a allows precise data acquisition periods or "frames" to be
specified. These are of 2 types - "live frames" where coupled modules (e.g.
mcs or dl100 MCA memory) are allowed to collect data or "dead frames" where
the coupled modules are inhibited.
To specify a frame duration, two parameters are required. First a clock
period is set of 10 to the power n micro seconds where n has the range 0 -
7 i.e. periods of 1usec to 10sec. The second parameter sets the number of
such clock periods for the frame in the range 1 to 256. Thus the actual
time range possible is from 1usec to 2560 secs. Due to the storage method,
some count times may be rounded slightly and extension pincer functions are
available to read the adjusted user-unit times back.
The module has pairs of frames loaded as a composite command word in the
order dead then live frame for execution. Pincer only has one value for the
live and one value for the dead frame and this pair of command words is
loaded in the tfg up to the number of frames (pairs) requested. An extra
dead frame at the end has the stop bit set and so stops the tfg. There is
no use made of the 3 possible front-pannel pulse lemo's or the lap
facility. After loading, the tfg dos not start framing until the Pincer
"start" command which enables the unit via the Camac dataway. Once it is
framing, it goes at full speed asynchronously to Pincer which can monitor
progress by checks of the frame no. ("getfr") and status ("getstat").
The mcs is a 32-channel (24-bits) scaler which can collect TTL or ECL
pulses at full tfg speeds. It has on-board memory for storage of this
scaler data for each of the 1024 max live frames. The FRAMING of the tfg is
connected to the VETO of the mcs to prevent counting during dead frames and
the INHIBIT of the tfg is connected to the LOAD (= XFER) of the mcs causing
the scaler data to be written to on-board mcs memory at the start of the
dead frame. This takes a time of 500ns to enter the shadow registers and
from there 16 microsecs to memory. Thus dead frames in Pincer are set to
17usecs minimum. So that the correct memory address is written by the mcs,
a 14-way ribbon cable from the tfg carries the 10-bit live frame number to
the mcs. Reading of the scalers from Pincer is from the mcs memory and this
may not contain useful data if the framing is still active and has not
reached the live frame of interest at the time of inspection.
Standard Pincer ctr functions use only a single live frame and access to
the others requires the extension functions to be called. There is no need
to refer specifically to timer devices in macros as the ctr_tfc s/w
searches for the first timer device entered in this file in order to carry
out any operations relating to the mcs. The same is true of the non-timer
mcs devices. Pseudo mcs devices can be entered which have the start channel
for readout set to other than 1. The Pincer s/w reads from this start
channel to a maximum of either 32 or the size of the array passed from the
cli, whichever is the smaller. Thus channel data of interest can be read out
easily and faster.
After framing completion, the data remains in the mcs memory so it can
be read out when required and is not cleared until the next timing period
is started.
ctr_tfc.dat parameters
-----------------------
Name info
----- ----------------------------------------------------
no_of_tfc_ctrs_in_file No. of devices set in this file
Name User name string of device (in ctr_gen.dat also)
Addr start mcs scaler channel for readout (1st chan = 1)
Branch Camac branch number
Crate Camac crate number (OS9=1, others=0)
Stn Camac station of device
min_hw_limit Low h/w unit limit used by timer secs
max_hw_limit High h/w unit limit used by timer secs
timer_dev Index of device type - 1 is timer (tfg) type
nframes Max no. of live frames supported by this device
Pincer CTR functions supported
-------------------------------
Kernal :
stop halt counting and timing
rdparam load ctr_tfc.dat parameters to memory
counta enable timer & counter and return immediately
counts enable timer & counter & wait for completion
getstat return current status
rdscaler read the contents of a single scaler channel (active or not)
init check name, reset Camac crate and set modules esp. tfg status
trace list current active ctr_tfc parameters set
Extension :
loadfr load framing info live, dead, no. and returns rounded L/D periods
startfr given valid loaded parameters, starts the framing off
getfr returns current frame number from tfg lap/status register
maxfr returns max number of live frames available for this device
readfr returns an array of scaler channel data for a single chosen frame

0
7
96
3
timer TIMER 1 32767 1
hw1 SCALER 0 0 2
hw2 SCALER 0 0 2
---------------------------------------------------------------
This is ctr_hwc.dat - harwell ctr-tim parameter file read by
the hwc_controller layer. Contents in hw units (.1 of sec timer) :-
pc_rs232_port # (e.g. 0=com1, 1 = com2)
rs232_data_bits (dummy - a DOS mode command is needed outside program)
rs232_baud_rate (ditto)
no_of_harwell_devices_in_file
Name Axis min_hw_limit max_hw_limit device_type*
string string long_int long_int int [data types]
* Device types : 1=timer, 2=scaler
----------------------------------------------------------------------------
Harwell 6000 Counter-Timers General Information
-----------------------------------------
The Harwell 6000 is a crate based instrumentation system which includes
simple support for counter-timing. The type supported here depends on
the X-ray Spectrometer Control System 36415-2 which has an RS232 link
to the host computer (PC) for command writes and position and status reads.
Up to 2 scalers can be operated and a single timer and these must be set as
different device types in this parameter file.
The baud rate is fixed at 1200 (slow) and other params are no parity,
7 data bits and 1 stop bit. The handshaking is s/w only.
The ctr_tim commands are as follows :
START timer n starts timer for n * 0.1 sec & clears/starts scalers
READ timer reads timing interval remaining
STOP timer stops timer and scalers
STATUS timer returns current status 1=busy, 0=stopped
READ scaler reads contents of 2 scalers as a single 16-digit no.
Nasty Bugs in the Harwell system :
a) A timing interval of 0 will never end !!
b) No error messages appear if anything goes wrong e.g. bad command !!
f) I/face locks up if RS232 is unplugged - hard reset needed which
zeros all registers !!
ctr_hwc.dat parameters
-----------------------
Name info
----- -------------------------------------------------
pc_rs232_port Index of PC com port 0=com1, 1=com2
rs232_data_bits Not used. A DOS mode command is needed to set it
rs232_baud_rate Not used. A DOS mode command is needed to set it
no_of_harwell_devices_in_file No. of device entries in this file
Name User name string for ctr-tim
Axis Actual Harwell device name used in commands
min_hw_limit Timer only low h/w count limit
max_hw_limit Timer only high h/w count limit
device_type Index of device type - timer (1) or scaler (2)
Pincer CTR functions supported
-------------------------------
Kernal :
stop halt counting and timing
rdparam load ctr_hwc.dat parameters to memory
counta enable timer & counter and return immediately
counts enable timer & counter & wait for completion
getstat return current status
rdscaler read the scaler contents (active or not)
init check name & settle with dummy read
trace list current active ctr_hwc parameters set
Extension :

3
timer dev6 48 1 65535
mcc1 dev6 48 1 65535
mcc2 dev6 49 1 65535
---------------------------------------------------------------
This is ctr_mcc.dat - minicam ctr-tim parameter file read by
the mcc_controller layer. Contents in hw units of 10 msec :-
no_of_minicam_devices_in_file
Name GPIB_name MIC_addr min_hw_limit max_hw_limit
string string int long_int long_int [data types]
----------------------------------------------------------------------------
Bede Minicam Counter-Timers General Information
-----------------------------------------
This is the Bede Scientific Instrument Minicam Microcomputer Interface
system, known as "minicam" (short for minicamac though totally different in
every respect!). It consists of a controller and a crate of various modules
such as motors, counter-timers, ADC's etc. It is used widely at Strathclyde
University, Dept. of Pure and Applied Chemistry. The main features are
descibed below.
The mincam normally has a single GPIB primary address which is used for
all motor (and counter-timer operations, see file ctr_mcc.dat) operations.
In this mode, only 1 device in the whole minicam rack can be driven at any
one time. It is possible to have > 1 controller which would then allow
modules to be driven in parallel. The minicam controller status is returned
as a GPIB serial poll which is converted to the pincer BUSY or IDLE status.
No other status information is available and steps will be lost if e.g. a
limit is hit so this should be avoided - set min_hw_limit and max_hw_limit
to a sensible range.
The GPIB commands sent to the minicam are 7 binary bytes as follows :-
USR A% N% T%
1 byte 2 bytes 2 bytes 2 bytes
where USR = a function number for the required operation, for ctr-timers
the usr's needed are 2 for ctr-timing and 3 for reading
A% = module minicam (mic) address LSB,MSB
N% = this field is ignored with ctr-timers
T% = timing period in units of 10msec (range 1-65535 units)
LSB,MSB
The ctr-timers have 2 addresses for the 2 independant scalers involved
which are controlled by the same timer. Counting can be synchronous or
asynchronous and the end of timing can be seen with a "getstat" command when
an IDLE status is found. Unfortunately a BUSY status can result from another
minicam module such as a motor. Usually scalers can be read at any time by
Pincer but minicam does not allow this while the bus is busy (1 controller only).
If the bus is busy, the scaler data returned is the last value read and generates
no error, otherwise the scaler module is read out with usr=3.
The ctr-timers are driven in overlap mode to ensure that Pincer is not tied up
while the minicam bus is busy. This involves setting the MSB of the module
address to 1 in bit 0. In this mode the reply comes back immediately as a
dummy in the following 3 byte binary form which Pincer ignores and then again when
the timing period is over with usr=0 or at any time again with usr=3. This reply
is the actual 16-bit unsigned scaler read data as follows :-
A STATUS
2 bytes LSB,MSB as 0 1 byte as 0
The ctr_tim commands are as follows :
START dev n starts timer for n * 10 msec & clears/starts scalers
STOP dev dummy stops timer and scalers - can't be done
STATUS dev returns current minicam status 1=busy, 0=stopped
READ dev reads requested scaler contents but as minicam can't
actually read while the bus is busy the last value
read is returned as a dummy.
ctr_mcc.dat parameters
-----------------------
Name info
----- -------------------------------------------------
no_of_minicam_devices_in_file No. of device entries in this file
Name User name string for ctr-tim
gpib_name GPIB device driver name of minicam - usually dev6
mic_addr minicam address (2 per ctr-timer modules)
min_hw_limit low h/w count limit for timer
max_hw_limit high h/w count limit for timer
Pincer CTR functions supported
-------------------------------
Kernal :
stop halt counting and timing
rdparam load ctr_mcc.dat parameters to memory
counta enable timer & counter and return immediately
counts enable timer & counter & wait for completion
getstat return current status
rdscaler read the scaler contents (active or not)
init check name & settle with dummy read
trace list current active ctr_mcc parameters set
Extension :

12
tfg 5 1. 0. 0. n/a
tfg24 3 1. 0. 0. n/a
dl1 1 1. 0. 0. n/a
dl1a 1 1. 0. 0. n/a
mcs 3 1. 0. 0. n/a
mcs24 3 1. 0. 0. n/a
gmcs 3 1. 0. 0. n/a
gmcs24 3 1. 0. 0. n/a
tst 3 1. 0. 0. n/a
tst24 3 1. 0. 0. n/a
can 2 1. 0. 0. n/a
lc1 4 1. 0. 0. n/a
----------------------------------------------------------
This is mca_gen.dat generic MCA parameter file read by
the mca_controller layer. Contents in user units ("units") :-
no_of_generic_mcas_in_file
Name mca_type* gear_ratio offset rnding_fmca unit
string integer float float float string [Data types]
* device type index : 1 = PC Hytec i/face, 3512ADC, tdc-comb + DL100
2 = PC AT-bus i/face to PC Canberra MCA
3 = TCA RAW CAMAC i/o driver
4 = CAMAC LECROY 3512/3588 ADC/Hist mem combo
5 = GPIB/RS232 raw character i/o device
----------------------------------------------------------
Generic MCA General Information
-------------------------

This generic mca file provides an index of the specific mca hardware
type which controls the real mca and so results in code for that specific
type being called by the mca_gen code. The specific controller is then
responsible for carrying out all mca operations for that device.
Also it provides parameters for the conversion of user-units from the
cli to hardware units used by the specific mca controllers and back again
for values which are returned to the cli from the hardware layers.
The unit conversion equation h/w units = (user units - offset) * gear_ratio
is used but precision errors are possible. Thus a rounding factor also is
present to add if +ve or subtract if -ve and so round up/down). Unlike the
mca devices the conversion of user-hardware units and back is not automatic
but is invoked by the specific code only when needed.
mca_gen.dat parameters
-----------------------
Name info
------------------------------------------------------
no_of_generic_mcas_in_file No. of generic mca entries in this file
Name User name string of mca
mca_type Index of h/w type of mca (specific controller)
gear_ratio Gearing ratio for mca for calc user-h/w units
offset User unit position offset for calc user-h/w units
rnding_fctr Rounding factor to fix precision errors -> " "
unit String of user-unit name (a dummy normally)

1
can 4 4096 1 4096 1 2 4 1 100
----------------------------------------------------------
This is mca_can.dat - PC Canberra S100 MCA parameter file read by
the mca_can_controller layer. Contents in hw units :-
no_of_can_mcas_in_file
Name board spec_size min_chan max_chan type_dev* start_spec nspectra [contd]
string int int int int int int int
real_t_flag pre-set-time+
flag long
* dev_type integer specifies type of device either pseudomca or component unit
making part of a "logical" mca which generic layer treats as a single
name : -
type_dev unit
--------- ------------------------------------------------
1 Canberra master device type
2 spare
+ time pre-set for real or live time is in hw units of .01secs
flags are set true if 1, false if 0.
----------------------------------------------------------
Canberra S100 Board General
----------------------------
This is a full-length PC AT-bus card. It has board numbers 1-4 possible,
each hard linked to a port i/o base address. Choose 4 to avoid conflicts with
Hytec 1330 CAMAC card. Software uses Canberra BD100 and S100IO i/o libraries
as supplied.
MCA Data is collected by the board in a max of 16k channels, each of 32
bits capacity. This memory can be divided into spectra ("groups") up to 16
max. E.g. there may be spectra of 4k channels size and so there can be
spectra 1 - 4. On starting data acquisition, the spectra size must be given
and this is set by the mca_can.dat parameter "spec_size". The spectrum number
is set as "start_spec" where the data will be collected and so one device name
is needed for each spectra required if more than one is to be stored in the
board memory at any one time.
For spectrum readout, the "nspectra" parameter allows a number of spectra
to be examined from the board using the same device name. When a spectrum is
read out, the channel range read is derived from the "min_chan" and "max_chan"
parameters unless a specific range is requested by using the "readch" mca
function.
This complexity allows a number of pseudodevices to be set up with
different names which read different channel ranges of the same spectra
representing different diffraction peaks for example.
The board carries out timing of data collection in one of 2 modes : live
time (actual data conversion time) or real time (= elapsed time). These are
switched by the "real_t_flag" (real_time_flag = real time if non-zero). Units
are in .01 secs and the default value used is the parameter "preset_time". To
change this at run time the extension mca function "setpre" must be used. The
board only stores the values for the real and live times for the last data
collection episode once so these should be read each time by the extension
function "rdtime".
mca_can.dat parameters
-----------------------
Name info
----------------------------------------------------------
no_of_can_mcas_in_file set to number of device entries in file
Name string of device / pseudodevice. Also in mca_gen.dat
board set to number on board switch setting (1-4). 4 is best
spec_size set to size of whole spectra used for data collection
and "clearsp" function. Values possible 256,512,1024,
2048,4096,8192,16384. If unmatched, 4096 is used.
min_chan } set to region of interest (up to spec_size max) for
max_chan } "readsp" operation. 1st chan is numbered 1
type_dev only 1 available at present time
start_spec spectrum number (from 1) for data to be collected in
nspectra max no. of spectra possible to read from this device
real_t_flag if non-zero used real (elapsed) time, otherwise live
pre-set-time default time for real/live time in .01 secs units
Pincer MCA functions supported
-------------------------------
Kernal :
stop stops the canberra data acquistion if active
start starts Canberra data acquisition with set pre-set time
readsp read specified spectrum from board (even if active)
readch read specific channel range for a spectrum (even if active)
getstat get current Canberra status (busy/idle/error)
clearsp clear whole spectrum
maxch return device spectrum range
maxsp return max spectra onf this
trace return max spectra of this device
init check board is available and get status
rdparam load mca_can.dat parameters to memory
Extension :
rdtime read last data acquisition real and live time
setpre set new pre-set time (real/live time as set)

1
tfg dev6 2 2 10 0 2 10 13 96 e 7 1
----------------------------------------------------------
This is mca_cio.dat - raw GPIB/RS232 parameter file read by
the mca_cio_controller layer. Contents in hw units :-
no_of_cio_mcas_in_file
name GPIB rs232_mode* RS232! termin ntermin ntailch [tail ..
dev_name port char chars after remov chars, if set]
string string int int int int int [tail1 tail2 ..] ..
baud parity databits stopbits
e.g.96 n,e,o
int char int int
flags are set true if 1, false if 0.
* 0=raw GPIB, 1=raw RS232, 2=RS232 via IOTEC 4-port GPIB-RS232 box
! The port nos are PC 0-3 com1-com4, GPIB 1-4 port 1-4, OS-9 0-5 ports 1-6
(NB the port(s) must be enabled for pincer i/o outside the program).
----------------------------------------------------------
RAW / TEST GPIB/RS232 CONTROLLER CIO "MCA"
------------------------------------------
This is not a normal MCA device but resides here for convenience. It is a
device which allows GPIB/RS232 modules to be tested and new ones added to the
system and rapidly programmed using macros instead of having new controller
software hard-coded into Pincer. This allows novel experiments to be carried
out on a temporary basis without affecting the core Pincer program. The MCA
device was chosen because raw CAMAC TCA also resides here. A new function
"stringio" has been provided for user-controlled raw i/o in association with
parameters set in the file mca_cio.dat which controls whether GPIB or RS232
interface is selected and how the reply string is to be collected and
manipulated before return to the Pincer call.
The cio syntax for a GPIB/RS232 cycle is as follows :-
mca stringio <CIO_device_name> <command_string> <nreply_chars> = <reply_string_var>
The device is made active with rdparam and init as other devices but only
the readch is thereafter available together with the normal trace.
mca_cio.dat parameters
-----------------------
Name info
---------------------------------------------------------
no_of_cio_mcas_in_file set to number of device entries in file
Name string of device name
Branch GPIB/RS232 branch number
Crate GPIB/RS232 crate number
Stn GPIB/RS232 station number
cfsa_cycle flag for true if 24-bit cycle or false for 16-bit cycle.
GPIB_CAMAC Allows Kinetic Systems 3988 GPIB/RS232 controller to be set
if non-zero with GPIB primary address as this number.
The NI AT-GPIB PC card must have name "dev<prim_address>"
e.g. dev1 for 3988 GPIB primary address of 1.
Pincer MCA functions supported
-------------------------------
Kernal :
stringio do a GPIB/RS232 i/o operation specifying input string, no. of reply chars
required (max) and giving a string variable for the return string.
trace list all generic mca parameters plus specific ones for this device
init check board is available and get status
rdparam load mca_cio.dat parameters to memory and initialise all devices found
Extension :

2
lc1 1 0 0 1 4000 1 4000 1 4
adc 1 0 0 2 4000 0 0 2 4
----------------------------------------------------------
This is mca_lhm.dat - PC CAMAC LeCroy 3512/3588 parameter file read by
the mca_lhm_controller layer. Contents in hw units :-
no_of_lhm_mcas_in_file
Name St_spec Branch Crate Stn spec_size min_chan max_chan type_dev* nspectra
string long long long long long long long int int
* dev_type integer specifies type of device either pseudomca or component unit
making part of a "logical" mca which generic layer treats as a single
name : -
type_dev unit
--------- ------------------------------------------------
1 L3588 - LeCroy 3588 histogramming memory unit
2 ADC3512 - LeCroy 3512 ADC
flags are set true if 1, false if 0.
----------------------------------------------------------
LeCroy 3512 ADC / LeCroy 3588 HISTOGRAMMING MEMORY
---------------------------------------------------
This MCA consists of 2 CAMAC modules, the LeCroy 3512 ADC (with peak
detect) and the LeCroy 3588 histogramming memory both connected via a 50-way
3M ribon connector (3588-bus). This bus allows data acquisition to take place
between the 2 modules independant of the CAMAC bus and control software.
In all operations a check is made that the appropriate device type for the
function requested has been specified. If this is not the case then the known
device list (as read from mca_lhm.dat) is searched and the first device found
with the required type is used. Only two types exist but pseudo-mca's can be
set to different spectral blocks or regions of interest in the memory.
The clear function clears the complete 3588 memory. The start function
carries out the following sequence of events. Firstly the 3588 is enabled
for data acquisition via the front-pannel. Lastly the adc is enabled with an
offset of 0 and a gain (no. of channels) specified by the matched value of
the "spec_size" parameter (default 4000). When this has all been executed
correctly then an active flag is set to show that the module has been
enabled. It is good practise to stop the mca device prior to collecting data
just in case the last scan has been aborted and the flag left to active. This
would otherwise protect the 3588 memory from clearing and modification by
further data acquisition episodes. Assuming that valid data is input to the
adc, the spectrum is collected in the memory block corresponding to the
current "St_spec" selected and the converted input adc voltage results in the
incrementing of the channel scaled to its position within the range of the
adc descriminator settings. The spectra can be read out one at a time with
"readsp" or particular regions of interest can be read out with "readch" or
alternatively a device can be set with parameters corresponding to a region
of interest i.e. a "pseudomca" which can be read out simply with "readsp".
The readout can be done at any time although if data is being acquired, it is
not guaranteed to be correct where there is a channel i/o conflict.
The 3588 memory consists of 16kwords (24-bits) and so more than 1 spectrum
can be stored / collected at any one time. It has been set up so that there
are 4 blocks i.e. max 4 spectra in the memory and while 1 is being collected
3 others can be stored. In order to do this an ADC device must be declared with
"St_spec" set to the required spectrum numbers needed. Thus for full data
collection there must be 4 adc devices with st_spec values 1 to 4. Care
must be taken with the control macros, however, as a "cleasp" function clears
the whole memory not just a single spectrum.
For spectrum readout, the "nspectra" parameter allows up to 4 spectra
to be examined from the board using the same device name. When a spectrum is
read out, the channel range read is derived from the "min_chan" and
"max_chan" parameters unless a specific range is requested by using the
"readch" mca function.
This complexity also allows a number of pseudodevices to be set up with
different names which read different channel ranges of the same spectra
representing different diffraction peaks for example.
Diagnostics
------------
Test data can be put into the ADC input from a pulse generator i.e. 5V max
ttl pulses. This results in data appearing in about 5 channels around channel
1500 for a 4000 channel spectrum. The ADC should be set to pd peak-detect,
anti-coincidence mode and +ve polarity. When converted data is entering the
3588 memory, a red light can be seen at the "external access" LED.
mca_lhm.dat parameters
-----------------------
Name info
----- ----------------------------------------------------
no_of_lhm_mcas_in_file set to number of device entries in file
Name string of device / pseudodevice. Also in mca_gen.dat
St_spec start spectrum 1-4 for ADC daq and memory readout
Branch CAMAC branch number
Crate CAMAC crate number
Stn CAMAC station number
spec_size set to size of whole spectra used for data collection
ADC device supports 250,500,1000,2000,4000,8000 chans
If there is no match of the given value, 4k chans set.
min_chan } set to region of interest (up to spec_size max) for
max_chan } "readsp" operation. 1st chan is numbered 1
type_dev index of component module type 1-2 3588,ADC3512
nspectra max no. of spectra possible to read from this device
4 defined by the max memory capacity for 4k spectra.
(for 8k spectra this will be only 2!)
Pincer MCA functions supported
-------------------------------
Kernal :
stop stops the lhm data acquisition if active
start starts Lhm data acquisition under control of tfg EC728
readsp read specified spectrum from board (even if active)
readch read specific channel range for a spectrum (even if active)
getstat get current Lhm status (busy/idle/error)
clearsp clear spectra specified from spectrum 1 to nspectra
maxch return device spectrum range - start and end channels
maxsp return max spectra of this device
trace list all generic mca parameters plus specific ones for this device
init check board is available and get status
rdparam load mca_lhm.dat parameters to memory and initialise all devices found
Extension :

2
mxia 1 0 0 1 3000
mxib 2 0 0 2 3000
----------------------------------------------------------
This is mca_mxi.dat - raw VME-MXI parameter file
the mca_tca_controller layer. Contents in hw units :-
no_of_mxi_mcas_in_file
Name AddrSp AccPriv ByteOrder DataSize Timeout
string unsigned unsigned flag unsigned int
Most of the values above are codes of some description. Their meanings are
as follows :
VME Address Space - AddrSp
A16 - 1
A24 - 2
A32 - 3
VME Access Privelige - AccPriv
Non-Priveliged Data - 0
Priveliged Data - 1
Non-Priveliged Program - 2
Priveliged Program - 3
Non-Priveliged Block - 4
Priveliged Block - 5
Byte Order - ByteOrder
Motorola - 0
Intel - 1
Data Item Size - DataSize
Byte - 1
Word - 2
Long - 4
Time Out Delay - Timeout
Time out delay in ms.
----------------------------------------------------------
VME-MXI RAW DEVICE
------------------
This device provides generic VME access using a National Instruments MXI interface system, and the NI VXI software. It functions in a similar way to the tca (Test CAmac) "mca" device. As with the tca device access is performed using the mca readch command. This takes the following format :
mca readch <dev> <access mode> <vme address> <no. of items> = <data>
These parameters are as follows :
<dev> - Device name
Specifies the name of a device in this file (and mca_gen.dat).
<access mode>
In order to provide high performance data transfers, a number of different block modes have been programmed into PINCER to avoid any need for relatively slow command interpreter read/write loops. As well as specifying the block mode this parameter also selects whether to read or write data. It can take the following values :
0 - Read repeatedly from the same vme address into subsequent elements in the data array starting at the beginning, and reading <no. of items> values.
1 - Write repeatedly to the same vme address from the elements in the data array starting at the beginning, and reading <no. of items> values.
2 - Read from a series of vme addresses (beginning with the specified address, and then going up in steps of 1, 2 or 4 depending on the size of data being read) into the data array.
3 - Write to a series of vme addresses (beginning with the specified address, then going up in steps of 1, 2 or 4 depending on the size of data being read) from the data array.
4 - Read repeatedly from the same vme address into the first element of the data array.
5 - Write repeatedly to the same vme address. For the first cycle write the value of the first element in the data array, for the second write that value + 1, for the third that value + 2, etc.
<vme address>
The address in vme address space at which to read/write.
<no. of items>
The number of data items to read or write. The exact meaning of this parameter depends on the access mode. Note that in modes which make use of more than one element in the data array will stop if they reach the end of the array, even if this value is bigger.
<data>
An array of data to read/write. This needs to be a numeric array. Note that even though it is an output parameter on the command line, its exact role (as regards being read from or written to) depends on the access mode.
PINCER MCA functions supported
------------------------------
readch - read/write from/to vme address space.
trace - list all generic mca parameters plus specific ones for this device.
init - check board is available and get status.
getstat - get status.
rdparam - load mca_mxi.dat parameters to memory and initialise all devices.
setaddr - allows setting of the data size (same meaning as in this file).

4
dl1 0 0 0 1 4096 1 4096 1 512
dl1a 0 0 0 9 4096 11 20 1 1
adc 0 0 0 2 4000 0 0 2 1
tdc 0 0 0 3 4096 0 0 3 1
----------------------------------------------------------
This is mca_pdl.dat - CAMAC DL100/ADC/TDC MCA parameter file read by
the mca_pdl_controller layer. Contents in hw units (pulses) :-
no_of_pdl_mcas_in_file
Name Addr Branch Crate Stn spec_size min_chan max_chan type_dev* nspectra
string long long long long long long long int int
* dev_type integer specifies type of device either pseudomca or component unit
making part of a "logical" mca which generic layer treats as a single
name : -
type_dev unit
--------- ------------------------------------------------
1 DL100 - dl100 memory controller EC601 (with memory)
2 ADC3512 - LeCroy 3512 ADC
3 TDCCOMB - EC652 TDC-combiner
4 ADCUDS - Garath Derbyshire UDS digitizing ADC in VME (future)
flags are set true if 1, false if 0.
----------------------------------------------------------
PDL DL100 / TDC combiner / LeCroy 3512 MCA combo
-------------------------------------------------
This MCA consists of 3 CAMAC modules, the Dl100 memory controller EC601
with memory, the LeCroy 3512 Histogramming memory (with peak detect) and the
TDC combiner EC652 which connects them together.
For data acquisition to occur, a time-frame-generator (tfg) EC728 must also
be present in the system to provide control and live frame address via the TDC
combiner setting the memory area in the DL100 memory where the data is
acquired. Once the PDL is ready to go the starting of the tfg is needed or no
data is collected. As the tfg is a ctr type device it is not included here and
other units may depend also on it elsewhere e.g. multi-channel scaler EC727.
For more EC728/EC727 details, see the document ctr_tfc.dat.
In all operations a check is made that the appropriate device type for the
function requested has been specified. If this is not the case then the known
device list (as read from mca_pdl.dat) is searched and the first device found
with the required type is used. Thus the full device for the dl100 memory with
the maximum spectra (= live TFG time frames) should be the first dl100 device
in the list.
The clear function of the dl100 clears the memory from channel 0 of the
memory to the end of the 1st spectrum and repeats for the number of spectra
specified by "nspectra". Effectively the whole memory is cleared therefore.
DMA channel 1 is used for this function with the EC601. The start function
carries out the following sequence of events. Firstly the dl100 is enabled
for data acquisition using the front pannel direct memory modify mode (DMM)
which involves DMA channel 1. Next the tdc combiner module is set for DMM mode
after a match of the spectra size required "spec_size" (default 4094
channels). Lastly the adc is enabled with an offset of 0 and a gain (no. of
channels) specified by the matched value of the "spec_size" parameter (default
4000). When this has all been executed correctly then an active flag is set
to show that the module has been enabled. It is good practise to stop the
dl100 device prior to collecting data just in case the last scan has been
aborted and the flag left to active. This would otherwise protect the dl100
memory from clearing and modification by further data acquisition episodes.
Data will not actually be acquired until the TFG has been started and is
framing at a live frame location. Assuming that valid data is input to the
adc, the spectrum is collected in the memory block corresponding to the
current live frame and the converted input adc voltage results in the
incrementing of the channel scaled to its position within the range of the adc
descriminator settings. The spectra can be read out one at a time with
"readsp" or particular regions of interest can be read out with "readch" or
alternatively a device can be set with parameters corresponding to a region of
interest i.e. a "pseudomca" which can be read out simply with "readsp". The
readout uses dl100 DMA channel 2 and so can be done at any time although if
data is being acquired, it is not guaranteed to be correct where there is a
channel i/o conflict.
For spectrum readout, the "nspectra" parameter allows a number of spectra
to be examined from the board using the same device name. When a spectrum is
read out, the channel range read is derived from the "min_chan" and "max_chan"
parameters unless a specific range is requested by using the "readch" mca
function.
This complexity allows a number of pseudodevices to be set up with
different names which read different channel ranges of the same spectra
representing different diffraction peaks for example.
Module Setups
--------------
1) ADC3512 input from solid-state detector (SSD) coaxial cable
50-way 3M ribbon cable 3588 bus output to EC652 TDC1 socket
NB this is modified i.e. pin1 cut, pins 43-50 set to ground.
mode is peak-detect and +ve polarity and anticoincidence
2) EC652 input 3588 bus from ADC in TDC1 socket
3 chip socket connectors at base connect to EC601 front pannel
edge connectors.
mem sync lemo connects to sync of EC601 front-pannel
lemo from PPR sync to TFG inhibit socket
DIL connector ribbon cable to front pannel of TFG (modified
so pin9 disconnected)
3) EC601 front pannel input edge connector from chip sockets of EC652
front pannel lemo sync from mem sync of EC652
rear 3M 40-way ribbon cables to 1Mword EC669 24-bit memories
4) TFG EC728 lemo from inhibit front pannel to PPR sync lemo of EC652
14-way ribbon cable to DIL connector on side of EC652 (modified
so pin9 disconnected)
Diagnostics
------------
As will be gathered the system is a complex one but some help can be gained
from the following information. Test data can be put into the ADC input from a
pulse generator i.e. 5V max ttl pulses. This results in data appearing in
about 5 channels around channel 1500 for a 4000 channel spectrum. The TFG is
seen to be framing ok by a steady green inhibit light during a live frame and
a red framing led flash at the start of a live frame of each live frame. When
the TDC combiner is enabled, the green enable 1 is lit and NB the ready led is
lit when valid data is being written to the memory from the TDC combiner.
mca_pdl.dat parameters
-----------------------
Name info
----- ----------------------------------------------------
no_of_pdl_mcas_in_file set to number of device entries in file
Name string of device / pseudodevice. Also in mca_gen.dat
Addr not used at present
Branch CAMAC branch number
Crate CAMAC crate number
Stn CAMAC station number
spec_size set to size of whole spectra used for data collection
and clearing if a DL100 memory device :-
ADC device supports 250,500,1000,2000,4000,8000 chans
TDC supports 256,512,1024,2048,4096
If there is no match of the given value, 4k chans set.
min_chan } set to region of interest (up to spec_size max) for
max_chan } "readsp" operation. 1st chan is numbered 1
type_dev index of component module type 1-3 DL100,ADC,TDC comb.
nspectra max no. of spectra possible to read from this device
corresponding to live frames set in tfg EC728
Pincer MCA functions supported
-------------------------------
Kernal :
stop stops the pdl data acquisition if active
start starts Pdl data acquisition under control of tfg EC728
readsp read specified spectrum from board (even if active)
readch read specific channel range for a spectrum (even if active)
getstat get current Pdl status (busy/idle/error)
clearsp clear spectra specified from spectrum 1 to nspectra
maxch return device spectrum range - start and end channels
maxsp return max spectra of this device
trace list all generic mca parameters plus specific ones for this device
init check board is available and get status
rdparam load mca_pdl.dat parameters to memory and initialise all devices found
Extension :

6
tfg 0 0 1 0 0
tfg24 0 0 1 1 0
mcs 0 0 8 0 0
mcs24 0 0 8 1 0
gmcs 0 0 8 0 1
gmcs24 0 0 8 1 1
----------------------------------------------------------
This is mca_tca.dat - raw CAMAC parameter file read by
the mca_tca_controller layer. Contents in hw units :-
no_of_tca_mcas_in_file
Name Branch Crate Stn cfsa_cycle GPIB_CAMAC *
string long long long flag int
flags are set true if 1, false if 0.
* If zero Hytec 1330 or CES type A2 controller, else GPIB 3988 CAMAC
cntr and val=gpib primary address
----------------------------------------------------------
RAW / TEST CAMAC CONTROLLER TCA "MCA"
--------------------------------------
This is not a normal MCA device but resides here for convenience. It is a
device which allows CAMAC modules to be tested and new ones added to the
system and rapidly programmed using macros instead of having new controller
software hard-coded into Pincer. This allows novel experiments to be carried
out on a temporary basis without affecting the core Pincer program. The MCA
device was chosen because the command line parameters to "readch" are enough
to specify a CAMAC cycle. The tca syntax for a CAMAC cycle is as follows :-
mca readch <dev> <CAMAC_function_code> <Module_subaddress> <input_data> = <vector>
where <vector> is an array of minimum dimension 2 to return <output_data> and
<q_response_flag> of the operation. A cycle is either read or write but all the
parameters must be specified as above in either case.
The name string dev must consist of a CAMAC module name in the mca_tca.dat
file and from that other parameters are assumed for the CAMAC cycle. These are
the branch, crate, station and size of the cycle i.e. 24-bit i/o for cfsa_cycle
true and 16-bit i/o for cfsa_cycle false. In addition to a dedicated CAMAC
interface (HYTEC 1330 for PC, CES A2 on OS-9) there is support for GPIB type
of controller i.e. Kinetic Systems 3988 as set in the GPIB_CAMAC where a non
zero value means GPIB type and the number is the primary address n which derives
a GPIB device driver name of "devn". Currently, only the PC platform has GPIB
support via the National Instruments NI AT-GPIB card and software.
The device is made active with rdparam and init as other devices but only
the readch is thereafter available together with the normal trace. In
general, 2 entries per CAMAC module are needed in the mca_gen.dat and this
mca_tca.dat for 16 and 24 bit CAMAC cycles named conveniently to reflect this
as e.g. tfg and tfg24.
mca_tca.dat parameters
-----------------------
Name info
----- ----------------------------------------------------
no_of_tca_mcas_in_file set to number of device entries in file
Name string of device name
Branch CAMAC branch number
Crate CAMAC crate number
Stn CAMAC station number
cfsa_cycle flag for true if 24-bit cycle or false for 16-bit cycle.
GPIB_CAMAC Allows Kinetic Systems 3988 CAMAC controller to be set
if non-zero with GPIB primary address as this number.
The NI AT-GPIB PC card must have name "dev<prim_address>"
e.g. dev1 for 3988 GPIB primary address of 1.
Pincer MCA functions supported
-------------------------------
Kernal :
readch do a CAMAC cycle with normal MCA parameters specifying the CAMAC
functions as Function code, subbaddress, input_data and an output
array for the return of the output_data and q-response flag.
trace list all generic mca parameters plus specific ones for this device
init check board is available and get status
rdparam load mca_tca.dat parameters to memory and initialise all devices found
Extension :

4
ox1 1 10. 0. 0. Kelvin
ox2 1 10. 0. 0. Kelvin
eur1 2 1. 0. 0. Kelvin
eur2 2 1. 0. 0. Kelvin
----------------------------------------------------------
This is tem_gen.dat generic temperature contr parameter file read by
the tem_controller layer. Contents in user units ("units") :-
no_of_generic_temp_devices_in_file
Name tem_type* gear_ratio offset rnding_fac unit
string integer float float float string [Data types]
* temp type index : 1 = Oxford Instruments ITC4 via RS232
2 = Eurotherm 900 EPC via RS232

2
2
ox1 1 1 10 1
ox2 2 11 20 1
----------------------------------------------------------
This is tem_itc.dat - Oxford Instr ITC4 temp contr parameter file read by
the tem_itc_controller layer. Contents in hw units :-
no_of_itc_tems_in_file (int)
RS232 interface port # on PC : 0-3 = com1 - com4 (int)
Name sensor# min_tem max_tem type_dev* [for each named tem device]
string long long long int
* dev_type integer specifies type of device either pseudoitc4 or component unit
making part of a "logical" itc4 which generic layer treats as a single
name (e.g. each sensor is a pseudoitc of type 1) : -
type_dev unit
--------- ------------------------------------------------
1 Oxford Instruments ITC4 temperature controller
flags are set true if 1, false if 0.

2
0
eur1 1 0 1 1 10 1
eur2 2 0 1 11 20 1
----------------------------------------------------------
This is eur_itc.dat - Eurotherm 900 EPC eur contr parameter file read by
the eur_itc_controller layer. Contents in hw units :-
no_of_itc_eurs_in_file (int)
RS232 interface port # on PC / OS-9 : 0-3 = com1 - com4 (int)
Name loop# gid uid min_eur max_eur type_dev* [for each named eur device]
string long long long long long int
* dev_type integer specifies type of device either pseudo eur or component unit
making part of a "logical" eur which generic layer treats as a single
name (e.g. each sensor is a pseudoeur of type 1) : -
type_dev unit
--------- ------------------------------------------------
1 Eurotherm 900 IPC single controller loop device
flags are set true if 1, false if 0.

4
pr1 1 1. 0. 0. Tonnes
pr2 1 1. 0. 0. Tonnes
pr3 2 1. 0. 0. Tonnes
pr4 2 1. 1. 0. Tonnes
----------------------------------------------------------
This is pre_gen.dat generic pressure contr parameter file read by
the pre_controller layer. Contents in user units ("units") :-
no_of_generic_pre_devices_in_file
Name pre_type* gear_ratio offset rnding_fac unit
string integer float float float string [Data types]
* pre type index : 1 = Dennisson PC control system (accessed by RS232)
2 = Spare

2
2
pr1 1
pr2 1
----------------------------------------------------------
This is pre_hyd.dat - Hydraulic press controls contr parameter file
for Denison PC press programmer and VME strain guage readout (Datel).
read by the pre_hyd_controller layer. Contents in hw units :-
no_of_pre_hyds_in_file (int)
RS232 interface port # : 0-3 = port no 1 - port no 4
Name type_dev* [for each named hyd device]
string int
* dev_type integer specifies type of device either pseudo hyd or component unit
making part of a "logical" hyd which generic layer treats as a single
name (e.g. Strain guage devices are pseudohyd type 2) : -
type_dev unit
--------- ------------------------------------------------
1 Denison PC programme device type (RS232 link)
2 Datel VME card (ADC) strain guage device type
flags are set true if 1, false if 0.

10. References

[1]. "Portable Data Acquisition Software based on a powerful Command Interpreter and Object Oriented Hardware Control", M.C.Miller, K.Ackroyd and G.Oszlanyi. Presented at ESONE Real-time Data Conference (RTD94), Dubna, Russia 27th - 31st July 1994 and Daresbury Laboratory Preprint DL/CSE/P29E.
2. "SRS Station 2.3 Manual", C.C.Tang, M.C.Miller, E.J.Maclean. CLRC Technical Report DL-TR-98-001, March 1998.
3. "A Novel X-ray Diffractometer to Study the Texture of Materials", C.C.Tang, M.C.Miller, S.M.Clark, M.A.Player and G.R.G.Craib. Accepted for J. Synchrotron Rad. 1996 (in press).