• On Wenesday morning (27/03/19) :
  • With Holger and Robert (MPI) , many telescope "park in/park out" operations have been performed in order to refine the positionning in the acces tower and at the elevation locking bolt
    Holger and Robert applied many mechanical modifications on the acces tower to make the telescope park operations very smooth
    ==> Conclusive operations. 

• Cabling the azimuth end switches.

After pointing Polaris yesterday, it seems that the zero position of the telescope was incorrect but It's never had been calibrated (zero was equals to parking position towards center of tower).

So I shift the zero position of telescope by 0.869°.

As the consequence the new Parking Position = -0.869° don't be surprised.

The 2 swicthes are too far from the target at 56.48 elevation.  The sensor have been tuned in parkin position and the distance was correct (2mm) and at 56.48 is about 10mm. (impossible to tune correctly the sensor and the atrger has to be tuned)

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.

Last week we put in sevice the new ALS completly modified:

_ Main System with new reducer.

_ New Speed parameters for Main System (motor is at full speed but due to reducer the spped is slow). Decceleration sensors not installed since the speed is very slow.

_ All the sensors were replaced by new ones (2 logic embedded in each sensor (NC + NO) ) = only one type of sensor in the ALS. Sensor with connector to ease maintenance.

_ All sensor cabling were changed and new ducts were installed to ease maintenance.

_ The damaged cable of the loadcell was welded again and protected (Heat shrink tube + tape).

_ Add mechanical part to protect loadcell cable when opening over the opening position. It's now impossible to damage Loadcell cable.

_ Increase speed of plier. We add a deceleration sensor in each plier.

_ All the sensors support are new to avoid dammage if there is over position due to manual operation.

The ALS is now functionnal with human interface. The system are so slow 180s !!!, They were not integrated into automatic cycles.

Shifters must manage the Opening/Closing of the ALS at the Start/End od telescope operations.

A new error code is ride up if a door is opened during motion (3002).

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

(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.

At parking in, the telescope got stuck at 94.254°. We checked in the container that fuse Q21 went off. We did not see any errors both in the Drive cointainer and the GUI. We texted the experts. After 15 minutes, we pressed again "ParkIn" (without having touched the fuse). After nothing happend in the GUI, we called the experts. They authorized us to switch back the fuse. After that, still heavy intervention by the experts was needed, who finally made the telescope successfully park (fuse was on during all the trials). Thanks to the experts solving the issue at late night!

Tonight, we tracked Vega to test (a correction of) the pointing offset of the Drive.

Around 22:30UTC, we tried different Az offsets of the pointing in the Semi-expert GUI, followed by taking an image with the PSF camera to see the effect of the offset choice.

We tried delta_az = 0.3°, 0.1°, 0.26°, 0.6°. Strangely, we saw some unexpected (much too large) shifting of the spot for delta_az = 0.3° and delta_az = 0.6° (but looked reasonable for delta_az = 0.26°), which appeared quite puzzling to us (see specific Camera Elog here).

After having tracked with delta_az = 0.6°, we stopped again, and selected delta_az = 0.4°. We submitted the command ("Start"). Some seconds after submission, we became unsure whether we used the right field in the GUI where we entered the delta_az values. We hit "abort current action" (to check our previous command), when probably the slewing to the new offset position wasn't finished yet (about 5 seconds after the previous "Start" command). Then, the GUI became stuck displaying "abort current action", and not displaying the field to enter new positions/targets. According to the GUI, the telescope had in fact stopped tracking, but without any possibility to receive further commands.

We restarted the GUI, but the state remained the same, and checked the telescope outside. Then we called the experts, who could solve the problems after some non-trivial intervention.

Installation of the new PLC code and re-initilalisation of the system.

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

• 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

• Debugging of the MOS plugin corresponding to the tracking 

• Tracking procedure has been debugged from the GUI-MOS (OPCUA Server with tracking plugin)-PLC
• Still some improvments to apply but globally the procedure is running well.

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.

In the late afternoon shifters noticed the semi-expert drive GUI was not updating, several restarts did not help. Checking into the issue with the drive team connecting from remote it was found that the MOS server is not running and cannot be restarted. This issue could not be solved and will be revisited tomorrow, Jan 17, during the day.

Actions applied for solving this issue: (T. Le Flour)

The status is the following

• The MOS OPCUA Server cannot be relauched since the port used by server was not properly released after the last stop.
• We decided to reboot the VM running on TCS02 but after this operation , the concerned port was still in use.
• By using the commend lsof , we relased the port and relaunched successfully the server.
• Actions : releasing the port has been included in the script used to launch the server to prevent such an issue.