26 April 1985

Rod:

     I've been working on the BPM mux implementation.  I am
embarrassed when I note the September 1983 date on your letter.
Here is what I am doing.  Sing out if you have other ideas.

     The idea is to pack enough information into a single SSDN
to enable you to handle all BPM and BLM systems easily.  You thus
get to plug the following information into your data base entry:

	House code and module type (for Gas setup operation)
	MADC number and channel (for analog readback)
	Gas T and N for the setup stanc.
	BPM or BLM channel number for setup operation.

     In order to make it all fit I made some simplifications:

	A (aspect) is zero
	C (count) and BC (byte count) are one
	N fits in a nibble (N=0-15)
	BPM or BLM Channel number fits in a nibble


     The whole SSDN thus looks like this:

	+-------------------------------+
	| MADC channel	| MADC number	|  Like a normal A/D
	+-------------------------------+
	| 00 (hex)	| 33 (hex)	|
	+-------------------------------+
	| Gas modul type| Gas house code|  Like a GSSET call
	+-------------------------------+
	| Stanc T	|Stanc N| chan	|
	+-------------------------------+
		^	    ^	   ^
		|	    |	   |
		|	    |	   +------ BPM or BLM channel
		|	    +------------- 0 or 1 for BPM mux,
		|			     	0 for BLM mux.
		+------------------------- 8 for BPM, 41 or 61
						for BLM.


     This should let you assign all the horizontal detectors to
one channel and all the vertical detectors to the other. 

     My current thinking is that whenever a new request competes
with a currently running channel the new request wins. The issue
is whether to return an error to the earlier request, which is
expensive for me to program, or just ignore the issue, which will
probably work. 

     This is already partly coded.  I can finish it off on Monday.
Let me know if you have any thoughts or if I have goofed in some
way.
	
				Michael Glass