LabVIEW
Troubleshoot reenterant vi
Basically, yes.
If you place a breakpoint inside the VI you'll get one popup per instance and it'll be named [vi name]:4 or similar in the window title.
While debugging it's common to turn off the reentrancy, though it's not possible in a recursive scenario. I do hope you're not keeping any data internally, that's bound to cause problem in a reentrant VI.
/Y
@Yamaeda wrote:
Basically, yes.
If you place a breakpoint inside the VI you'll get one popup per instance and it'll be named [vi name]:4 or similar in the window title.
While debugging it's common to turn off the reentrancy, though it's not possible in a recursive scenario. I do hope you're not keeping any data internally, that's bound to cause problem in a reentrant VI.
/Y
I think you're safe if the re-entrancy is "pre-allocated clone". It gets "interesting" if you forget to set that. 😉
How are you probing the VI? You should only be able to effectively probe a clone of the VI.
What type of reentrancy are you using? If using Shared Clone, then you could just be reusing the same clone at each call. This would show what you are describing. If using Preallocated Clone, then I would not expect this.
It sounds from your description like you may be talking about a "non-reentrant" VI - since you said you are able to probe it and you are seeing values from multiple different places where the VI runs (though this could also happen if it is shared clones reentrant and you have a clone open).
Press ctl+i to open VI properties and go to the Execution tab, and tell us which option you see selected there.
https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/reentrancy/ Note "Shared Clone Reentrancy".
| Usage Considerations | Non-reentrant | Shared Clone Reentrancy | Preallocated Clone Reentrancy |
|---|---|---|---|
| Ability to maintain state, such as in uninitialized shift registers | Maintains a single instance of the data space and uses its state across all call sites. | Does not maintain state—Each call site pulls the data space of a clone randomly from the pool of clones. Call sites may end up sharing state. | Maintains state for each call site—Each call site has its own separate and specific clone. |
| Determinism for multiple, simultaneous calling VIs | Call sites might wait in line behind other simultaneous callers—The time required for an instance of a subVI to begin executing varies with how many other instances are scheduled to execute before it. | Possible waiting—Call sites may need to wait for LabVIEW to create a new clone if the pool of clones is empty. When the pool is not empty, pulling a clone and returning the clone to the pool can introduce non-deterministic delays. | No waiting—LabVIEW allocates a clone for each call site prior to execution. This allows deterministic memory usage and execution speed. |
| Call overhead when no simultaneous calling VIs exist | Medium—LabVIEW must check for simultaneous callers. | Highest—LabVIEW must atomically pull clones from and return clones to the pool of clones. Calls may need to wait for LabVIEW to add a clone to the pool. | Lowest—LabVIEW already preallocates a clone to each call site. |
| Memory usage | Lowest—LabVIEW allocates only a single data space for the subVI. | Medium—LabVIEW must allocate clones only for the maximum number of instances running simultaneously. | Highest—LabVIEW must allocate a clone for each instance of the subVI. |
