Decided to try adding in an OP amp just to see if it would work. Added LT1012 and a 100k resistor to the circuit (I originally wanted to do AD743 as it seems to be the best choice according to Zach's elog here, but it said that they are very precious so I went with LT1012 for testing purposes). When heating it with a heating gun, the output voltage went down by a few 0.01V. The maximum voltage was 0.686V. Similar thing happened when I switched to a 10k resistor, where the maximum was 0.705V and it also went down by a few 0.01V upon heating.
I've attached a few pictures showing the circuit.
I didn't realize that the LT1012 needed an additional input to function. I added in +15V and -15V to pins 7 and 4, respectively and placed a 10k resistor and the numbers make more sense now. The voltage showed a negative value, but it became more negative as I heated it up (it's negative due to how a transimpedance amplifier works).
I have attached the new setup and the value it shows (~-3V). It became more negative by about 0.4V, which translates to about a 40K increase in temperature, which makes sense.
In addition, I have attached an updated sketch of the circuit. I will need to do more testing to determine how accurate this is. The next step would be to calculate how much noise there is currently and figure out how to remove this circuit from the breadboard and use a PCB or something like that for final testing in an insulated container.
The reason I chose AD743 initially for the OP amp is because at low frequencies (which is what we are working with), a FET amp such as AD743 will have a low current noise at high impedance, which is what we have in this case. While a FET amp has high voltage noise compared to other OP amps, the current noise becomes more important at high impedance, so it will work better. According to Zach's graphs, the AD743 is best at high impedances, followed by LT1012.
Tested to make sure that even when only the AD586 was heated that there was no change in the reading. I did so by placing the AD586 away from the rest of the circuit and blowing hot air only on it. There was, in fact, no change.
I fixed the temperature control of the oven for the PSL doubling crystal.
The PID settings were not good, and also, TC200 was beging DETUNED. So, I activated TUNE function and adjusted PID settings.
I'm not sure what the DETUNE function is for. The manual can be found here;
Current settings for Thorlabs TC200 are (Red ones are what I changed from the previous setting);
Green glass for aLIGO OMC shield is temporarly stored in the inside of the Y-arm.
The drill room floor will be retiled Thursday, June 16. Temporary nitrogen line set up will allow emptying the hole area.
Ifo room entry will be through control room.
This is a connection diagram for the input PZTs (i.e. PZT1 and PZT2).
As drawn in the diagram, the signals don't go through the anti-imaging filter D000186 in the current configuration.
Just FYI I'm running a test of updated daqd code on fb1.
fb1 has it's own fiber to the daq network switch, so nothing had to be modified to do this test. This *should* not affect anything in the rest of the system, but as we all know these are famous last words.... If something is going haywire, and you can't get in touch with me and can't figure what else to do, you can just log on to fb1 and shut it down. It's not writing any data to any of the network filesystems.
The daqd code under test is from the latest advLigoRTS 3.2.1 tag, which has daqd stability fixes that will hopefully address the problems we were seeing last time I tried this upgrade. We'll see...
I'm going to let it run over the weekend, and will check in periodically.
I'm not sure if this is related, but since today morning, I've noticed that the data concentrator errors have returned. Looking at daqd.log, there is a 1 second timing mismatch error that is being generated. Usually, manually running ntpdate on the front ends fixes this problem, but it did not work today.
If this problem started before ~4pm on Friday then it's probably unrelated, since I didn't start any of these tests until after that. If unexplained problem persist then we can try shutting of the fb1 daqd and see if that helps.
The centos 5.5 compiled gds code is currently living on rosalba in the /opt/app directory (this is local to Rosalba only). It has not been fully compiled properly yet. It is still missing ezcaread/write/ and so forth. Once we have a fully working code, we'll propagate it to the correct directories on linux1.
So to have a working dtt session with the new front ends, log into rosalba, go to opt/apps/, and source gds-env.bash in /opt/apps (you need to be in bash for this to work, Alex has not made a tcsh environment script yet). This will let get testpoints and be able to make transfer function measurements, for example
Also, to build the latest awgtpman, got to fb, go to /opt/rtcds/caltech/c1/core/advLigoRTS/src/gds, and type make. This has been done and mentioned just as reference.
The awgtpman along with the front end models should startup automatically on reboot of c1sus (courtesy of the /etc/rc.local file).
Alex tooked at the channel definitions (can be seen in tpchn_C1.par), and noticed the rmid was 0.
However, we had set in testpoint.par the tst system to C-node1 instead of C-node0. The final number inf that and the rmid need to be equal. We have changed this, and the test points appear to be working now.
However, the confusing part is in the tst model, the gds_node_id is set to 1. Apparently, the model starts counting at 1, while the code starts counting at 0, so when you edit the testpoint.par file by hand, you have to subtract one from whatever you set in the model.
In other news, Alex pointed me at a CDS_PARTS.mdl, filters, "IIR FM with controls". Its a light green module with 2 inputs and 2 outputs. While the 2nd set of input and outputs look like they connect to ground, they should be iterpreted by the RCG to do the right thing (although Alex wasn't positive it works, it worth trying it and seeing if the 2nd output corresponds to a usable filter on/off switch to connect to the binary I/O to control analog DW. However, I'm not sure it has the sophistication to wait for a zero crossing or anything like that - at the moment, it just looks like a simple on/off switch based on what filters are on/off.
I have attached the setup I completed today. The metal box contains the heater circuit and the board for the temperature sensor is right above it. This is basically the same setup as before, but I've just packaged everything up neater. I expect to be able to perform the test tomorrow and begin implementing PID control. I still need a DAC input for the heater circuit and the temperature sensor is having some issues as well.
The MOSFET was getting pretty hot, so I switched it out to a larger heat sink and it's fine now. I then used a function generator in place of the DAC to provide ~3.5V. I got the current in the circuit to 1.7A, which is as expected, since we have 24V input, the heater resistance is 12.5ohm and the resistor we are using is 1ohm, so 24V/(12.5+1)ohm = 1.7A. The temperature inside the can rose about 5 degrees in half an hour. The only issue now is the voltage regulators and OP amp inside the box get hot, though it doesn't seem to be dangerous. I switched the function generator input to a DAC and Gautam set it to 1.5V. If it works, then we'll leave this on overnight and work on the PID control tomorrow. I've attached images of the current heater circuit box when it is open and the new heat sink for the MOSFET.
gautam: we also tried incorporating the EPICS channels from the Acromag into the RTCDS so that we can implement PID control by using Foton. I tried doing this using the "EpicsIn" and "EpicsOut" blocks from CDS_PARTS. While the model recompiled smoothly, I saw no signals in the filter module i had connected in series with the EpicsIn block. So I just reverted c1pem to its original state and recompiled the model. Guess we will stick to python script PID reading EPICS channels to implement the PID servo.
according to the temp sensor readout, which was ~-3.35V which corresponds to ~335K, the temperature of the can is now 60 deg C. This is a bit warm for my liking so i'm turning the heater current down to 0 now by writing 0 to C1:PEM-SEIS_EX_TEMP_CTRL
we don't ever want to use our 16 kHz real time system for such low frequency action; its main purpose is for real-time controls, whereas we are OK with multiple seconds of delay in a thermal loop. The Python PID script is sufficient and highly reliable (after years of testing).
I fit the data that we got from the test. The time constant for the cooling came out to be about 4.5 hours. The error is quite large and we should add a low pass filter to the temperature sensor eventually in order to minimize the noise of the measurements.
I've moved my setup to the actual seismometer. I attached the temperature sensor to the seismometer (attachment 1) with duct tape, though this is temporary. I will be monitoring the temperature fluctuations of the seismometer for a whole day then take the can off and repeat the test. The can isn't clamped down so the insulation isn't perfect, so I'd expect to see some noticeable fluctuations even with the can on. I've also labeled the long cable for the temperatuse sensor readout (attachments 2 and 3). There will also be an out of loop sensor added in later, but for this test since I am not running the loop it doesn't matter which sensor I monitor. Attachment 4 is a picture of the current setup.
Here is the result of my test. I think I'll leave the can on over the weekend because there's a long period of time where the seismometer heated up by 0.8 degrees so I can't fully see the fluctuations over a full 24 hour period.
I guess it's fine for now while we are still finalizing the setup at EX, but we should eventually line up the seismometer axes with the IFO axes. Is there a photo of the orientation of the seismometer pre heater can tests? If not, probably good to make some sort of markings on the granite slab / seismometer to allow easy lining up of these axes...
I have attached the graph for the seismometer temperature fluctuations over 3 days. As we can see, there is a noticeable fluctuation in daily temperature as well as a difference between days in the maximum and minimum temperatures. I will repeat this test but take the can off to see if there's any difference between having the can on or off.
It appears that one of the wires was disconnected overnight or this morning so I wasn't able to gather data over a full 24 hour period. Perhaps someone accidentally kicked it. I placed some cones in that area so hopefully the wires won't be in the way as much and I can get the data tomorrow. From the data I do have it seems that the seismometer is at a colder temperature when the can is not on, though it is difficult to see by how many degrees the temperature fluctuates. I've included the data from 5 days back to see the comparison.
This time the test went without issue. The first attachment is the data for the past 24 hours and the second attachment is the full data over 6 days. The average temperature fluctuations (from highest point to lowest point) for the can on was 0.43 C and for the can off it came out to 0.55 C. In addition the seismometer with the can off is about 1 C cooler than with the can on. I'd like to leave the can off until the end of the week so we can get a comparable data set for both the can on and off. Eventually I'll need to figure out a way to clamp the can down to the block in order to get better insulation and hopefully get even smaller temperature fluctuations.
We found that a transistor was broken from yesterday spark too. We partially fixed TTFSS, and it should be enough for testing purpose.
From yesterday test, we found that the RF amplifier for LO signal was broken. There was no spare at the electronic shop at Downs,
so we shorted the circuit for now. Another part which was broken too was a transistor, Q3 PZT2222A, on D0901846.
It was removed and two connections, which are for Q3's 1 and 3 legs, are shorted. Now the voltages out from the regulators are back to normal.
We are checking a MAX333A switch, U6A on D0901894. it seems that the voltage that controls the switch disappears.
There might be a bad connection somewhere. This will be investigated next.
Q3, a PZT2222A transistor, on D0901846 is replaced by a GE-82. However, the board is still not fully function.
Since Q3, PZT2222A, was broken, I went to Wilson house and got some SP3904's for replacement. But somehow, I broke it during
installation, and did not notice it, and resumed the test. When I got to test 8 on the list, the TTFSS did not work as specified.
Koji checked and found out that -15V, Nref, Vref voltages output did not work correctly. So the SP3904 I installed was removed
and replaced with another SP3904 by Koji, and Vref is working.
Q4 transistor is broken as well and it was replaced by GE 82.
Q1 might be broken too since -15V out is not working.
I'll go to Wilson house to get more transistors next week.
After the broken parts have been replaced, I have to make sure that I separate the power supply board from the rest of the circuit and
check if all V outputs are working, then reconnect the board and check if the current input is reasonable before resume the test.
I hope the wrong input voltage problem today wouldn't damage anything else.
How much current do you need for each voltages?
GE-82 was the only PNP transister I could find in the lab. It's too old but we just like to confirm any other components are still functioning.
Similarly, we can confirm the functionality of the other components by skipping those current boost transisters,
if we don't need more than 30mA.
The testpoint.par file, located at /opt/rtcds/caltech/c1/target/gds/param/testpoint.par, which tells GDS processes where to find the various awgtpman processes, was completely empty. The file was there but was just 0 bytes. Apparently the awgtpman processes themselves also consult this file when starting, which means that none of the awgtpman processes would start.
This file is manipulated in the "install-daq-%" target in the RCG Makefile, ultimately being written with output from the src/epics/util/updateTestpointPar.pl script, which creates a stanza for each front-end model. Rebuilding and installing all of the models properly regenerated this file.
I have no idea what would cause this file to get truncated, but apparently this is not the first time: elog #3999. I'm submitting a bug report with CDS.
There is a small wood cabinet under the south end flow bench, labeled STACIS.
Unit is complete with extension cards and cables.
Yuta, Joonho, and Suresh received the Basic Laser Safety Training from Peter King today.
Now, we got homework.
I turned ON the laser at the X end station, which had been OFF for several weeks because of the crane business.
Now the green beam hits the ITMX and I got a reflection back to the end table.
This green beam will be a nice reference when we install the green periscope in the chamber.
If it's necessary, feel free to correct the alignment of the green beam during my absence.
How to minimize particles entering the vacuum envelope.
Just the way it was in August 2011 vent and before.
The portable HEPAs were set up at ETMY and ITMY with CP STAT 100 curtains.
The 40m particles on the floor at ITMY 3000-5000 counts of 0.5 micron cf / min and 0.3 micron size particles are 55,000 - 65,000 counts cf / min
At this condition the MET One Counter #3 on the floor inside the tent goes to zero count of 0.5 micron and 20-40 counts cf / min for 0.3 micron when the tent is slightly overpressured.
Some more numbers we found while working in/around the chamber today:
These numbers were measured using our particle counter, which has a pump rate of 0.1 cfm, so the numbers above are 10x the numbers shown on the instrument after a measurement to account for this.
Essentially, the chamber is pretty dirty. Peeling the F.C with hard to reach optics like the ITM installed in place is not really feasible, and after peeling the F.C, we are looking at a best case of an additional 1-2 weeks in air to align the IFO, during which the optic is apparently exposed to quite a lot of particulates. In fact, with the high intensity flashlight left on, I actually saw some flecks of dust occassionally floating around inside the chamber while I was working on the optic. But this is just something we have to accept I guess.
Sorry folks! I couldnt get to the elog and didnt know that the elog was crashing every time I tried to access it.
But have found other means to access it and the elog is safe for now!
The IFO room temp is up a bit and it is coming down. The out side temp is not really high.
The temperature is decreasing slowly but is still above 24 C.
The IFO room temp is up
Steve, Rob and Alberto
Starting capacitor 216 miroFarad was installed on the compressor. Water lines were connected to the MOPA as corrected, so the flow meter readings are logical.
Now IN means flowing water in the direction of black arrow on the hose.
We struggled with the Neslab presetting: temp, bauds rate and other unknowns till Rob found the M6000 manual on Peter king's website.
Alberto realized that the chiller temp had to be reset to 20C on water chiller.
I put 1mg of Chloramin T into the water to restrict the growth of algae in the bath.
The NPRO heat sink was around ~20C without flow meter wheel rotation and the PA body ~25C by touch of a finger
I just opened up the needle valve a litle bit so the flow meter wheel would started rotating slowly.
That small glitch at the end of this 3 hrs plot shows this adjustment.
- The tanks are open
[done] - Remove the PZT cable currently underlying between BS and ITMY chambers
[done] - Put this PZT cable between BS and IMC chambers. Connect it on the PZT on the IMC table (SM1)
[done]- Put the two OSEM cables between BS and ITMY chambers. Connect this cable to SRM.
The connector for this cable at the BS side is coming from Bob's place on Wednesday. We left it disconnected for now.
- Energize all of four PZTs and check the functionality.
Five mechcanical traps set inside of boxes. Red-white warning tape on top of each.
Last jump at rack Y2.
I drained the water and removed side covers from the Neslab RTE 140 refrigerated water cooler unit this morning. The hoses to the laser were disconnected.
This abled you to see the little window of refregerant R404A was free of bubles, meaning: no recharge was needed.
The circulator bath was refilled with 7 liters of Arrowhead distilled water and the unit was turned on.
The water temp was kept 20.00+- .05C without any load. Finally the AC-repair man Paul showed up.
He measured the R404A level to be as specified: 23-24 PSI on the suction side and 310 PSI on the discharge side.
The unit was working fine. Paul found an intermittently functioning starting capacitor on the compressor that was removed.
The 240 micro Farad 120VAC cap will arrive tomorrow