Re: Accomodating I2C and CAN in Hall D control system

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

Hi Gerard,

I am in complete agreement.

As a side note, there are some flags on the F1TDC and fADC250 that can 
be used for monitoring their operation, such as power good and F1TDC 
lock. These are used for debugging and don't require constant monitoring.

Regards,
Fernando




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.
>>>
begin:vcard
fn:Fernando J. Barbosa
n:Barbosa;Fernando J.
org:Jefferson Lab
adr:Suite #10, 12B3;;12000 Jefferson Ave.;Newport News;VA;23606;USA
tel;work:757-269-7433
version:2.1
end:vcard