							6 July 1986

		Support For the 192 Multiwire Controller
		------- --- --- --- --------- ----------

     There are two types of database devices for the 192: those which
retrieve single calculated values for the parameter page and those which
support the specialized multiwire programs.  These two types of devices
have different SSDNs and are supported by different front end device
drivers.

     At the current time this document describes only the parameter
page devices.  Support for the special application page will be added
shortly.


			Parameter Page Devices
			--------- ---- -------

     Every multiwire paddle ends up with 8 database entries.  There is
one each for calculated mean, sigma, chi squared, and area.  The set of
four is entered twice: once for the vertical wires and once for the
horizontal wires.  A 192 card can support up to 4 paddles, which have
32 database devices. 

     The Reading property addresses the 192 card to retrieve the
calculated values, but the Basic Status and Basic Control properties
address the 184 card connected to the motors and limit switches.  It is
possible (it wasn't obvious) to support the motors and limit switches
with normal 184 card services.  Thus a parameter page multiwire device
will have one format for the 192 card Reading property and another for
the 184 card status and control properties. 

     We note a potential difficulty here.  The 192 card, in addition to
the 184 card, also knows the status of the various wires.  When we
decide whether to return a given calculated datum we rely upon the 192's
version of which wires are actually available.  However the operator
gets to see only the 184's version of the state of the world. 

     I ultimately decided to address the 184 card directly for two
reasons:

	1) The motors are controlled only by the 184 card, which
	   raises the possibility of the opposite discrepancy if
	   we read the status from the 192 card.

	2) The 192 card is run by a microprocessor, while the 184
	   card is (more reliable) dumb hardware.

     Neither of these is compelling and I am open to requests to read the
positions of the wires from the 192 card instead.


Reading Property
------- --------

     The SSDN for the Reading property ONLY looks like this:


		+-------------------------------+
		|		0		|
		+-------------------------------+
		|    4B (hex)	| OID = 4B (hex)|
		+-------------------------------+
		|      crate	|      slot	|
		+-------------------------------+
		|    4B (hex)	|   sub-code	|
		+-------------------------------+


     Where the "sub-code" is 8 bits like this:

	XXowwwcc

	c = channel 0 - 3
	w = which calculated value:
		0 = mean * 10
		1 = sigma * 10
		2 = area
		3   (error)
		4 = max ADC value
		5 = chi sq. * 10
		6 = zero adjustment
		7 = out/horizontal/vertical
	o = orientation: 0=horizontal  1=vertical


     Although not all the calculated values have been requested the 
capability exists to define devices to retrieve any of them.

     When the console requests one of the calculated values on a plot
or a parameter page the front end needs to take care of the following
issues:

	1) Return data from each booster cycle exactly once.
	2) Do something meaningful in the periods where there
	   is no beam.
	3) Return an error if the requested wires are not
	   actually in the beam.

     The first problem arises because there is no natural
synchronization between beam pulses and front end data collection.  Even
if the front end tried to synchronize data collection with clock events,
there would be no guarantee that the 192 card would complete its
calculations in a predictable time. 

     Fortunately the 192 card keeps track of which beam pulses have been
collected and processed during the current cycle.  The general approach
of the front end is to remember the last beam pulse reported to the
console and to try to report them all in order.  If the 192 gets ahead
of the front end then the data remains stored in 192 memory; if the
front end gets ahead of the 192 then the front end will delay a bit and
simply not return a value for a moment. 

     It is my belief that as long as data is requested at 15hz then
this scheme should work famously.  If data is requested at some slower
rate then values may be missed, but there is no help for it.  At least
it should behave in a graceful manner.

     When there is no beam, and the last calculated value has been
returned from the previous cycle, then the front end will repeatedly
return that last value.  This is necessary to get meaningful values onto
the parameter page, although it may look funny on a slow time plot. 

     The 192 card helpfully provides two Camac commands, one for
horizontal and one for vertical, which will No-Q if the wires are not
oriented correctly.  I intend to use these commands.  The result will be
that if you are trying to plot, say, horizontal data, and the paddle is
not in horizontally, then you will get an error.  Unfortunately the only
error the 192 card returns in this case is No-Q, which is too general. 
It may, for instance, indicate a dead card.  Thus when the front end
gets this error it needs to disambiguate it by reading the wire status. 
If, in fact, the No-Q was caused by a wire being out of position, then
it will return error code -67. 

     
Basic Status Property
----- ------ --------

     The Basic Status uses a 184 style SSDN.  The important parameters
in the SSDN are:

	A) The MASK identifies which hardware bits are used for
	   this device.  The multiwires in Ducar's writeup are
	   therefore assigned masks of:

		000F	Motor 1 (a.k.a. channel 1)
		00F0	      2
		0F00	      3
		F000	      4

	B) The SHIFT bit should be on.  This will ensure that the status
	   for EACH of the 4 motors is right-justified, so that they all
	   look IDENTICAL.

     Using the above convention every parameter page device will have
the same 4-bit long basic status.

     What I am saying here is that the information as to which 184 bits
are assigned to which motor is buried within the mask field of the SSDN.
		
     There is a systematic difference between the horizontal and vertical
orientations which has to be reflected in the PDB for basic status.  This
shows up, for instance, in the ON mask which will be '80'x for the
horizontal devices and '40'x for the vertical devices.


Basic Control
----- -------

     The SSDN for Basic Control is also a 184 style SSDN.  Again, we
make use of the MASK and the SHIFT to regularize the data.  In this
case the masks are:

	0003	Motor 1
	0030	Motor 2
	0300	Motor 3
	3000	Motor 4

     With the Shift bit set all basic control will be right-adjusted to
a small integer.  This enables you to set up your PDBs thusly:

	Horizontal Device ON mask:  1
			  OFF       0

	Vertical Device   ON Mask:  3
			  OFF       0

     This will enable you to move paddles into or out of the beam from
the parameter page.


EMC
---

     The EMC will be 'attached' to the 184 card.  Do not worry about
the 192 card not having any labels on page D20: the devices for Glenn's
page will take care of it.

     One reason for attaching the EMC to the 184 card is that digital
alarms, if you should desire them, are automatically available.  You just
have to include a digital alarm property.

     The first byte of the EMC (the low order byte of the first word)
is the front end node number:

	16 (hex)  Dec-BS
	18        Dec-T
	1A	  Dec-S
	1B	  Dec-P

     The second byte of the EMC (the high order byte of the first word)
is a constant 2.

     The rest of the EMC is an EXACT COPY of the last 3 words of the
BASIC STATUS SSDN.
