[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,
Perhaps I exaggerated concerning cpu availability, but it certainly is not 100%. Servers
required to keep cpu's going may be undergoing maintenance, networks may be down, cpu's
crash and no one may notice during down periods, etc. The list is endless.
I know little about I2C, but I've been assuming the master would be some box we buy or
build, separate from the crate and its contents.
I completely agree that cpu's are not a good choice for any sort of critical 24/7
monitoring, and autonomous fail-safe systems should be implemented to protect all
hardware. But in all cases I'd like to be able to detect that something was shut down
without having to look at a histogram of detector channel multiplicities.
Gerard Visser wrote:
> Hi Fernando,
> Apart from any scaler data (which is another issue to discuss), I
> would think it is desirable to read from each module two temperatures
> and perhaps four power supply parameters and be able to log or alarm on
> them. This would amount to, e.g., a total of 12 bytes. These would be
> read every 10 seconds, perhaps. I don't think this would be a noticeable
> load on the VME bus, the CPU, or the ethernet. As you note, the VME bus
> and ethernet will be loaded near maximum, so this is perhaps an
> additional 0.000001 percent.
> This would _not_ be an equipment protection mechanism. If the board
> needs to be shutdown to prevent damage from an overtemperature condition
> (I don't know that it would need to be, but _if_), then it would be
> handled locally in the board's hardware. There would be no requirement
> for high-rel 24/7 monitoring.
> I would think it prudent that the board temperatures and power
> parameters are logged while data is taken, because an extreme of
> temperature or other anomalous condition could affect calibrations.
> The argument that DAQ CPU is not necessarily available 24/7 I don't
> really understand... It may be true... But, what else would sit in the
> crate and be for instance an I2C master, and be guaranteed to work
> 24/7?? I think it is more realistic just not to require 24/7
> availability from this sort of controls stuff. In other words it is not
> to be used for personnel or equipment protection purposes.
>
> - Gerard
>
> p.s. In any case, if the fADC250 and the F1TDC do not require a separate
> I2C or such controls interface, I think it is a little crazy to require
> such for the ADC125. I should just provide the parameter reading VME as
> I intend, and we can always decide not to use that in operations. It
> will still be worth having for board testing and debugging purposes.
>
> p.p.s. I put the email list back on - this _is_ a valid topic for
> discussion amongst all concerned.
> Fernando J. Barbosa wrote:
>> Hi Mark,
>>
>> Earlier, I suggested to Elliott that a document outlining the
>> architecture of the slow controls in Hall D is required, especially for
>> the May review.
>>
>> With regards to the fADC125, which is the bottleneck in DAQ, the
>> occupancy rates can be really high and with 72 ch per module, the
>> backplane transfer rates will definitely be high in regions of the
>> tracking detectors. It may be OK to have the ROC get any monitoring info
>> at some point.
>>
>> Gerard may want to be more explicit as to what parameters he needs to
>> monitor on the fADC125.
>>
>> On the F1TDC and fADC250, the programming parameters are set at startup
>> but there is no temperature monitoring or such.
>>
>> Regards,
>> Fernando
>>
>>
>>
>> Mark M. Ito wrote:
>>> Chris,
>>>
>>> C. Cuevas wrote:
>>>> After talking with Elliott yesterday he explained a few reasons not
>>>> to send the 'housekeeping' values of board temperature, etc in the
>>>> data stream.
>>> Why not?
>>>
>>> -- Mark
>>>
>>> P. S. Took the email list off the list of addressees.
>>>
--
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
================================================================================