hello...
sorry I had a busy day.. I agree with taylan, and btw we
discussed at various points the need for an epics "summary"
variable for the beam helicity after the experience of last year.
It seems that problem is
> when target flips it resets this bit. It is
> reminence of the time when this bit was Nitrogen
is this a feature of ABSsoft such that when the target flips all
bits on the input register flip or is it simply how the flip
sequence was programmed ?
The problem of last year occurred when we were flipping the beam only.
It had to do with the fact that if a run was started midfill after a
spin flip, that run started non flipped.
I don't see a problem of sending a TTL from compton directly to
rack 3. Even less so if there is a spare in the patch...
regards,
-- tancredi
________________________________________________________________________________
Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Fri, 27 Feb 2004, Taylan Akdogan wrote:
>
> On Fri, 27 Feb 2004, vitaliy ziskin wrote:
> > I'm not sure if that is possible. Scalers get their TTL signal from
> > this ribon cable which comes staright from the ABS rack 13 (lucky
> > number). To do what you are sugesting we need to make another scaler
> > channel (another epics channel is easy) , do we have an exra one.
>
> That's exactly my point. Why do we use the epics for this
> purpose? The hardware signal is out there already! Delivering a
> signal through epics is equivalent of introducing more breakable
> points along the way. The Flip-Odd signal we produce is already a
> TTL signal.
>
> As for the epics channel: Of course it doesn't hurt to have this
> one as well. What I am suggesting is that we should use a
> hardware signal read by a device and distributed by the epics,
> instead of a software bit that we can set (means any other
> software can change it - not error-prone).
>
> And, that kind of channel is already in place; no software is
> involved (other than epics server, off course), it is read
> directly from the hardware signal. It is called
> "sp2_6034e:flip_odd".
>
> Thus, the conflict is not whether it is doable or not, but
> finding the best approach. I vote for using directly the TTL
> signal from the Compton electronics for scaler normalization.
>
> Correct me if I'm wrong: The current setup is as follows:
>
> 1) Compton Controller flips the spin.
> 2) The flip-odd TTL signal is generated by the compton
> electronics.
> 3) Compton controller sets the proper epics bit according to the
> flip-odd state.
> 4) A digital I/O board (call it an out-register) produces a TTL
> signal that supplies the scalers.
>
> We can eliminate item 2&3 by using directly the TTL hardware
> signal produced by the item-2. And, there is already an epics
> channel that reads the same TTL signal produced by item-2.
>
> (Finding a proper cable for the scaler channel is a small
> detail.)
>
> Maybe, I'm missing something, let's discuss this on
> paper/electronics.
>
> Cheers,
> Taylan
>
> ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---
> Taylan Akdogan Massachusetts Institute of Technology
> akdogan@mit.edu Department of Physics
> Phn:+1-617-258-0801 Laboratory for Nuclear Science
> Fax:+1-617-258-5440 Room 26-402b
> ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST