1. Many parkin and parkout operations with different torque  (with the clamping system of the access tower (from 18% to 8% = 26N/m). With 8%, the locking position cannot be reached
2. Some minors have been corrected

• To define precisely the correction to apply to Azimuth positionning, a set of movements have been done to calculte the correction coefficient.
• A scan from 0 deg. to 270 deg. with a step of 10 deg. and a reverse scan from 270 deg. to 0 deg. with a step of 50.deg realized to have a better approximation

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)

After issues during the parkin procedures ( 100% elveation torque ) :

• a visual inpsection has been done :  access is not involved , 2 possible causes :
  • rolls on elevation structure because they are rolling (4 of them yes , 4 of them not)
  • motor break ==> under investigation

The brake of the elevation issue has been fixed. Operations on drive can be resumed.

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

(For Thierry with love <3 :-)

The semi-expert drive control panel uses various terms for the zenith angle: "Altitude (zenith angle)", "Elevation", "Angle". "Zenith Angle". 
It would be less confusing, if only one and the same term were used over all places in the GUI.

After we issued the tracking command, giving RA/Dec, the GUI displayed

• "Tracking in process" when the telescope was still moving, and the tracking point was not reached.
• "Action in progress.Please wait ...", when the telescope was actually tracking.

We believe these two should be exchanged. Maybe even a colour code (yellow when still going to the tracking point, indicating that the telescop is not in nominal operation, and green when tracking is ongoing) could help the shiftcrew to understand in one glimpse where we are.

On park-in command, telescope went to the right position 95/-1, but did not recognise that it was there.

• Pushed Park-In again
• Acknowledged one error
• Then everything fine.

After tracking Mk421, we abort current action (acknowledged) and try to go to a new source: RA=308.1, Dec=40.96. Drive Control refuses these parameters ("check your parameters").

General Abort without effect for 2 minutes. Called expert (Ino). He will look into it.

Ino explained: MOS was totally desynchronised with PLC. (It was assuming that the telescope was parked.) He parked the telescope manually. Thanks!
Experts will investigate on Monday. But the shift crews can continue to use the  Drive Control and tracking.

The Current&Power Monitoring was not updated and hidden by two emtpy modal dialogue windows.

Restart of display (via icon on desktop) not successfull. ("MODBUS #2 communication failed.")

Called expert (ThLF), who advised how to call the old instance, then restart worked.

When parking in yesterday, the telescope drove to the nominal position (approx. 95° zenith angle and -1° azimuth), but then it took a long time and never showed the "park out" button again.

In the driver container, we saw two alerts to acknowledge, then the GUI indicated "telescope parked". We confirmed visually that the position was correct and we could lock azimuth and elevation. Informed experts on WhatsApp and got confirmation that everything was done right.

This morning we were asked by Ino to rearm fuse Q21 (24V), which was the reason for the wrong statement from the UI.

When checking the telescope visually outside, while it was in the "park-out" position, a car happened to pass by from the upper road (coming from the other telescopes). Its lights flashed directly into the camera. It seems that the road is in direct prolongation of our current park-out position.

• We saw the CAM HV going down several times in the park-out position (where the shutter is typically opened) during the last weeks. Can we change this standard position slightly (higher or lower)?
• Another question is of course, why cars drive with lights on in that place. The "no luz larga" sign is below the MAGIC site, if I remember correctly.

The aim was to observe several stars with different magnitude and check the sensitivity of the CDM. We wanted to use a semi-automatic procedure with command sent to the drive via a script to the Acs

After we realized that the telescope was not moving after a StarTracking command we try to use the drive system through the Acs server. StartTracking command not sent to the drive but the other commands (such as StopTracking) worked. 

Instead we used the Semi-expert Gui to make our test. All fine. list of stars observed:

AlphaAqr mag 3.11

10 images with LEDs and OARL

100 images + 100 dark

Homam mag 3.39

10 images with LEDs and OARL

100 images + 100 dark

48-peg mag 3.66

10 images with LEDs and OARL

100 images + 100 dark

24-peg mag 3.87

10 images with LEDs and OARL

100 images + 100 dark

47-peg mag 4.13

10 images with LEDs and OARL

120 images + 120 dark

17 And mag 4.26

10 images with LEDs and OARL

120 images + 120 dark

84Peg mag 4.69

10 images with LEDs and OARL

120 images + 120 dark

56Peg mag 4.91

10 images with LEDs and OARL

180 images + 180 dark

81Peg mag 5.13

10 images with LEDs and OARL

300 images + 300 dark

63 Peg mag 5.70

10 images with LEDs and OARL

400 images + 400 dark

85 Peg mag 5.87

10 images with LEDs and OARL

400 images + 400 dark

On Dec 6, Dario, Frederic and Yuji showed to Koji Noda and Daniel Mazin how to operate the new ALS. The idea was to do an unlock and lock again, as the weather was still bad. The automatic part went more or less OK ending in error state (excpected). We then went to EAST ALS to open the main actuator manually. After moving the actuator manually, the status of the ALS was either locked not unlocked. We realized that secondary sensor for South part was reacting incorrectly (close to metal OFF, far from metal ON), and we thought it is the reason. We removed the endswictch screw but the status did not change. After pressing again Unlock we realized that the secondary South plier squeezed the sensor cable and destroyed it (see Attachment 1). We consulted Ino and closed the ALS EAST manually (all three actuators) because the eather was getting worse.

Next day, Dec 7, we (Daniel and Koji) examined the sensor cable and confirmed it is completely distroyed. We introduced a patch cable and few adapters as a temporary repair (See attachements 2,3,4 and 5). We confirmed the reading of the pressure of the South and North sensors of teh secondary pliers are good again (attachment 6). See pictures.

- During shutter tests, we were requested to move the telescope many times between two positions at different zenith. Sometimes, once the position is reached and in the log I got the message 'GoToTelescopePosition Done received', the command panel stay stack with the "action in progress" bar without possibility to perform other atctions. I need to click to 'general abort' to stop the action and  get the panel comand back. It happened 3 times

- During tracking, the message on the screen switch from "tracking in progress" to "action in progress, please wait..." The latter is quite misleading for non-familiar user of the gui.