Water State Library Progress

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.

Library to Calculate the State of Water

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.

Progress Bars Corrected

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.

Test Mode Complete

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.

Test Mode Progress

Purpose:

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.

Implementation:

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.

Next:

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.

Designing a Software Testing 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.

Quad Relay Library improvements

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 Logging Improvements

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.

HDI Updated to Include Dynamic Temperature Unit Conversion

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.

HDI Updated to Include Dynamic Pressure Unit Conversion

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.

24 Hours with no Error

Both pressure and temperature errata appears to be fixed.  Data collected every second for 24 hours has no sign of errata.

Long-term Testing on Temperature and Pressure Errata

Testing has began to see if temperature and pressure errata is resolved. 

Pressure Errata 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.

Pressure Accuracy Confirmation

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.

Pressure Errata Realized

While troubleshooting the temperature errata, I discovered a similar issue with the pressure readings.  Once in a while, I will get a bogus pressure reading.  I have began a logging operation in an attempt to locate the issue.

Temperature Errata Resolved

I believe the temperature errata has been resolved.  The MCP9600 apparently has a glitch that causes it to return a full-scale reading once in a while.  I checked the data-ready flag processing etc. and found no issues.  Finally (using the new LogFile library) I was able to isolate the problem.  The raw data was coming from the MCP9600 incorrectly.

I was able to confirm that others were having this same issue.  So, I had to resolve the issue in software.  Fortunately, the errant data was uniform and I was able to filter out that particular value.  If that particular value is returned from the MCP9600, I simply poll it again for new data.

This will need to be monitored in a long-term test, but I am confident it is resolved.

Constructed Log File Management Library (C++)

To track progress of the required metrics of the freezedrying process,I needed a logging library.

Initially it was made to track events and times, but I decided to expand it to use the high-precision clock in the crono library.  This adds the ability to not only perform event logging functions, but also high-precision scientific data logging 

The library will record elapsed time accurate to the nano-second, if your hardware is capable of such precision.  If your hardware is not capable of nanosecond precision, the library will automatically adjust to the highest precision the hardware is capable of.

Site Navigation is in the Left Column

Trying to Resolve Temperature Errata

Occasionally, temperature readings will spike.  This is most likely due to reading the Hot Junction register before ADC is completed.   The native library does not have a means to handle this, so I am collaborating with the designer of the thermocouple amplifier to develop or repair the native library to prevent the errata.

Duty Cycle Programming Complete

The duty-cycle routines have been written and tested.  

Now, the relay library includes functions to turn the relays on and off as well as functions to control the duty cycle of the device controlled by the relay.

For instance, I do not want to have to constantly check and see if the compressor is being ran too much. With the duty cycle routines, I can program the duty cycle for 90 seconds on and 90 seconds off.  All the main routine needs to do is call for service. The relay will immediately turn on for 90 seconds, then turn off for 90 seconds.  If the main program is still calling for service, the relay will turn on for 90 more seconds.

The duty cycle is completely driven by event handlers and timers.  So the main loop does not need to check the duty cycle times or anything like that.