Open rsbrost opened 3 weeks ago
Bug found where continuous scan saving protocol impacted. Won't save half of the data. Was working on the commit from August 12th: f9cca3fa85e307a9d30981401d6490998abed3a9.
Was working on August 22nd commit: 14f246504be69e4b85ae59d87708cf19c8530cc1.
Was working on commit: b759498fbea0d6b25af74905eb7a898b4ca785de
Broke from commit: 35a8e029902b0f0aeebb7b48eabb3334dcf73695
One possible change that could be considered ideal but would contribute to increased redundancy is to effect the expt.key value saving for datapoints in its own unique function. This might make pyscan more robust/extendable for other experiments, such as sparse sweep, or others; however, would require duplicate code for determining if the expt is continuous or not.
Alternatively, we could assign expt.runinfo a continuous attribute/@property that is only true if there is a continuous scan; however, duplicate code would still be required to capture run count and stop condition, unless these are also assigned as runinfo attributes/properties.