I have identified graphing errata that happens at certain stages. Occasionally, the graph will reset and revert back to the Kelvin temperature scale. If the temperature units have been changed prior to that event, the graph will draw the correct temperature but at the wrong unit scale.
At this point, this seems to be the graphing library crashing and resetting. It is too early to tell if that's the case for certain, though.
The temperature process indicators were not calculating correctly when temperature units were changed. This has been corrected so the process indicators remain consisted through temperature conversions.
Pressure indicators were also corrected.
I implemented the Antoine formula to calculate saturated vapor pressure at temperatures between the LGS Triple point and the critical point.
After the boiling test, I decided to up the ante. The ultimate test of a vacuum pump for a freeze dryer is to prove it can reach the triple point of water.
To prove this, I made some ice water. Ice water will reach a temperature of 32 degrees F (0 degrees C.) If I can draw a hard enough vacuum on ice water to make it boil at 32F, I can reasonably assume the vacuum pump can reach the triple point.
I was able to boil ice water in my home lab using a 2-stage oil-diffusion vacuum pump.
A few things to keep in mind during this experiment:
The boiling of ice water will not be as vigorous as you might expect. That is because at that vacuum level, it takes very little water vapor to raise the pressure above the triple point. You will likely just see a simmer.
The triple point, while reached, does NOT indicate the vacuum pump cannot go lower in pressure. The boiling of the water continuously replaces evacuated water vapor from the chamber. Essentially, the pressure will not go lower than the pressure that causes the water to boil until all of the water is gone.
I was able to boil water at 70 degrees F today. This is the first test to see if the pump can reach appropriate levels of vacuum.
Once a few bubbles rose to the top, the water broke into a vigorous boil within seconds.
It is important to note that the chamber pressure will not go lower than the pressure required to boil the water. The boiling of the water replaces water vapor being evacuated form the chamber.
I started testing the vacuum pump to see if it could draw down lower than previous tests.
I was only able to draw about 25 inHg in previous tests. So today, I started tracking down issues with the vacuum system.
What I found was encouraging. See, to be used in a freeze dryer, the pump has to draw down to 600 Pa or lower. A rough calculation tells us the pump will need to draw down to less than 29.2 inHg.
Sealing hoses and fittings for vacuum use can be a challenge. A leak does not manifest itself as a drip, for instance. It cannot be observed from outside. Basically, everything is backwards.
I found the vacuum canister had a design flaw in its fitting port. I fixed that flaw. It took some doing, but the seal is now reliable and vacuum tight.
I fixed a few hose leaks and a leaky valve packing.
Sealing most vacuum leaks can be performed like any other leak. The difficult part is finding the leak.
I used Vacuum Grease to seal threads and hose fittings. It is designed to do just that.
I was eventually able to draw down to the limit of the gauge on the vacuum canister. But it is way better than it was in previous test. I will have to hook the vacuum sensor up to the canister to get a more accurate reading.
I am going to develop the water-state library in two stages. I have decided to abandon the complex state for now. It is taking more time than I want to spend right now. I will only focus on the simple-state aspects so the library doesn't delay the FreezeDryer project any more.
At first, this seemed pretty simple. After a few days working on it, it has become more complex. The scope of the library has creeped a bit. Since I was finding myself writing a lot of code to do this, I decided to expand the scope to include scientific measurements.
The library has 2 modes: a simple mode and a complex mode. While in simple mode, it will return a simple answer in terms of SOLID, LIQUID, or GAS.
While in complex mode, it will return all known states of water including Ice I, Ice II, Ice III, Ice IV, Ice V, Ice VI, Ice VII, Ice VIII, Ice IX, Ice X, Ice XI, Ice XII, Ice XIII, Ice XIV, Ice XV, GAS, LIQUID, SUPER CRITICAL, SUBCRITICAL GAS, SUBCRITICAL LIQUID.
Additionally, the library will return hits on all triple points and phase lines appropriately.
You simply give it a temperature and pressure and the library will tell you what phase the water is in.
I currently have about 1/3 of the state-transition diagram programmed. I will need to research some of the more exotic Ice phases to get it complete.
The software uses several progress bars to indicate positions in the process. These were initially added to the GUI as place holders. I have managed to get all of them functioning. Some of them may need to be altered in the future, but they are offering feedback at this time.
The testing mode was fully implemented.
It is currently implemented using conditional compilation directives. I may change it to be dynamic in the future.
This will allow testing without the need to compile a test version of the software.
The test mode work is progressing. Spinners have been added to the GUI to allow me to intercept the pressure and temperature sensors. This will allow me to manually enter readings into the program and test state transitions as temperatures and pressure changes.
Effectively, I will be able to simulate cooling and evacuation cycles etc. without having to actually wait for the unit to cool off. This will significantly reduce the time it takes to test the state transitions.
At the moment, I have the spinners showing when the code is compiled into a test version. I use C++ conditional compilation to add the spinners and associated test code. The spinners already have ranges and stepping programmed properly. Additionally, when the temperature or pressure units are changed, the spinners will automatically convert to the new units.
The next step is to insert the intercept code into the sensor code module. At that point, the software will read the spinners instead of the sensors when in test mode.
To test some of the logic in the process code, I am building a testing module that will allow me to simulate temperature changes and pressure changes. I have already confirmed the transducers are all working as planned. But now I need to run through scenarios on the bench.
I redesigned the QR library to be easier to manage. I converted the relay control portion into its own class that is wrapped in the QR class. This allows one piece of code to be instantiated for all 4 relays. If modifications or features are added, this will allow them to be deployed in one location instead of 4. It also allows the library to be easily expanded in the event the Quad Relay module is expanded to 8 relays in the future.
In addition to all of this, it makes a large portion of the code re-usable in memory. This makes the program smaller.
Added temp and pressure units to the data log. This was necessary in order to track changes to temperature and pressure options. Otherwise changes in pressure units would appear to be anomalies in the data log.
I also improved the Log Library by adding the ability to write custom log headers to the log file at run-time.
I added the ability for the HDI to dynamically switch between temperature units.
I updated my MCP9600 library to deal with temperature unit symbology, too.
The library now supports C, F, K, and R temperature scales.
I have added the ability to dynamically convert the display between different pressure units. The HDI currently uses Pa, kPa, and psi. But my MPR library supports several other pressure units, including Pa, kPa, psi, atmospheres (both standard and technical) Torr, Bar, Bayre, inHg, mmHg, inH2O, mmH2O and others.
I added a Temperature unit symbology to the library, too. This allows you to fetch the symbol for the the pressure you are using by function call.
Since I am using an absolute pressure transducer, I can easily convert between pressure units by a simple calculation using the conversion factors of the source unit and the target unit.
Both pressure and temperature errata appears to be fixed. Data collected every second for 24 hours has no sign of errata.
Testing has began to see if temperature and pressure errata is resolved.
The pressure transducer had an issue similar to the temperature transducer. Once again, the errata was a specific number being returned, so it could be easily filtered out.
I was able to confirm the accuracy of the MPR pressure transducer.
I had a concern that it was not matching official barometric pressure readings for this area. I found that the official measurements are always adjusted for temperature and altitude. Effectively, official measurements are what the barometric pressure would be if the measurement was taken at 32F (0C) at sea level.
Once I discovered this, I found the official "station" measurements and found the MPR device is reading accurate to 100 Pa, or about 0.1%. That is pretty good for a $20 pressure transducer.
