On Tue, 22 Jul 2003, Karen Dow wrote:
>
>
> 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 .
>
Cycling the power kills the socket connection to the ioc. This means that
the linux ioc needs to be rebooted to control them so the question of what
state the crate is in after cycling is not meaningful.
When the ioc is rebooted, crates are on, the voltages are the OPER ones,
but the detector channels are disabled-meaning no voltage. the oper button
will turn the detectors on
Adam
>
> 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