Debugging Labwindows dll in teststand with CVI 9.1.1

[markus kossmann]

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 ?

[markus kossmann]

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.

[markus kossmann]

Sorry for the bad formating, But IE6 which I'am forced to use here, seems to mess up things.

[markus kossmann]

Now the code again as attachment with some additional comments where you can find the correspondending Spy steps

[markus kossmann]

It looks like that the attachments were suppressed too :-(. another try fgrom another PC.

[SFK · Accepted solution]

Markus,

to my knowledge, one would not start CVI prior to the TestStand Sequence Editor for debugging purposes. CVI is launched automatically when needed. Keeping this in mind, I can imagine that the instrument handle is reset after each step when having an IVI project open in CVI and using CVI parallely to debug a DLL.

So please try the following:

--8<---------------------------

1. Open the sequence file.

2. Complete the following steps to enable the LabWindows/CVI Adapter to execute steps in an external
instance of LabWindows/CVI.
   ❑ Select Configure»Adapters.
   ❑ Select the LabWindows/CVI Adapter.
   ❑ Click Configure.
   ❑ Enable the Execute Steps in an External Instance of CVI option.

   ❑ Click OK to close the LabWindows/CVI Adapter Configuration dialog box.
   ❑ In the Warning dialog box, click OK to unload all modules. 
   ❑ Click Done in the Adapter Configuration dialog box.

3. Place a breakpoint.
   ❑ Click to the left of one of your CVI code module sequence steps to place a breakpoint at the step.

4. Compile a debuggable DLL.
   ❑ Select the step with the set breakpoint.
   ❑ Click Edit Code in the Module tab.
   ❑ In LabWindows/CVI, select Build»Configuration and verify that Debug is enabled.
   ❑ Select Build»Create Debuggable Dynamic Link Library to compile the debuggable DLL.
   ❑ Click OK when prompted that the files were created successfully.
   ❑ Close LabWindows/CVI.

5. Execute the sequence in TestStand.
   ❑ Select Execute»Single Pass.
   ❑ When the execution pauses, click Step Into to step into the LabWindows/CVI code module.

The LabWindows/CVI Debugging window launches, where you can use the LabWindows/CVI
debugging tools, Watch window, and Variable window to debug code.

--8<---------------------------

Are your power supplies then reset, too?

Best regards,
Sebastian

[markus kossmann]

Starting CVI prior to the TestStand Sequence Editor for debugging purposes used to work with CVI7/Teststand-3.1.

Running the cvi code in an external instance of CVI seems to solve the problem. But another question: How to debug a teststand code module by attaching the debugger to the running process ( new feature in cvi2010) . Attaching it to the teststand process seems to trigger the same side effects as starting CVI first.

[SFK]

Markus,

I have not yet worked with the new process debugging feature, but I believe that when you try to debug the TestStand in the "normal" CVI environment, it will again auto-init and auto-close the IVI drivers when stepping through the code to prevent reference leaks.

Best regards,

Sebastian

[markus kossmann]

You speak about Teststands "auto-init and auto-close IVI drivers" ? Is this documented somewhere ? And could you point me to the documentation ?  If it is properly documented this can be considered as feature. But if it lacks documentation it should be considered as bug.

PS: Does it make sense to switch to the Teststand Forum to discuss that further ?   

[SFK]

This behaviour is not caused by TestStand, but by your attempt to share IVI code across two processes. The DLL is called by your test execution. If you now try to debug (= execute) this code in a separate CVI environment, the IVI session will to my knowledge be terminated and re-initialized for every new call in order to arbitrate access.

I do not know if this really needed special documentation, because it is in my opinion logical behaviour, and the recommended debugging way does not expose the user to this issue.

Best regards,

Sebastian