[Halld-tagger] Voltage control for microscope

[Hovanes Egiyan]

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.
>
>
>
> On 4/3/2012 7:47 AM, Hovane Egiyan wrote:
>> Hi Richard,
>>
>> thanks for your quick response. It sounds like what will be required 
>> in hardware is a Linux computer and a network hub.  We do plan to 
>> have a VME crate with a Linux controller in the tagger hall.  But if 
>> we do not want to tie this application to a VME crate then we could 
>> instead just attach  together  an embedded PC running Linux EPICS 
>> Input/Outut Controller (IOC) process and a network hub (or make a 
>> small chassis) that can be mounted in a rack.
>>
>> For the software side, it would be nice if we had a C or C++ library 
>> above pcap that would provide a set of functions to read and write 
>> parameters into the control boards. That would facilitate interfacing 
>> the voltage control with EPICS.  We would need to discuss the 
>> parameters and the set of functions in details.
>>
>> Hovanes.
>>
>>
>> On 4/2/2012 7:17 PM, Richard Jones wrote:
>>> Hovanes,
>>>
>>> These microscope readout control boards communicate with a host over 
>>> a private ethernet segment.  The physical layer is just RJ45 twisted
>>> pair ethernet, using a cheap 10Mb hub.  The ethernet protocol can 
>>> coexist with normal ip traffic without interference on this segment,
>>> but it only uses the ethernet transport layer so it requires the 
>>> host to be on the local segment.  The protocol does employ special
>>> broadcast packets for automatic discovery and global reset 
>>> functions.  It is our own protocol.
>>>
>>> I think the best way to control it in the hall would be an epics 
>>> application that runs on an in-crate computer with one of its ethernet
>>> ports dedicated to the private segment.  Thank you for starting us 
>>> thinking about this.  Right now our software runs on a windows app
>>> built on the pcap library, but there is not a lot of investment in 
>>> that.  We just set that up because it was quick and did not require us
>>> to buy a VME crate.
>>>
>>> -Richard J.
>>>
>>>
>>> On 4/2/2012 3:56 PM, Hovanes Egiyan wrote:
>>>> Hi Richard,
>>>>
>>>> We are planning the controls for voltages for Hall D. Tagger 
>>>> microscope will be using SiPMs for which UConn is providing the 
>>>> bias voltages
>>>> and the power to the boards. At this stage we would like to know 
>>>> how these are in principle designed to interface with EPICS. Is 
>>>> this going to be a standalone Labview program which will have to be 
>>>> interfaced with EPICS, or you could provide a library that could be 
>>>> used to integrate it with EPICS on Linux, or you are using some 
>>>> standard communication protocol we could use to talk to these 
>>>> boards. Also I would like to know which parameters will be 
>>>> controlled and monitored. I listed below what (hopefully) will be 
>>>> available to the software for voltages for other detector components.
>>>>
>>>> o Voltage Setpoints    (RW)
>>>>
>>>> o Voltage Readback    (R)
>>>>
>>>> o Maximum Voltage    (RW)
>>>>
>>>> o Current Readback    (R)
>>>>
>>>> o Maximum current(s) [trip]                    (RW)
>>>>
>>>> o Time for trip condition before turning off            (RW)
>>>>
>>>> o Channel Status [On/Off/RampingUp/RampingDown/Tripped/etc]    (R)
>>>>
>>>> o Switch On/Off                            (W)
>>>>
>>>> o Board Temperature                        (R)
>>>>
>>>>
>>>> Although it would be desirable if all detector components have 
>>>> similar features exposed to the shift operators,  this list is 
>>>> obviously dependent on the features of the detector and can change.
>>>>
>>>> Also, when do you think we could have an opportunity to have a 
>>>> system at JLab that will allow us to develop an EPICS interface for 
>>>> these
>>>> voltages?
>>>>
>>>> Thanks,
>>>>        Hovanes
>>>>
>>>
>
>