Re: Accomodating I2C and CAN in Hall D control system

["Fernando J. Barbosa" <barbosa@jlab.org>]

Hall D Electronics:

Hi Gerard,

Good point!

Elliott, can you clarify the functionality envisioned for the slow 
controls infrastructure?

Regards,
Fernando




Gerard Visser wrote:
> Hi,
>     I mostly agree, but it depends on the implications of your 
> statement "...not to be considered part of the slow controls domain."
> I think it is important to be _able_ to log board temperatures, for 
> instance. And I think it is important to alarm on board temperatures. 
> If  these things can be done, then I would be satisfied, whatever the 
> "domain" is. (I don't think we always have to log all readout board 
> temperatures - but I think we should at least be able to switch on 
> such logging if there is a problem to be debugged.)
>
>     Gerard
>
>
> Fernando J. Barbosa wrote:
>> Hi Gerard, Elliott,
>>
>> Yes, the same is true of the F1TDC and fADC250 modules. I should also
>> mention that the VXS backplane supports I2C because the switch slots do
>> not have any VME interface capability. I should emphasize that all these
>> functions (in these modules) are "internal" and are not to be considered
>> part of the slow controls domain, I think.
>>
>> It is great to start thinking about these issues with regards to the DAQ
>> controls (run control?). Isn't the DAQ group going to provide the
>> interfaces and GUIs to all these modules? I believe Vardan addressed
>> some of these global issues (control agents?) at a recent talk.
>>
>> Regards,
>> Fernando
>>
>>
>>
>>
>> Gerard Visser wrote:
>>> Hall D Electronics:
>>>
>>> Hi Elliott,
>>>     It should be noted that _all_ control functions for the ADC125 are
>>> done by VME. I presume the same is true of the ADC250 and the F1TDC
>>> boards (Fernando?).
>>>     For the ADC125, I think there are three types of
>>> control/monitoring functions.
>>>     A. Readout controls to setup, e.g., latency setting, window
>>> length, zero suppression thresholds, probably some time/amplitude
>>> algorithm parameters, channel masks, etc. This stuff, I imagine you
>>> should download once at the start of a run and no need to touch them
>>> during a run. So this is no bandwidth burden on the DAQ system.
>>>     B. A few housekeeping parameters to read and log and/or alarm on.
>>> This means, most importantly, board temperatures, probably some power
>>> supply voltages/currents. These things are read only and expected to
>>> vary. They need be read at most once every couple of seconds, and no
>>> need to read synchronously across different boards. It seems to me
>>> this should not be a big burden.
>>>     C. Scalers and other data monitoring, e.g., storing min/max/mean
>>> values (if you want any scalers or such stuff). I would imagine there
>>> should be at least one simple level crossing scaler per channel.
>>> Probably more, e.g., count pulses going over 95% full scale, so you
>>> know what is getting saturated. I have already proposed to you that a
>>> separate trigger command is defined to cause all ADC125 boards to
>>> simultaneously capture their scaler data and stuff it as a special
>>> "event" packet into the DAQ stream. In this way the readout of scalers
>>> proceeds at maximum speed with a minimum of effort from front end
>>> through to online display software (I think), and also it is, I would
>>> imagine, useful to have them captured simultaneously. If this is not a
>>> good plan, for whatever reason, vanilla VME transactions may be used
>>> to capture and read the scaler data. Or you can tell me not to include
>>> any scalers at all. (Well I probably would do so anyway to facilitate
>>> testing, but you wouldn't have to read them of course.)
>>>     Besides the fact that I don't want to have any I2C or such control
>>> interface into the ADC125, I don't think it would be at all
>>> appropriate for item C. And item C would presumably account for the
>>> greatest part of the controls bandwidth for these boards.
>>>     Comments? Asap if there are significant objections to the above...
>>>
>>>     - Gerard
>>>
>>> Elliott Wolin wrote:
>>>> Hall D Electronics:
>>>>
>>>> Dear Gerard, Fernando, and friends,
>>>>
>>>> I understand there will be a large number of I2C and CAN channels in
>>>> Hall D.  In
>>>> particular, one I2C channel per 24-channel preamp card, and one CAN
>>>> channel per
>>>> Cockroft-Walton base.  I understand there are other I2C channels (how
>>>> many?);  are there
>>>> additional CAN channels?
>>>>
>>>> I don't know how many I2C and CAN channels can be daisy-chained on
>>>> one I2C or CAN bus.  We
>>>> may not want to daisy-chain too many channels, as then access to each
>>>> device might take
>>>> too long, e.g. when setting all the C-W high voltages prior to
>>>> starting a run.
>>>>
>>>> Further, I assume the detector and/or electronics budgets include
>>>> whatever devices are
>>>> needed to read out I2C and CAN, as the online budget contains just
>>>> computers and network
>>>> components.
>>>>
>>>> Finally, I am concerned about mixing controls and DAQ data paths.
>>>> How are all the I2C
>>>> devices connected and read out?  I hope not via VME in the DAQ
>>>> crates, as this would
>>>> interfere with the high-speed DAQ readout.
>>>>
>>>> Controls data paths should be independent of DAQ data paths unless
>>>> the controls data is
>>>> intimately associated with DAQ (e.g. trigger scalers), i.e. only
>>>> needed if DAQ is running.
>>>>
>>>> Thanks,
>>>>
>>>>                                 Sincerely,
>>>>                                         Elliott
>>>>
>>>>
>>>> ================================================================================ 
>>>>
>>>>
>>>>
>>>>
>>>>   Those raised in a morally relative or neutral environment will hold
>>>>                     no truths to be self-evident.
>>>>
>>>>
>>>> Elliott Wolin
>>>> Staff Physicist, Jefferson Lab
>>>> 12000 Jefferson Ave
>>>> Suite 8 MS 12A1
>>>> Newport News, VA 23606
>>>> 757-269-7365
>>>>
>>>> ================================================================================ 
>>>>
>>>>
>>