<html><body><div style="font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000"><div><div style="" data-mce-style="">Hello,<br data-mce-bogus="1"></div><div style="" data-mce-style=""><br data-mce-bogus="1"></div><div style="" data-mce-style="">TR817FS was at 325 K this morning. Attached is a screenshot of the Cerenox's raw data from the LV Chassis. The LV cRIO has been reset and TR817FS now reads ~4.5 K.<br data-mce-bogus="1"></div><div style="" data-mce-style=""><br data-mce-bogus="1"></div><div style="" data-mce-style="">Also, in attempts to find a way where the 325 K error can fix itself, I took the fact that we know restarting the LV cRIO program fixes the 325 K Error and modified the LV cRIO LabVIEW program to cause the entire cRIO wait for about five seconds and also clear all VISA buffers if a Cerenox reads 325 K. The delay/VISA Clear would hopefully replicate at least part of what happens when the LV cRIO is manually restarted. To prevent the LV cRIO from waiting five seconds on all DAQ loops if the delay and VISA Clear does not reset the error, there will also be code added to trigger the five second delay only once when a sensor first reads 325 K.<br style="" data-mce-style=""></div><br style="" data-mce-style=""><div style="" data-mce-style="">Just a note, though: if successful, these new additions should only be a temporary fix, as we still would not know what is really causing the error.</div><div style="" data-mce-style=""><br style="" data-mce-style=""></div><div style="" data-mce-style="">I plan to deploy the modified LabVIEW program to the LV cRIO this afternoon.<br style="" data-mce-style=""></div><br style="" data-mce-style=""><div style="" data-mce-style="">Best regards,<br style="" data-mce-style=""></div><div style="" data-mce-style="">Tyler</div></div></div></body></html>