LabVIEW debugging sometimes does not work when running as code module in TestStand

[ANV_Vollinger]

Hello,

I have recently started to face issue with debugging of LabVIEW code modules in LV 19 when used with TS 19. What happens is that either breakpoints sometimes do not work or sometimes if they do, I cannot single step in VIs. Also, probe data is not available in LabVIEW even when retaining wire values - I see only text "No debug info" when checking the values by probes. I am not sure why this is the case, since the debugging is enabled in VIs. Any ideas what might cause that VIs cannot be debugged when run from TestStand?

[proland1121]

I've noticed sometimes that TestStand will launch a fresh copy of the VI i'm trying to debug (sorry for the bad description; but think of it like a clone).  If I set-up probes & breakpoints before running my sequence, the probes don't contain any data & the breakpoints don't trigger.  

Instead, it is more reliable to set a breakpoint in TestStand, step into the VI (F8 key), and then setup probes & continue execution.  I use 2017 TestStand though...

[billko]

Make sure you are opening VIs only from TestStand when TestStand is open.  I think that you can open them from the project if you unload the modules first, but if you don't do it right, it can lead to VI corruption.  The easiest thing to do is to limit yourself to opening it from TestStand when TestStand is open.

[santo_13]

Ensure your VIs are non-reentrant. If your VIs are re-entrant, it is expected that TS will launch a new clone instead of using the VI you've opened and placed a breakpoint.

[JÞB]

And I'll add another tidbit.

If your vi is in a lvproj and you don't call it through the project in teststand it opens directly though the LabVIEW proxy caller in the teststand application context rather than a proxy call to the project context in the teststand application.  Obviously then, nothing you do to the vis in the project context reflects in the teststand module.

<Buff chest await applause>

[proland1121]

---

@JÞB wrote:

And I'll add another tidbit.

If your vi is in a lvproj and you don't call it through the project in teststand it opens directly though the LabVIEW proxy caller in the teststand application context rather than a proxy call to the project context in the teststand application.  Obviously then, nothing you do to the vis in the project context reflects in the teststand module.

<Buff chest await applause>

---

This is probably why I experience different behavior during debug efforts.  Some Vi are in projects, some in packed libraries, some are just stand alone.

[JÞB]

---

@proland1121 wrote:

---

@JÞB wrote:

And I'll add another tidbit.

If your vi is in a lvproj and you don't call it through the project in teststand it opens directly though the LabVIEW proxy caller in the teststand application context rather than a proxy call to the project context in the teststand application.  Obviously then, nothing you do to the vis in the project context reflects in the teststand module.

<Buff chest await applause>

---

This is probably why I experience different behavior during debug efforts.  Some Vi are in projects, some in packed libraries, some are just stand alone.

---

Assuredly!   A library member knows it is part of a library and MUST open in the context of the library (packed or not.)   Project items do not know they can be called by a project and may open in any project context or in the main application context. 

You can inspect the context ring control at the lower left panel edge to see what the current context is or even switch context if the item is open in more than one context.

[billko]

---

@JÞB wrote:

---

@proland1121 wrote:

---

@JÞB wrote:

And I'll add another tidbit.

If your vi is in a lvproj and you don't call it through the project in teststand it opens directly though the LabVIEW proxy caller in the teststand application context rather than a proxy call to the project context in the teststand application.  Obviously then, nothing you do to the vis in the project context reflects in the teststand module.

<Buff chest await applause>

---

This is probably why I experience different behavior during debug efforts.  Some Vi are in projects, some in packed libraries, some are just stand alone.

---

Assuredly!   A library member knows it is part of a library and MUST open in the context of the library (packed or not.)   Project items do not know they can be called by a project and may open in any project context or in the main application context. 

You can inspect the context ring control at the lower left panel edge to see what the current context is or even switch context if the item is open in more than one context.

---

That's what I was trying to get at, but your post was so much more elegant and actually included how to deal with it.