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.

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

Here is the first entry in the DRIVE ELOG logbook

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

• 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

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

Debugging of the tracking sequence :

• PLC sequence : trajectory tracking data correctly managed
• PLC tuning : regulation OK ==> need to refine.
• Tracking algorithm :
  • Changes in Drive.ccp to allow azimuth negative values.
  • Tracking duration : even by changing the duration of he tracking (from 1'to 5') ==> not correctly managed (still 1' tracking) ==> to be checked
•  

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