[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Accomodating I2C and CAN in Hall D control system
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
>>
>> ================================================================================
>>