40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  PSL  Not logged in ELOG logo
Entry  Tue Nov 29 19:49:07 2016, awade, DailyProgress, FSS, FSS problem solving 
    Reply  Mon Dec 5 13:56:07 2016, awade, DailyProgress, FSS, FSS problem solving 
       Reply  Mon Dec 5 22:31:26 2016, awade, DailyProgress, FSS, FSS problem solving (south path PM EOM optimization) 
Message ID: 1782     Entry time: Mon Dec 5 13:56:07 2016     In reply to: 1777     Reply to this: 1783
Author: awade 
Type: DailyProgress 
Category: FSS 
Subject: FSS problem solving 

After another couple of restarts I found that the output channels were not responding to changes of values of their associated soft channels (the human friendly channel names). Pinging the IP address of the output acromag card at yielded no response.  Turned the whole chassis acromag power on and off and found it responsive after that.  I must have restarted modbusApp over fifty times in the last week, maybe it wasn't happy on one exit and froze up.

As a side note: when I load the outputs with 50Ω (internal setting on oscilloscope) the output looks fine.  When I switch back to 1 MΩ loading it has a bunch of drift/noise (only looked in time domain).  Not sure what this means, I didn't think they needed to be loaded.


The FSS control loops have been operating with relatively low gain and a UGF of some 20 kHz.  We must fix this before any useful beat note can be obtained.  

About two weeks ago I was progressing towards this with tuning up the gains of the loops.  I found that there were some issues with the offset and the boost being engaged at the time of establishing the lock.  Now I am finding that it is impossible to push the UGF above about 10 kHz without the loop breaking down into a ringing mode.  I have tuned up the alignment of beams and polarisation for the input chain of optics so the issues now appear to be in the control stage.  

Today I was bashing my head against a wall on the why both paths seemed to be glitching as I got close to tuning the laser to resonance for a lock. It turns out that I had two instances of the 'startAcromag' script running in two separate windows of tumux.  Weirdly they were able to co-exist without throwing an error in each other.  I only found the problem after plugging the slow controls actuation signal into a oscilloscope and deciding that I would progressively restart processes until the problem went away.

It might be better practice, not to mention more efficient, in the long run something like a cron job for each of the PID and EPICS scripts to keep them up and running without manual wrangling with tumux.  I think Evan has done this before, it was something along the lines of calling a bash script to check if the process is running and then restarting it if its down.  I guess it needs some condition to stop it temporarily.


ELOG V3.1.3-