LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Build vi as shared clone re entrance in build specs

Recently, I've been experiencing lots of labview crash while debugging the re-entrance vi, when it crash, it tends to removed block diagram and results non-recoverable work loss. I'd like to get a work around with this issue by specify vi as re-entrance only at run-time, while under development environment, the vi stays as non-re-entrance, allow for debugging. Therefore, there's no switching back & force or clunky break point to debug re-entrance vi. 

 

Can anyone shed light how to I include vi's execution properties in build specs ?

0 Kudos
Message 1 of 3
(2,247 Views)

A very strange question, made harder to answer by not seeing the VI in question, and not seeing it "in context" (i.e. being called).

 

There are several reasons to make a VI reentrant --

  1. It is recursive (i.e. it calls itself).
  2. It is used by multiple callers, but you want each caller to have "its own copy" (typical example would be a "Delay 1 second" VI tied to the Error Line).
  3. It is a "clone", one of several identical VIs running asynchronously in parallel.

Case 1 can't be avoided -- if you make a recursive VI non-reentrant, the VI will have a Broken Arrow and won't run.  Cases 2 and 3 would largely restrict you to calling the VI in only one place, and if you do that, there's no reason to make it reentrant!

 

So let's return to the Real Question -- how do you debug a Reentrant Routine?  What I've done is write a little "Debug" VI that writes a Text file allowing me to trace the variable in question.  If you're sufficiently motivated, you can also get it to write out the name of the VI, which should get you the Clone ID (another thing I do if I'm debugging a recursive routine is to pass the Recursion level into the VI and make that part of the Debug string, e.g. "Level 1 -- Path = C:\Program Files (x86)\National Instruments", where "1" is the Recursion level and Path is the argument I'm recursing).

 

Bob Schor

 

P.S. -- here's a bad pun -- do you know why they call following a recursion chain "recursing"?  Because first you "curse", then you "curse again", or "recurse" ...

0 Kudos
Message 2 of 3
(2,218 Views)

wrote:

There are several reasons to make a VI reentrant --

  1. It is recursive (i.e. it calls itself).
  2. It is used by multiple callers, but you want each caller to have "its own copy" (typical example would be a "Delay 1 second" VI tied to the Error Line).
  3. It is a "clone", one of several identical VIs running asynchronously in parallel.

Case 2 and 3 are the same.  I think you meant you want multiple callers to use it and it doesn't matter if they have their own copy.  If the function is thread safe, you can call it in multiple locations without harm.

0 Kudos
Message 3 of 3
(2,212 Views)