Here is a summary of the cryocooler discussion hosted at JPL.
Dave Glaister of Ball Aerospace presented on their low-vibration cryocooler assemblies (CCAs). A summary of their work can be found in this paper. Ball has their own cryocooler vibration testing setup that they use to assess/characterize their platforms. They did not show frequency-dependent vibration noise with/without their assemblies, but they advertized up to 50x reduction in noise at 50-60 Hz. The paper above does show a spectrum of sorts (unknown units) but it does not display data below 50 Hz. Notably, they have experience in augmenting the Sunpower DS-30 cooler which meets the Mariner cooling requirements (though their CCAs should be cooler-agnostic).
Notes from their meeting:
- Fanciest Sunpower DS-30 CCA (with all the bells+whistles): $2 million; 12-24 month lead time. Results in few mN of vibration.
- Yukon Soft Ride CCA for Sunpower DS-30 - lowest cost; in the $100,000 range if they use cheaper electronics.
-vibration attenuation 8x
- They suggested the option of circulating gas instead of a cryocooler for our needs: helium gas lines; keep compressor outside IFO to eliminate almost all vibration.
The Yukon CCA seems to be a reasonable baseline to discuss with them. They can customize to our needs. We should ask them to provide us with vibration measurements of the DS-30 cooler with and without their Yukon CCA down to 1 Hz.
Here is the code to generate a random list of parameters and evaluate the energy ratio of each.
L = rand(100) * 200 + 10;
d = rand(100) * 10 + 0.3;
h = rand(100) * 5 + 0.1;
y = zeros(300);
for i = 1:1:length(L)
model.param.set('base_height', append(num2str(h(i)), '[mm]'));
model.param.set('length', append(num2str(L(i)), '[mm]'));
model.param.set('base_width', append(num2str(d(i)), '[mm]'));
I am trying to get a plot of the fminsearch data, but I was not sure how to extract the data. But fminsearch has built in plots that I think capture the data pretty well.
Restricting the search to nothing less than the initial parameters (L = 2 cm, h = 0.3 mm, d = 0.55 mm), fminsearch outputs L = 2.0088 cm, h = 0.3000 mm, d = 0.5776 mm.
With the search restricted to L >= 1 cm, h >= 0.1 mm, and d >= 0.5 mm, fminsearch outpus L = 1.0313 cm, h = 0.1000 mm, and d = 0.5033 mm.
The code works now. If the function is specified by a file, there should be an @ symbol front of it when it is passed into fminsearch.
I am trying to use fminsearch to find the best cantilever dimensions to maximize the bond/cantilever energy ratio. Fminsearch takes in a function and a set of intial parameters. The function that is passed in should be a function of the parameters, but my getEnergy function does not work unless the COMSOL model is passed in as an argument. I tried to make a helper function, but I run into the same problem.
After running getRatio (attempted helper function):
The COMSOL model is now accessible using the variable 'model'
Unrecognized function or variable 'model'.
Error in getRatio (line 3)
ratio = getEnergy(model, L, h, d)
The COMSOL model is now accessible using the variable 'model'
Unrecognized function or variable 'model'.
Error in getRatio (line 3)
ratio = getEnergy(model, L, h, d)
The COMSOL model is now accessible using the variable 'model'
Unrecognized function or variable 'model'.
Error in getRatio (line 3)
ratio = getEnergy(model, L, h, d)
function ratio = getEnergy(model, L, h, d)
model.param.set('base_width', append(num2str(d), '[mm]'));
model.param.set('base_height', append(num2str(h), '[mm]'));
model.param.set('length', append(num2str(L), '[cm]'));
data = model.result.numerical('int1').getReal;
bondenergy = model.result.numerical('int2').getReal;
min = data(3)/bondenergy(1);
for i = 1:1:6
if data(i*3)/bondenergy(i) < min
function ratio = getRatio(L, h, d)
ratio = getEnergy(model, L, h, d)
x0 = [2, 0.3, 0.55];
x = fminsearch(getEnergy, x0)
Here is the model including an additional LN2 tank aiding in inner shield cooldown, applied to Voyager [Attachment 1]. The same assumptions have been made as in the previous ELOG. The LN2 is switched off once the inner shield reaches 90K.
Using LN2 in such a way cools down the test mass to 123K 5 hours faster. This is a ~6% improvement from the original 85 hours of cooldown [Attachment 2]. Note that the fundamental radiative cooling limit for a Voyager-like test mass is ~68 hours.
I am trying to design a cantilever setup to find the quality factor of optically bonded silicon. The cantilever will be given an impulse, and the ring down will be measured. In order to determine the Q of the bond, the relative energy contributions from each part of the cantilever must be analyzed. The primary energy contribution should come from the bond.
The below equations come from https://roymech.org/Useful_Tables/Beams/Strain_Energy.html. I believe the relevant ones are the bending and traverse shear energies.
c = distance from neutral axis to outer fibre(m)
E = Young's Modulus (N/m2)
F = Axial Force (N)
G = Modulus of Rigidity (N/m2)(m)
I = Moment of Inertia (m4)(m)
l = length (m)
M = moment (Nm)
V = Traverse Shear force Force (N)
x = distance from along beam (m)
z = distance from neutral (m)
γ = Angular strain = δ/l
δ = deflection (m)
τ = shear stress (N/m2)
τ max = Max shear stress (N/m2)
θ = Deflection (radians)
The young’s modulus (E) of silicon is 130 to 188 GPa from a quick google search. The shear modulus (G) is 50 – 80 GPa. The calculation is easier when using a rectangular beam. In that case, (U traverse) / (U bending) ~ 1.2 * V^2/(50 * bh * M^2) * (bh^3/12 * 188) = (.376 to .16) * (V^2)(h^2)/(M^2) where M depends on the distance from the applied force.
For a circular beam, height is swapped out for diameter, K is 1.11, and I = pi/64 d^4. (U traverse) / (U bending) ~ (.26 to .11) * (V^2)(d^2)/(M^2), which means (U bending) / (U traverse) ~ (3.8 to 9) * (M^2)/((V^2)(d^2)).
However, for a cantilever beam with the bond on the neutral axis, the maximum shear energy would be at the bond. For gentle nodal suspension, the maximum bending energy would be at the top and bottom.
I simulated the Mariner cooldown with an additional LN2 tank connected to the main cold strap shared by the cryocooler. LN2 can aid in the initial cooldown from room temperature, and once the inner shield is sufficienly cold the cryocooler can take full control. (The LN2 should not be on the whole time - once the inner shield crosses 77K the LN2 would be contributing heat.) In the model I chose the inner shield temperature of 90K to signal when to turn off the LN2 (any lower and the IS temperature starts to flatten out as it approaches 77K).
The closer the LN2 tank sits towards the chamber/IS (and away from the cold head), the better. This is because the cold head of the cryocooler drops rapidly to ~60K, and the LN2 joint would contribute to heating the cold head. Plus, the cooling of the IS is more efficient if the LN2 source is closer. The model assumes the LN2 tank sits halfway between the coldhead of the cryocooler and the inner shield.
The last assumpion made is that the LN2 tank volume is large enough such that the tip in contact with LN2 remains at 77K.
In Attachment 1, the dashed traces show the cooldown of the cold head, inner shield, and test mass without the additional LN2 cooling. The solid traces include LN2 cooling and use the assumptions above in green. We see that the inner shield is cooled significantly faster with LN2 (on par with the cold head until 150K). As a result, the heat load the inner shield puts on the cold head is reduced, and that reduction more than compensates for the additional heating on the cold head from the LN2 at 77K. Thus the cold head cools much faster in the first 10 hours. The kinks in the cold head/inner shield traces are presumably from the system re-equilibriating after the LN2 source is shut off - it's not clear why the cryocooler doesn't immediately continue the downward trend.
The effect on the test mass is more subtle, but we see the test mass cools to 123K ~2 hours faster (in 28 h). I was then curious if we could get the same gains by simply moving the cryocooler/cold head halfway closer to the inner shield. This simulation is in Attachment 2 - it takes ~1 h longer for the test mass to reach 123K, since we don't get the added cooling power from the LN2.
While there's merit to the additon of LN2, maybe an improvement of a few hours isn't enough to justify the increase in complexity.
Summarizing the current Mariner ITM cooldown model assumptions:
- Inner shield and outer shield have snouts of equal length (1 m end-to-end)
- Laser off during cooldown
- Inner shield cooled by DS30; outer shield cooled by LN2 tank
- ITM barrel emissivity = 0.9
A simplified block diagram can be found in Attachment 4.
Here we lay out the Mariner cryocooler requirements and discuss the most recent cooldown model, which includes a cryocooler that cools down the inner shield and a separate LN2 dewar that cools the outer shield.
The chosen cryocooler must supply at least 2x the cooling power to the TM than the heat loads on the TM, at 123 K. Implicit in this requirement is that in the absense of temperature control, the cooling power must be enough to cool the TM to well below 123 K.
Attachment 1 is the latest Mariner ITM cooldown model. This updated model is pushed to mariner40/CryoEngineering/MarinerCooldownEstimation.ipynb. Before running the notebook you can toggle between IS cooling sources: LN2, DS30, CH-104, or in the future any crycoolers we are considering. All attachments are generated using the cooling curve of the DS30.
Since the OS is no longer a heat load on the cryocooler, the IS gets cooled more efficiently and reaches within 5 K of the coldhead. The heat loads on the TM (snout, apertures, laser heating) make its temperature plateau just under 100 K. It reaches 123K in ~50 hours.
Attachment 2 is a power budget for the TM. We see that at 123K, the heat loads sum to ~0.4 W. The cooling power at this temperature is around 1 W. The DS30 satisfies our cryocooler cooling requirement; however vibration requirements / vacuum interface compatibility still need to be determined.
Lastly, Attachment 3 is an updated block diagram of the heat transfer couplings considered by the model. (The model also considers radiative links between the inner shield and cage, and inner shield and upper mass; these are omitted from the diagram for simplicity.)
Previously, we had one Arduino taking the two thermocouple readings and another, separate one controlling the PWM of the hot plate. I have since combined them together, which is better because now only one computer and one set of Arduino code is needed to do all of the work. This also gives us the potential to, in the future, use re-time temperature feedback to control the heating rate.
Everything was a success. The PWM of the hot plate works the same as it did when I was using the other Arduino, and adding the PWM Arduino code to the thermocouple Arduino code has not broken the handshake with the Python code. I plan to play around with the code for bit, and try to see if I can get some real-time temperature feedback working.
I also added fork spade U-type connectors (stud size 10, WIRE18-22 AWG, McMAST 69145L433) to the wires going to the thermocouple, to make them easier to plug into the thermocouple-reading Arduino component (MAX6675). I used a hammer and a little solder to make sure the connectors stay on. To securely attach the connectors to the component, you need to unscrew, insert, and re-screw, which gives a nice, tight connection. Red should be positive and green should be negative, but I need to double check.
Upper limits on the mechanical loss of silicate bonds in a silicon tuning fork oscillatorâ€‹ and
Temperature Dependence of Losses in Mechanical Resonator Fabricated via the Direct Bonding of Silicon Strips
https://link.springer.com/article/10.1134/S1063782620010200 (I don't have access, but I was given a PDF of this paper over the summer)
The arduino was able to read temperature data and send it to a python program that graphed the data.
I made a quick investigation of the crane configuration for the suspension test chamber.
CAML has three types of ceilings.
1) Low ceiling area (west side) the clearance height 75.5"
2) Mid ceiling area (most of the lab area) 85.5". This is limited by the height of the FL light cover.
3) High ceiling area (northeast corner) 105". This is limited by the height of the FL light cover there.
Nominal closed state: The chamber top height is about 68". Even in the low ceiling area, there is 7.5" space and the crane can remove the lid when the chamber is empty.
Open chamber with suspension (direct connection): If the lid and the hook are directly connected, the corner of the chamber is going to be very close to the jib arm when the chamber is fully opened with ~1" clearance. This is not a safe condition, considering that the chamber can oscillate due to the lateral motion associated with raising the jib arm.
Open chamber with suspension (connection via a 3" shackle): When the lid and the hook are connected via a 3" shackle, we'll observe a safe amount of clearance between the chamber and the jib arm. And the crane height is still 96" which is lower than the ceiling height of the high ceiling area of the lab.
Caltech transport came in this morning. They first went to the OMC lab and moved the 3ft x 4ft table out. They lifted the heavy objects only with human power.
Then the suspension chamber was moved with a hydraulic lifter. (Attachment 1)
The chamber bottom was sled on the table. We asked them to leave the chamber lid on the mylar + cardboard sheet (Attachment 2) so that we can carefully close the lid with a crane (Attachment 3).
JC and I continued to work on the chamber closure, but it wasn't so straightforward.
The nominally planned location of the table (seen in Attachment 3) has a low ceiling and was not a great place to open/close the lid. It is high enough just to close the lid but we can't do anything else.
We worked on the crane operation close to the lab entrance (Attachment 4). We found that the chamber needed to be offset from the center of the table because the legs of the hoist turned out to be too wide to get in between the table legs. This low ceiling had ~3" gap to the crane when the lid was closed (Attachment 5). Meaning, we can't put anything in the chamber if the lid gets stuck with the low ceiling.
Anyway, the chamber was closed and the table was rolled to the end of the lab (for storage) (Attachment 6).
BTW, the rolling of the table further destroyed the floor (Attachment 7)
So, how high the ceiling should be, so that we can put a tall suspension in the chamber? We probably need to use the northeast part of the lab where the ceiling is much higher. But the crane itself can be another limitation. It needs careful consideration.
See the attachments.
[JC, Stephen, Paco, Gabriele, Aidan, Radhika, Koji]
We have successfully extracted the crackle suspension from the chamber at the DOPO lab. We ended up using the engine hoist brought from the cryo lab instead of the yellow Skyhook as Skyhook's arm was too short.
Attachment 1 shows how the hoist is inserted to the table and how the lid was lifted. The lid was placed on a cardboard box wrapped with a Mylar sheet. It could be slid on the floor.
Attachment 2 shows how the suspension was lifted and placed on a similar Mylar-wrapped cardboard box. Upon the removal of the suspension, the cables were disconnected from the suspension. A few OSEM wires needed to be cut so that the suspension to be free.
Attachment 3 We are ready for the chamber transportation.
1) Paco cleared the path in the DOPO lab. We'll need a flat dolly or wooden bars (covered with a mylar sheet) to place the lid on it while we will remove the suspension. The suspension will be placed next to the wall and wrapped with mylar sheets.
(from the 40m) a dooly, mylar sheets, spare slings
(from Downs) heavy-duty inline scale
(from OMC lab) some tapes
2) The crane base is in CAML right now.
3) The yellow crane is in QIL right now. We'll dismount the top part and mount it on the base.
- Remove the lid. Place it on a clean safe platform.
- Remove the suspension, wrap it, and place it next the wall.
- Put the lid on.
- The chamber will be moved to CAML on Thu morning.
I was able to get a USB adapter for my computer so I could test my code. The Arduino can read the temperature of the room and output the values with a tenth of a second time delay. Jupyter Notebook recognizes the Arduino and can receive temperature data from it.
I am getting started on building the arduino circuit as well as setting up my computer so I can communicate between jupyter notebook and the arduino. I will need a USB adapter for my computer before I can make much more progress.
The bond quality measurements can be split into two categories: destructive and nondestructive. For destructive, we have measuring tensile and shear strength, and for nondestructive, we have gap distrance and mechanical quality. I am also currently searching for more ways to measure the strenght, but I am having a hard time finding any others.
Proposed method: based off of the traditional razor test, a blade will be systematically inserted into the gap. For a prototype, I used optical bread board components to hold the razor while a knob was slowly turned to push the razor forward. The knob had markings on it, which could be used to estimate the amount of force applied to the gap. The prototype was made for the larger glass slides, so it is too big and forceful for the silicon and smaller, more fragile glass slides. However, the principles of the protoype had potential to be adapated to be gentler.
Proposed method: a cord will be adhered to the outer sides of the sample such that one side will be hung to the ceiling while the other will have weight hanging from it. Weight us added to the latter cord until the bond breaks. This could pontentially be a little dangerous as it could shatter when the bond finally breaks, so a protective barrier of some sort will have to be set up.
Alternative: affix one outer surface to the table so that it cannot move. Attach the other surface to something that can spun/twisted. The more twists it takes to break the bond corresponds to the shear strenght.
Proposed method: use ellipsometry to find how big the gap is between the two bonded surfaces. I think this would be great to combine with one of the destructive methods since, if you could relate the nm thickness of the gap to, say, the tensile strength, then you could estimate the tensile strength of future bonds without having to destroy them. I read a lot about ellipsometry over winter break, and I know what components are needed for it.
Proposed method: this would be based around the paper which measured the ring down of an optically contacted tuning fork. My focus would be on varying the parameters to find the most precise and accurate dimensions of the fork. Although it sounds interesting, I am not sure how practical it would be to pursue as it requires a lot of modeling and building. However, given the application of these measurements (specifically, for Voyager, (if my understanding is correct) the use of optical contacting will resolve the issue of messy noise caused by unpredictable thermal vibration of adhesives), knowing the mechanical quality of the bond seems valuble.
The Arduino / AC PWM interface looks good. I recommend that you maintain the code in GitHub and post a link to the repo whenever you update the code. Use detailed commit messages so that it makes sense.
For the plotting, it would be good if you can use grid lines and markers for the data points. Then we can see the difference between the data and the fits, etc.
And to avoid the hysteresis, etc. you can record the temperature in your Arduino and use feedback to make the heater just go to whatever temperature you specify. So you would have a prescribed T(t) and the PID feedback loop would just make the heater take you there. Can your Arduino read the thermocouple?
Somehow I never thought of this before, but instead of increasing the "on" time of the hot plate to account for the heating drop-off, I should keep that constant and instead decrease the "off" time. That feels more logical given that I am trying to keep the temperature of the two plates as close as possible.
[I'm (once again) behind on data processing, but I'm creating an entry on the day I actually run the tests]
[I'm behind on data processing, but I'm creating an entry on the day I actually run the tests]
To combat the bottom plate heating up much faster than the top plate, I decided to try increasing the cycle period from 1000ms (1s) to 10000ms (10s). In other words, taking the test I today ran as an example, the hot plate will now be on for 1000ms then off for 9000ms then repeat. Hopefully this should give more time for the heat to transfer to the top plate, but even in this short test, it still appears to be a problem.
Due to the slower heating times, this will be a bit more challenging to test as each test could take hours to complete, but this is more in line with the final intended use anyways. Perhaps my cycle of 1000ms on is too much (e.g. I should do 100ms on then 9900ms off, although I think that might be so slow that it will never heat up; this also raising the question as to how I will deal with mantaining this slow heat up at the higher temperatures).
I decided test how fast the plates would heat up if the heat was just on constantly on for 5 minutes. In general, these tests are raising a lot of questions in regards to controlling the temperature given the hysteresis in the system. It is also apparent that the bottom plate heats up signficantly faster than the top one, which means I need to heat the samples much longer than, say 10 minutes, if I want to avoid unevenly heating both parts of the optically contacted piece.
I also have to be conscientious that I am already half way through the quarter and ideally should be devoting time to bond strength testing rather than continuing to fiddle with the hot plate.
With v3.0, I took a couple steps backwards by getting rid of the feature that increases the heating rate so I can isolate the base heating rate for the two plates. In my experience, the best way to figure out how to modify the program is to try a bunch of different target temperatures and heating times and look for correlations. I started with (attempting) to increase the plates by 280°C in 10 minutes.
For a future release, I am thinking of radically (relatively speaking) changing the function parameters: the user only inputs the target heating rate and how long the plates should be heated at this rate. This is to address the hysteresis in this new set-up, which I will elaborate on if I make the change.
I performed the same tests I have been doing prior (+180°C in 10 minutes) but now with the (correctly wired) thermocouples attached to the metal plates. The top plate is thermocouple #1 attached to the Fluke and the bottom plate is thermocouple #2 attached to the TPI (the lime green one).
The base heating rate for the new set up will require some tweaking to the code because the plates heat up much slower, but as I have mentioned previously, I do not think this will require a lot of extra work since I now know the tips and tricks to PWMing the hot plate. The only difficulty might come from the increase in hysteresis (i.e. the plates continue to increase in the temperature long after it turns off). For future tests, I need to remember to continue recording the temperature after program finishes its 10 min cycle.
On the positive, I think this test shows that taking the average of the two thermocouples to find the temperature in the center (where the optically contacted samples are) is a worthwhile endevor, considering how much the top plate lags behind the bottom plate in terms of heating speed.
Since the two devices are giving different temperature readings, I would like to find out if this imprecision is linear (e.g. they are always 3°C off, so I just need to add/subtract 3°C after taking the measurements). If not, some sort of calibration is probably required. I decided to figure this out by running the heating tests I did before, but this time with the plates. This also serves as a test to see how the plates heat up.
Or rather, this is what I would have done, had I not realized that the thermometers were going down as the heat was increaing, meaning I had switched the polarity for both thermocouples. It turns out that this mix-up is a common mistake. I thought that I double checked that red was positive for thermocouples, but it is in fact not:
"red is the usual color for positive charges, whereas the red wire in thermocouple cables typically contains the negative signal. This coloration is ANSI standard for thermocouples, but it is not what most people expect."
I intended to test the new thermocouple set up today, but when I plugged them in, both did not read a temperature. It took me a long time to figure out what went wrong: when installing the K Type thermocouple connector, the wires of the thermocouple need to be pushed in as far in as possible, otherwise the circuit would not be completed. It took a lot of trial and error to figure this out. I first created a test "circuit" with wire and a resistor to make sure that the connector itself was not broken. Then I carefully observed how moving the wires in different places affected the reading.
Once I did carefully reassemble the thermocouples, they worked perfectly, as indicated by the non-zero current. I ran tests with my three thermocouples and two devices to see how precise the temperature reading is. The results are below and pictures of the readings can be found in the zip file. I cannot explain why one of the adhered thermocouples is hotter than the other.
Plate #1 and 2 refers to the two different aluminum plates. T1 and T2 refers to the two ports on the Digital Thermometer 343. It cannot read two thermocouples simultaneously (as far as I can tell); it's so one can be used as a baseline/reference value for the other.
Firstly, last night's heating did not change the contacted surface area greatly, but there is too many factors to speculate as to why that is the case. I leave that for future testing.
I attached the thermocouples by adhering them to the two aluminum plates. I was careful to make sure that the thermocouple was in the dead center of the aluminum plate. The other end of the thermocouples—exposed positive and negative wires—were screwed into the K Type connector so they can be plugged into the thermometer/multimeter. Taking the average between the top and bottom plate will give a more precise estimate of the temperature of the samples.
Now that I have (relatively) good PWM code, I wanted to do my first real test with actual samples. Since everything went smoothly, I will now work on building the original set up for the project, which included attaching thermocouples to two plates so we could precisely measure the heat between them.
As you can see in the pictures below, I am running an Arduino off of my laptop which controls an AC/DC control replay that turns the AC power to the hot plate on and off.
Since I was focusing on the hot plate code and therefore did not need my weights, I decided to leave them on top of my samples for roughly 2 weeks.
It appears that an increased amount of time under pressure does not result in any noticable differences. A slight increase in surface area (SA) in two places, and a slight decrease in SA in another place, but overall no change. Note that "(initally)" in the picture below refers to http://nodus.ligo.caltech.edu:8081/Mariner/89.
I realized that, after changing so much from v2.3 to 6, I should check that my first two tests produce correct results with the latest version. This was good because all three tests turned out to be innaccurate, as they were all short roughly 10°C. However, they were very precise. For all three, the final temperature was 193.15±1.5°C.
The goal of "v2.X test #3" is to heat the hot plate to 200°C over the course of 20 minutes, and with v2.6, I have effectively succeeded. There will likely be more issues once I try, for example, to heat the hot plate to 300°C over the course of 60 minutes, but for now, I want to stick with lower temps and shorter times while I work out the kinks. Now that I understand the difficulties of PWMing a hot plate, adapting the code to combat future issues should be straightforward.
To summarize my code, I control the heating rate by cycling the hot plate's power on and off for some % of 1000ms. In other words, the hot plate is on 300ms then off 700ms then on 300ms etc., where the relation between target heating rate and hot plate on time is based on previously gathered data. This produces a nice, linear(ish) temperature increase up until a certain temperature, at which point it plateaus. In the previous versions, the way I compensated for this was by increasing the on time by 5ms for every cycle after 150°C. This did not work for slower heating rates, so the newer versions changed this by making the 5ms and 150°C varry depending on the target heating rate. The exact value is a linear extrapoliation from previous data. This is imperfect, but I do not think perfection will ever be possible with the current equipent, and I think I have reached something good enough that now I can finally apply it to my optically contacted samples.
Since I have finished this "stage" of work, for completeness, I am including all of the code, data*, and graphs involved so far.
*the .txt data files are in the cycle_vX_graphs folders; these folders also have the Jupyter notebooks I used for graphing the data
My two corrections ended up being huge overshoots. The drop off time (100°C) is correct, but the default rate increase that worked in the other cases is not working at all here.
I tried increasing the temperature by 180°C over 20 minutes. As suspected, it did not quite reach the target temperature because the temperature started to drop off around 100°C instead of 150°C, as the program expected. This should be an easy adjustment, since it is just a matter of increasing the duration of the cycle at an earlier time.
Here are the graphed results from yesterday's tests, both by themselves and overlayed with the previous tests. I am satisfied with my code; it has given me the (roughly) linear heat increase that I desired. The only last thing I would like to test is heating over a signficantly slower time.
Before trying the PWM on actual samples, I wanted to make one final attempt at improving my code (labled as v2.1). This change appears to have 1) broken the code regulating the basic heat cycling process 2) caused the hot plate to heat up far, far too quick. Since the thermometer strangely turned off halfway through, I only have two pictures as evidence that this test existed: a screenshot of the Arduino program telling me that the max cycle rate had been reached (which should have not happened) and a frame from the video filming the thermometer showing the peak temperature (which is 100°C high than expected). Somehow the hot plate reached over 300°C, which I thought was impossible because the hot plate's built-in heat cycle should have kicked in around 260°C. Unrelated, but I am performing this test in my dorm room because I was quarentined due to COVID exposure, and I like using my personal fan and the house's freezer to cool down the hot plate quicker.
I made some adjustments (labled as v2.2), and I had the same failure as v2.1, except I managed to capture it on camera.
Finally, with v2.3, I managed to fix all the issues. I ran out time today to transcribe the temperatures for graphing, but this itteration of the code managed to reach 200°C in 10 and 7 minutes for test #1 and #2, respectively. I also managed to fix the problem of the hot plate not turning off after the desired heating time. The real test will be trying a slower heating time, like 20 minutes, but I am glad I postponed using actual samples because this fix has given me code that appears to work exactly as I hoped.
For the following two graphs, I ram four tests: two using the the v1 of the PWM code and two using v2 of the PWM code. The graphs show the heating rate I was aiming for and the actual results. It turns out, my v2 does not work better than my v1. Before 150°C (which is where I believed that (assuming the rate is kept constantly) the heating rate shifted from linear to logarithmic), v1 is an overshoot and v2 is slightly less of an overshoot. The goal of v2 was to increase the rate after 150°C to compensate for this drop off, but it does not appear to have worked.
While I would still like to refine my code, I think it will be good enough to try using it to actually heat the samples.
I had some trouble with the code not working as intended (partially because it has been I while since I coded in C++). However, I was able to run two tests with the new code, although I ran out of time to type up the data for the 2nd. Graphing the 1st test's data, it appears that my improved code is an improvement, but the heating is still slowing down as it approaches 200°C. I need to re-run this test, but with v1 of the code, for better comparison.
The hot plate was supposed to increase 180°C in 10 minutes (so that I would reach 200°C), but due to an inscrutable bug, it did not exit the while loop, so it continued past 10 minutes.
I had a little set back regarding the non-linear portion of the heating. After about 150°C, if the heating rate is kept constant, the heating graph transitions from linear to logarithmic. I was able to show graphically that, yes, it is indeed logarithmic, but I could not think of an algorithmic way to translate this logarithmic curve into the increase in heating rate to maintain a linear heating rate. I do have some ideas which I will test tomorrow.
The previous test was cycled with 0.3s on follwed by 0.7s off*. This test was 0.7s on followed by 0.3s off. I intended to let it run longer, but I accidetly knocked the thermocouple over while trying to move the cable father from the hot plate so the plastic would not risk melting.
Like before, we see that it starts out relatively linear. I noticed the heating light kind of fluttering around 200°C which appeared in the data as a small decrease around 450s on the graph. I do not know the source of this issue, but I fear it may be the hot plate overriding my cycling with its own built-in cycle; something left for future testing. This is the last data I will gather using v1 of my Arduino code, as am I now working on implementing what I have learned in a smarter v2 of the code. I included v1 of the code, and the txt files for the first three tests.
*I think. Could have been 0.1 on, 0.9 off. Note to self: double check this.
I repeated the first test, but let the hot plate run longer. It revealed that the linearity for the lower temperatures completely falls apart at the higher temperatures. I think it should be fairly straightforward to modify the code to accommodate this.
I wrote a program to control the heating rate of the hot plate using Pulse Width Modulation (PWM), and it was a great success!
For roughly 6 minutes, the hot plate was power cycled with a rate of 100 ms on followed by 900 ms off. Based on my calculations, this should correspond to a 0.08°C/sec temperature increase. In other terms, we expect a 24°C increase in the span of 5 minutes. For comparision, without PWM, the hot plate heats up roughly 100°C in that same timespan. I recorded the temperature by filming a thermometer and transcribing that video into a text file, which could be analyzed and graphed. I only transcribed the first 5 minutes of the 17 minute video (I also filmed part of the cool down) because 5 minutes was enough to show clear results.
At t=0, the hot plate was 21.4°C, and at t=300, the hot plate was 49.7°C. That is a 28.3°C increase in the span of 5 minutes, only 4.3°C higher than the predicted value. The rate, 0.094°C/sec, is only slightly faster than the desired 0.08°C/sec. Further, as shown in the graph, the temperature increase was almost perfectly linear, which is ideal. Overall, using an Arduino to PWM the hot plate is looking very promising.
I was unable to check the samples because I could not get access to Bridge, so they will be checked tomorrow and the results will be added as an edit to this log.
Given that I was unable to do work in the lab, I instead began a second attempt at writing code for the Arduino to use PWM to control the hot plate temperature.
As expected, the suface area of the bond only increased for the samples under the weights. I did notice something worrying: one of the non-weighted samples actually had its surface area decrease. It is unclear if this is a one-time thing or if all of the bonds deteriorate with time. Unrelated, but I also noticed that the bonded areas always have small dots that refuse to bond. It's unclear if that is due to imperfections or contamination (I suspect the latter).
I left all 4 samples under both weights out of curiosity to see if the bonded surface area would increase further (or possibly decrese further).
Before jumping to conclusions based on my previous results, I wanted to check that it was indeed heat and pressure, not time, that led to the bonds improving.
I prepared 4 samples, all with my standard pressing technique (which still leaves room for improvement). 2 samples will simply be left to sit undisturbed, and the other 2 will be left under both (rectangular and cylindrical) weights. I will check these in roughly 24 hours, just like the last test.
The 2 slides on the right are the ones under the weights.
These are the results from the previous log.
At long last, there was an improvement with pressure and heat! Pressure without heat and pressure with heat both showed a small improvement. Although the improvement was not major, it does show that pursuing this method of adding weight and heat are viable. Since this was a test, I put less weight on and heated it fast than intended, but now I feel confident to add more weight and slower/greater amounts of heat.