AO preset from AOS failed. Missing setups file.

The preset of the AO system requires many parameters to configure the Adsec and the WFS, in the WFS side there is one file that it has some initial parameters for bayside stage, adc, etc..and one of the them is the status of the WFS. The status of the WFS is important because gives to the Arbitrator that the WFS is in oeerating state, without this line the status is not share and it will report an error that it is " wrong operating state". Also to mention that this directory is used to load the boardsetups.

Example of file: LUCIFER_ACE-AO.

self.flowerpot.setOperatingState(0)

self.stagez.moveTo(52.9)

self.lens.moveTo(0,0)

self.adc._motor1.moveTo(-208)

self.adc._motor2.moveTo(-0)

self.stagez.waitTargetReached(checkStatus= True)

self.adc._motor1.waitTargetReached(checkStatus= True)

self.adc._motor2.waitTargetReached(checkStatus= True)

The OperatingState (0) gives the status.

Error message:

python_118654 |ERR| 314|2022-09-29 01:43:58.165849| MAIN > [AOException] presetAO: WARNING - RETRY: No setup for instrument LUCIFER, mode ACE-AO: [Errno 2] No such file or directory: '/home/AOeng/live/aoroot/calib/wfs/current/setups/LUCIFER_ACE-AO' (-20004) WFSARB_ARG_ERROR

Action:

  • Check the diectory for files LUCIFER_ACE/TTM-AO.
  • If file is missing: cp the file to this dierectory. eg. LUCIFER_ACE/TTM-AO. Another operating environment where the file can be copied; aoroot.latests
  • Check that the file has the line; self.flowerpot.setOperatingState(0)

AO preset from AOS failed. Not reconstructor loaded.

Example a presetAO for LBTIWFS, reports an error at the time to load the reconstructor.

If the WFS machines (Soul/LBTI) were booted , it could happen that the the mount (share) of the disc in not and it will require to mount it.

Error message:

AO,focst:bentGregorianCenter,instr:LBTI,wfs:LBTIWFS,sox:0[0],soy:0,rox:0[0],roy:0,mag:9.5,cindex:0,,elev:nan,rotang:nan,grvang:nan,r0:0,skybr:nan,windsp:nan,winddir:nan)
Wed Sep 14 18:18:51.391 2022 aos.info - WFS source set to: LBTIWFS
Wed Sep 14 18:18:57.154 2022 aos.PresetAO{FLAO}.failed - PresetAO {FLAO}[2] - [AOException] presetAO: FATAL - [Errno 2] No such file or directory: '/local/aomeas/adsec_calib/M2C/KL_v20/RECs/Rec_LBTI_IIR_b1_400m1000.fits'

Action:
  • Check that the file exists.
If Exists.
  • mount the disk in the Adsec machine.
  • sudo mount -a

SET flat failed.

Using the AOSGUI to set the flat with an error or warning message in the AOS log message and the shell doesn't go to Flat position.

Error message:


Wed Apr 10 18:29:16.691 2024 aos.warning - Stop{FLAO} rejected. Busy serving PresetAO{FLAO}[1246]
Wed Apr 10 18:30:29.793 2024 aos.warning - SetNewInstrument{FLAO} rejected. Busy serving PresetAO{FLAO}[1246]
Wed Apr 10 18:39:35.097 2024 aos.warning - AdsecSet rejected. Busy serving PresetFlat[1245]
Wed Apr 10 18:40:06.388 2024 aos.info - Updated variable AOARB.R.AO_READY: 1

Action.
  • open FLAO GUI.

Most porbably there is a preset already in execution.
  • Cancel preset.
  • Set flat.

Arbitrator disconnected from msgd-RTDB

Disconnection of the msgdm-RTDB and the adsec doen;t responds to any external commands from AOARB or other commands. The process reconnect by itself and it requires sometimes until os connected again ( x seconds to re-attach).
The last command sent is not longer active and also it doesn't refresh the current state, so to troubleshoot a new preset should be sent to align all the arbitrators and the mgd-RTDB.
For the example described here took about 40 seconds to reconnect again (06:03:21-06:03:47.299475).

Error message:

06:03:22.532125| MAIN > >> Initializing connection with adsecarb...
06:03:22.532078| MAIN >
06:03:22.532136| MAIN > --------------------------------------------------
06:03:22.532142| MAIN > >> Initializing connection with adsecarb...
06:03:22.532144| MAIN > Trying to register for alerts notification from adsecarb...
06:03:22.532137| MAIN >
06:03:22.532151| MAIN > Trying to register for alerts notification from adsecarb...
06:03:22.532163| MAIN > >> Initializing connection with adsecarb...
06:03:22.532177| MAIN > Trying to register for alerts notification from adsecarb...
06:03:23.032390| MAIN > Connection to adsecarb failed
06:03:23.032390| MAIN > Connection to adsecarb failed.

Action:

  • Wait until the Arbitrator is connected again.
  • Send the preset again.

Example:

The arbitrator detached during a save status command sent and resumeAO almost at the same time. The save status was discard and the resume AO never went through.The other commands like as RunAO will not work. StopAO worked and a new preset was sent to sync the arbitrators.

Time of events:

06:03:21.495185| COMMANDHANDLER > FSM (status: AOPause) has received command 2028 (ResumeAo Ao)
06:03:21.505557| COMMANDHANDLER > Command ResumeAo Ao (code 2028) successfully completed
06:03:21.618936| MAIN > Received cmd: Offloading(1)
06:03:21.619035| COMMANDHANDLER > FSM (status: AORunning) has received command 2029 (TTOffload)
06:03:21.760913| COMMANDHANDLER > FSM (status: AORunning) has received command 2024 (Save status)
06:03:21.760972| COMMANDHANDLER > adsecarb: Fsm is discarding command 2024 (Save status)...
…………DISCONNECTED………..

………… TRY TO RECONNECT ……….

06:03:22.532125| MAIN > >> Initializing connection with adsecarb...
06:03:22.532078| MAIN >
06:03:22.532136| MAIN > --------------------------------------------------
06:03:22.532142| MAIN > >> Initializing connection with adsecarb...
06:03:22.532144| MAIN > Trying to register for alerts notification from adsecarb...
06:03:22.532137| MAIN >
06:03:22.532151| MAIN > Trying to register for alerts notification from adsecarb...
06:03:22.532163| MAIN > >> Initializing connection with adsecarb...
06:03:22.532177| MAIN > Trying to register for alerts notification from adsecarb...
06:03:23.032390| MAIN > Connection to adsecarb failed
06:03:23.032390| MAIN > Connection to adsecarb failed.
………………. ATTACHED…………
06:03:47.298879| MAIN > >> Initializing connection with adsecarb...
06:03:47.298888| MAIN > Trying to register for alerts notification from adsecarb...
06:03:47.299475| MAIN > Alerts notifications succesfully requested!
06:03:47.299561| MAIN > Alerts notifications succesfully requested!

The adsecarbitrator connected again.

06:03:47.408950| MAIN > Receved alert registration request from: AOARB.L
06:03:47.409050| MAIN > initAlert() completed
06:03:53.114752| MAIN > Received cmd: ResumeAo ()
06:03:53.114823| COMMANDHANDLER > FSM (status: AORunning) has received command 2028 (ResumeAo Ao)
06:03:53.114856| COMMANDHANDLER > adsecarb: Fsm is discarding command 2028 (ResumeAo Ao)...
06:03:53.114974| MAIN > ResumeAo: WARNING - adsecarb:Illegal command for state AORunning (ResumeAo Ao)

…………Same command sent several time and it processed the StopAO

06:04:10.574775| MAIN > Received cmd: ResumeAo ()
06:04:10.574853| COMMANDHANDLER > FSM (status: AORunning) has received command 2028 (ResumeAo Ao)
06:04:10.574891| COMMANDHANDLER > adsecarb: Fsm is discarding command 2028 (ResumeAo Ao)...
06:04:10.574923| MAIN > ResumeAo: WARNING - adsecarb:Illegal command for state AORunning (ResumeAo Ao)
06:04:15.450885| MAIN > Received cmd: ResumeAo ()
06:04:15.450950| COMMANDHANDLER > FSM (status: AORunning) has received command 2028 (ResumeAo Ao)
06:04:15.450977| COMMANDHANDLER > adsecarb: Fsm is discarding command 2028 (ResumeAo Ao)...
06:04:15.451018| MAIN > ResumeAo: WARNING - adsecarb:Illegal command for state AORunning (ResumeAo Ao)
06:04:41.462473| MAIN > Received cmd: ResumeAo ()
06:04:41.462573| COMMANDHANDLER > FSM (status: AORunning) has received command 2028 (ResumeAo Ao)
06:04:41.462620| COMMANDHANDLER > adsecarb: Fsm is discarding command 2028 (ResumeAo Ao)...
06:04:41.462685| MAIN > ResumeAo: WARNING - adsecarb:Illegal command for state AORunning (ResumeAo Ao)
06:04:59.763169| MAIN > Received cmd: ResumeAo ()
06:04:59.763254| COMMANDHANDLER > FSM (status: AORunning) has received command 2028 (ResumeAo Ao)
06:04:59.763288| COMMANDHANDLER > adsecarb: Fsm is discarding command 2028 (ResumeAo Ao)...
06:04:59.763342| MAIN > ResumeAo: WARNING - adsecarb:Illegal command for state AORunning (ResumeAo Ao)
06:05:01.511433| MAIN > Received cmd: ResumeAo ()
06:05:01.511522| COMMANDHANDLER > FSM (status: AORunning) has received command 2028 (ResumeAo Ao)
06:05:01.511572| COMMANDHANDLER > adsecarb: Fsm is discarding command 2028 (ResumeAo Ao)...
06:05:01.511634| MAIN > ResumeAo: WARNING - adsecarb:Illegal command for state AORunning (ResumeAo Ao)
06:05:11.755379| MAIN > Received cmd: ResumeAo ()
06:05:11.755454| COMMANDHANDLER > FSM (status: AORunning) has received command 2028 (ResumeAo Ao)
06:05:11.755478| COMMANDHANDLER > adsecarb: Fsm is discarding command 2028 (ResumeAo Ao)...
AdSecArbitrator_71287|WAR| 88|2022-03-09 06:05:11.755524| MAIN > ResumeAo: WARNING - adsecarb:Illegal command for state AORunning (ResumeAo Ao)
06:05:14.344557| MAIN > Received cmd: ResumeAo ()
06:05:14.344657| COMMANDHANDLER > FSM (status: AORunning) has received command 2028 (ResumeAo Ao)
06:05:14.344692| COMMANDHANDLER > adsecarb: Fsm is discarding command 2028 (ResumeAo Ao)...
06:05:14.344736| MAIN > ResumeAo: WARNING - adsecarb:Illegal command for state AORunning (ResumeAo Ao)
06:05:36.655197| MAIN > Received cmd: StopAo (0)
06:05:36.655299| COMMANDHANDLER > FSM (status: AORunning) has received command 2015 (Stop Ao)
06:05:36.655362| SERIALIZATION > StopAoImpl (): restoreShape = 0
06:05:38.127488| COMMANDHANDLER > Command Stop Ao (code 2015) successfully completed
06:05:42.524016| MAIN > Received cmd: RunAo (0,365,770)
06:05:42.524073| COMMANDHANDLER > FSM (status: AOSet) has received command 2014 (Run Ao)
06:05:42.524120| COMMANDHANDLER > Command not executed (status RETRY) (errstr No focal station selected)
06:05:42.524157| MAIN > RunAo: WARNING - No focal station selected
06:05:42.524734| MAIN > Received cmd: RunAo (0,365,770)
06:05:42.524789| COMMANDHANDLER > FSM (status: AOSet) has received command 2014 (Run Ao)
06:05:42.524820| COMMANDHANDLER > Command not executed (status RETRY) (errstr No focal station selected)
06:05:42.524848| MAIN > RunAo: WARNING - No focal station selected
06:07:28.312553| MAIN > Request: PresetAO (


Camera lens out of operation temperature range.

During winter time, the camera lens can shows an alarm related to operation temperature. The active alarm for the camera lens temperature is activated when the temperature is below 7 degrees Celcius. The alarm is triggered only during the preset AO and not during the system startup.

Error message:

WfsArbitrator _159178|ERR| 262|2021-12-05 13:35:50.345605| MAIN > RETRY: Camera lens temperature too low. T= 5.17, minimum allowed is 7.00 (0) NO_ERROR

Action:

Open WFS Hardware GUI.
  • Check temperature of the BCU47.
  • Leave the system running.The temperature will start to rise.
  • Takes about 30 mnutes to reach the operation temperature during the cold temperature (below zero)
  • Perform a few camera lens movements using the camera lens hardware Gui.
FAST way:
  • Turn off the FAN_47.

camra_lens_temp.png

OCAM NOT LIVE in open loop.

After the Power On of the WFS, the OCAM could come up that it is not connected, the power on of the controller and BCU2K are up an running but the OCAM viewer shows "NOT LIVE"

Action:

1. Close and open again the OCam2k viewer. This is to check that the Gui is refreshing correctly.
2. Check the status of following processes (WFS System processes GUI), if down restart them:
  • BCU2K interface , Slope computer ctrl, OCAM2k controller, Master diagnostic
  • OCAM2K viewer-> Set the OCAM binning to “2x2” and back to "1x1 cropped".
3. If processes are up do:
  • OCAM2K viewer-> Set the OCAM binning to “2x2” and back to "1x1 cropped".
4. If doen't comes life after the setting of binning.
  • Power cycle the BCU2K and change binning using the OCAM2K GUI.

OCAM NOT LIVE close loop.

An issue in the communication between the WFS and the Adsec can be expressed as a OCAM2k NOT LIVE. This error could be identified in the BCU2K that it is not communicating or in the Fast communication (masterdiagnostic) process that it is stuck.

Action:

  • Open the Mirror GUI on the AdSec workstation.
    frame_counter.png
  • Check if the WFS Frames Counter value in the bottom-left part of the GUI is increasing and it doesn't show random values.
  • Open the AO loop clicking “Open” button in the “Loop control” panel of the WFS control GUI.
    A StopAO command should be sent to the Adsec and WFS.
  • Power cycle the BCU2K.
  • From the OCAM2K HW GUI select a binning.
  • Open the OCAM viewer and it should come alive.

    If the camera doesn't come live try:
  • Stop/Start the Masterdiagnostic process in the WFS side.

OCAM NOT LIVE during the pupil centering process.

During the pupil centering the Ocam2k can come not live due to the lost of communication with the adsec, the center pupils perform a "soft" close loop and the masterdiagnostic is managing the communications between WFS and Adsec.

Actions:

  • Restarted Master Diagnostic and re-start the preset

OCAM shows bad frame.

The OCAM2K after the power On could shows bad frames with noisy quadrant, "triangle" feature,diagonal lines.

ocam2k_triangle.png

Action:

bcu2k_powercycle.png
  • From the OCAM2K HW GUI select a binning 2.
A pop up terminal shows the configuratIon of the CCD. Wait. -> LIVE
  • From the OCAM2K HW GUI select a binning 1x1 Cropped.

A pop up terminal shows the configuration of the CCD. Wait. LIVE

ocam_reset2.png

OFFSET FAILED DUE OPEN LOOP

OffsetXY failed and the next ResumeAO failed. There is a lost communication with the FLAOWFS. This can be due to an open loop during the execution of the observing OB.

Error message at wfsarbitrator:

fsArbitrator_73363|INF| 4104|2021-03-31 05:48:03.698141| WFS > Python command: WfsArbScripts.offsetXY(self, sensor = 'FLAOWFS', instr = 'LUCIFER', offsetx = -1.19383, offsety = 2.39392, brake = True)
WfsArbitrator_73363|INF| 4105|2021-03-31 05:48:03.699433| MAIN > LUT Applied: Rotang Ele X_LUT Y_LUT X_Enc Y_Enc X_Enc Y_Enc X_Tot Y_Tot
WfsArbitrator_73363|INF| 4106|2021-03-31 05:48:03.699502| MAIN > LUT Applied: deg deg V V mm mm V V V V
WfsArbitrator_73363|INF| 4107|2021-03-31 05:48:06.125864| WFS > Python command: WfsArbScripts.updateNcpa(self, sensor = 'FLAOWFS', instr = 'LUCIFER', rotAngle = 297.034, zero = 0)
WfsArbitrator_73363|INF| 4108|2021-03-31 05:48:08.309463| WFS > Command returns success .
WfsArbitrator_73363|INF| 4109|2021-03-31 05:48:14.487798| WFS > Executing resumeLoop...
WfsArbitrator_73363|INF| 4110|2021-03-31 05:48:14.487959| WFS > Python command: WfsArbScripts.resumeLoop(self, sensor = 'FLAOWFS', instr = 'LUCIFER')
WfsArbitrator_73363|INF| 4111|2021-03-31 05:48:14.624105| WFS > Command returns success .
WfsArbitrator_73363|INF| 4112|2021-03-31 05:48:14.624172| MASTDIAGN > Setting master diagnostic in closed loop mode
WfsArbitrator_73363|INF| 4113|2021-03-31 05:48:18.163308| MAIN > Camera lens tracking: moving by x= 0.6 y= 1.8 (um)
......
WfsArbitrator_73363|INF| 4122|2021-03-31 05:49:27.203218| WFS > Executing stopLoop...
fsArbitrator_73363|INF| 4123|2021-03-31 05:49:27.203364| WFS > Python command: WfsArbScripts.stopLoop(self, sensor = 'FLAOWFS', instr = 'LUCIFER')
WfsArbitrator _73363|INF| 4124|2021-03-31 05:49:27.207651| WFS > Command returns success .
WfsArbitrator _73363|INF| 4125|2021-03-31 05:49:27.207693| MASTDIAGN > Setting master diagnostic in open loop mode
WfsArbitrator _73363|INF| 4126|2021-03-31 05:49:27.308211| COMMANDHANDLER > FSM (status: AOSet) has received command 2033 (StopLoopAdsec)
WfsArbitrator _73363|INF| 4127|2021-03-31 05:49:27.309801| ADSEC > Executing openLoop...
WfsArbitrator _73363|INF| 4128|2021-03-31 05:49:27.309868| ADSEC > Requesting StopAo to AdSecArbitrator...
WfsArbitrator _73363|ERR| 4129|2021-03-31 05:49:27.333623| ADSEC > Error during command StopAo:
WfsArbitrator _73363|ERR| 4129|2021-03-31 05:49:27.333623| ADSEC > . StopAo: WARNING - adsecarb:Illegal command for state Failure (Stop Ao)
WfsArbitrator _73363|INF| 4130|2021-03-31 05:49:27.333732| COMMANDHANDLER > Command execution failed: Fsm forced to Failure
WfsArbitrator _73363|ERR| 4131|2021-03-31 05:49:27.333924| MAIN > StopLoopAdsec: FATAL -

Actions:

  • Then next offsetXYdisappears and returns an error to the AOS
  • The ResumeAO is not requested because OffsetXY failed. Error is passed to LUCI
  • Send the same OffsetXY from the AOS command GUI and stages moved. -> Light is on PWFS
  • ResumeAO from the AOS Command GUI and loop is closed
  • The next offset failed because the AO Ref star moved off the hotspot
  • the AOS Command GUI to Pause the loop, and then offsetXY the opposite X,Y values of the last offset
  • The AO Ref Star was now on the PWFS. ResumeAO from AOS
  • Next OffsetXY from LUCI was successful.
Other workaround:

Our current work around is
  • From Luci -> insert a pause after the current exposure and before the next offset.
  • reclose the loop, sets the gains, turns on GOPT and turns on NCPA
  • continues the LUCI script and data is again collected.
Note, the last LUCI image has to be thrown out because it will be SL rather then DL

If the LUCI script does not pause before the next offset, then the script stops. In this case, LUCI has registered a failure of the AO loop and will not continue with the script, even if the AO loop is re-closed.

If this LUCI script stopping occurs, the work around is:
  • re-closed the loop, optimize gain, GOPT and NCPA
  • send a 0,0 absolute offset from the LUCI services GUI. This offset will be successful. In this, the LUCI software will again be aware that the AO loop is closed and the LUCI script can be resumed at the position it has stopped.

TREFOIL IN LUCI IMAGE.

Observed a trefoil in the Luci images. The loop close at bin3 350Hz.

Actions:

  • Optimize gain and Gopt.
If the trefoil is still visible;
  • turn on NCPA
  • re-close, run optimize gain and run gopt processes.

CCD47 NOT CONNECTED.

During the power ON or a preset the CCD47 is connected and configured. It can report a failure.

Error message:

ERR| | WFS > Command returns error : Cannot turn off Bcu47 RESET-Active Low. Reason: Timeout waiting for powerboard.L.RESET_BCU_47.CUR - TIMEOUT_ERROR (-1000) GENERIC_SYS_ERROR

ccd47_failure.png

Action.

  • Turn ON/OFF the BCU reset signal.

CENTER PUPIL FAILED AND AO PRESET STILL ACTIVE.

Process Acquisition activated and the Center Pupil failed, to have the preset back or the process activated again, the INTERRUPT COMMAND can be applied to stop the AcquireRef process

FlaoGui failed the Pupil check process.

AOS_GUI_acqstill running..png

flaocenterpupil.png

APPLY OPTICAL GAIN. FAILED.

The process stop and it reports in the FLAOGUI the following error message". In the scenario of remote operation, the display of the GUI should be laggish and the GUI responds is not quick enough that the user can click two or three time a button. The execution of the process happens the first time and the next one will report as ERR.

To see that the optical gain is running, the log file (Gopt.L/R.xxxxxxxx.log) can be checked or looking at the Auxloop GUI tab-> OldGopt.

FLAOGUI error message:

"RETRY:optical gain is not one, cannot start tracking"

The FLAOGUI reports as an |ERR| and the wfsarbitrator is a |WAR|.

Action:

For an error of Gopt tail -f /home/AOeng/aolog/2021/mm/dd/gopt.L/R.xxxxxxxx.log

If it is not running:
  • From FLAOGUI:
  • Execute a second time the optimization Gain to reset the value to ONE.
  • Execute Apply Optical Gain.
  • Check the Gopt log for Tracking values.
Check the Gopt log for Tracking values:

python_156613 |INF| 23|2021-04-02 23:28:33.861787| MAIN > Tracknum: 20210402_250000 demodDelta/demodCmd: 1.9e-08/1.9e-08 gopt: 0.397

python_156613 |INF| 24|2021-04-02 23:28:40.402069| MAIN > Tracknum: 20210402_250000 demodDelta/demodCmd: 1.85e-08/1.89e-08 gopt: 0.395

For Multiple clicks check in the Gopt log or opening the Auxloop GUI plot.

RE-ROTATOR IN RED TRACKING.

Telescope tracking high in elevation and the rotator moving fast towards the re-rotator limit or just the rotator position is beyond the limit operations triggers a WFS-Adsec misalignment and the corrections become bad with a possible Rip of the Shell.

derotator_notracking..png

Error message:

WfsArbitrator _73363|INF| 2781|2021-03-31 04:45:06.956176| WFS > Python command: WfsArbScripts.updateNcpa(self, sensor = 'FLAOWFS', instr = 'LUCIFER', rotAngle = 359.38, zero = 0)
WfsArbitrator_73363|INF| 2782|2021-03-31 04:45:09.776475| MAIN > Camera lens tracking: moving by x= 0.2 y= -1.6 (um)
WfsArbitrator_73363|INF| 2783|2021-03-31 04:45:16.995055| WFS > Python command: WfsArbScripts.updateNcpa(self, sensor = 'FLAOWFS', instr = 'LUCIFER', rotAngle = 358.866, zero = 0)
WfsArbitrator_73363|INF| 2784|2021-03-31 04:45:18.295541| MAIN > Camera lens tracking: moving by x= -0.7 y= -1.3 (um)
WfsArbitrator_73363|INF| 2785|2021-03-31 04:45:27.025753| WFS > Python command: WfsArbScripts.updateNcpa(self, sensor = 'FLAOWFS', instr = 'LUCIFER', rotAngle = 358.345, zero = 0)
WfsArbitrator_73363|INF| 2786|2021-03-31 04:45:31.451637| MAIN > Camera lens tracking: moving by x= -0.4 y= -1.2 (um)
WfsArbitrator_73363|INF| 2787|2021-03-31 04:45:37.054146| WFS > Python command: WfsArbScripts.updateNcpa(self, sensor = 'FLAOWFS', instr = 'LUCIFER', rotAngle = 357.83, zero = 0)
WfsArbitrator _73363|ERR| 2788|2021-03-31 04:45:44.085160| MAIN > Internal rotator position 352.0 is out of the allowed range
WfsArbitrator _73363|ERR| 2789|2021-03-31 04:45:45.086005| MAIN > Internal rotator position 352.0 is out of the allowed range
WfsArbitrator _73363|ERR| 2790|2021-03-31 04:45:46.086775| MAIN > Internal rotator position 352.1 is out of the allowed range
WfsArbitrator _73363|ERR| 2791|2021-03-31 04:45:47.087451| MAIN > Internal rotator position 352.1 is out of the allowed range
WfsArbitrator_73363|INF| 2792|2021-03-31 04:45:47.087636| WFS > Python command: WfsArbScripts.updateNcpa(self, sensor = 'FLAOWFS', instr = 'LUCIFER', rotAngle = 357.315, zero = 0)
WfsArbitrator_73363|INF| 2793|2021-03-31 04:45:47.153305| MAIN > Camera lens tracking: moving by x= -0.3 y= -1.3 (um)
WfsArbitrator _73363|ERR| 2794|2021-03-31 04:45:48.106517| MAIN > Internal rotator position 352.1 is out of the allowed range
WfsArbitrator _73363|ERR| 2795|2021-03-31 04:45:49.107475| MAIN > Internal rotator position 352.1 is out of the allowed range

march_31_rotangle.png

Action:

  • Cancel preset.
  • Unwrap the rotator.
  • Preset.

OCAM NOT LIVE after Power up

The OCAM camera can not be live if the masterdiagnostic process at the WFS side is not up and running. During the power up, the masterdiagnostic process can be in an state of INIT (yellow).

In that State, the power ON will finish succesful, but the ocam viewer will show NOT LIVE.

Screen Shot 2021-04-16 at 10.33.22 AM_masterdiag_init_ocamnot live2.png Screen Shot 2021-04-16 at 10.33.22 AM_masterdiag_init_ocamnot live0.png

Actions:

  • Open the system process GUI.
  • Masterdiagnostic START.

OCAM OVERILLUMINATION TRIGGERED.

The OCAM camera has a protection of overillumination. The camera doen;t responds and it requires to RESET the protection from the OCAM engineering GUI.

CCD47 PSF like Snow flake.ADSEC NOT FLAT.

Looking at the PSf of the ARGOS white source on the CCD47 and there is an image that looks like a snow flake. This is a typical image of the Adsec in rest mode.

Adsec in Rest Mode.

Adsec-notFlat.png

Action:

  • Open Adsec Control GUI or AOS GUI.
  • Check Adsec is in Rest mode (power On and load program done).
  • Set FLAT from Adsec or AOS GUI.

ADSEC PANIC!.

A failure of the close loop process can triggered a Failure state of the Adsec and the posteriori Fault Recover process ends up with a Panic state.

In the panic state the adsec sometimes doen;t responds to the IDL commands and a recover stop/start the Adsec arbitrator only will not solve the issue.

Example of failure.

WFS pupil centering process the loop opens->Adsec Failure.-> Recover failure process->Adsec Panic!
  • Adsec arbitrator stop/start->adsec Status to AORunning. It is clear that the loop was open before and the shell was in rest state. This is an unknown status of the adsec and it clears up with a adsc_stop/start.

Action:

  • Adsc_stop/start.
  • Check for processses up and running; adsc_check
  • Power On
  • Load program.
The load program has showed that sometimes requires a second try.
  • Set the shell.
  • WFS arbitrator->stop/start.


WFS AOSET and AOS pause step still running.

In an open loop event, the System can be trapped in an open loop and the Pause process still running.

Stop AO is executed but it doen;t clean the AOS process. From the Telescope side a cancel preset can be executed and it seems that it clears up the AO, but the case is that the Pause process is still running.

flao_pause.png

Action:

  • Stop AO. Open loop
  • Adsec process GUI-> AO arbitrator: stop/start.

Faster Recovery from AdSec PANIC

In a shell logged into AOeng@d(s)xadsec, type "adsceng &". Open the "System Processes" GUI. Stop the following processes in the following order: IDL controller, Fast diagnostic. Give the AdSec a few seconds, then restart the IDL controller, followed by the Fast diagnostic. Then cycle the AdSec Arbitrator. Be sure to do those operations in order.

Open the "Adsec Control" Gui to check on the progress of the recovery.

If this fails after more than one attempt. Open the IDL terminal from the "adsceng" Gui. Type "print, fsm_power_off()".

If this commend works, you'll see a couple of messages print in the IDL terminal and it will return you to the command prompt. Close the terminal by pressing the "X" button. Don't quit IDL or it will quit every IDL process on the Adsec. Stop and Restart the Adsec Arbitrator process. The "Adsec Control" Gui should show the Adsec powered off. You can then power the Adsec on normally and set the shell.

Note: if this doesn't work, just do adsc_stop/start

GOPT Process Won't Keep Running.

Note: The Arcetri people have fixed this so that it now works automatically, but it is probably a good idea to make sure that we know this procedure, just in case.

The Gopt process keeps crashing a few seconds after the process is restarted.



There is usually one of two problems:

Problem 1, the m2c() matrix is missing.

In a terminal logged into the wfs machine, type:
aoidl
IDL> ao_init

Then do the commands:

IDL> a= getaoelab(YYYYMMDD_mmhhss) 

This needs to be a tracking number with the same modal basis as is

used now, perhaps with the same reconstructor, too. The easiest way to do this is
to save a new set of optical loop data and enter that tracking number
("Filename"). Click all of the check boxes under "Optical loop", and only those,
then save some number of frames. We usually use 4000 for normal analysis, but
for this, try a smaller number, say 100.



IDL> help, (a->control())->c2m()

Problem 2, the system can't rewrite files in the directory
/local/aomeas/adsec_data/today'sDate/today'sDate_250000

Delete that directory (it will be rewritten) and presto!

IDL Problems

These issues are rare, but may still happen.

* If the AOSGUI pops up an error message box, there is a 50\% chance that there really is an IDL License problem.

IDL Zombie Process

    • If adsc_check shows idlctrl to be a Zombie Process, IDL must be stopped and restarted:
      idl_zombie.jpg

Solution

  1. Stop the IDL Control via the System Process GUI (see above)
  2. Start the IDL Control via the System Process GUI
  3. Start an IDL Terminal via the adsceng GUI (see above)
  4. At the idl prompt type AdOpt > print, fsm_load_program(/auto) (note, you will see output scrolling on the AdSec Control GUI. This take more than a minute)
  5. The AdSec should be in a Ready state
  6. Stop the AdSec Arbitrator via the System Process GUI
  7. Start the AdSec Arbitrator via the System Process GUI
  8. The AdSect is ready ready to "SET" This solution disconnects the IDL controlling program that communications to the AdSec by Stopping the IDL Control Process. When IDL is restarted, id does on reconnect to the AdSec. The IDL> command fsm_load_program(/auto) reconnects to the AdSec and reloads the DSP code. IDL will then have full communication to the AdSec. The AdSec Arbitrator process usually does not reconnect automatically to the IDL process, so this arbitrator must be stopped and restarted to force a reconnection. In addition, the *fast diagnostic* process will usually reconnect to the AdSec when the DSP codes are loaded via the *fsm_load_program(/auto)* command. Be sure the *fast diagnostic* process is running and connect to the Msgd before the DSP load code request is executed.

  • As a last resort, the entire AdSec can be powered off, processes stopped and restarted and powered back on (see for instructions) IDL License "Really" Not Available

  • To determine if IDL really has lost its connection to the license server:
    1. The adsc_check command will show the idlctrl as "NOT running"
    2. In an adsecsx terminal type idl. If a license is available then IDL will start:https://cd9b379d-a-79502442-s-sites.googlegroups.com/a/lbto.org/flao_operations/troubleshooting/for-ao-scientists/misc/idl_prompt.jpg?attachauth=ANoY7cpEm95Su2Toj5PeqN_uLlcCFlt9Iwf-uK8mY2Zy2TP9gC9vZGA3ZBH4DFOX7oTtJQgN9RiImL_QAmTRFrG2OKJAGCkfMyx9n37jfjOdZaQKJ6Qi8yJT_QbedxFf6qnzlo-Xdr1NB-b140Qi2GW0dsBATH_bP6unNI0wpnGO2y0bjabB-zG3fp8F-yMcmGkJgnLZvCG1eijSgl0obfkISsYCJ_Ls94zZfLrnAJlMgmNc6mWEYCim5KyF7KHmeHiFTiXfmZQ1eROMQuHfLQ63fmXIM-hJxQ%3D%3D&attredirects=0 Solution

  • SX: The SX AdSec computer has an INAF stand alone license, so a Stop and Start of the IDL Control Process should solve the problem. The DSP code must be reloaded via the IDL> *print, fsm_load_program(/auto)* command. If the Stop and Start IDL Control Process does not solve the problem then there is some larger IDL problem
  • DX: The DX AdSec computer uses the LBTO license server. Thus, if a Stop and Start of the IDL Control Process does not solve the problem then there is a larger IDL problem. The starting of IDL in an adsecdx terminal will fail (ie go in to demonstration mode) if there is a problem with the LBTO IDL server. IDL License Not The Problem

In some cases error unrelated to IDL are displayed on the AOSGUI as an IDL License Not Available. In these cases, the Engineering GUIs must be examined to see if there are other process that are stop or in a Zombie state. If so, then usually restarting the process will correct the problem

*NOTE* if the *fast diagnostic* process has to be restarted, then the command *fsm_load_program(/auto)* must be executed at an IDL> prompt so a reconnection is made.

No Wind Speed Displayed

On the AdSec Control GUI, make sure that the Wind speed is being displayed.

If it isn’t displaying a wind speed, like this:

Make sure that the Anemometer process is “Up”, on the AdSec System Processes GUI.

If the Wind speed value is not updated in the Adsec GUI. Execute the following procedure described in the Adsec procedures wiki.

Link below.

https://wiki.lbto.org/AdaptiveOptics/Anemometer_no_info


No Elevation Information

make sure that the Elevation and Swing arm information is correct:

If they are incorrect or missing, it is a problem with the connection to AOS. Xianyu has made a new, quick method for fixing this on the AOS GUI: Simply press the “E” button (it stands for “Execute”) on next to where it says “FLAO: Connected” (outlined in blue). (It would actually say FLAO: Disconnected, in red, but anyway...) After pressing the “E” button, stop and restart the AdSec arbitrator process. This fix has worked every time that I’ve tried it. If for some reason, that doesn’t work, restart the AOS process.


AOS COMMAND GUI DOESN'T ALLOW TO SET THE WFS.

The WFS is power ON and ready to use used. The system was used previously in LBTIWFS mode.
The WFSMODE has to be updated in the AOS command gui. having the LBTI Active, the AOS only get the connection from the LBTI and when the user tried to edit the field doen;t allow to change it.

Checking the LBTI tag in the AOS shows the LBTI "Active" and the FLAOWFS in "idle"

lbti_FLAOWFS.png

Action:

  • STOP/START AOS.
AOS_2.png

ARTIFICIAL SOURCE NOT VISIBLE IN CCD47.

To have the artificial source (Argos calibraiton unit) in the CCD47 requires to have the light path align to the WFS. If the light is not in the CCD47 after the setup of the Hexapod. There are a few checks.
  • Check that the Luci calibraiton Unit is not in the light path.
It has been observed that after a luci calibraiton the calibraiton Unit is still in place and looking at web cam can be sseing the unit is blocking the light to the WFS
  • M3 pointed to WRONG focal station.
It has been observed that the position of M3 doen;t corresponds with the focal station and even whe the instrument Luci is authorize and all the OSS guis shows that it is in the right place.

CCD47 view when there is not a M3 pointing to the right focal station. The CCD47 catch some ambient light.

M3_OFF.png
  • Looking at the web cam, it is visible that the M3 is not WITH the right rotatIon.
M3_POS.png
  • Init/home the M3 from the OSSGUI.
The home steps takes about a few minutes to be completed.
  • Authorise Luci from IIF GUI.
M3_oss2.png

TMS SOURCE VISIBLE IN THE CCD47 WITH A BACKGROUND PATTERN.

When the TMS is used after the SSD or any telescope intervention that requires to remove some of the TMS retrorelectors or it requires new aignment, the TMs system uses visible light (640nm). This laser can be remained on after the TMS system is powered off. The control of this laser is local and it can be left on.

For the AO operations this laser illuminates the secondary and the light can be picked up in the CCD47 and the OCAM and this extra background compromise the AO close loop.

Check:

The figure below shows the AO preset with the hexapod position and the Argos source in CCD47 field of view. To have a better visualization of the background, the Filter#2 is set to empty.

The observed pattern in the CCD47 ("Jupiter pattern") can be give a wrong idea of what it is happening, where it is the source, is there something interfiering in the light path?, is the light path well aligned.?etc...

TMS_laseron_CCD47_bright spot.png

Image of the CCD47 with Argos light source off.

ccd47_20220909.png

Alignment of the PSF in the PyWFS shows 4 spots at the edge of the pupils.

ocam_spots_20220909.png

Turn off the Argos light source.

ocam_spots_lightoff.png

Looking the GUIDER images on sky, the ffect is a diffuse background. The image below shows the two GUIDER foul1 and two and it is vissible the type of background that the visible TMS laser produced.

guider_with_TMS_laserlagnmentON_20230605.png

Action:

  • Contact TMS team to get some feedback about the TMS tasks.
  • The laser can be turned off using the local button of the laser control unit located int the AUX room. This is local control.
  • Contact mountain crew to send someone to turn off the laser. Use the POWER button.
  • Send an email to telescope work that the laser alignment is turned off
Image of the laser control unit.

TMS_laser_control.jpg

NOTE from HeeJoo Choi:

" The alignment laser is the TMS internal system that has exactly the same optical path with the metrology (IR, 1550 nm) laser.

Maximum output alignment red 640 nm: < 250 μW, red light

Since the metrology laser is invisible IR, we use a visible alignment laser for guiding.

Usually, it is only turned on only for aligning work. (2-3 times per year)

In front of the TMS cabinet (in the Aux room, photo attached),

there is push button to turn on and off the alignment laser. This button only can turn on and off, and we don't have remote access to control it. "

ROTATION MISMATCH TRIGGERS FRINGES IN OUTER EDGE OF PUPIL.

Looking at the PUPILS images in a close loop status with some gains applied to the High Orders, a fringes patern starts to show up and this can be an indication that there is a mistmatch in the rotation.

-rotation____.png Rotation_signal_ocam_mismatchrotation.png

Actions:

1. Check for Pupil rerotator function is active.
  • Open WFS control GUI.
  • Check that the Pupil rerotator is in Tracking Mode.
  • If it is not ON-> turn ON
2. During tracking the pupil re-rotator goes to the limit. It shows a Red button.
  • move to a new Rotator position. Ask astronomer support for a new rotation angle.
3. Pupil tracking active and calibration good.
  • Home the pupil rerotator from the Pupil rerotator hardware GUI.
4. Requires calibration of the offset.
  • Close loop with a low gain in the HO1 and HO2, just to se the outer edge fringes.
  • Open pupil rerotator tracking.
  • Move the pupil rerotator using the HARDWARE GUI positve and negative from no visible fringes to visible fringes.
  • Determine the midpoint from the positions where the fringes starts to be visible.
  • Modify the wfsarbitrator file with the new offset.
  • Repeat for the other binnings.

WFS control GUI.

pup_rotation2.png

TIMEOUT DURING POWER UP.

During the power up (Operate) sequence, it is seems comon to have a timeout during the peorcess; PROC BCU_2K.

See the crop of the message log:

Action:

  • Re-try the OPERATE.

ARTIFICIAL SOURCE VIGNETTED CCD47.

The artifitial source can be vignetted by the Autoguider probe. This effect can be detected in a defocused PSF where it is visible the vignetting.

The vignetted PSF in the CCD47 could looks like that it is OK and the process of acquistion don't fail and it is in the center pupils that the AO oscillated (skip frames).

The source looks "normal" in the CCD47.

psf_vignetted0.png

Check.

  • Set the hexapod positions for the last know positions.
  • Check that the PSF is visible in the CCD47.
  • Defocus, eg. delta of +0.5.
  • The image defocused shows to be truncatted.
psf-vignetted_defoc0.png

Action.

  • Most probably the AGW is in the optical path and it required to be parked or move away.

ARGOS CAL UNIT NOT DEPLOYED.

The deploy/retract of the arm didn't success and the OSS information could show an UNKNOWN status.

The drivers losses the communication and it is not updating the current status.

After a power bump, the Swing arm controller can be in a fault state or to have the wrong setup parameters after the power cycle of the controller. In this scenario the OSS doesn't trap the status and a command like Park/Deploy will show moving and the arm is not moving.

The information in the OSS is limited and it requires to connect to the argos machines sx/dx-lalas and to open the GUI DX/SX_SwimArm to have all the status and variables set.

The basic Tab wiill show the hardware status: Simotion Error.

Good status.

Report of the Argos GUI when the Arm is parked and hardware SimotionOK

Good_status_argoscalunitarm.png

Action.

  • From the obs1/2 machines connect to Argos computer argos@sx-lalas via VNC. vncviewer 192.168.26.148, dx-lalas->vncviewer 192.168.26.149
  • The computer Desktop is accesed and open the GUI called; eg. SX_Cal_Swim_Arm_gui
  • Check the TAB->basic->Hardware status ->Simotion error.
  • Execute a STOP
  • Go to Tab Status.
  • Do RESET.
  • Check Tab->Status -> enable conditions fullfilled YES.
  • wait a few seconds for the feedback in the log message.
  • Go to Tab basic.
  • Hardware status ->Simotion OK
  • If the status is not Simotion OK execute another RESET.
  • Execute the park/working movements.
  • When the movement is completed.
  • Basic->hardware status Position achieved (PP)
  • OSS ->Status: Retracted/Deployed.

OSS fault.

oss_fault_20221012.jpg

Argos Cal Unit light source UNKNOWN state.

After a power bump or a reset of the hardware the Lamp status in an UNKNOWN state.

Action.

Connect to the Argos servers.
  • Open the White source GUI from the Argos server.
    • SX: vncviewer 192.168.26.148:3
    • pwsd:
  • DX:
    • vncviewer 192.168.26.149:3
    • pwsd:
  • Close GUI.
To refresh the status.
  • Open Gui again.
  • Click the Power OFF or ON
It will report: "Probably ON/OFF"
  • Open the shutter fully.
Check the GUI status for update of status.

Argos Cal Unit light source ? state.

The State of ? in the Panel GUI could come from:

Possible power bump that it triggered a a power cycle of the Argos server.

The process that runs the Source is not active anymore.

Action.

  • Open the GUI from the Argos server.
  • SX: vncviewer 192.168.26.148:3
  • pwsd:
  • DX: vncviewer 192.168.26.149:3
  • pwsd:

Check if the Gui is Connected. The top right of the GUI.
  • Connected green
  • No connection Red.
source_argos0.png
  • Open the Argos Firefox.
    • Open the Monit web page.
source_argos2.png

  • Check the process (the last three at the botton.
  • Restart the process. SX/DX_CAL_WHITE_LIGHT_SOURCE BASDARD.
source_argos1.png

Argos Light source too dimm.

It was reported in 2018 that the DX source measured with the CCD39 a magnitude 4 times fainter. The magnitude expected should be ~10.

The magnitude for Soul-SX is 10.2 and Soul-DX is 10.8

Action:

If the problem is the source, park the swingarm and take the telescope to horizon.
1.Using the radiometer, "carefully" measure the flux of the source at the front of the AdSec, in the same way it was done in 2016 (see Michael's report from back then, attached to this IT) and compare (was 200 nW).
2. If flux is actually lower, go to the back of the AdSec, remove fiber and measure flux coming out of fiber. Compare with flux measured in 2016 (600 nW).
3. If fiber flux is lower, the problem is either the fiber itself or the source located in the ARGOS DX CRE cabinet.

Access to the back of the adsec is using the blue scissor lift.
  • Remove the white cover
  • unplugg the yellow fiber.
  • Connect to the power meter. Expected 350nW.
Note from IT#7412

- The DX AdSec was moved out of the beam (and DX LBC out of the beam) and the telescope sent to horizon. ARGOS DX Cal on-axis source turned on.
- Using the blue scissor lift, I positioned myself in front of the AdSec and could barely see the light. Using the newly acquired power meter, I measured ~2 nW.
- Next I moved the scissor lift to get access to the back of the AdSec hub, removed the white cover and unplugged the yellow fiber. I connected it to the power meter and measured 350 nW. Michael L. had recorded 600 nW on September 2016 (using a different power meter). Not the same, but still OK. Then I reconnected the fiber, making sure that the connector went all the way in.

Argos Swing arm controller. Input parameter error.

After a power bump or a power glitch at the telescope, the Swing arm controller could be affected and the ocntrol process lose the operations parmameters.

The ARGOS swing ARM interface shows the hardware status with: Input parameter error.

argos_inputparametererror.jpg

Action:

  • Open the SX/DX_SwimgArm GUI from the Argos server; SX: vncviewer 192.168.26.148 and DX:vncviewer 192.168.26.149.
  • Go to tab STATUS.
  • Reset button.
    • The reset button set the configuration parameters for the controller.
  • The Output should show: SIMOTON OK.
    • The DX has a faster refresh of the status than the SX. So be patience for the SX
  • if the status doesn't change. Try it again.
  • If the status doesn't change.
  • Open a Firefox session in the machine. e.g sx-lalas.
  • Go to localhost:2812. This open a web interface to stop/start processes.
  • scrool down to the process list.
  • Restart: SX/DX CAL.SWING ARM.BASDARD.
  • wait a few seconds.
  • Open the swing arm GUI application.
  • Reset button.
  • Expected output: SIMOTION OK

Acquire Luci through WFS Optical loop data or WFScontrolGUI error.

The acquisition of the Luci images through the Optical loop data or WFS Control GUI; Luci Darks reports an error at the level of the WFS arbitrator and in the optical loop data. The Optical loop data GUI takes the AO telemetry and it reports an error.

The error has been triggered for a change of the Luci computers where the connections keys (ssh ) where not exported from the old machine.

Error message Optical loop data process:

OptLoopDiagnostic _166752|DEB| 287|2023-03-22 20:32:21.34004 ARB-INTERFACE > Waiting message reply: sender=adsecarb.L@M_ADSEC, code=2024
OptLoopDiagnostic_166752|DEB| 288|2023-03-22 20:32:22.34017 ARB-INTERFACE > Error in thWaitMsg: -5001 (Timeout error)
OptLoopDiagnostic_166752|ERR| 289|2023-03-22 20:32:22.34027 MAIN > Command Save status error
OptLoopDiagnostic_166752|ERR| 290|2023-03-22 20:32:22.34032 MAIN > Error saving AdSec status: (-1) Return from search routine (item not found)

If a LUCI dark is taken from the WFS control GUI an error message pops up.

luci_erro_takedark.png

Action.

Remove the luci.luci line from ~/.ssh/known_hosts and do ssh-copy-id lucifer@luci.luci.lbto.org (which required a password) to copy our public keys into to luci.luci's ~/.ssh/authorized_hosts.

Recover WFS from Optical Loop Diagnostic GUI stuck.

The Optical diagnostic acquisition GUI is a process that it required to save AO telemetry and Luci images. This process request adsec telemetry through the masterdiagnsotic process.

When this process get stuck block many of the communications to the Adsec and for example Open loop command will not pass through. This is an scenario that we don't want to have.

The GUI remains in grey, the process can be restarted but the "knot" is already in place in the system and a new GUI will stuck again.

Action:

open the loop through the changes in the WFS variable inspector.
  • slopecompctrl.R/L.FASTLINK.ENABLE.REQ -> 0
  • Restart the WFS arbitrator.
  • Force open loop from FLAO GUI or StopAO from AOS GUI.
  • Restart the optical loop diagnostic process.
With this recover steps the AO ref star is still in the PyWFS and the loop can be resume using the FLAO GUI and the optimize/Gopt steps to set new gains.

Loop Open but it is still be reclosed through FLAOGUI.

The loop is closed and an event triggers an open loop. The star still in the pupils and the operator tries to use the FLAO gui to reclose. The reclose loop shows to have sikp frames and loop open again. To remember that when the loop opens tha guider takes care and drag the star, if this type of sequence persist do the recover.

Action.

  • If Reclose loop doesn't work giving an open loop due to skip frames.
  • Open guider loop . Ask OSA.
  • Set TT gains to 0.1
  • Close loop from WFSControlGui.
  • Observe that the pupils are illuminated, increase the TT gains 0.5 and apply 0.1 to HO1.
  • Observe that loop is stable. The pupils should be illuminated and not skip frames
  • Open loop from WFScontrolGui.
  • Reclose Loop from FLAO.
  • Restore the gains before the Open loop event.

It is important to sync the AOArbitrator to allow the instrument to send offsets.

-- JuanCarlosGuerra - 19 Mar 2021
I Attachment Action Size Date Who Comment
-rotation____.pngpng -rotation____.png manage 46 K 03 Jan 2022 - 20:09 JuanCarlosGuerra  
AOS_2.pngpng AOS_2.png manage 118 K 17 May 2021 - 21:16 JuanCarlosGuerra  
AOS_GUI_acqstill running..pngpng AOS_GUI_acqstill running..png manage 76 K 07 Apr 2021 - 16:25 JuanCarlosGuerra  
Adsec-notFlat.pngpng Adsec-notFlat.png manage 85 K 03 Jan 2022 - 19:57 JuanCarlosGuerra  
FLAOWFS_IDLE.pngpng FLAOWFS_IDLE.png manage 177 K 17 May 2021 - 21:06 JuanCarlosGuerra  
Good_status_argoscalunitarm.pngpng Good_status_argoscalunitarm.png manage 163 K 13 Oct 2022 - 23:27 JuanCarlosGuerra  
LBTI_ACTIVE.pngpng LBTI_ACTIVE.png manage 173 K 17 May 2021 - 21:06 JuanCarlosGuerra  
M3_OFF.pngpng M3_OFF.png manage 36 K 16 Dec 2021 - 19:03 JuanCarlosGuerra  
M3_POS.pngpng M3_POS.png manage 633 K 16 Dec 2021 - 18:56 JuanCarlosGuerra  
M3_oss2.pngpng M3_oss2.png manage 155 K 16 Dec 2021 - 19:06 JuanCarlosGuerra  
Rotation_signal_ocam_mismatchrotation.pngpng Rotation_signal_ocam_mismatchrotation.png manage 45 K 03 Jan 2022 - 20:12 JuanCarlosGuerra  
Screen Shot 2021-04-16 at 10.33.22 AM_masterdiag_init_ocamnot live0.pngpng Screen Shot 2021-04-16 at 10.33.22 AM_masterdiag_init_ocamnot live0.png manage 47 K 16 Apr 2021 - 22:29 JuanCarlosGuerra  
Screen Shot 2021-04-16 at 10.33.22 AM_masterdiag_init_ocamnot live2.pngpng Screen Shot 2021-04-16 at 10.33.22 AM_masterdiag_init_ocamnot live2.png manage 55 K 16 Apr 2021 - 22:26 JuanCarlosGuerra  
Screen Shot 2021-04-16 at 10.33.22 AM_masterdiag_init_ocamnot live3.pngpng Screen Shot 2021-04-16 at 10.33.22 AM_masterdiag_init_ocamnot live3.png manage 868 K 16 Apr 2021 - 22:12 JuanCarlosGuerra  
TMS_laser_control.jpgjpg TMS_laser_control.jpg manage 380 K 12 Sep 2022 - 17:30 JuanCarlosGuerra  
TMS_laseron_CCD47_bright spot.pngpng TMS_laseron_CCD47_bright spot.png manage 674 K 12 Sep 2022 - 17:06 JuanCarlosGuerra  
argos_inputparametererror.jpgjpg argos_inputparametererror.jpg manage 1 MB 17 Mar 2023 - 17:24 JuanCarlosGuerra  
argoscalunit_20220611.pngpng argoscalunit_20220611.png manage 144 K 13 Oct 2022 - 21:42 JuanCarlosGuerra  
bcu2k_powercycle.pngpng bcu2k_powercycle.png manage 205 K 24 Apr 2021 - 01:55 JuanCarlosGuerra  
camra_lens_temp.pngpng camra_lens_temp.png manage 155 K 16 Dec 2021 - 18:33 JuanCarlosGuerra  
ccd47_20220909.pngpng ccd47_20220909.png manage 38 K 12 Sep 2022 - 17:08 JuanCarlosGuerra  
ccd47_failure.pngpng ccd47_failure.png manage 141 K 29 Mar 2021 - 18:33 JuanCarlosGuerra  
derotator_notracking..pngpng derotator_notracking..png manage 518 K 29 Apr 2021 - 18:08 JuanCarlosGuerra  
flao_pause.pngpng flao_pause.png manage 29 K 27 Apr 2021 - 06:54 JuanCarlosGuerra  
flaocenterpupil.pngpng flaocenterpupil.png manage 216 K 07 Apr 2021 - 16:35 JuanCarlosGuerra  
frame_counter.pngpng frame_counter.png manage 430 K 19 Mar 2021 - 03:37 JuanCarlosGuerra  
guider_with_TMS_laserlagnmentON_20230605.pngpng guider_with_TMS_laserlagnmentON_20230605.png manage 239 K 05 Jun 2023 - 16:15 JuanCarlosGuerra  
lbti_FLAOWFS.pngpng lbti_FLAOWFS.png manage 189 K 17 May 2021 - 21:11 JuanCarlosGuerra  
luci_erro_takedark.pngpng luci_erro_takedark.png manage 139 K 23 Mar 2023 - 19:41 JuanCarlosGuerra  
march_31_rotangle.pngpng march_31_rotangle.png manage 57 K 13 Apr 2021 - 20:59 JuanCarlosGuerra  
ocam2k_triangle.pngpng ocam2k_triangle.png manage 96 K 19 Mar 2021 - 03:50 JuanCarlosGuerra  
ocam_reset2.pngpng ocam_reset2.png manage 110 K 23 Apr 2021 - 09:59 JuanCarlosGuerra  
ocam_spots_20220909.pngpng ocam_spots_20220909.png manage 121 K 12 Sep 2022 - 17:14 JuanCarlosGuerra  
ocam_spots_lightoff.pngpng ocam_spots_lightoff.png manage 110 K 12 Sep 2022 - 17:14 JuanCarlosGuerra  
oss_fault_20221012.jpgjpg oss_fault_20221012.jpg manage 366 K 13 Oct 2022 - 23:56 JuanCarlosGuerra  
psf-vignetted_1.pngpng psf-vignetted_1.png manage 38 K 11 Feb 2022 - 21:23 JuanCarlosGuerra  
psf-vignetted_defoc0.pngpng psf-vignetted_defoc0.png manage 39 K 11 Feb 2022 - 21:22 JuanCarlosGuerra  
psf_vignetted0.pngpng psf_vignetted0.png manage 31 K 11 Feb 2022 - 21:22 JuanCarlosGuerra  
pup_rotation2.pngpng pup_rotation2.png manage 277 K 03 Jan 2022 - 20:38 JuanCarlosGuerra  
source_argos0.pngpng source_argos0.png manage 332 K 25 Jan 2023 - 22:42 JuanCarlosGuerra  
source_argos1.pngpng source_argos1.png manage 266 K 25 Jan 2023 - 22:43 JuanCarlosGuerra  
source_argos2.pngpng source_argos2.png manage 124 K 26 Jan 2023 - 00:15 JuanCarlosGuerra  
wfs_ocampowercy.pngpng wfs_ocampowercy.png manage 142 K 23 Apr 2021 - 09:53 JuanCarlosGuerra  
Topic revision: r60 - 10 Apr 2024, JuanCarlosGuerra
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback