Running the EPD Remotely

These instructions were pruned from a very helpful document from Eleanor, which can be found at: drupal.star.bnl.gov/STAR/system/files/STAR_remote_SC_RC.pdf

if password expire
ssh-add .ssh/id_rsa
To request additional accounts, one goes to:
http://www.star.bnl.gov/starkeyw

Open up shiftlog editor at:
https://online.star.bnl.gov/apps/shiftLog/loginSuccessful.jsp

ssh -A -Y rjreed@ssh.sdcc.bnl.gov
ssh -A -Y stargw.starp.bnl.gov
ssh -A sysuser@sc3.starp.bnl.gov
vme_plat1

brings up the VME crate GUI

Send an email to star-ops before using run control.
Join the control room zoom at: https://bnl.zoomgov.com/j/1605144596?pwd=N3ExMDh3Q2txK0FxYTBVTzg4N0hHZz09

Bring up the daq monitor at:

https://online.star.bnl.gov/daq/export/daq/

Bring up the STP2 monitor at:

https://online.star.bnl.gov/L2TimingPlotsCeph/stp2mon/stp2mon.html

Open a new terminal window for the trigger log
ssh -A -Y rjreed@ssh.sdcc.bnl.gov
ssh -A -Y stargw.starp.bnl.gov
ssh evpops@daqman
tail -f /net/daqman/log/trigger.log

Open a new window for Run Control
ssh -A -Y rjreed@ssh.sdcc.bnl.gov
ssh -A -Y stargw.starp.bnl.gov
ssh -A evpops@rts02.starp.bnl.gov

Then kill all other instances of run control using:
killall java
rc_daq.sh

The pedestal_rhicclock_clean configuration actually has 2 triggers that are defined: pedestal and ped_all.
The pedestal trigger is the one that is set up to be used during normal STAR running. It includes a VETO on BBC-E and BBC-W/
If we are running with the BBQ crate powered OFF, the BBC crate can not  be included in the pedestal run. The BBC-E and BBC-W bits would float high.
So, the BBC VETO condition would preventing the pedestal trigger from firing.

Short answer:
pedestal_rhicclock_clean
ped_all should be checked in

Bring up the EPD GUI:
https://dashboard1.star.bnl.gov/daq/EPD_UI/?EPD

Jack's magic email:
rosi

 
if you see a bunch of "L2 time out messages" on the DAQ monitor, i could be an indication that one or more of the STP-PMC cards mounted in the crate processors are in an error state.  it's probably more obvious if you monitor the trigger log.  but there's so many messages streaming past even when things are going well that it's tough to catch.  so, if you run into all the events timing out (and not just 1 or 2) log into the crate processors and check the status of the PMC cards
 
to log into the processors you can either
1) from the startrg machine as the staruser or trg user, use the "grab" command  e.g.
               grab eq1
2) from a machine on the private network (e.g. daqman, rts02 ) use the "telnet" command  e.g.
               telnet eq2.trg.bnl.local
 
once you are logged into the processor use
                PMC_status_all
this SHOULD return a value of 0x100
if not, then try to reset it with the command
                PMC_reset

then check the status again.  if you can't get it to clear after trying "PMC_reset" a couple of times then try power cycling the offending crate.