Debugging Labwindows dll in teststand with CVI 9.1.1

Question

Is there a known problem when debugging Labwindows DLL used as Teststand Code module ( using the Labwindows CVI Adapter)?
My setup includes to powersupplies with IVI instrument drivers ( Agilent 6032A and and E3634 A) a a few other instruments with non-IVI instruments drivers. When start CVI, load the dll project and then start the Teststand Sequence editor as program to be debugged an then step into the C-Code it looks like there is process that watches both powersupplies and tries to reset them again if I access them from my C code through the instrument driver. There is no such effect with the non-IVI instruments and also if I run the code outside the debugger there is no such effect.
Any Ideas whats going wrong here ?
Solved!
Go to Solution.

Answer 1

some more information. I#ve updated now to CVI 2010 and the effect still exists. To demonstrate it I've attached a NI SPY log. The 6032A lives at GPIB ID 3 the E3634 at GPIB ID 5. I'am running the following code:
Fmt(resource_id,"GPIB::%d::INSTR",addr_PS_P24V);
tsErrChk(status = hp6xxxa_init (resource_id, VI_ON, VI_ON, 2, &Instr_Handle_PS_P24V));
// Export Instrument handle for PS_P24V
tsErrChk (TS_PropertySetValNumber (testData->seqContextCVI, &errorInfo,
"FileGlobals.Instr_Handle_PS_P24V", 0x1,
Instr_Handle_PS_P24V));
//set limit voltage and current
// status = hp6xxxa_603xA_soft_limits (Instr_Handle_PS_P24V, 30, 0.5);
tsErrChk (status = hp6xxxa_603xA_fold (Instr_Handle_PS_P24V, 0));
//set voltage and current depending on device A/AP 10A B/C 11.5 A
if ( is_ALA_B_device( testData->seqContextCVI) || is_ALA_C_device( testData->seqContextCVI) )
tsErrChk (status = hp6xxxa_volt_curr (Instr_Handle_PS_P24V, 26.0, 11.5, 1));
else
tsErrChk (status = hp6xxxa_volt_curr (Instr_Handle_PS_P24V, 26.0, 10.0, 1));
tsErrChk (status = hp6xxxa_delay (Instr_Handle_PS_P24V, 0.500, 1));
Delay(.2);
//output off
tsErrChk (status = hp6xxxa_output_onoff (Instr_Handle_PS_P24V, 0, 1));
Delay(.2);
[... later for the E3634]
// Get GPIB-Adress of PS_P3V3
tsErrChk(TS_PropertyExists(testData->seqContextCVI, &errorInfo, "FileGlobals.GPIB_ADDR_PS_P3V3", 0, &propertyExists));
if (propertyExists)
tsErrChk (TS_PropertyGetValNumber(testData->seqContextCVI, &errorInfo,
"FileGlobals.GPIB_ADDR_PS_P3V3",
0, &GPIB_ADDR_PS_P3V3));
addr_PS_P3V3 = GPIB_ADDR_PS_P3V3;
#ifndef NO3V3 // NO 3.3V programmable source on TK2
// Initialize PS_P3V3
Fmt(resource_id,"GPIB::%d::INSTR",addr_PS_P3V3);
tsErrChk(hpe363xa_init (resource_id, VI_TRUE, VI_TRUE, &Instr_Handle_PS_P3V3));
// Export Instrument handle for PS_P3V3
tsErrChk (TS_PropertySetValNumber (testData->seqContextCVI, &errorInfo,
"FileGlobals.Instr_Handle_PS_P3V3", 0x1,
Instr_Handle_PS_P3V3));
hpe363xa_ConfigureOutputRange (Instr_Handle_PS_P3V3, "",
HPE363XA_VAL_RANGE_VOLTAGE, 5);
hpe363xa_ConfigureVoltageLevel (Instr_Handle_PS_P3V3, "", 3.3);
// Output off
hpe363xa_ConfigureOutputEnabled (Instr_Handle_PS_P3V3, "", VI_FALSE);
hpe363xa_ConfigureCurrentLimit (Instr_Handle_PS_P3V3, "",
HPE363XA_VAL_CURRENT_REGULATE, 0.5);
hpe363xa_ConfigureOVP (Instr_Handle_PS_P3V3, "", VI_TRUE, 4);
#endif
#ifdef TK3 // use E3640 powersupply for TK3
Fmt(resource_id,"GPIB::%d::INSTR",addr_PS_P3V3);
tsErrChk(hpe364xa_init (resource_id, VI_TRUE, VI_TRUE, &Instr_Handle_PS_P3V3));
// Export Instrument handle for PS_P3V3
tsErrChk (TS_PropertySetValNumber (testData->seqContextCVI, &errorInfo,
"FileGlobals.Instr_Handle_PS_P3V3", 0x1,
Instr_Handle_PS_P3V3));
hpe364xa_ConfigureOutputRange (Instr_Handle_PS_P3V3, "1",
HPE364XA_VAL_RANGE_VOLTAGE, 5);
hpe364xa_ConfigureVoltageLevel (Instr_Handle_PS_P3V3, "1", 3.3);
hpe364xa_ConfigureCurrentLimit (Instr_Handle_PS_P3V3, "1",
HPE364XA_VAL_CURRENT_REGULATE, 0.5);
hpe364xa_ConfigureOVP (Instr_Handle_PS_P3V3, "1", VI_TRUE, 4);
// Output on
hpe364xa_ConfigureOutputEnabled (Instr_Handle_PS_P3V3, "1", VI_TRUE);
#endif
If you look into the Spy Log you will see at #241 the first hit of that strange process, which beginns with a viOpenDefaultRM
and ends with a viClose at #252
after issuing an *IDN?, which fails because the 6032A doesn't support *IDN?. Then the first driver call ( init function) can be identified.
later on , when the code goes to the E3642 using ID5 at #1142 in SPY log you will see that the strange process will finally send a *RST if the *IDN? succeeds.