We tracked stars at various zenith angles and changed the Az and Zd offsets, taking images with the PSF camera for each position. After Armand's changes during the day the offset is the same for all Zenith angles.

Star Zd Az
dAz, dZd image

Polaris 61.5 0.7
0, 0 1568923765.fits
0.5, 0 1568923985.fits
0, 0.5 1568924088.fits
0.5, -0.5 1568924324.fits

Eltanin 29.2 327.9
0, 0 1568924558.fits
0.5, 0 1568924683.fits
0, 0.5 1568924747.fits

Benetnasch 66.6 314.7
Vega 15.6 313.8
0, 0 1568925023.fits
0.5, 0 1568925090.fits
0, 0.5

Kochab 57.3 342.0
Sulafat 8.7 299.5
0, 0 1568925265.fits
0.5, 0 1568925420.fits
0, 0.5 1568925485.fits

Alphecca 52.6 283.0
Arcturus 72.2 282.5
Oph Alpha-55 32.2 246.0
Albireo 1.2 229.1
0, 0 1568925734.fits
0.5, 0 1568925842.fits
0, 0.5 1568925917.fits

Nunki 55.8 190.6
Altair 20.2 168.3
Enif 35.7 115.2
Alpheratz 59.0 71.4
Caph 54.8 35.6
Deneb 21.2 33.9
Polaris 61.5 0.7

Emergency stop applied because of a azimuth value(encoder) not in the pre-defined range +-0.015

• first parkin ==> Azimuth 0.013 ==> Emergency because offset even if in the correct range
• 2nd parkin ==> Azimuth 0.004 ==> Emenrgency stop because offset not in the correct range (eye control not drive control)

Many parkin operations done. To confirm the different movements , a Parkin test with a azimuth position 20 and Elevation 70.

This is to validate the complete "Parkin" scenario with "random" az and el positions

Many differents succesfull  "goto position" operations ... MOS configuration file (XML) modified to aplly to correct Azimth and Elevation ranges for secure movement 

• GotoPosition azimuth range : [-126..354]
• GotoPosition elevation range : [0..75]
• FastGotoPosition azimuth range : [-96..324]
• FastGotoPosition elevation range : [0..50]

• Debugging of the "Parkout" sequence with errors ==> 
  • MOS received the error and set the FSM in error state
  • User from semi-expert GUI should acknowledge the error ==> MOS FSM acknowledge methosd is call (just authorized from the error state) to acknowledge the error to the PLC.
  • PLC set up all the needed variables to inform the MOS and GUI of the result of the acknowlegment 
• Today, an PLC error sends the MOS FSM in the ERROR state which can the only go "Parked" state via the "Acknowlegde" method.

Tests and debugging of the tracking procedure. Many components are involved : PLC MOS GUIs.

Each component needs to be well debbuged to achieve a safe movement of the telescope

==> IN PROGRESS

Start of the tracking debug ==> PLC and MOS 

Pointing to polaris ==>

Azimuth = 0.808

Elevation = 59.941 + 1 degree (correction)

Same operations as yesterday ==> pointing to Polaris with the same coordinates

Same operations as yesterday ==> Polaris position

. Fisrt day of the high speed drive tests with IFAE team.

• Tests for tuning and generating motor plots at 10% (0.0234 Rad/s) of the maximal speed (GRB alert speed)
• Tuning of the emergency stop from 0.05 Rad/s2 up to 0.2 Rad/s2
• 6 movements at 25% speed. (from -90 to 270)
• repositionnning to -90 at 40% 
• movements from -90 to 270 and reverse at 40%
• 3 movements from -90 to 270 and reverse at 60%  : the FW generates an alarm and the drive stops the movement.
  • The FW level was ok but the the status (GRB Fast Rotation and UPS system) got red.
  • Koji has been contacted to look at this issue.

• The FW issue is not solved . No movement can be done
• The FW is going to be restarted ==> It takes several hours to put it down and up again
• Drive movement are stucked 

During a park-in action , the acces tower did not close correctly.

• Test at 60% maximal speed from -90 to 0
  •  Check of the FW discharge : No error (FW 2 : 95% FW1 : 100%)
• Test at 60% maximal speed from -90 to 270
  • Check of the FW discharge ==> Error (FW 2 : 90 % FW1 : 100%)
  • Drive stops at 250 degree.
  • Power consumption = 60kw
•  

• On Thrusday :
  • new movements at 45% from -90 to 270 have been done.
  • No possible movement at 60% because the FW and UPS issues are not solved yet
    • Ino will back on site when HITACHI team will be on site for FW maintenance
      • Tests at 60% will be done to validate (or not) the correction applied by Hitachi team.

new session of high speed drive tests after issues with Power Supply.

• Tests of emergency stop (with a speed at 25% and 43 % GRB speed) with a modification of the jerk value from 0.08 to 0.2 ==> OK
• Tests of azimuth movements : (-90 to 270 degres)
  • at 60% of GRB speed. ==> Ok for 6 movements
  • at 80% of GRB speed
    • Ok for 4 movements
    • Failures due to resistance  (sur-tension). Breaking modules in failure then reset
    • Ok for 2 next movements
  • at 100% of GRB speed :
    • 3 movements from -90 to 90 ==> OK
    • Temperature of breaking resistance are getting very high (at least the top one) 

• Regulation of the motors (PID) for slow and fast tracking and motor oscillations.
• Implementation and Debugging of the Semi-Expert control software for the drive.
  • GUIs + MOS plugin (OPCUA Server)
•  Results are quite encouraging in good wheather condiftions.
  • additionnal tests in different (wind) conditions are envisaged to validate completly the process

• Cabling the azimuth end switches.

• Tracking at position :
  • RA = 101.288541 RA Offset = -0.6
  • DEC = -16.71343 DEC Offset = 0.7

• Different ParkOut and Parkin done with different values for testing the torque limitation. 
  • By decreasing the torque and the position , the parkin failed because we are not in the CSS locking sensor (in locking position)
  • By setting back the original values, th parkin is ok but the bolt cannot be properly inserted.