Reports until 17:57, Thursday 23 August 2018
H1 ISC
sheila.dwyer@LIGO.ORG - posted 17:57, Thursday 23 August 2018 - last comment - 12:18, Friday 24 August 2018(43630)
pico motor bug, x TMS IR QPDs pico'd

Craig, Sheila

Craig moved pico motors on TMSX M14 and M4 (D1000484) so that the beams are now centered on the QPDs with our current alignment which gives a recycling gain of about 32.  

I attempted to do this for the TMSY picos, but ran into some kind of bug.  

The worst feature of this bug is that you can select a current motor, and it looks like you have selected it if you are looking at one of the single motor screens.  In the screen shot attached I circled in red that the current motor is 3, but you can see from the green dots above motor 1 (these channels are actually readbacks of the LEDs on the controller, so they are reliable about which motor is the current motor).  

However, if you opened the single motor screen and start clicking on the buttons to move the motor you will move the wrong pico.  

I did this, moving M3 which is the steering to the green QPD by mistake.  We unshuttered the green beam for the y arm, I tried to reset the pico, and then Craig and I reset the QPD offsets to zero the green WFS signals so that our green reference is still well set.  After this the camera spot is in the reference location, as expected.  

We have tried many combinations of pushing buttons to try to change which motor is enabled, but we can't change the led lights right now.  We will try power cycling the controller next time we loose lock. 

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 21:24, Thursday 23 August 2018 (43635)

After a lockloss I went to EY to try power cycling the unit.  

When I power cycled it I saw that the PD out LEDs on the shutter controller which is mounted right above the pico controller toggled.  (Photo will be attached to this log). Jenne saw that the shutter also shut.  This is related to bug 11354

After the power cycle I tried changing the current motor on the medm screen, and saw that the behavior wasn't changed.  (on the medm screen, the current motor changed but the green circles which represent the leds on the controller didn't change.) However, the leds on the front panel of the controller actually do change.  (So it is hard to say if I did actually move the wrong pico earlier this afternoon)

Next I logged into the beckhoff machine, and see that in the system manager the LED readbacks are wired as a group (1st screenshot), while at end X where the led readbacks are working correctly, each bit is wired individually (2nd screenshot).  It seems like the mapping is that the first BOOL (MOTOR_X[1]) gets the value of the entire byte (it is currently 4, which would mean the 3 motor is on which is the current motor right now).  

I think that we should re-wire this tomorrow and find a time to fit in a restart, so that we can center on this QPD. 

I've added an FRS 11356

Images attached to this comment
patrick.thomas@LIGO.ORG - 08:04, Friday 24 August 2018 (43637)
It looks like there are inconsistencies at both end stations. Screenshots attached.
Images attached to this comment
sheila.dwyer@LIGO.ORG - 12:18, Friday 24 August 2018 (43642)

Patrick, Sheila

We looked at some of the readback from the times when we were moving pico motors last night.

The first attached screenshot shows what happened at EY, where the wiring of the LED readback is incorrect.  The selected motor channel is changing as we were requesting different motors, but the LED readback is indicating that the 1st motor was active the entire time. Based on what I saw when I went to the end station and looked at the lights I think that the LEDs were actually changing, and so the motor that I was moving was actually the one indicated by the selected motor channel most of the time.  However, as you can see from the channel called MOTOR_1_Y_POSITION, the software was counting steps as if I was moving MOTOR_1.  I think this must mean that somehow the software looks at the LED readbacks to decide which motor it is moving, but it doesn't enforce that the selected motor matches the readback of which motor is selected, which it should.

The second attachment shows a bug in a controller that we think is wired correctly in the system manager EX. Here Craig was walking  motor 3 and motor 4 to center the beam on the TMS IR QPDs.  However, sometimes when he clicked to select one motor, the selected motor chanel changed but the LEDs which read back the active motor didn't change.  The software allowed him to move the motor anyway, but recorded the move as if the wrong motor moved. 

We should do at least two things:

Fix the wiring in EY so that the LED readbacks work

Change the code so that if the selected motor doesn't match the motor that is readback as on from the LEDs the user gets an error and can't move the motor.

Images attached to this comment