Re: Accomodating I2C and CAN in Hall D control system

[Gerard Visser <gvisser@indiana.edu>]

Hall D Electronics:

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
>>>
>>> ================================================================================
>>>
>