Instrument driver architecture

[bryanthomas]

Any suggestions on how to structure instrument drivers that are used in tests?

Should I create instances of the driver in the setup portion and then pass them into the tests as parameters?

for example:

setup:
    Create TemperatureSensorObject step  // Locals.TemperatureSensor

main:
    Test1 step (send Locals.TemperatureSensor to the .net test module)



.net module call:
public result runTest(TemperatureSensorObject tempSensor, other parameters....)
{
    double temp = tempSensor.getReading();
    .
    . // do other parts of the test
    .
    return result;
}


what do most developers do?

thanks,
Bryan

[Dennis_Knutson]

What you are doing is probably pretty typical. All of my instrument drivers are modeled on the IVI step types. Each has an EditSubstep where the user first selects an instrument operation and different tab controls will then be displayed based on that. Most of time, the user just has to point and click to set something. I'm not a big fan of typing (that's why I use LabVIEW) and the users like this feature. So, all of the settings are contained in the step type itself. A PostSubstep reads these and performs the necessary actions. The major settings are also written to the step's description so it's pretty easy to see at a glance what the step is supposed to do. All of this takes a little extra work because you have to create the edit substep.