Regarding the problem on the Flywheel PLC (see here), we entered UC1 under the supervision of Daniel M. and Koji (11:16 local time).

First we checked the LEDs of the black Ethernet cable. LINK in green was constantly ON and ACT in orange was blinking.

Then, we disconnected the black cable and reconnected again after 20 sec (11:30). But, the LEDs of the PLC in the right side were OFF.

Finally, we removed the two red power lines connected to the PLC with a screw driver and reconnected again (11:52). The LEDs of the PLC turned ON. The UC1 web page was back (12:08).

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

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.

When parking in the telescope, accidently hit "Shutdown" button instead of "Parkin" in Drive Semi-epert GUI. Nothing seem to happen for minutes despite telling command in progress "Shutdown"

Texted Drive experts, they told to just hit again the correct "Parkin" button.

Near the end of parkin in, procedure got stuck. Drive expert identified fuse Q21 having gone off. Switched back the fuse, acknowledged error, retried park in. Then, tower close. After expert intervention, did close and everything was fine.

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!

During this weeks we solve this problems:

_ Park In: Sometimes the final locking position was too limit and the "In Position" sensor was lost during the locking witch put the sytems in bad state vs safety constaint (we can't unlock if the sensor In Position is not active). So now the final poition is now adjusted dynamically with the difference betwwen motors and encoders to be sure to stop on torque limit. No more problems since this modification.

_ Problem of communication between the 2 main PLC of the Drive. Due to this error randomly the PLC receive a 2ndTracking command after a Cancel Command. An other random error is to receive the Start Tracking before the Goto Position witch gives errors in the PLC sequence. Communication was rewritten between the 2 PLC. No more problems since this modification.

_ Some change were done in Cancel and Emergency Stop sequence.

_ Now the Power and the Intensity of Main Electrical Cabinet can be available in the OPCUA of the Drive.

_ The High speed of west ALS was decreased since sometimes the variator gives overspeed error. The speed are now identical between the two ALS

+ other minors improvement.

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.

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

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

Here is the first entry in the DRIVE ELOG logbook

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

• 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) 

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]

Drive GUI stacked due to a wrong shutdown procedure (Jul. 27th 01-02UTC). This was simply a human error.

First, we pushed ParkIn button as usual in the end of the night. We confirmed the telescope was in Locking Position in GUI, but most probably overlooked to check the statuses of access tower and CSS.

Next, we went to the drive container, turn the key into Service mode and pull it out. (Before get into the drive container, we saw the telescope in parking position, but apparently this inspection was not enough.)

Then, we visually found the camera shutter/SIS was not closed/put back (this was also our misoperation). BUT, at this time, we couldn't notice that access tower was open. (Since it was complete dark time, it was not clear to see even using a fully charged flash light.)

After closing/putting back the camera shutter/SIS (visually checked), we inserted the elevation bolt and locked the azimuth properly. Then, inserted the key back and went back to CC.

Finally, we found that the status of access tower/CSS was opened/unlocked. At first we though this was a bug of the GUI, so closed and opened the GUI, but (of course) it didn't change.

Then, we tried to push the parkin button after turning the key into Automatic mode, but the GUI didn't response. So, we contacted to the drive expert at this point (01:35UTC).

Ino asked us to visullay check the access tower and CSS (01:52UTC). After turning the key into Service mode, we confirmed that the CSS seemed to be locked but the tower was indeed open (02:00UTC). We turned the key into Automatic mode and got out the telescope area. Ino successfully locked and closed remotely (02:21UTC). We turned the key into Service mode and closed the shop.

After finishing the normal start-up procedure, we tried to park out by GUI, but got an error (22:30 local time): "MSG_WARNINGPark_Out_TimeOut"

The Drive, FSM and Command Statuses were "Parked", "in parking Area" and "No command in progress," respectively.

We closed&reopend the GUI and "Park Out" three times, but everytime got the same error.

We then send a message to the WhatsApp group of Drive experts (22:32).

Thierry asked us to restart the server on 10.1.8.3 and we killed the corresponding process (ps -ef | grep MOS), but the statuses didn't change (still FSM "in parking Area").

Thierry asked us to press the "General Abort" button, but didn't improve the situation.

After Ino's intervention (probably, we don't know detail), Thierry asked us to restart the GUI and we did so. The statuses got improved (Drive&FSM: Parked, Command: Started). So, we pushed the park out button, but the same error happend.

Ino suspected if the telescope wasn't unlocked by ALS, but we could visually confirm the ALSs unlocked the telescope properly.

Ino found the problem that "the Flywheel interlock says no motion allowed so PLC refuse to do Park out". He wanted to see the screen shot of Flywheel page. But, we could not connect to the server 10.1.200.1 which means the Flywheel PLC is probably down.

Daniel M. asked us to go to UC1 and we went there (23:45). After some discussion between Daniel and Ino, they asked us to try "stop" -> "run" -> "reset" in the PLC (lower white one, in the cabinet opposite side of the Flywheels). But, still there was no connection to 10.1.200.1 (also no two LEDs in the right side of the PLC turned on). See attachment 1, the LEDs were ON when it was working fine. Attachment 2 was taken tonight (the LEDs were OFF).

Daniel M. suggested us to close the shop because we need Koji's help to fix this problem (00:01).

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

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