To be clear, if the target state is "undefined", physics triggers
will be inhibited (and hence there will be no physics events in
RunControl), but the raw phototube scalers (such as the first two columns
on visual_scal, the TOF tubes) will still count.
If the HV is causing the inhibit (voltages in STBY, an HV trip,
running the HV from the dumb terminal in the D Tunnel), then even the raw
phototube scalers won't count. The discriminators are inhibited by the "HV
not good" signal. Evidently power-cycling the HV crates brings the
voltages back to OPER, but doesn't lift the inhibit. Presumably an
autofill cycle would lift the inhibit, or there's beamgate_on .
As Tancredi says, a problem in CAMAC could also cause this, since
beamgate_on is set by sending commands to a output register in the left
sector trigger crate. That doesn't seem to have been the problem this time.
Karen
At 09:56 AM 7/21/2003 -0400, Tancredi Botto wrote:
>On Mon, 21 Jul 2003, Kevin McIlhany wrote:
>
> > Two main issues:
> > 1) There is a problem with e-log submission as one of the scripts ate
> > itself (cleanthis.bash). So, we do it the old fashioned way - via
> > email.
>
>yes elog is still moving and being fixed daily. However the correcting
>action should be a little more specific: in this case the problem was with
>updating the web page after download the trigger. A little investigation
>into the trig.cc program would have given you the right script name and
>that could have been fixed or its updating action be commented out.
>Running cleanthis clearly did more than that...
>
>
> > Investigation shows that at least one environmental variable as lost
> > related to Epics ($EPICS_DISPLAY_PATH)
>
>On purpose commented out, as sourcing epics paths (not "ours") typically
>brings in the problem of not being able to boot the coda front end. So we
>have to do with less epics niceties.
>
>
> > happened before and to fully cycle power on the HV crates (ie. turn them
> > off from the back and let them rest for a minute). After the first try,
> > two of the crates refused to make connections (right sector WC and left
> > sector TOFs) prompting a second try at a full power cycling. After this
> > time, all crates responded and we are back in business.
>
>
>this is quite usual operation I am afraid it can happen again.
>
>
> > Well... not quite.... after trying to start a run, we notice that
> > there are no scalers being reported although the HV is now behaving (it
> > shows trips and recoveries). A trip to the d-tunnel to reboot the
> > FASTBUS crate does not help.
>
>
>fastbus and scaler screen have little in common.
>
>
> > Finally, a call to Karen Dow helps with her suggestion to try
> > "beamgate_on", which magically un-inhibits the datastream and we are
> > really back in business now.
>
>related to either a loss of power in the camac crates, or maybe the camac
>controller in the scaler VME crate or maybe a down-right bad download
>sequence of the camac trigger. I think it is documented in the manual,
>the gate circuit is also documented in logbook 6. The beamgate comes on
>normally closed (off) after a power up or a camac reset.
>
>Please also check the target state is "defined" (red) as that also inhibit
>the trigger
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST