Rethinking the Flexible Standards Paradigm
Abstract: In many of today’s software projects, developers are challenged with the task of designing interchangeable standards architecture into their metrology based applications. Currently, many developers see an oscilloscope as an oscilloscope and believe that all oscilloscopes are created equal, and are therefore interchangeable; at the same time, any oscilloscope manufacturer will tell you their oscilloscope is different with special features requiring non-standardized sets of commands to implement those special and specific features. Consequently, developers write their code to implement special and unique features in what was designed to be a generic driver. Cal Lab Solutions took a step back to re-evaluate the problem and all the solutions. We came up with a software design methodology that allows the user to incorporate non-standardized features of complex standards while maintaining a highly flexible interchangeable instrumentation model. This paper will demonstrate how a process centric model allows greater flexibility over the generic command centric model.
Hey Mike,
thanks for the link, was looking through your article again, and noticed a couple of problems if the code snippits are from actual drivers, then you may want to check your Uncertainty calculation in both the .Net and Met/Cal code.
in GetInstUnc(), you assume the unit is on the most appropriate range(autorange) because the range is based on the value(reading). That’s ok if your driver doesn’t allow you to measure 1V(or less) on the 10V range, or even measure 10.02V on the 10V range!
Same kind of thing in the Met/Cal accuracy lookup, the value in the accuracy file is a single value. Since the specs of the multimeter have both %reading and %range, you cannot get the calculated value from a static file(reading changes every time), you have to do the math.
Regards,
Larry