[Halld-tagger] Voltage control for microscope

[Richard Jones]

Hovannes,

These voltages are maintained as read/write registers on the control boards in groups of 30 per board.  The time to read or write a complete voltage array is on the order of a millisecond, including the overhead of transmitting the packets on 10Mb ethernet and receiving a replies.  All of the details of the protocol can be hidden in the software layer, for example whether many voltages are set at once, or one at a time, etc.  The auxilliary registers that can also be read, such as local preamp board temperature, local supply voltage levels, the state of the high/low gain setting, etc, can be assigned special addresses and accessed like read-only voltages in the API, or accessed using special methods.  The fact that we can independently read and write the registers makes all of the protocol details transparent to the API designer.

Just tell us what API you want, and we will expose it.  Our protocol also supports automatic wake-up discovery, so the system can discover how many stations are online and what their geographic addresses are (set with jumpers on the detector), and global reset of all boards to a default power-up state.

All of this protocol is implemented in a Xilinx FPGA programmed in VHDL.  UConn student Igor Senderovich wrote that program, and is able to answer detailed questions about the design.  He designed it with a reasonable hierarchy, so it should not be difficult to modify.

-Richard Jones


On 4/5/2012 9:27 AM, Hovanes Egiyan wrote:
> Hi Richard,
>
> I could do that, although it is difficult to do that without knowing the
> hardware/firmware limitations. I would need some description of the basic features of these boards and how many of them is going to be there. Also the choice of the interface would depend on how fast these boards process a request, complete the operation and send the response.   Also it matters how these boards are programmed to operate: are they going to accept bulk requests for all parameters,  or just single parameter at a time; or we have freedom to change that in the firmware?  Is there any kind of document on that, some sort of write up? We probably need a phone call to get these issues cleared .
>
> Actually I forgot to include the ramp up and ramp down rates in the list
> in my previous message, thanks for pointing it out. For the biases on
> the BCAL we will use Wiener boards that  do have these parameters (although just two groups for the 16 channels on a single board, and the ramp-up rate equals to the ramp-down rate).  So it would be good to have these parameters for the microscope as well.
>
> Hovanes.
>
>
> On 04/03/2012 11:16 AM, Richard Jones wrote:
>> Hovanes,
>>
>> That sounds good.  Since you already have an idea of the functionality
>> that this API should expose, let me ask you for a favor.  Can you
>> draft an interface specification for the C or C++ API that we should
>> implement on top of our protocol?  Things that we would not think of,
>> for example, would be to ramp the bias voltages up and down
>> gradually.  At these low bias voltages, our instinct would be to just
>> switch them on and off abruptly.  But if operators are not used to
>> that, it might cause concern or confusion.  Having as uniform as
>> possible an interface to all operating voltages on detectors would
>> seem to make sense, and you might be better able to design that than I
>> would.
>>
>> If you write the API specification, I will provide a tested library
>> layered on top of pcap that implements the API.
>>
>> -Richard J.
>>
>>
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2757 bytes
Desc: S/MIME Cryptographic Signature
Url : https://mailman.jlab.org/pipermail/halld-tagger/attachments/20120405/07a99c4e/attachment.bin