Re: Accomodating I2C and CAN in Hall D control system

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

Hall D Electronics:

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