[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:
Cheers,
After talking with Elliott yesterday he explained a few reasons not to
send the 'housekeeping' values of board temperature, etc in the data
stream. I did not know the overall control scheme to readout the
temperatures etc for the GAS preamps, nor the CANbus channel count for
the FCAL tubes. Each have a significant number of channels, and I
presumed that the control/readout was not via a VME module.
I know it is obvious, but any module that has a VME interface will use
that interface path for initialization parameters(PreStart?) and of
course high speed block readout of the data after receiving a trigger.
The power supply voltages/current, fan speed, slot temperatures
monitoring, and VMEbus reset will be through the Wiener 'fan tray'
ethernet interface. That does not preclude us from designing other
monitoring features on the front end boards. Elliott had a few reasons
for not adding these monitoring data into the readout data stream, and I
presumed that any on-board monitoring data could be readout with a
different trigger type or another process running on the Cpu.
As Fernando points out, the Signal Distribution(Switch B) and Crate
Trigger Processor(Switch A) do not have direct VME access, so the plan
is to use serial communication from the Trigger Interface module(VME
PayloadPort18). We have talked about including an ethernet interface to
these switch slot modules, either from the Cpu slot(PayloadPort17) or a
front panel RJ45 jack. Presently these switch board designs only
include the serial interface to the TI board.
Thanks,
Chris
~~~~~~~~~~
Fernando J. Barbosa wrote:
> 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
>>>>>
>>>>> ================================================================================
>>>>>
>>>>>
>>>
>