40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 139 of 327  Not logged in ELOG logo
ID Date Author Type Category Subject
  9499   Fri Dec 20 01:24:11 2013 DenUpdateLSChigh bandwidth loop achieved for yarm

Koji, Den

CM Servo with POY11 successfully engaged. UGF: ~15kHz.


Tonight we decided to repeat one arm locking using high-bandwidth CM servo. We low-passed AO signal to avoid saturations of the EOM. We tried different configurations that compromise between noise and loop phase margin and ended up with a pole at 30kHz. SR560 is used as a low-pass filter.

Another problem that we faced was big (~2.6V) electronic offset at the input of 40:4000 BOOST. Once engaged, cavity would be kicked out of lock. We calibrated this offset to be almost half linewidth of the cavity (~300pm). To avoid lock loss during engaging the boost we increased common mode gain to maximum (31 dB).

Measured OL is attached. UGF is 15kHz, phase margin is 60 degrees. We have also simulated evolution of loop shape during bringing AO path. Plot is attached.

The final procedure is

  • set common gain up to 31dB, AO gain to 8dB, MC IN2 gain 10dB, CM offset 0.7V
  • lock arm with CM slow path with bandwidth of 200 Hz
  • enable AO path, gradually increase slow and fast gains by 12 dB
  • enable boost
Attachment 1: CM_OL_meas.pdf
CM_OL_meas.pdf
Attachment 2: cm_ol_sim.pdf
cm_ol_sim.pdf
Attachment 3: CM_slow_fast_cross.pdf
CM_slow_fast_cross.pdf
  9498   Fri Dec 20 00:16:39 2013 KojiSummaryCDSRCG parsing bug?

A while ago, I noticed that the most significant bits of the LSC whitening DOs are not toggling.
I track this issue down and found what is happening. I need experts' help.


To illuminate the issue, terminators are connected to Bit15 of the Bit2Word blocks in the LSC model (attached screen shots).

The corresponding source file is found in c1lsc.c at the following location.
The last channels of the Bit2Word are connected to lsc_cm_slow (the filter module).
This is the source of the issue. This wrong assignment of the connections
can't be changed by connecting Go-From tags to the chennels.

/opt/rtcds/caltech/c1/rtbuild/src/fe/c1lsc/c1lsc.c

3881// Bit2Word:  LSC_cdsBit2Word1                                                                                                              
3882{
3883double ins[16] = {
3884        lsc_as110_logicaloperator4,
3885        lsc_as110_logicaloperator1,
3886        lsc_refl11_logicaloperator4,
3887        lsc_refl11_logicaloperator1,
3888        lsc_pox11_logicaloperator4,
3889        lsc_pox11_logicaloperator1,
3890        lsc_poy11_logicaloperator4,
3891        lsc_poy11_logicaloperator1,
3892        lsc_refl33_logicaloperator4,
3893        lsc_refl33_logicaloperator1,
3894        lsc_pop22_logicaloperator4,
3895        lsc_pop22_logicaloperator1,
3896        lsc_pop110_logicaloperator4,
3897        lsc_pop110_logicaloperator1,
3898        lsc_as165_logicaloperator4,
3899        lsc_cm_slow
3900};
3901lsc_cdsbit2word1 = 0;
3902for (ii = 0; ii < 16; ii++)
3903{
3904if (ins[ii]) {
3905lsc_cdsbit2word1 += powers_of_2[ii];
3906}
3907}
3908}

3946// Bit2Word:  LSC_cdsBit2Word2                                                                                                              
3947{                                                                                                                                           
3948double ins[16] = {                                                                                                                          
3949        lsc_as55_logicaloperator4,                                                                                                          
3950        lsc_as55_logicaloperator1,                                                                                                          
3951        lsc_refl55_logicaloperator4,                                                                                                        
3952        lsc_refl55_logicaloperator1,                                                                                                        
3953        lsc_pop55_logicaloperator4,                                                                                                         
3954        lsc_pop55_logicaloperator1,                                                                                                         
3955        lsc_refl165_logicaloperator4,                                                                                                       
3956        lsc_refl165_logicaloperator1,                                                                                                       
3957        lsc_logicaloperator_cm_ctrl,                                                                                                        
3958        ground,                                                                                                                             
3959        ground,                                                                                                                             
3960        lsc_logicaloperator_popdc,                                                                                                          
3961        lsc_logicaloperator_poydc,                                                                                                          
3962        lsc_logicaloperator_poxdc,                                                                                                          
3963        lsc_logicaloperator_refldc,                                                                                                         
3964        lsc_cm_slow                                                                                                                         
3965};                                                                                                                                          
3966lsc_cdsbit2word2 = 0;                                                                                                                       
3967for (ii = 0; ii < 16; ii++)                                                                                                                 
3968{                                                                                                                                           
3969if (ins[ii]) {                                                                                                                              
3970lsc_cdsbit2word2 += powers_of_2[ii];
3971}
3972}
3973}

 

Attachment 1: Bit2Word1.png
Bit2Word1.png
Attachment 2: Bit2Word2.png
Bit2Word2.png
  9497   Thu Dec 19 21:16:16 2013 KojiConfigurationGeneralnetgpibdata is working again now

Now netgpibdata is working again.

Usage:

cd /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata   
./netgpibdata -i 192.168.113.108 -d AG4395A -a 10 -f meas01
./netgpibdata -i 192.168.113.105 -d SR785 -a 6 -f meas01   

Jenne witnessed and certified that they were working fine.
Now no one can say "it does not work"!


These weeks I was annoyed by the fact that netgpibdata was messed up by dummies.
A terrible situation was found:

1. Someone pushed the factory reset of one of the wifi bridges (LINKSYS WET54G).
2. Someone gave wrong IPs to the bridges (192.168.1.* instead of 192.168.113.*)
3. Someone left a default IP to the bridges. This means the routers had the same IPs.

-------

I gave the IPs to the bridges. According lines of /etc/hosts in linux1 were updated.

192.168.113.230 WET54G1
192.168.113.231 WET54G2

All of the network settings are taped on the bridge now.
The reset switch of each bridge was covered by a tape so that dummies can't randomly push the button.

The command was tested with each device.

  9496   Thu Dec 19 19:45:12 2013 ericqUpdateGreen LockingX-Arm Green PDH Loop Stuff
With the fixed servo box, I remeasured the OLTF, the servo, and the low pass filter between the mixer output and servo input. Dividing the OLTF by the servo and LPF transfer functions should just leave the the [laser PZT->cavity->PD] transfer function, which should have the shape of the cavity pole plus any delay in the loop, up until the PZT is no longer linear / the measurement has bad SNR.

I'm missing a few pieces of the loop. While I know the PD gain in V/W, I don't know how much power is in the sideband, which affects the slope of the PDH error function. Also, I've found old ELOG posts mentioning either 1 or 5MHz/V being the NPRO PZT response, but am not sure how to determine what it actually is. These are essentially just scalars though, so finding the reason for low phase margin doesn't depend on them.

Here are the TFs I've measured ("residual" refers to OLTF/(servo*LPF)):



The teal "residual" TF presumably owes its shape to the cavity pole + the time delay around the loop. Messing around with the data, the shape fits very well to a real pole at 27kHz and a ~3usec delay. I have no real way to back that up as the unique truth behind it, however. Is there a good way to measure the delay? Without assuming any delay, the shape is best fit by a real pole at 26kHz and some funky complex zeros.

Another thing to look at is the CLG implied by the measurement of the OLTF, given by 1/(1-G). I plotted this quantity for the measured loop, and also for G/2 and 3G/2 to get an idea for how it changes as you turn the servo gain knob. I measured with the knob at 4.0. There seems to be quite a bit of gain peaking!



Also, I drew up a simple block diagram sort of thing to show how everything is connecting down at the green electronics rack at the end of the X arm (while totally glossing over the optical elements involved). This hopefully helps anyone who wants to inspect/take apart/massacre the setup.

  9495   Thu Dec 19 18:33:25 2013 GabrieleSummaryLSCEstimate of the sign of the PRC length error

Maybe I'm getting confused, but I still believe there is no way to decide the direction from yesterday's measurement.

Let's say for example that the arm sideband detuning from antiresonance is equivalent to a PRC length change of +1cm away from the position of ideal resonance of the sidebands without arms. Then we can get a measured separation of the sidebands, without arms, corresponding to 5cm both if the PRC is off by +4cm or by -6cm...

  9494   Thu Dec 19 14:40:42 2013 KojiUpdateCDSRFM Time over mitigation for c1mcs

I worked on the mitigation of c1mcs time-over issue this afternoon.

The timing for the c1mcs is successfully reduced from >60us to 45us.


The previous models are svned in redoubt as follows:

MCS rev. 6696
RFM rev. 6697
IOO rev. 6698

What I changed was:

- Remove connection from ALS (on c1ioo) to MCS (on c1sus). This should be all done in LSC. (# of RFM IPC in MCS -1)

- MC2 trans QPD filters are moved from IOO to MCS to reduce the RFM channels in MCS.
  Previously the signals for the 4 segments are sent. Now the processed siganls (pit/yaw/sum) are sent. (# of RFM IPC in IOO -1, MCS -1)

- WFS MC3 feedback channels are moved from MCS to RFM to distribute the RFM channels (# of RFM IPC in MCS -2, in RFM +2)

model    prev. timing[us] current timing[us]  diff in time[us]  diff in ch#
c1mcs         >60                45                -15              -4
c1rfm         47                 53                + 6              +2       
c1ioo         47                 36                -11              -1

Revisions of the new models:
MCS rev. 6702
RFM rev. 6701
IOO rev. 6700

  9493   Thu Dec 19 12:51:57 2013 JenneSummaryLSCEstimate of the sign of the PRC length error

My hunch is that the PRC is SHORT by a few cm, not long. 

In my Optickle simulation, the sidebands are not perfectly co-resonating in the PRMI when the arms are not locked.  See Fig 1, which is the fields in the PRMI using the design PRC length.  If I add 5cm to the PRC length, I get Fig 2, where the peaks are about the same separation, but the upper and lower sidebands have swapped sides of the 0 mark.  However, if I remove 5cm from the PRC length, I get Fig 3, where the peaks are much farther apart than in Fig 1.  This case looks more similar to the data that Gabriele plotted in his elog entry, where the peaks are separated by at least a linewidth.  This is not at all conclusive, but it's a guess for which direction we need to move.  Obviously doing an actual measurement will be better. 

My tummy feelings also agree with this simulation:  When we flipped PR3 (the only optic change in the PRC since Gabriele and I measured the 55MHz peak separation in April), since the HR side of the optic is now at the back, we had to push the whole suspension cage forward to get the beam aligned to the Yarm.  Conversely, however, transmitting through the glass substrate adds to the optical path length.  So, my tummy feelings may be wrong.

Figure 1, PRC at design length, PRMI sweep:

DesignLength.png

Figure 2, PRC 5cm longer than design length:

Plus5cm.png

Figure 3, PRC 5cm shorter than design length:

Minus5cm.png

 

  9492   Thu Dec 19 03:29:34 2013 DenUpdateLSCCM servo test using yarm is complete

Koji, Den

Procedure:

  • lock yarm on IR, wire POY to CM input
  • transition arm to CM length path by actuating on IMC
  • increase AO gain for a stable crossover
  • engage CM boosts

Result:

  • arm can be kept on resonance and even acquired on MC2
  • stable length / AO crossover is achieved
  • high bandwidth loop can not be engaged because POY signal is too noisy and EOM is running out of range

We spent some time tuning CM slow servo such that fast path would be stable in the AO gain range -32db -> 29dB (UGF=20kHz) when all boosts are turned off and common gain is 25dB. Current filters that we use for locking are not good enough - AO can not be engaged due to oscillations around 1kHz. This is clearly seen from slow path closed loop transfer function. I will attach servo shapes tomorrow.

Attached plot "EOM" shows EOM rms voltage while changing AO gain from -10dB to 4dB. For UGF of 20kHz we need AO gain of 29dB.

It seems we can start using CM servo for CARM offset but the sensor should be at least factor of 30 better than POY. Add another factor of 10 if we would like to use BOOST 2 and BOOST 3.

Attachment 1: EOM.png
EOM.png
  9491   Wed Dec 18 18:45:39 2013 JenneUpdateLSCREFL 165 demod phases

I checked out the REFL165 demod phase, and it looks like it was okay.  it was -20.9 degrees.  I turned on my sensing matrix oscillators, and maximized the PRCL signal in the REFL165_I_ERR channel, and got a pretty good maximization at +155 degrees.  I used this to lock the PRMI on sidebands, with MICH gain of +0.3, and PRCL gain of +0.1 . 

Since this is working, I'm leaving the REFL 165 phase here, at +155 degrees, although this is almost exactly 180 degrees from what Den left it at, so I'm not sure why I was not able to lock with a demod phase of -20.9.  (I tried all 4 permutations of signs, with gain values of the same magnitude (0.3 for MICH, 0.1 for PRCL), and wasn't able to lock.  I'll try to figure this out tomorrow, but it was time for the meeting, then the IFO has been busy doing more important things the rest of the afternoon.

Plan for checking:  Lock with demod phase of 155, measure TF to one of the other REFL diodes (11, 33 or 55), lock on that other REFL diode.  Then, change the REFL 165 demod phase back to -20.9, and measure the transfer function again.  Hopefully the answer is just that I was doing something dumb, and it works easily.  This test/measurement should only take a few minutes, but it'll make me happier knowing that things still work as they should.

  9490   Wed Dec 18 17:28:50 2013 GabrieleSummaryLSCEstimate of the PRC length error

Measurement 

Looking back at what I did in april (see log #8411) I realized that it is possible to get an estimate of how much the PRC length is wrong looking at the splitting of the sideband resonant peak as visible in the POP_110_I signal. With the help of Jenne the PRMI was aligned and left swinging. The first plot shows a typical example of the peak splitting of 55MHz sidebands. This is much larger than what was observed in April.

When the sidebands resonate inside the PRC they get a differential dephasing given by 

dPhi = 4*pi*f_mod/c * dL

where dL is the cavity length error with respect to the one that makes the sidebands perfectly resonant when the arms are not there. This is not exactly the error we are interested in, since we should take into account the shift from anti-resonance of the SBs in the arm cavities.

Nevertheless, I can measure the splitting of the peak in units of the peaks full width at half maximum (FWHM). I did this fitting few peaks with the sum of two Airy peaks. Here is an example of the result

data_fit2.png

The average splitting is 1.8 times the FWHM. Knowing the PRC finesse, one can determine the length error:

dL = c / (4 * f_mod * Finesse) * (dPhi / FWHM)

Assuming a finesse of 60, I get a length error of 4 cm.

To get another estimate, we kicked the PRM in order to get some almost linear sweeps of the PRC length. Here is one of the best results:

data_kick.png

The distance between consecutive peaks is the free spectral range (FSR) of the PRC cavity. Again, I can measure the peak splitting in units of the FSR and determine the length error:

dL = c / (4 * f_mod) * (dPhi / FSR)

The result is again a length error of 4 cm.

Simulation

An error of 4 cm seems pretty big. Therefore I set up a quick simulation with MIST to check if this makes sense. Indeed, if I simulate a PRMI with the 40m parameters and move the PRC length from the optimal one, I get the following result for POP_110_I, which is consistent with the measurement.

pop110_vs_dL.png

 

 Therefore, we can quite confidently assume that the PRC is off by 4 cm with respect to the position that would make the 55 MHz sideband resonant without arms. Unfortunately, it is not possible with this technique to infere the direction of the error.

 

 

 

 

 

 

Attachment 3: pop110_vs_dL.png
pop110_vs_dL.png
  9489   Wed Dec 18 15:35:48 2013 SteveUpdatePEMexcess seismic noise

This is not a test. Life can be dangerous in the 40m Control  Room.

Attachment 1: seismicCar.jpg
seismicCar.jpg
  9488   Wed Dec 18 13:34:03 2013 SteveUpdateGeneralLIGOX people

40m crew and visitor Holger Muller from Berkeley.

Attachment 1: 40m2013Dec.jpg
40m2013Dec.jpg
Attachment 2: 40mCup.jpg
40mCup.jpg
  9487   Wed Dec 18 11:37:12 2013 JenneUpdateLSCPOP22 and POP110 demod phases

Somehow the POP22 and POP110 demod phases weren't correct anymore.  I guess Den saw this after he changed the setup for the REFL165 PD at the LSC rack, but didn't elog it. 

I went out to the LSC rack, and found that the power supply that is supplying the amplifiers for both POP22/110 and REFL165 was set to ~16V each channel.  I put it back to 15V for each channel.  I don't know what Den intended for the 165 amplifier (more volts is more gain), but the POP22/110 amplifier usually runs with 15V. 

I also reset the POP22 and POP110 demod phases.  Since I'm not able to lock PRMI on sideband this morning (why?!?!), I locked on the carrier, and moved the phases around until POP22 and POP110 were both maximally negative.  The phases are/were:

  OLD [deg] NEW [deg]
POP22 107.2 -165.0
POP110 95.0 150.0

This is a ~60 degree change for both PDs. 

I am not sure if Den ever checked the demod phase of REFL165 after he put in the new SMA cable (there's no mention of it in the elog!), so I'm going to check that to see if it helps get PRMI locking back.  I know that Den had also been using REFL11 for PRMI locking, but the parameters he used for that aren't in the log either.

  9486   Wed Dec 18 11:32:34 2013 ranaUpdateLSCXend QPD schematic investigation

 

 Since we use the TransMon QPD for triggering the high/low gain switching we need to run with the whitening OFF during lock acquisition and the turn it on after we have the arms locked with ALS. This should be put into the up/down scripts.

  9485   Wed Dec 18 03:29:48 2013 DenUpdateLSCyarm locked on mc

As a CM slow path test I locked free swinging yarm by actuating on MC length with bandwidth of 200 Hz. Crossover with AO is not stable so far.

I used xarm as an ool frequency noise sensor. MC2 violin mode is at 645 Hz, I have added a notch filter to LSC-MC2 bank.

Attachment 1: MC_ARM.pdf
MC_ARM.pdf
  9484   Wed Dec 18 00:26:15 2013 JenneUpdateLSCXend QPD schematic investigation

I have looked at the photo of the Xend QPD from elog 9367, as well as the schematic for the board (D990272). 

Things that will need swapping out:

  • Thick film resistors in the signal path need to be changed to thin film.
  • MAX333 needs to be replaced with MAX333A.  The 333 has "ON Resistance" of 140-175 ohms, whereas the 333A has "ON Resistance" of 20-35 ohms.
  • AD797 needs to be replaced by OPA140.  The 797 is a low voltage noise op-amp, but for a diode we want low current noise.  AD797 has 2pA/rtHz at 1kHz, whereas the OP140 has 0.8fA/rtHz at 1kHz (see Zach's elog 8125 re: OPA140).

I have ordered from digikey via techmart 10 each of the MAX333A's and the OPA140's.  (4 per QPD times 2 QPDs plus 2 spares = 10).  Both of these new chips have the same footprint and pinout as the part that they are replacing, so it'll be a fairly easy task.

Next up, I need to make a LISO model for the circuit for one of the quadrants, to see what shape it'll turn out to be.  Part of this will include deciding what resistors and capacitors to put in the OPA140 gain stage. 

Right now, the AD797s say on the schematic that the gain options are different by a factor of 5, but the actual QPD has a different resistor than is on the schematic, and there is also a capacitor in parallel with each resistor, so I need to just pull those out, and pick some values that make sense to me. 

Rana and I have discussed ignoring the 2nd and 3rd gain switching options on each quadrant, as that is getting to be more fine control than we need. 

Other things on the board:

  • The 50 ohm resistors to ground for the "QPD_rtn" have all shorted.  Rana says this is good, so leave it as-is.
  • The positive input to the AD797's all have a 100 ohm resistor to ground, rather than just being connected to ground.  Why is this??

For now, I will probably just work on the QPD head, and not the whitening board.  For now, we can run with 1 stage of whitening, and if we need lower noise, we can revisit the whitening board (including replacing the thick film resistors with thin film).

When thinking about what gains I want on my gain stages, I want to have my full arm power (~700 TRX units) be ~20,000 counts from the ADC.  So, I want my single arm power (1 TRX unit) to be ~30 counts from the ADC.  This is not such a big number, so this may also require more thinking. 

  9483   Tue Dec 17 21:28:36 2013 JenneUpdateLSCCM servo slow output digitized

Den just plugged an output from the common mode board into an LSC whitening board (the spare channel that used to be called "PD_XXX_I" in the LSC model).  I have modified the LSC model to reflect the new name of the new signal ("CM_SLOW"), and have added this channel to the LSC input matrix.  Koji is, I believe, adding this channel to the LSC screen in the auxiliary error signals section.  I am also adding the _OUT of the filter bank to the DAQ channels block.

  9482   Tue Dec 17 20:59:23 2013 JenneUpdateLSC1/sqrt(TR) signals added to frames

I noticed that we have not been saving the 1/sqrt(TRX) and 1/sqrt(TRY) data, so I modified the c1lsc model and added them to the DAQ channels block.  I restarted the c1lsc model, and the _DQ channels are now archived.

  9481   Tue Dec 17 14:06:59 2013 ranaUpdateLSCNew Broadband PD for POP 22/110

 I looked at the BBPD design so that we could make a POP22/110. It looks like it will be easy (I hope).

 The first attachment shows the schematic with the RF notch modified to handle 55 MHz. As long as the capacitor in this notch can be kept to below 20 pF, it doesn't degrade the noise so much,

The second attachment shows the TF and input referred noise. We ought to be able to get 20 pA/rHz at the input to the first RF amplifier.

The LISO files are in the svn under liso/examples/aLIGO_BBPD/,

Later, if we have to notch more than just 55 MHz, we can add a notch between the 2 RF amplifiers as Koji has done for the REFL165.

Attachment 1: POP22110sch.pdf
POP22110sch.pdf
Attachment 2: POP22110.pdf
POP22110.pdf POP22110.pdf
  9480   Tue Dec 17 02:10:29 2013 DenUpdateLSClocking activity

Koji, Den

Some results and conclusions from tonight:

PRC macroscopic length is detuned. We measured REFL phases in carrier and sideband configurations - they are different by ~45 degrees for both 11 and 55 MHz sidebands. Additional measurement with phase locked lasers is required.

We got stable lock of PRMI+2arms with CARM offset of ~200 pm. We think this is the point when we should transition to 1/sqrt(TR) signals. We plan to rewire LSC model and also test CM servo with 1 arm during the day.

POP ASC OL shape changes when we reduce CARM offset probably due to normalization by sum inside the PD. Servo gets almost useless when PRMI power fluctuates by a factor of few.

SMA cables were made and installed for the REFL165 RF amplifier in lsc rack.

  9479   Mon Dec 16 20:08:43 2013 KojiUpdateLSCCM servo module installed

I found another backplane cable for the CM servo module. It is plugged to the module now.

I can see that C1:LSC-CM_SLOW_MON is responding to C1:LSC-CM_REFL_OFFSET.
But C1:LSC-CM_SUM_MON and C1:LSC-CM_FAST_MON are not replated to the given offset.
I probably need to check the cross connects.

  9478   Mon Dec 16 02:20:49 2013 DenUpdateLSCMICH rms is improved

When PRMI is locked on REFL 165 I&Q signals MICH rms is dominated by the 60 Hz line and harmonics. It comes from demodulation board.

To increase SNR ZFL-100 LN amplifier (+23.5dB) was installed in LSC analog rack. MICH 60 Hz and harmonics are improved as shown on the plot "mich_err"

I have also added a few resg at low frequencies. MICH rms is not 3*10-10. In Optickle I simulated power dependence in PRC and ARMs on MICH motion. Plot is attached.

 I think we need to stabilize MICH even more, down to ~3*10-11 . We can think about increasing RF amplifier gain, modulation index and power on BB PD.

CARM offset reduction was a little better today due to improved MICH RMS. Power in arms increases up to 15 and than starts to oscillate up to 70 and then PRMI looses lock.

Tomorrow we need to discuss where to put RF amplifier. Current design has several drawbacks:

  • DC power for the amplifier is wired from a custom (not rack based) +15V power supply that was already inside the lsc rack and used for other ZFL-100LN
  • BNC cables are used because I could not find any long SMA cables
  • we would like gain of ~40 dB instead of 23.5 dB
Attachment 1: MICH_ERR.pdf
MICH_ERR.pdf
Attachment 2: DC_power.pdf
DC_power.pdf
Attachment 3: ARM_OFFSET.pdf
ARM_OFFSET.pdf
  9477   Sun Dec 15 21:01:19 2013 KojiUpdateLSCCM servo module installed

Now the module is inserted at the 2nd crate from the top of 1Y2 (LSC analog rack). It is next to the DCPD whitening module.

I found the backplane cable for the Common Mode servo module.
I traced a cable form XY220 at the right most module on the crate where iscaux2 is living.
This cable was connected to the upper backplane connector.

Switching of the module is tested. All the switches and gain control are doing their job.

It was found that the offset and slow readback are not responding.
I checked the schematic of the CM servo module (D040180).
It seems that there is another cable for the offset and read back voltages.

  9476   Sun Dec 15 20:37:41 2013 ranaSummaryTreasureThere is a Wagonga in the container that Steve does not believe in

From Linda and Bram:

Attachment 1: WagSu.pdf
WagSu.pdf
Attachment 2: Wagonga.jpg
Wagonga.jpg
Attachment 3: MandehlingMedStrong.jpg
MandehlingMedStrong.jpg
  9475   Sun Dec 15 03:13:15 2013 DenUpdateLSCattempt to reduce carm offset

X,Y arms were stabilized using ALS and moved 5 nm from the resonance, PRMI was locked on sideband using REFL165 I&Q. POP angular servo was running; PRMI RIN was good (~2-3%)

During slow offset reduction I was sweeping MICH, PRCL and POP servos for instabilities due to possible optical gain variations, loops were fine.

I could reduce offset down to ~200 pm and then lost lock due to 60 Hz oscillations as shown on the attached plot "arm_offset"

Arms were stabilized with RMS comparable to the offset and power in arms was fluctuating from 3 to 45.

60 Hz line most probably comes from MICH. RMS is dominated by the power lines and is ~ 1 nm as seen on the plot "PRMI_CAL". I think this is too much but we need to do simulations.

Attachment 1: ARM_OFFSET.pdf
ARM_OFFSET.pdf
Attachment 2: PRMI_CAL.pdf
PRMI_CAL.pdf
  9474   Sat Dec 14 14:21:46 2013 DenUpdateLSCcommon mode servo

Quote:

 

 These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?

Attached is matlab code that I used

 % IMC OL
G = zpk(-2*pi*8964, 2*pi*[-10; -10; -10; -1000; -274000], db2mag(242.5)) * ...
    tf([1 0.8*1.55e+05 3.1806e+10], 1);

% CARM PATH
CARM = G/(1+G);

% Common mode boosts
BOOST = zpk(-2*pi*4000, -2*pi*40, 1);
BOOST1 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST2 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST3 = zpk(-2*pi*4500, -2*pi*300, 1);

% Coupled cavity pole
CCPole = zpk([], -2*pi*100, 2*pi*100);

% Servo gain
Gain = db2mag(43);

% CARM OL with boosts
H = CARM * CCPole * BOOST * Gain;
H1 = H * BOOST1;
H2 = H1 * BOOST2;
H3 = H2 * BOOST3;

% Plot
% bode(H, H1, H2, H3, 2*pi*logspace(3, 5, 10000));
% bode(1/(1+H), 1/(1+H1), 1/(1+H2), 1/(1+H3), 2*pi*logspace(3, 5, 10000));

  9473   Sat Dec 14 13:46:54 2013 DenUpdateIOOlow bandwidth MCL loop

Last time we designed MCL loop with UGF ~ 30 Hz and I think, it was hard to lock the arm because of large frequency noise injected to IFO.

This time I made a low bandwidth MCL loop with UGF=8 Hz. MCL error RMS is suppressed by factor of 10 and arms lock fine.

Attached plots show MCL OL, MCL error suppression and frequency noise injection to arms.

It is interesting that spectrum of arms increases below 1 Hz meaning that IMC sensing noise dominates in this range.

I did not include the loop into the IMC autolocker. I think it is necessary to turn it on only during day time activity and when beatnote is moving too much during arm stabilization.

Attachment 1: MCL_OL.pdf
MCL_OL.pdf
Attachment 2: MCL_ERR.pdf
MCL_ERR.pdf
Attachment 3: MCL_ARMS.pdf
MCL_ARMS.pdf
Attachment 4: MCL_MEDM.png
MCL_MEDM.png
  9472   Sat Dec 14 11:56:54 2013 ranaUpdateLSCcommon mode servo

Quote:

 

 It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.

 These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?

We should be able to estimate the noise coming out of the MC using the single arm and then make a guess for the CM loop gain requirement. There's no reason to keep the old Boost shapes; those were used in the old MC configuration which had a RefCav. In addition to minimizing the EOM range, we should also minimize the AO signal as Koji has pointed out. In practice, I've seen that using ~300 Hz of offset makes no harm with 4 kHz MC pole.

  9471   Sat Dec 14 02:51:47 2013 DenUpdateLSClocking activity

I had a look on x,y arms stabilization using ALS. Input green beam was misaligned and I was loosing 00 every few minutes. I vent on the floor and realigned green beams.

YARM alignemt was smooth - transmission increased from 0.4 to 0.85 with PSL shutter off.

XARM was tough. Steering mirrors did not have any derivatives when transmission power was 0.5. I walked the beam with piezos but got only 0.55. It seems that the input beam is mismatched to the cavity. When the transmission was 1 last time? Does anyone have a model of the xend table to compute mode matching?

Input green alignent was improved and I could keep arms stabilized for periods of ~30min - 1 hour. Still not forever.

I noticed that ALS_XARM and ALS_YARM servos have limiters of 6000 and control signal had high frequency components that were not rolled off as shown on the plot "ETMY_DRIVE". I have added a low pass filter that reduced RMS by factor of 5 and took 7 degrees of phase at UGF=150 Hz. Now margin is 33 degrees.

Then I excited ETMY longitudinally at 100 Hz and measured first and second harmonics of the YARM RIN. I got total DC offset of 0.3 nm. This means significant length coupling to RIN. First of all, "scan arm" script does not tune the offset very precise. I guess it looks at DC power, checks when cavity passes through symmetrical points of the resonance and takes the average. It is also useful to look at POX/POY and confirm that average is 0. Plot "ALS_RIN" shows comparison of YARM power fluctuations when it is locked using IR and stabilized using ALS. By manually correcting the offset I could reduce length coupling into RIN, coherence was ~0.1.

Cavity RMS motion also couples length to RIN. Plot "ALS_IR" shows YARM error signal. I also looked at POY signal (LSC-YARM_IN1) as an OOL sensor. At low frequencies POY sees only IMC length fluctuations converted to frequency. I have engaged MCL path and ALS error and LSC error signals overlaped. Cavity RMS motion is measured to be 200 pm.

Attachment 1: ETMY_DRIVE.pdf
ETMY_DRIVE.pdf
Attachment 2: ALS_RIN.pdf
ALS_RIN.pdf
Attachment 3: ALS_IR.pdf
ALS_IR.pdf
  9470   Fri Dec 13 23:07:04 2013 KojiUpdateIOOcommon mode servo

Looks good.

Once the control cable (bakplane cable) is identified, we can install the module to the LSC analog rack.

We should be able to test the CM servo with either POX or POY and only one correspoding arm without modifying the servo TF.
Just for this test, we don't need to use MCL.

  9469   Fri Dec 13 19:33:56 2013 DenUpdateASCETM X,Y QPDs

I have modified/compiled/installed/restarted c1scx and c1scy models to include arm transmission QPDs in angular controls.

For initial test I have wired normalized QPD pitch and yaw outputs to ASC input of ETMs. This was done to keep the signals inside the model.

QPD signals are summed with ASS dither lines and control. So do not forget to turn off QPD output before turning on dither alignment.

Medm screens were made and put to medm/c1sc{x,y}/master directory. Access from sitemap is QPDs -> ETM{ X,Y} QPD

  9468   Fri Dec 13 18:03:00 2013 DenUpdateIOOcommon mode servo

Quote:

Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.

 It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.

Frequency response of the servo is taken from the document D040180. I assumed coupled cavity pole to be ~100 Hz.

The only question is if our EOM has enough range. Boost 2 increases noise injection by 10 dB in the frequency range 20-50 kHz. Boost 3 has even higher factor.

Attachment 1: CM_OL.pdf
CM_OL.pdf
Attachment 2: CM_CL.pdf
CM_CL.pdf
  9467   Fri Dec 13 16:34:20 2013 SteveUpdateVACPS will be replaced next week

Quote:

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

 The temperature went down to room temp with temporary fan in the back. Voltage and current are stable.

Regardless, it will be replaced early next week.

Attachment 1: hotPSvacRack.jpg
hotPSvacRack.jpg
Attachment 2: fan1X8.jpg
fan1X8.jpg
  9466   Fri Dec 13 13:45:50 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

rect_replace.py script was updated.
This sounds crazy but it was actually quite easy as I could use a free font data.


/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

Now new type "CHAR" (i.e. REPLACE_CHAR) was added. This replaces the string in Channel B slot
into 5x7 dot matrix representation of the string with the specified color. The dot size is derived from the
height of the original rectangular object.

 

Attachment 1: screen_shot.png
screen_shot.png
  9465   Fri Dec 13 13:28:07 2013 DenUpdateLSCarm calibration template

I have calibrated ETMX and ETMY actuators and added a template armSpectra.xml into /users/Templates directory.

Template shows control and error signals of both arms. Procedure is standard: calibrate control to meters and match error based on UGF measurement. XARM UGF: 200 Hz, YARM UGF 210 Hz.

Noise level at high frequencies (>100 Hz) for YARM is 3*10-15 and is factor of 3 better then for XARM. Servo gains are in the same ratio. I think there is less light on POX than on POY RF PD because I checked phase rotation and analog gain. I assume transimpedances are the same.

Attachment 1: armsCal.pdf
armsCal.pdf
  9464   Fri Dec 13 11:47:11 2013 GabrieleUpdateGreen LockingBetter Xarm OLTF

I'm not as good as a fit, but it seems that there is a loop delay of about 30 microseconds, looking at the high frequency phase. This might explain the limitation on the BW. Eric should be able to get the delay out of the fit with some care.

  9463   Fri Dec 13 02:30:22 2013 KojiUpdateLSClocking activity

According to the measurement by Eric, the X-arm green PDH UGF is too low. We still have some room to increase the gain.

The out of loop stability of the ALS for each arm should be measured everyday.
Otherwise we can't tell whether the arm is prepared for advanced locking activities or not.

We expect to see the arm stablity of ~50pm_rms for the Y arm and ~150pm_rms for the X arm.

  9462   Fri Dec 13 02:19:57 2013 JenneUpdateLSClocking activity

[Jenne, Den]

Tonight we worked on tweaking up the PRCL new ASC, and then PRMI+1 arm locking.  We were unable to get the Xarm to stay locked on a TEM00 mode for very long, and after an hour or two of using the PZTs to try to align the beam to the cavity, we gave up and just used Yarm green.

NB: We haven't done anything to MCL, although it is not in use.  Den is still going to get around to elogging what servo shaping he changed on that last night.

I wrote a script that will handle the transitions between the new PRCL ASC and the PRM oplev and local damping.  The script is accessible from the PRC ASC screen, and will detect when the PRMI is locked or not.  When it is locked, it will turn down the PRM oplev gains and turn on the ASC, and then it will turn off the local shadow sensor damping for PRM pitch and yaw.  When the PRMI unlocks, the script will turn off the ASC and restore oplev and local shadow sensor damping. 

We saw that the bounce mode of the PRM was getting rung up with our new ASC, so we included a band stop in the ASC, and also turned on the triggering for the PRCL LSC FM6, which has the resonant gain for the bounce mode (as well as roll, and the stack mode).  This made the PRMI spot very stable. 

We then moved on to green arm locking.  The Yarm is behaving perfectly nicely (as nice as it has been lately - it's alignment and mode matching could also use some work), but Xarm was giving us a bit of trouble.  As always (since the PZTs were installed?), the mode matching isn't excellent for the green to the arm, so it can be hard to catch a TEM00 mode.  Also, even if we did catch a good mode, it would often not stay locked for more than a few tens of seconds.  We tried several alignment tweakings, and several different end laser temperatures (within the confines of seeing the beatnote under 100MHz), and didn't have a lot of success.  It looks like Eric had the slow servo engaged for the Xend laser, so the temperature offset was something like +300,000, which seemed totally crazy.  I turned that off, and found the beatnote somewhere around output of -10,300.  So, I haven't gone to the end to look at the temperature, but it's going to be different than when Eric was taking measurements this afternoon.  It seems like the main problem with the Xarm is poor mode matching - the maximized input pointing for TEM00, when you unlock and relock the cavity, is just as likely to give you a TEM_9_0 mode, as TEM00.

So, we gave up on the Xarm for the evening, and tried PRMI+1arm, with the new PRCL ASC.  This was successful!   The Yarm beatnote was around laser slow servo output of +4450.  Beatnote at 46.0MHz, -26dBm.  We found the IR resonance, moved off, locked the PRMI, transitioned to the new ASC, and brought the Yarm back to IR resonance.  What we see is that the power fluctuations in the PRC are much smaller than they were back around Halloween (elog 9338), however the arm power fluctuations still seem very, very large.  This is certainly partly due to the fact that we haven't done a thorough Yarm alignment since before messing with the greens, so we will have drifted somewhat.  Also, the ALS beatnote sensor isn't perfect, so won't be perfect at holding us near resonance. 

Den is thinking about whether we can use the arm transmission QPD signals to feed back to the ETM ASC servos, to try to reduce the RIN in the arms.  I feel like we should also see if this amount of power fluctuation can be explained by our ALS noise, because maybe we'll be fine once we transition to IR and turn off the ALS system.   Attached is a plot showing that the arm's RIN is coherent with the spot motion seen by the transmission QPD, so we need to check the alignment of the cavity, as well as consider using the trans QPD in an ASC feedback loop.

Here is a plot of the PRC sideband power, as well as the Yarm transmission.  The GPS time for this plot is approximately 1070963372.

PRMI_Yarm_NewPRCLasc.png

Attachment 2: try_dc.pdf
try_dc.pdf
  9461   Thu Dec 12 22:12:17 2013 KojiUpdateGreen LockingBetter Xarm OLTF

OK, the next question will be "why the loop bandwidth is so miserable?"
In other words, what is preventing us to have the bandwidth of 20~30kHz?
Your breaking down will give us the answer.

  9460   Thu Dec 12 21:30:52 2013 JenneUpdateASCPRMI-relevant oplevs centered

The ITM oplevs were pretty close to the edge of their ranges, and none of the oplevs have been centered in a while, so I centered ITMX, ITMY, BS, PRM after having done alignment (arms, then PRMI).

  9459   Thu Dec 12 21:23:15 2013 ericqUpdateGreen LockingBetter Xarm OLTF

With the newly repaired PDH board, I spent some time with the x arm green PDH loop. I found it SO MUCH EASIER to measure the OLTF by injecting before the servo, instead of after it. (i.e. I added a swept sine from the SR785 to the mixer output (error signal) before the servo input). This is likely because the error signal is much flatter. I used a 10mV excitation across the whole frequency range (30-100kHz). 

Here's the OLTF. I'm working on fitting it and breaking it up into its constituent TFs, then making a rudimentary noise budget. 

Dec12_Xarm_OLTF.pdf

  9458   Thu Dec 12 17:22:07 2013 SteveUpdateGeneralrack power supplies checked

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

Attachment 1: 1x1ps.jpg
1x1ps.jpg
Attachment 2: 1X5ps.jpg
1X5ps.jpg
Attachment 3: 1X9ps.jpg
1X9ps.jpg
Attachment 4: 1Y1ps.jpg
1Y1ps.jpg
Attachment 5: 1Y4ps.jpg
1Y4ps.jpg
Attachment 6: AuxLSCps.jpg
AuxLSCps.jpg
Attachment 7: AuxOmcSouthRackPs.jpg
AuxOmcSouthRackPs.jpg
Attachment 8: 1Y2.jpg
1Y2.jpg
  9457   Thu Dec 12 14:57:01 2013 KojiUpdateIOOIMC servo inspection

In order to accomplish CARM control with the PSL laser frequency, we use two actuators.

One is the longitudinal direction of one of the MC mirrors. The londitudinal motion of the MC induces
the laser frequency control via the MC servo. As we move the mirror, the range is sort of big,
but the BW is limited by the mechanical response.

The other is the additive offset path. We inject a signal to the additional input port of the MC.
The MC servo supresses this injection by giving the same amount but oppsite sign offset to
the error signal (before the addtion of the inputs). The bandwidth of this AO path is limited
by the bandwidth of the MC servo. Basically the BW of the AO path is about 1/10 of that of the MC servo.

In order to confirm the capability of the AO path as a frequency actuator, 1) OLTF of the MC servo
2) TF of the AO input to the servo error was measured.

Attachment 1 shows the openloop TF of the MC servo. The UGF seems just little bit higher than
100kHz. The OLTF is empirically modelled by LISO as seen in the figure.

Attachment 2 shows the TF from the additive input (In2) to the error monitor (MC Servo module Q error mon).
The gain setting of the MC servo box was: In1 +18dB, In2 0dB. The measured TF has arbitorary gain 
due to the gain setting, the measuemrent data was multiplied by 4 to mach the DC value to the unity.
This is to compare the measurement with the prediction from the OLTF.

The AO path TF is expected to show the character of -G/(1+G) where G is the OLTF. In my case,
G = 0.75*OLTF showed the best maching. There might have been some misalignment of the MC
upon the AO path measurement as I found after the measurement.

From the plot , we can see that the response is flat up to 20kHz. Above that it rapidly raises.
This should be dealt with the CM servo filter as the bump may hit the unity gain. Since we have to use
strong roll off to avoid the bump, this will eat the phase margin at low frequency.

In the case that we don't like this bump:
This bump is caused by low phase mergin of the OLTF at 30~40kHz. If the total gain
is increased, the bump is reduced. Or, we can decrease the PZT loop gain in order to
reduce the dip at the crossover ferquency between the PZT and PC loops. In both cases,
the PC path suffers more actuation. We may need to think about the HV actuation option
for the PC (Apex PA85).

Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.

Attachment 1: OLTF_IMC.pdf
OLTF_IMC.pdf
Attachment 2: AOTF_IMC.pdf
AOTF_IMC.pdf
Attachment 3: 131209.zip
  9456   Thu Dec 12 00:47:45 2013 DenUpdateLSClocking activity

Jenne, Den

Today we worked on PRM angular servos and Y-arm ALS stabilization.

In the current PRMI angular control configuration two servos simultaneously drive PRM - oplev and POP ASC. We considered 2 ways to redesign this topology:

  • once lock is acquired, turn on POP ASC servo that corrects oplev error signal
  • turn off PRM oplev and turn on POP ASC  servo

The first option requires model rewiring so we started from the second one. We had to redesign POP ASC pitch and yaw servos for this because PRM TF has changed. Attached is servo OLTF.

This method worked out well and once PRMI is locked we turned off oplev servo with ramp of 0.5 sec and enable ASC POP servo with ramp of 1 sec.

Once PRMI was locked and ASC running we have turned off PRM angular local damping that presumably prevents us from bringing arms into resonance due to IR coupling to shadow sensors.

PRMI was stable using only ASC POP servo and we moved on to ALS. We found Y-arm beatnote and enabled control to ETMY.

Cavity was stabilized but not robust - we were loosing IR in a minute because green relocked to 01 mode with transmission equal to more than half of 00 mode. This is probably due to angle to length coupling of ETMY.

We were also loosing IMC during cavity stabilization. We made MCL servo and will tune it tomorrow looking at the arm spectrum as an OOL sensor.

Attachment 1: POP_ASC.pdf
POP_ASC.pdf
  9455   Thu Dec 12 00:21:04 2013 KojiUpdateGreen LockingX end PDH box oscillation issue solved (Re: screwed up the end PDH box)

What a such long pain we suffered.

After more than three years from Kiwamu's discovery, the PDH box 50kHz oscillation issue was finally solved.

This "weird peak at 50kHz" was caused by the oscillation of the voltage regulator (ON's MC7912).
As it imposed common noise almost everywhere, it screwed up transfer function measurements
like EricQ saw recently.

The negative voltage regulator (79XX) tends to get unstable than the positive counter parts (78XX).

The oscillation was removed by adding 22uF electrolytic capacitor between the output pin (pin3) and the ground pin (pin1) of MC7912.
This is indeed more than 20 times of the specification you can find in the data sheet.

  9454   Tue Dec 10 17:27:47 2013 JenneUpdateTreasureBaby oplev LQR designed loop

I *finally* figured out how to bend Matlab to my will, and close a very simple oplev loop using LQR technology. 

This is super, super simple, but it's a step in the right direction.  There is no noise, just a simple pendulum with a resonant frequency of 0.75Hz, and a Q of 10.  The LQR tries to keep the position of the pendulum at a minimum, and does not care at all about the velocity.  You cannot (with Matlab's LQR, at least that I can find) make it care "0" about the control output, so it cares about the control output a factor of 1e-4 as much as the position.

Here are some plots:

The first plot has the open loop system (just the pendulum, no control at all), as well as the closed loop system (the pendulum under control).

NoControlVsClosedLoop_BabyOplev.png

Plot 2 is the open loop gain of the controller that the LQR designed.

OpenLoopGain_BabyOplev.png

Plots 3 and 4 are the step and impulse responses of the open loop (pendulum with no control), and closed loop (pendulum with feedback) systems.

StepResp_BabyOplev.png

ImpResp_BabyOplev.png

The conclusion from the plots (if this were an interesting system) is that it doesn't take much to damp an ideal pendulum.  The real conclusion here is that I think I now know how to use the Matlab LQR function, and can make a loop with some noise now.

  9453   Tue Dec 10 15:13:55 2013 KojiUpdateIOOIMC servo inspection

Yesterday evening I inspected at IMC servo as a preparation of the CM servo recommissioning.

More details to come.

  9452   Tue Dec 10 10:07:01 2013 SteveUpdateIOOmore beam traps

 New razor beam dump installed to trap reflected beam of the input vacuum window.

 

Attachment 1: InputWindowRefDump.jpg
InputWindowRefDump.jpg
Attachment 2: InpWindowRefDupm.jpg
InpWindowRefDupm.jpg
  9451   Mon Dec 9 11:44:08 2013 SteveUpdateendtable upgradeETMY optable got new beam dump

Aluminum shield replaced by razor beam dump.

Attachment 1: ETMYoptBefore.jpg
ETMYoptBefore.jpg
Attachment 2: ETMYoptAfter.jpg
ETMYoptAfter.jpg
  9450   Sat Dec 7 19:29:14 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

In order to unify the theme for MEDM screens, I'll have to make many combinations of rectangles, polygons, and invisible related-screen buttons.
Everytime I change the size of the block, I have to modify the size of this combination. It is impossile for me.

So, I made a script to replace a certain type of rectangles with a combination of the objects with the same (or related) size.

The script is here (so far)

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

So far, there is only "TYPE1" for the predefinition. It actually takes another argument to specify the
path of the related screen to open when the block is clicked. The path should be filled in "Channel B"
slot of the original rectangle. (See Attachment 1)

The "TYPE1" style has the function calls as indicated below. place_rect is to place a rectangle object. You can
specify the filling method and color. place_rel_disp is to place an invisible button with the link to the specified
path by strOpt. place_polygon places a polygon. The cordinate array for the polygon is described with
the relative positions from the specified position.

        place_rect(rect_x-4,         rect_y-4,        rect_w+7, rect_h+7, "outline",  0) # outline white box
        place_rel_disp(rect_x, rect_y, rect_w, rect_h, strOpt, 0, 14)                    # invisible button
        place_rect(rect_x,           rect_y,          rect_w,   rect_h,   "fill",     3) # main gray box
        place_rect(rect_x+3,         rect_y,          rect_w-6, 3,        "fill",     0) # top white rim
        place_rect(rect_x,           rect_y,          3,        rect_h-3, "fill",     0) # left white rim
        place_rect(rect_x+rect_w-3 , rect_y,          3,        rect_h,   "fill",    10) # right gray rim
        place_rect(rect_x,           rect_y+rect_h-3, rect_w-3, 3,        "fill",    10) # bottom gray rim
        place_polygon(rect_x+rect_w-3,rect_y,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # top-right white triangle
        place_polygon(rect_x,rect_y+rect_h-3,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # bottom-left white triangle

Attachment 1: rectangle_config.png
rectangle_config.png
Attachment 2: rect_replace_result.png
rect_replace_result.png
ELOG V3.1.3-