TestStand Debugging of CVI

[DSandoval]

Hi,

About four or five months ago I've been debugging dll´s created in CVI 7.1 and used in TestStand 3.1 by specifying SeqEdit.exe as "external process" and then "->Run->Debug SeqEdit.exe".  Everything was OK then, but these days, when I try to debug any CVI dll's, both TestStand and CVI got frozen, then I need to restart my laptop. This is happening everytime: from TestStand sequence, I can stop on the breakpoints I set, debug only a few lines and then both applications are frozen and the only way I can continue working is by restarting the PC. Any suggestions or ideas on what to do?

Thanks a lot,

Delfino

[Caroline Bright]

Hi Delfino,

I would actually recommend that you debug your CVI dll's in another way.  The way we recommend only takes a few simple steps and then you can debug them from TestStand as opposed to through CVI then TestStand.

In TestStand, Select Configure -> Adapters.  Select the LabWindows/CVI Adapter and then click Configure.  Enable the Execute Steps in an External Instance of CVI. 

Yo should now be able to place a breakpoint on the step that calls the dll and then step into the code module from TestStand.  Just start the sequence as normal (Single Pass or Test UUT) and once you reach the breakpoint, select Step Into from the toolbar.

Hope this helps,

Caroline

National Instruments

[James_Grey]

While the external process execution option is a possible work-around, the method you were using is a perfectly good one and should work.

I'm not sure what to suggest other than to uninstall anything you have installed since the time when it was working, and/or to uninstall and reinstall the versions of CVI and TestStand that were working.

[mhousel]

---

@DSandoval wrote:

Hi,

About four or five months ago I've been debugging dll´s created in CVI 7.1 and used in TestStand 3.1 by specifying SeqEdit.exe as "external process" and then "->Run->Debug SeqEdit.exe".  Everything was OK then, but these days, when I try to debug any CVI dll's, both TestStand and CVI got frozen, then I need to restart my laptop. This is happening everytime: from TestStand sequence, I can stop on the breakpoints I set, debug only a few lines and then both applications are frozen and the only way I can continue working is by restarting the PC. Any suggestions or ideas on what to do?

Thanks a lot,

Delfino

---

I have had the same experience recently.  Particularly with LabWindows/CVI 8.1.1 (361) and TestStand 4 (4.0.0.326).  The setup using the sequence editor as the external process is so unreliable as to be nearly unusable.

In fact while I was typing this I ran CVI and the Sequence editor to get the exact versions and the sequence editor crashed when I brought up the about splash with NO sequence loaded and NOT being run by CVI.

NOTE: I can repeat this every time.  Open the sequence editor, bring up the about splash.  TestStand frozen completely using about 87MB of memory with NO sequence loaded.

FWIW, I can typically detect an impending crash by watching the task Manager performance window and noticing when CVI's memory usage jumps from about 75MB with the sequence open and running to ~94-95MB or more.  It des this sometimes while sitting stopped in the debugger.

My test code is NOT allocating any memory at this point and I'm not doing much in the way of dynamic memory allocation at any point, and NO malloc/free on the flay.  everything is malloc'e up front and stays until the sequence closes.

In general I haven't seen this with TestStand 3.5 nearly as much (I have both 3.5 and 4.0 projects)

I'll try the other method to see if it works any better.



Message Edited by mhousel on 12-16-2007 08:35 PM

[mhousel]

BTW, where it asks for the project that 'contains the exectuion server' is this my CVI project?

[mhousel]

Ok, so the second method of debugging CVI code seems to be stable.  Thanks for the suggestion.

 It requires a different perspective to debugging as until you are in a particular file having stepped there from the sequence editor youi can't set any break points in the CVI code.

There should be some clues here for the NI developer people and they should address this problem, OR it should be noted somewhere that debugging via the sequence editor as an external process is problematic.

[RayFarmer]

Hi,

Have you changed you CVI or TestStand recently, upgraded any of them, added any new hardware?

Regards

Ray Farmer

[mhousel]

No new HW, in fact there is no NI hardware involved in this test setup.  Just TELNET connections to the product and to a Terminal Server.

But I recently upgraded from CVI 8.0 and TS 3.5 to 8.1/4.0 because that's what the customer bought. ;-(

The system there has a clean 8.1/4.0 combination and is nearly unusable for debugging CVI test code.

On my laptop that I run 3.5 and 4.0 on with CVI 8.1 the TS 3.5 seems reasonably reliable although it has locked up a couple times.  TS 4.0 is pretty bad but much better than the system at the customer site.

Switching the debugging methodology has made it reliable although it's still dog slow.  But I'll take that over not working at all. 😉



Message Edited by mhousel on 12-17-2007 02:03 AM

[RayFarmer]

Hi mhousel,

Sorry, I had actually aimed my question at the Delfino.

From your comments about TestStand 4.0, it sound like your TestStand is very unstable. It shouldn't stop working just launching it.

I would recommend un-installing your TestStand, remove the TestStand 4.0 folders, maybe cleanup the registry and try installing again. Maybe switch off any virus scanner that maybe running, during the installation.

Regards

Ray Farmer

[Josh_W]

mhousel,

Is your sequence editor still behaving badly, even when run directly (and not as an external debugging process from CVI)?  Did the suggestions to uninstall/reinstall help at all?

Are you still having this trouble when using seqedit.exe as an external debugger?  I set up a simple test here yesterday, and I was able to get it to work with no problems.  Is there anything else unique or different about your system that might be contributing to this error?

The more information we have to work with, the better the chances of getting to the root of this problem.
Thanks!