40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 257 of 339  Not logged in ELOG logo
IDup Date Author Type Category Subject
  12888   Tue Mar 14 15:05:18 2017 SteveUpdateOptical Levershistory of ETMX oplev laser

 

Quote:

ETMX oplev laser is dead. It will be replaced this after noon. Sus damping recovered.

This 3 years old HeNe [ JDS 1103P, sn 351889 ]  has been dying for some time or just playing possum at age 1,126 days

I did not replace the ETMX oplev laser because I was unable to bring up the the C1ASC_ETMX_OPTLEV_SERVO  medm screen on laptops.

Attachment 1: ETMX_1103P_3y.png
ETMX_1103P_3y.png
  12889   Thu Mar 16 08:22:16 2017 SteveUpdateSUSETMX damping

Finally I see what kicks the sus damping off

Quote:

Huh? So should we ask them to put the container back? Or do you have some other theory about ETMX tripping that is not garbage related?

Quote:

ETMX sus damping recovered.

Note: The giant metal garbage container was moved from the south west corner of CES months ago.

 

 

Attachment 1: laser_power_glitch.png
laser_power_glitch.png
  12890   Fri Mar 17 10:47:16 2017 SteveUpdateOptical Levers ETMX oplev laser replaced

JDSU 1103P. sn T8070866, made March 2007, output power 2.7 mW,  on pd 17,750 counts,

GV 17 March 3pm: I found the Innolight NPRO was off when I walked down to the X end earlier, possibly was accidentally tripped during the Oplev laser replacement. I turned it back on.

Quote:

 

Quote:

ETMX oplev laser is dead. It will be replaced this after noon. Sus damping recovered.

This 3 years old HeNe [ JDS 1103P, sn 351889 ]  has been dying for some time or just playing possum at age 1,126 days

I did not replace the ETMX oplev laser because I was unable to bring up the the C1ASC_ETMX_OPTLEV_SERVO  medm screen on laptops.

 

  12891   Fri Mar 17 14:49:09 2017 gautamUpdateLSCMCREFL condition pictures

I did a quick measurement of the beam size on the MC REFL PD today morning. I disabled the MC autolocker while this measurement was in progress. The measurement set up was as follows:

This way I was able to get right up to the heat sink - so this is approximately 2cm away from the active area of the PD. I could also measure the beam size in both the horizontal and vertical directions.

The measured and fitted data are:

  

The beam size is ~0.4mm in diameter, while the active area of the photodiode is 2mm in diameter according to the datasheet. So the beam is ~5x smaller than the active area of the PD. I couldn't find anything in the datasheet about what the damage threshold is in terms of incident optical power, but there is ~100mW on th MC REFL PD when the MC is unlocked, which corresponds to a peak intensity of ~1.7 W / mm^2...

Even though no optics were intentionally touched for this measurement, I quickly verified that the spot is centered on the MC REFL PD by looking at the DC output of the PD, and then re-enabled the autolocker.

Attachment 2: MCREFL_X.pdf
MCREFL_X.pdf
Attachment 3: MCREFL_Y.pdf
MCREFL_Y.pdf
  12892   Fri Mar 17 15:30:39 2017 SteveSummarySUSoplev laser summary updated

         March  17,  2017         ETMX laser replaced at LT 3y with 1103P, sn T8070866

Attachment 1: oplev_sums.png
oplev_sums.png
  12893   Mon Mar 20 11:18:58 2017 gautamUpdateCDSNo internet connectivity on control room machines

There is no internet connectivity on any of the control room machines. 

I have been trying to debug by tracing the cabling situation in the rack in the office area, and will update if/when this problem has been resolved. I had last come into the lab on Saturday and there was no problem then. There 40m wireless network servicing the office area seems to work fine.

 

  12894   Mon Mar 20 14:39:44 2017 gautamUpdateCDSNo internet connectivity on control room machines

Koji diagnosed that the NAT router was to blame for this problem. I simply power cycled this router, and now the connectivity has been restored. 

It was possible to log into nodus and then to pianosa - and it was also possible to log into the various control room machines once logged into nodus. However, the outward packets seemed to not get transmitted. Anyways, power cycling the NAT Router unit seems to have done the job.

Quote:

There is no internet connectivity on any of the control room machines. 

I have been trying to debug by tracing the cabling situation in the rack in the office area, and will update if/when this problem has been resolved. I had last come into the lab on Saturday and there was no problem then. There 40m wireless network servicing the office area seems to work fine.

 

 

  12895   Mon Mar 20 17:12:08 2017 steveUpdatePEMparticle counter inside of PSL enclousure

The logging script is multiplying by 100 instead of 10 !

Quote:

The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am.

The HEPA filter speed at the Variac was turned down to 20V from 40

This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.

 

 

Attachment 1: enclousure_partical_count.png
enclousure_partical_count.png
  12896   Tue Mar 21 15:13:44 2017 gautamUpdateIMCIMC input beam mode matching

[valera, gautam]

Last night, Valera and I looked into two aspects of the IMC:

  1. How can we accurately set the offset at the error point of the PDH servo such that we lock to the true center of the resonance?
  2. What's up with the large common mode offset on the WFS?

I will post a more detailed elog about last night's work, but Valera also thought it might be a good idea to try and improve the mode-matching into the IMC. I couldn't find anything on the wiki/elog about the mode matching situation on the PSL table, so I quickly went over yesterday to measure some lengths. From looking at the MCREFL DC levels when the mode cleaner is locked (~0.37V) and unlocked (~5.7V), the current mode matching efficiency seems to be about 88%, so there is definitely some headroom for improvement.

Here is my cartoon of the situation on the PSL table. All lengths are measured in mm, and I would say correct to +/- 5 mm, so there could be considerable error here...

  (L1 : f=+200mm. L2: f=-150mm. L3:  f=+400mm)

I extracted the lengths from the edge of the PSL table to IM1 and MC1 from (what I think are) the latest CAD drawings on the DCC. I then put all this into an a la mode script [Attachment #5] - I assumed a waist of 370um at the PMC output mirror, and a waist of 1.78mm at MC1. I neglected the passage through the in-vac Faraday, EOM and BS1 (on the sketch above) and the MC1 substrate. I was able to achieve a theoretical mode-matching efficiency of 1 by just moving the positions of L2 and L3. 

Given that there are probably errors of the order 0.5cm in the lengths on the PSL table, and also the in-vacuum distance to MC1, I figured it would be ideal to just move one lens and see if we can improve the efficiency. It looks like it may be more effective to move L2 than L3. The plot on the right shows that the sensitivity is approximately equal to the positioning of L2 and L3. Judging by this plot, looks like w.r.t. the coordinates in this plot, we are somewhere around (0.02,-0.02).

It looks like if we want to do this, moving L2 (f = -150mm) may be the best way to go.

Attachment 2: IMC_ModeMatch.pdf
IMC_ModeMatch.pdf
Attachment 3: singleLensSensitivity.pdf
singleLensSensitivity.pdf
Attachment 4: sensitivity.pdf
sensitivity.pdf
Attachment 5: IMCmodeMatch.m
close all
clear all
clc

%Create a beamPath object
InpPath = beamPath;
%Add components - for a first pass, ignore Faraday and HWPs, so only
%mirrors and lenses..
InpPath.addComponent(component.flatMirror(35e-3,'M1'));
InpPath.addComponent(component.flatMirror(75e-3,'M2'));
... 115 more lines ...
  12897   Tue Mar 21 21:21:58 2017 gautamUpdateIOOWFS filter banks updated

The arrangement of filters in the WFS loop filter banks have been altered, Rana will update with details of the motivation behind these changes. Here is how the screen looks now:

I have updated the C1IOO SDF table, and also the mcwfson script to reflect these changes. The latter has been svn committed.

  12898   Tue Mar 21 21:59:48 2017 gautamUpdateIMCIMC input beam mode matching

[valera, gautam]

We implemented the plan outlined in the previous elog. The visibility (Pmax-Pmin)/(Pmax+Pmin) calculated with the MC REFL PD levels with the MC locked/unlocked is now ~96% (up from 88%yes). The MC REFL DC level in lock is now ~0.12V (compared to 0.4V). Assuming a modulation depth of 0.1 @ 29.5MHz, about 25% of this (i.e. 0.03V) is from sideband light.

The procedure followed was (see sketch in previous elog for various optic labels):

  1. Move L2 back (towards PMC) by ~2cm.
  2. Walk the beam using M3 and M4 to minimize MCREFL, re-lock IMC, run WFS. 
  3. Move L3 back (towards PMC) by ~2cm.
  4. Repeat steps 2 and 3, the latter with smaller steps, monitor MCREFL DC level.

We could probably tweak the fine positioning of L2 and L3 and improve the efficiency a little more, but the primary objective here was to see if there was any effect on the large common mode offset on the WFS demodulated "SUM" output. Unfortunately, we saw no effect.

Here are two photos of the relevant section of the PSL table before (left) and after (right) our work there:

   

  12899   Wed Mar 22 00:33:00 2017 gautamUpdateIMCIMC length offset nulling

[valera, gautam]

Motivation: see this elog

I was fiddling around for a few days trying to implement the method outlined in this paper to null this offset - I will post a separate elog about my efforts but Valera pointed out that we could try injecting an AF modulation at the IN2 input of the MC Servo Board. Last night, we hooked up an SR function generator (f = 312Hz, A = 0.01Vpp, IN2 gain = -5dB) to the unused BNC IN2 input of the MC Servo board. To avoid any additional offsets from the AO path during this measurement, I disconnected the LEMO cable (it is labelled).

We looked at the spectrum of the MC transmission around 312Hz and also 2*f = 624Hz. As a result of this modulation, we expect in the transmitted power, dP/P, a 2f term with amplitude ~(X_mod/X_0)^2 and a term at f with amplitude ~(X_offset * X_mod / X_0^2) - I may have missed out some numerical factors of order 1. So the latter should vanish if the offset at the error point is truly zero and the lock-point is the center of the resonance. Last night, we found that an offset in the range of -0.25 V to -0.19 V nulled this peak in the DTT spectrum. Today, the number was -0.05V. So the true offset seems to vary from lock to lock. Here are spectra around f=312Hz for a few different values of the offset slider (the center of the resonance seems to be -0.05V on the MEDM slider at this time).

Do these numbers make sense? Some time ago, I had pulled out the MC Servo board to find out what exactly is going on at this offset summing point. The MEDM slider goes from -10V to 10V, and by measuring the voltage at TP5 (see schematic below), I found that there is a 1/40 scaling factor between what is actually applied and the number on the MEDM slider (so for example, the numbers in the legend in the above plot have to be divided by 40). I've modified the MC Servo Board MEDM screen to reflect this. When I had pulled the board out, I noticed that in addition to the offset voltage applied via the backplane connector, there was also a potentiometer (R50 in the schematic below). I had nulled the voltage at TP5 using this potentiometer, but I guess drifts of ~5mV are possible. 

Discussion on calibration of offset slider in Hz/V:

I've yet to do a rigorous calibration of this slider into Hz, but looking at the spectrum of the transmitted intensity at 2f, we estimated the coefficient (X_mod/X_0) ~ 3e-3 for an offset of 0.2V. dP/P ~1 when the applied modulation equals the linewidth of the cavity, which is 3.6kHz. So 0.2V of offset slider corresponds to ~ 10Hz frequency offset. In other words, I estimate the slider calibration to be 50Hz/V. So with the full range of +/- 10V, we should be able to scan ~1kHz of frequency offset. What does this imply about the variation of the offset slider value that removes the peak at 1f between locks? As mentioned above, this variation is ~0.2V over a day - with the calibration mentioned above, this corresponds to a change in cavity length of ~10um, which seems reasonable to me...


So how did all of this tie in with WFS SUM offsets? We did the following:

  • After nulling the length offset using the procedure detailed above, we noticed non-zero offsets on both WFS1 and WFS2 "I" SUM outputs
  • So we set the dark offsets and RF offsets for the WFS, with no light incident on the WFS (PSL shutter closed). 
  • Re-locking the IMC and closing the WFS loops, we noticed that WFS2 SUM offset was still hovering around 0, but WFS1 SUM offset was ~ -2000cts.
  • Looking at some trends on dataviewer, this offset seems to drift around over a few days timescale by a few thousand counts - for example, the WFS1 offset today was +2000cts. Moreover, the WFS1 offset seems to drift around by ~factor of 3 times as much as WFS2 offset in the 24 hour period I looked up (plot to follow)...
  • Misaligned MC2 and looked at the sum offset with just the single bounce beam off MC1 onto the WFS

I neglected to screenshot the StripTool from the times we were doing these trials but I have the times, I will pull up some dataviewer plots and upload them here tomorrow...

Attachment 1: offsetInvestigation.pdf
offsetInvestigation.pdf
Attachment 2: offset_summing_amp.pdf
offset_summing_amp.pdf
  12900   Wed Mar 22 16:58:25 2017 gautamUpdateIMCWFS sensing matrix measurements

I've taken a bunch of transfer function measurements from the MC ASC PIT and YAW channels to the WFS error signals using the same set of DTT templates Koji used while characterizing the WFS loops a couple of months ago, before the IMC RF changes. Analysis is underway and I will post the results here shortly...

As an aside, Rana had added 10dB and 20dB gains to all of the WFS filter banks yesterday. I tried engaging the 10dB gains on the two MC2_TRANS PD loops, and this did not seem to induce any instability. I stepped both loops and saw that as expected, the 1/e times for both of these loops is about 45 seconds now (compared to ~150 seconds at the nominal gain). These have been running all day today, and the IMC seems well behaved, so I am going to leave these on for now... Jacking up the gain on the MC2_TRANS_QPD loops by 20dB induced instability - same story for the 4 WFS loops with 10dB additional gain...

  12901   Thu Mar 23 01:44:53 2017 gautamUpdateIMCWFS sensing matrix measurements

Thanks to Koji's nice MATLAB script using DttData functions, I was able to quickly analyze the TF data. Essentially, this measurement was a repetition of what was done here. The difference is that the modulation depth has been increased by ~25x compared to that measurement from December 2016. Here are the measured TFs (before accounting for the 1/f^2 normalization) for the various quadrants and the PIT/YAW channels:

  

The plots above are just to illustrate that the measurement was clean between the band over which the averaging will be done to compute the TF amplitude - i.e. 7-15Hz. The full summary of TF amplitudes, standard deviations, and the sensing matrix in the style of the referenced elog (the actual excel spreadsheet is Attachment #4, minus some of the graphics Koji had on his excel sheet):

Inverting those matrices, we get the matrices that diagonalize the sensor-actuator chain:

PITCH:

\begin{pmatrix} -0.00518 & -0.00305 & -639.6\\ 0.00354 & -0.00281 & 198.8\\ 0.00102 & 0.00672 & -756.6 \end{pmatrix}

YAW:

\begin{pmatrix} 0.00523 & -0.00276 & -856.7\\ 0.000318 & 0.00010 & -366.4\\ 0.00039 & -0.00548 & -851.9 \end{pmatrix}

I will try implementing these matrices tomorrow and take a look at the step responses of the loops - the idea is that perhaps the system wasn't optimally diagonalized before and perhaps we can now improve the bandwidths of all the loops.

 

Attachment 1: IMC_WFS_segment_TF.pdf
IMC_WFS_segment_TF.pdf
Attachment 2: IMC_WFS_channels_TF.pdf
IMC_WFS_channels_TF.pdf
Attachment 3: TFsummary.pdf
TFsummary.pdf
Attachment 4: IMC_WFS_170322.xlsx.zip
  12902   Thu Mar 23 08:43:11 2017 ranaUpdateIMCWFS sensing matrix measurements

For sensing matrix, better to use single frequency sine response. We don't want to measure around the bounce or above the 28 Hz cutoff filters in the MC SUS.

  12903   Thu Mar 23 23:38:58 2017 gautamUpdateIMCMC SUS damping gains stepped down

I've reduced the gains of the damping on all 3 MC SUS by a factor of 3 for overnight observation as part of the ongoing feedforward noise cancellation investigations. I will return them to the nominal values tomorrow morning.

  12904   Fri Mar 24 11:26:57 2017 gautamUpdateIMCMC SUS damping gains restored

I've restored the damping loop gains to their nominal values. Analysis of the coherence between MCL and seismometer channels under this reduced gain setting is underway, results to follow.

  12905   Fri Mar 24 12:21:27 2017 gautamSummaryIOOMCL / MCF / Calibration

I repeated this measurement as follows:

  1. Added a filter in the MC_F filterbank (FM9) to account for the Pomona box between the PZT control signal and the laser PZT (pole@2.9Hz). So the filter bank at the time of TF measurement looks like this:
  2. Measured TF from driving MC2 (with C1:SUS-MC2_MCL_OUT channel) to C1:IOO-MC_F, which is the output of the above filter bank. The response is the expected 1/f^2 shape of the free optic
     
  3. From this transfer function, the magnitude is 0.0316 ct/ct. Using the value of 6nm/ct for the MC2 actuator gain that I found in a previous elog entry, I calibrated the MC_F output into Hz using the calibration factor 3.95MHz/ct (FM10 in the above filterbank).

Here is a calibrated MC_F spectrum:

RXA: I've added this plot of the free-running noise of the Lightwave NPRO which is probably similar to our Innolight Mephisto. Seems like the laser is quieter than MC_F everywhere below 100 Hz.

Attachment 2: MCF_cal.pdf
MCF_cal.pdf
Attachment 3: MCFTF_mag.pdf
MCFTF_mag.pdf
Attachment 4: MCFTF_phase.pdf
MCFTF_phase.pdf
Attachment 5: MCFTF_coh.pdf
MCFTF_coh.pdf
Attachment 6: FreqNoiseReq.pdf
FreqNoiseReq.pdf
  12906   Fri Mar 24 19:04:18 2017 gautamUpdateIMCSeismic feedforward and WFS

[valera, gautam]

On Wednesday at the meeting, we were discussing why we aren't able to achieve more seismic feedforward subtraction in MCL. We spent some time thinking about this yesterday, and this elog is meant to be a summary of the stuff we tried. 

  1. We let the WFS loops run for a while and settle, and then turned the input gain down to zero so that the integrators held the outputs to the suspension at a "good" alignment. If the WFS loop bandwidth is ~0.1 Hz, then they aren't helping us at 1Hz anyways. We then looked at coherence between the seismometer signals in this state compared to when the WFS loops were running, and noticed negligible difference. It doesn't seem like the WFS loops are injecting noise into MCL at ~1Hz.
  2. We decided agains implementing the WFS sensing matrix I measured on Wednesday evening, as we found that the relative magnitudes of the matrix elements are virtually the same as in Koji's measurement back in December 2016. But looking at matrix elements like MC1P->WFS1P compared to MC3P->WFS1P - there is a difference of a factor of ~3. Why should there be? The response should be completely symmetric to MC1 and MC3?
  3. While looking at the OSEM channels (i.e. SUSPIT_IN1_DQ, SUSYAW_IN1_DQ etc) for each of the MC optics, we noticed a dramatic difference between MC1 (factor of ~10 higher) and the other two MC optics.
  4. Looking at coherence between MCL and the seismometer channels, we felt that there is less coherence at low frequencies (1Hz and lower) now than there was back in January when I took a measurement. However, there was coherence between the OSEM signals and the seismometers - so it doesn't look like the seismometer is to blame. To make an apples-to-apples comparison, I compared the MCL and Seismometer channel spectra from January to now (for the latter, at two different settings of the damping loop gains on the MC suspensions), and also the maximum predicted achievable subtraction (using EricQs frequency domain multicoherence tool). The two changes I can think of since January are that the MC1 satellite box has been interchanged with the SRM satellite box, and the IMC servo gains have been reallocated since the RF upgrade. My findings are summarized in attachments #1 and #2.

The seismometer spectra look similar enough to be explained by time of day variations, so perhaps the culprit is MC1. The ambient MCL spectrum is almost an order of magnitude higher above 4Hz now, with the nominal damping loop gains, as compared to back in January. I think the damping loops on MC1 need to be tweaked.

 

Attachment 1: MCL_comparison.pdf
MCL_comparison.pdf
Attachment 2: seis_comparison.pdf
seis_comparison.pdf
  12907   Mon Mar 27 12:48:36 2017 ranaSummaryIOOMCL / MCF / Calibration

What readouts do we have for the PMC length? If we could have a calibrated & whitened error and control signal for the PMC up to 16 kHz, perhaps we could see at what frequencies we can use it as a faux-RefCav.

  12908   Mon Mar 27 15:36:27 2017 SteveUpdatePEMparticle counter inside of PSL enclousure

 

Quote:

The logging script is multiplying by 100 instead of 10 !

Quote:

The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am.

The HEPA filter speed at the Variac was turned down to 20V from 40

This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.

 

 

Some one turned up the PSL HEPA rotation voltage from 20 V to 33 ( 120V Variac ) and  X-arm AC set temp lowered to 68F

Effects at 12" height from optical table :

                                                            1.0, 0.5 & 0.3 micron particle count  goes to zero and temperature fluctuaion increased

Rotation speed voltage was set to 30V

                                                            

Attachment 1: HEPA_flow_effects.png
HEPA_flow_effects.png
  12909   Mon Mar 27 16:01:55 2017 SteveUpdatePEMX arm AC set to 68F

 

The X arm air conditioner was not regulating properly. The arm temp was warmer than usual. I requested thermistor calibration.

The mechanic reset the thermostate to 68F last week.  It was 70-71F before.

 

The ETMX oplev laser now running 4 C lower at 30 C inside the enclousure.

The ETMX optical table top is 5 C cooler  at 21 C

The ETMX concrete wall temp 20 C at 9am with flow bench on.

ETMY conrete wall  temp 23 C at 9am

  12910   Mon Mar 27 20:29:05 2017 ranaSummaryDetCharSummary pages broken again

Going to the summary pages and looking at 'Today' seems to break it and crash the browser. Other tabs are OK, but 'summary' is our default page.

I've noticed this happening for a couple of days now. Today, I moved the .ini files which define the config for the pages from the old chans/ location into the /users/public_html/detcharsummary/ConfigFiles/ dir. Somehow, we should be maintaining version control of detcharsummary, but I think right now its loose and free.

  12911   Mon Mar 27 20:41:21 2017 rana, gautamUpdatePSLPMC DAQ assay for feed-forward integration

We are thinking to use the PMC signals to help us in figuring out the feedback / feedforward stuff and making it better.

Today we scoped out the PMC DAQ channels (which were never re-hooked up after the Joe/Jamie CDS upgrade 6 years ago).

There is a 4-pin LEMO connector on the front panel which gives

  1. the error signal (after the 4th order, post-mixer lowpass and a OP27 buffer with a 17 kHz low pass)
  2. the feedback voltage to the PZT, after a resistive divide by 50

Both of these signals are buffered by the AD620 inst amp configured with a gain of 1. In the green scope trace, you can see that there's a ~110 MHz signal strongly evident there. In the spectrum analyzer screen shot there is a instrument noise trace and then a PMC error point trace. You can see that all the peaks are ony there when I connect to the servo board instead of a Terminator. This RF noise is mainly the higher harmonics of the 35.5 MHz modulation getting there. It seems to be in both the error and control DAQ outputs, and a question is whether or not it is also in the servo electronics.

I also attach a close up of the servo board in the region of the post-mixer LC low pass filtering. I think its supposed to be 4th order cutoff at 1 MHz, but maybe the caps are busted or there's a way for the RF from the mixer to bypass the filters and get into the main servo path?

In the medium term, we probably want to use the new PDH servo that Rich is making. Need to buy/make a HV driver to use, but that should be easy.

Attachment 1: TEK00000.PNG
TEK00000.PNG
Attachment 2: 20170327_194931.jpg
20170327_194931.jpg
Attachment 3: 20170327_204554.jpg
20170327_204554.jpg
  12912   Mon Mar 27 22:40:44 2017 KojiSummaryIOOMCL / MCF / Calibration

In http://nodus.ligo.caltech.edu:8080/40m/11793 I posted the calibrated PMC free-running displcament with/without IMC locked. Unfortunately, this measurement was done with a part of the IMC electronics not perfect (https://nodus.ligo.caltech.edu:8081/40m/11794). I did the same measurement after the fix, but there is no low freq data http://nodus.ligo.caltech.edu:8080/40m/11795.

Assuming we have the similar error signal leve in the low freq band as The entry 11793, the IMC is considered to be noisier than the PMC between 0.8 and 4Hz. But we should do the same measurement with the current electronics.

The PMC calibration can be found in this entry http://nodus.ligo.caltech.edu:8080/40m/11780

  12913   Tue Mar 28 16:47:40 2017 SteveUpdatesafetyProjector bulb is out again

Three replacement bulbs ordered

Rana can discribe how it happened.

IF A LAMP EXPLODES

If a lamp explodes, the gas and broken shards may scatter inside the projector and they may comeout of the exhaust vent.
The gas contains toxic mercury.
Open windows and doors for ventilation.
If you inhale the gas or the shardsof the broken lamp enter your eyes or mouth, consult the doctorimmediately.
Quote:

This bulb was blown out on Feb 4, 2017 after 2 months of operation.

 

 

  12914   Tue Mar 28 21:06:53 2017 ranaSummaryCDS/cvs/cds/caltech/chans back on svn1.6

Debian doesn't like EPICS. Or our XY plots of beam spots...Sad!

Quote:
Quote:

No, not confused on that point. We just will not be testing OS versions at the 40m or running multiple OS's on our workstations. As I've said before, we will only move to so-called 'reference' systems once they've been in use for a long time.

Ubuntu16 is not to my knowledge used for any CDS system anywhere.  I'm not sure how you expect to have better support for that.  There are no pre-compiled packages of any kind available for Ubuntu16.  Good luck, you big smelly doofuses. Nyah, nyah, nyah.

  12915   Wed Mar 29 09:24:28 2017 SteveUpdateloresummery pages

The summery pages are working at a slow motion speed. It's response time 12 minutes.

  12916   Wed Mar 29 11:41:19 2017 gautamUpdatePSLPMC DAQ assay for feed-forward integration

The C1IOO frontend machine that resides in 1X1/1X2 has 2 ADCs, ADC0 and ADC1. The latter has 28 out of 32 channels unused at the moment, so I decided to use this for setting up fast channels for the PMC DAQ. On the RTCDS side of things, the PSL namespace block lives in the C1ALS model. I made the following modifications to it:

  1. Added channels for the PMC DAQ
  2. Added CDS filters for both the newly added PMC DAQ channels and the existing FSS DAQ channels, so that we can calibrate these into physical units
  3. Changed the names of the existing FSS channels from FSS_MIXER and FSS_NPRO to FSS_ERR and FSS_CTRL. The latter is still a bit ambiguous, but I felt that FSS_CM_BOARD_CTRL was too long. 
  4. Added DQ channels for the new PMC channels. These are recording at 16K at the moment, but since we have the fast testpoints courtesy of the CDS filter modules for diagnostics, perhaps the DQ channels need only be recorded at 2K?

The PSL namespace block in C1ALS looks like this now:

I then tried hooking up the DAQ signals from the PMC servo board to the ADC via the 1U generic ADC interface chassis in 1X2 - this has 4pin LEMO inputs corresponding to 2 differential input channels. I used J6 (corresponding to ADC channels 10 and 11) for the PMC_ERR and PMC_CTRL respectively. I was a little confused about the status of the 4 pin LEMO output on the front panel of the PMC servo board. According to the DCC page for the modified 40m servo board, the DAQ outputs are wired to the backplane connector instead of the 4 pin LEMO. But looking at photographs on the same DCC page, there are wires soldered on the rear-side of the PCB from the 4-pin LEMO to the backplane connector. Also, I believe the measurements made by Rana in the preceeding elog were made via the front panel LEMO. In any case, I decided to use the single pin LEMO monitor points on the front panel as a preliminary test. The uncalibrated spectra with ADC terminated, IMC unlocked and IMC locked look like:

So it looks like at the very least, we want to add some gain to the AD620 instrumentation amplifiers to better match the input range of the ADC. We also want to make the PZT voltage monitor path AC coupled. My plan then is the following:

  1. Figure out what is going on with the 4-pin LEMO connector on the front panel - is it connected to the DAQ monitor points or not?
  2. Ground pin 5 of U15 (this has already been done by Koji for U14 according to the DCC page)
  3. Add a resistor between pins 1 and 8 of U14 and U15 to get some gain. According to the datasheet, a 1k resistor will give a gain of 50, which for U15 will mean that we undo the existing 1/50 attenuation. Of course we need to AC couple this path first by adding a capacitor in series with R14. 
  4. Figure out where the RF harmonics are coming from and what is the best way to attenuate them.

I will update with a circuit diagram with proposed changes shortly.

Proposed changes:

  1. Cut PCB trace between R14 and R13, install capacitor - what is is correct type of capacitor to use here? I figured installing a series capacitor after the resistive divider, to the input of the instrumentation amplifier avoids the need for a HV capacitor, so we can use a 1uF WIMA capacitor.
  2. Add gains to U14 and U15 (error and control signal monitors respectively). Based on the uncalibrated spectra attached, I think we should go for a gain of ~50 for U15 (1kohm between pins 1 and 8), and a gain of ~200 for U14 (250ohms between pins 1 and 8).

The PCB layout is such that I think using components with leads is easier rather than SMD components.

If this sounds like a reasonable plan, I will pull out the servo card from the eurocrate and implement these changes today evening...

Attachment 2: PMCcheckout.pdf
PMCcheckout.pdf
Attachment 3: D980352-A-40m_151119.pdf
D980352-A-40m_151119.pdf
  12917   Wed Mar 29 16:38:00 2017 SteveOmnistructureTreasuresus fiber illluminated
Attachment 1: fiber.jpg
fiber.jpg
  12918   Thu Mar 30 00:16:09 2017 gautamUpdatePSLPSL NPRO PZT calibration

As part of the ongoing effort to try and calibrate the PMC DAQ channels into physical units, I tried to get a calibration for the PSL NPRO PZT actuator gain. In order to do this, I selected "Blank" on the PMC servo MEDM screen such that there was no feedback signal to the PMC PZT for length control. Then I used the summing box right before the  PSL PZT to inject a ~1Hz triangular wave, 4Vpp. This was sufficient to sweep the NPRO frequency over 70MHz such that both sidebands and the carrier go through resonances in the PMC cavity. I then simultaneously monitored the applied triangular wave voltage and the PMC error signal (using the single pin LEMO connector on the front panel) on an oscilloscope. Analysis is underway, but a quick look at one measurement suggests a PZT actuator gain of ~1.44MHz/V, which is close to what we expect for the Innolight NPROs. The idea is to use this calibration to convert the DQ channels into physical units. 

Details + plots + error analysis to follow...

  12919   Thu Mar 30 10:41:56 2017 ranaOmnistructureTreasuresus fiber illluminated

Very, very cool!  yes

  12920   Thu Mar 30 18:11:01 2017 ranaUpdatePSLPMC DAQ assay for feed-forward integration

What you have drawn looks good to me: the cut should be between TP3 and pin3 of the AD620. This should maintain the DC coupled respons for the single-pin LEMO and backplane EPICS monitors.

We want to use the PMC signal down to low frequencies, so the filter on the input of the AD620 should have a low frequency cutoff, but we should take care not to spoil the noise of the AD620 with a high impedance resistor.

It has a noise of 100 nV/rHz and 1 pA/rHz at 1 Hz. If you use 47 uF and 10 kOhm, you'll get fc = 1/2/pi/R/C ~ 0.3 Hz so that would be OK. 

  12921   Fri Mar 31 10:16:07 2017 SteveUpdatesafetylaser safety glasses annual inspection

Laser safety glasses cleaned in " Dawn Ultra " mild soap - water solution and measured for 1064 nm transmission at 150 mW
 

Attachment 1: march2017.jpg
march2017.jpg
Attachment 2: 2017march.jpg
2017march.jpg
  12922   Fri Mar 31 16:10:33 2017 SteveUpdateTreasureLes Guthman

Les Guthman interviews  gradstudent Graig.

Main laser emergency shut off was acuated by accident during this fiming. The laser is turned on.

  12923   Sun Apr 2 23:14:30 2017 ranaUpdateComputer Scripts / Programsnodus update/upgrade/reboot

I just did remote apt-get update, apt-get upgrade, and then reboot on nodus. ELOG started up by itself.

  12924   Mon Apr 3 17:09:47 2017 gautamUpdateCDSC1PSL burt-restored

When I came in this morning, Steve had re-locked the PMC and IMC - but I could see a ~1Hz intensity fluctuation on the PMC REFL video monitor. I unlocked the PMC and tried to re-lock it, but couldn't using the usual prescription of turning the servo gain down and moving the DC bias slider around. I checked the status of the slow machines - all were responding to pings and could be telnet'ed into, so that didn't seem to be the problem. In the past, this sort of behaviour was characteristic of the infamous "sticky slider" problem - so I simply burt-restored c1psl using a snapshot from 29 March, after which I could easily re-lock the PMC. The transmitted light level looked normal on the scope on the PSL table, and the PMC REFL video monitor also look normal now.

  12925   Mon Apr 3 17:25:13 2017 gautamUpdatePSLPSL NPRO PZT calibration

Summary:

By sweeping the laser frequency and looking at the PMC PDH error signal, I have determined the 2W Mephisto Innolight PZT actuator gain to be 1.47 +/- 0.04 MHz/V

Method:

  1. Re-aligned the input beam into the PMC to maximize transmission level on the oscilloscope on the PSL table to 0.73V.
  2. Disabled control signal from IMC servo to PSL. 
  3. Unlocked the PMC and disabled the loop by selecting "BLANK" on the PMC MEDM screen.
  4. Connected a 0.381 Hz 5Vpp triangular wave with SR function generator to the "SUM" input of the Fast I/F box just before the PSL PZT input. These params were chosen considering the Pomona box just before the NPRO has a corner at 2.9Hz, and also to sweep the voltage to the NPRO PZT over the full 150V permitted by the Thorlabs HV amplifier unit. Monitored the voltage to the Thorlabs HV amp from the "AFTER SUM" monitor point on the same box. Monitored the PMC PDH error signal using the single-pin LEMO monitor point on the PMC servo board (call this Vmon). Both of these signals were monitored using a Tektronix digital O'scope.
  5. Downloaded the data using ethernet.
  6. Fit a line to the voltage applied to the NPRO PZT - I assumed the actual voltage being applied to the PZT is 15*Vmon, the pre-factor being what the Thorlabs HV amplifier outputs. The zero crossings of the sideband resonances in the PDH error signal are separated by 2*fmod (separated by fmod from the carrier resonance, fmod = 35.5MHz assumed). With this information, the x-axis of the sweeps can be converted to Hz, from which we get the PZT actuator gain in MHz/V. 

An example of the data used to calculate the actuator gain (left), and the spread of the calculated actuator gain (right - error bars calculated assuming 5e-4 s uncertainty in the sideband zero-crossing interval, and using the error in the slope of the linear fit to the sweep voltage):

This will now allow calibration of the PMC DAQ channels into Hz.

GV 4 April - The y-axis of the lower plot in Attachment #1 has mis-labelled units. It should be [V], not [MHz/V].

Attachment 1: PDHerr.pdf
PDHerr.pdf
Attachment 2: NPROcalib.pdf
NPROcalib.pdf
  12926   Mon Apr 3 23:07:09 2017 gautamUpdatePSLPMC DAQ assay for feed-forward integration

I made some changes to the DAQ path on the PMC servo board, as per the plan posted earlier in this thread. Summary of changes:

  1. AC coupling PMC control signal path using 2 x 47uF metal film capacitors (in parallel)
  2. Grounding pin 5 of U15
  3. Adding gain to U14 (gain of ~500) and U15 (gain of ~50)

Details + photos + calibration of DAQ channels to follow. The PMC and IMC both seem to remain stably locked after this work.

  12927   Tue Apr 4 11:24:21 2017 SteveUpdatesafetyProjector bulb is out again

Shipped out for repair.

Quote:

Three replacement bulbs ordered

Rana can discribe how it happened.

IF A LAMP EXPLODES

If a lamp explodes, the gas and broken shards may scatter inside the projector and they may comeout of the exhaust vent.
The gas contains toxic mercury.
Open windows and doors for ventilation.
If you inhale the gas or the shardsof the broken lamp enter your eyes or mouth, consult the doctorimmediately.
Quote:

This bulb was blown out on Feb 4, 2017 after 2 months of operation.

 

 

It is back and running fine witth bulb  4-13-2017

  12928   Tue Apr 4 17:27:58 2017 ranaUpdatePSLPSL NPRO PZT calibration

good cal. I wonder if this data also gives us a good measurement of the cavity pole or if the photo-thermal self-locking effect ruins it. You should look at the data for the positive sweeps and negative sweeps and see if they give the same answer for the cavity poles. Also, maybe we can estimate the PMC cavity pole using the sidebands as well as the carrier and see if they give the same answer? 

  12929   Wed Apr 5 16:05:47 2017 gautamUpdateGeneralNB code checkout

[evan, gautam]

We spent some time trying to get the noise-budgeting code running today. I guess eventually we want this to be usable on the workstations so we cloned the git repo into /ligo/svncommon. The main objective was to see if we had all the dependencies for getting this code running already installed. The way Evan has set the code up is with a bunch of dictionaries for each of the noise curves we are interested in - so we just commented out everything that required real IFO data. We also commented out all the gwpy stuff, since (if I remember right) we want to be using nds2 to get the data. 

Running the code with just the gwinc curves produces the plots it is supposed to, so it looks like we have all the dependencies required. It now remains to integrate actual IFO data, I will try and set up the infrastructure for this using the archived frame data from the 2016 DRFPMI locks..

  12930   Thu Apr 6 15:35:44 2017 SteveUpdatePEM envioirmental noise

Building:         Central Engineering Services

     

Date:             Monday, 04/10/17          

          

Time:             7:00 AM TO 9:00 AM           

 

Notification:     Crane Activity

    

Contact:          Ben Smith, X-4190 Brad Nielsen, X-8751

 

Contractors will be removing the large vaporizer located on the South

side of CES. Vehicle access will be restricted due to crane placement

and operation, but there will be a single traffic lane available. This

work may create minor noise and vibrations.  

  12931   Fri Apr 7 13:46:23 2017 SteveUpdateSUSETMX enclosure feedthough

ETMX enclosure feedtrouh cabeling corrected.

Attachment 1: bad.jpg
bad.jpg
Attachment 2: good.jpg
good.jpg
  12932   Mon Apr 10 09:49:32 2017 SteveUpdateOptical Leversoplev laser RIN test planning

We are planning to test 3 identical 1103Ps RIN with  continous temp monitoring and control later.

Selected  temp sensor   Platinum RTD 1PT100KN1515CLA   or           RTD-830 

Temp controller  with analoge output 0-10Vdc, CNi854  and external dc pulse driven  relay

Temperature Measurement Comparison Chart
Criteria Thermocouple RTD Thermistor
Temp Range -267°C to 2316°C -240°C to 649°C -100°C to 500°C
Accuracy Good Best Good
Linearity Better Best Good
Sensitivity Good Better Best
Cost Best Good Better

Order placed 4-12-17 for sensor  RTD-830,  controller CNi8-5-4 and relay  SSRL240DC25 = ~$500.

Still need: fuse, fuse housing, on/off switch, female  AC receptical, chassy box and AC power cord.

 

  12933   Mon Apr 10 09:58:35 2017 SteveSummarySUSoplev laser summary updated

 

Quote:

                    Oct.  5, 2015              ETMY He/Ne replaced by 1103P, sr P919645,  made Dec 2014, after 2 years

                   Jan. 24, 2017              ETMY He/Ne replaced by 1103P,  sr P947049,  made Apr 2016,  after 477 hrs running hot

    Jan. 26,  2017              RIN test stared with P947034, made Apr. 2016  

    Apr.  10,  2017              purchased two 1103P from Edmund:  sr P964438 & sr P964431, made 02/2017

   

  12934   Mon Apr 10 14:21:57 2017 ranaUpdateOptical Leversoplev laser RIN test planning

I'm suspicious of this temperature sensor comparison. Usually, what they mean by accuracy is not the same as what we mean. I would not buy these yet. How about we just use what Caryn used several years ago (elog search) ?

  PS  Steve LM34             

  12935   Mon Apr 10 15:22:46 2017 ranaConfigurationWikiDokuWikis are back up

AIC Wiki updated to latest stable version of DokuWiki: 2017-02-19b "Frusterick Manners" + CAPTCHA + Upgrade + Gallery PlugIns

  12936   Mon Apr 10 15:37:11 2017 gautamUpdateCOCRC folding mirrors - v3 of specs uploaded

Koji and I have been going over these calculations again before we send a list of revised requirements to Ramin. I've uploaded v3 of the specs to the DCC page. Here is a summary of important changes.

  1. Change in RoC specification - I condensed the mode-matching information previously in 8 plots into the following 2 plots. Between tangential and saggital planes, the harmonic mean was taken. Between X and Y cavities, the arithmetic mean was taken. Considering the information in the following plots, we decided to change the spec RoC from 600 +/- 50m to 1000 +/- 150m. The required sensitivity in sag measurement is similar to the previous case, so I think this should be feasible.

    Why this change? From the phase map information at  /users/public_html/40m_phasemap/40m_TTI gather that we have 2 G&H mirrors, one with curvature ~ -700m and the other with curvature ~ -500m. An elog search suggests that the installed PR2 has RoC ~ -700m, so this choice of RoC for PR3 should give us the best chance of achieving optimal modematching between the RCs and arms as per the plots below.

  2. Cavity stability checks - these plots confirm that the cavity remains stable for this choice of RoC on PR3...
      
  3. Coating design - I've been playing around with the code and my understanding of the situation is as follows. to really hit low AR of 10s of ppms, we need many dielectric layer pairs. But by adding more pairs, we essentially become more susceptible to errors in layer thickness etc, so that even though the code may tell us we can achieve R_AR(532nm) < 50ppm, the minima is pretty sharp so even small perturbations can lead to much higher R of the order of a few percent. On the HR side, we need a large number of layer pairs to achieve T_HR(1064nm)=50ppm. Anyways, the MC studies suggest that for the HR coating design, with 19 layer pairs, we can be fairly certain of T_HR(1064nm)<100ppm and R_HR(532nm)>97% for both polarizations, which seems reasonable. In order to make the R_HR(532nm) less susceptible to errors, we need to reduce the number of layer pairs, but then it becomes difficult to achieve the 50ppm T_HR(1064nm) requirement. Now, I tried using very few layer pairs on the AR side - the best result seems to be with 3 layer pairs, for which we get R_AR(532nm)<1% and T_AR(1064nm)>95%, both numbers seem reasonable to me. In the spectral reflectivity, we also see that the minima are much broader than with large number of layer pairs.

    First row below is for the HR side, second row is for the AR side. For the MC studies, I perturbed the layer thicknesses and refractive indices by 1%, and the angle of incidence by 5%.
        
       

If there are no objections, I would like to send this version of the specs to Ramin and get his feedback. Specifically, I have assumed values for the refractive indices of SiOand Ta2O5 from google, Garilynn tells me that we should get these values from Ramin. Then we can run the code again if necessary, but these MC studies already suggest this coating design is robust to small changes in assumed values of the parameters...

Attachment 1: PRC_modematch.pdf
PRC_modematch.pdf
Attachment 2: SRC_modematch.pdf
SRC_modematch.pdf
Attachment 3: TMS_PRC.pdf
TMS_PRC.pdf
Attachment 4: TMS_SRC.pdf
TMS_SRC.pdf
Attachment 5: PR3_HR_spectralRefl.pdf
PR3_HR_spectralRefl.pdf
Attachment 6: PR3_HR_MC_CDF_revised.pdf
PR3_HR_MC_CDF_revised.pdf
Attachment 7: PR3_AR_spectralRefl_new.pdf
PR3_AR_spectralRefl_new.pdf
Attachment 8: PR3_AR_MC_CDF_new.pdf
PR3_AR_MC_CDF_new.pdf
  12937   Mon Apr 10 16:00:26 2017 rebeccaUpdateCamerasPylon installation warning

When trying to install an older version of Pylon packaged for Debian that Joe B. had sent, it gave the warning that the package was of bad quality along with the details below.

Is it safe to ignore the warning? Or should I hold off on the installation?

Lintian check results for /home/controls/Downloads/pylon-2.3.3-1.deb:
Use of uninitialized value $ENV{"HOME"} in concatenation (.) or string at /usr/bin/lintian line 108.
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.IpConfigurator
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.PylonViewerApp
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.SpeedOMeter
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3.2
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3.7.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/plugins/imageformats/libqtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libXMLLoader_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApiPreProcessor
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGCBase_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGenApi_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libLog_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libMathParser_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/liblog4cpp_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige.so

ELOG V3.1.3-