Search the Community

I tried to reuse clones of a re-entrant VI and did not succeed. Help says: “Shared clone reentrant execution—Allows parallel execution … this type of reentrancy reuses clones among VI calls. If a VI call occurs while all clones are in use, LabVIEW allocates a new clone for that VI call…”. As I understand, if there is a non-used clone, it has to be used instead of making a new allocation. I created a small project (attached archive Test_DynamicCloning.zip). It has two VIs. The r.vi is set as Shared clone reentrant execution. It does not do much but only counts the number of invocation with an uninitialized shift register and closes own FP after 5 sec (alternatively it is closed with a button click): main.vi creates a new clone on button clicks: But each click of the button results in a new clone that is indicated by both: new clone number in the title bar and by the shift-register counter. Now I set Auto Dispose Ref to true and run again. The title bar indicates reusing of the same clones but the shift-register counter shows that the clone is used first time. So, I need your opinions: What happens in the background? Why and how Auto Dispose Ref influences the cloning process? Why the shift register is re-initialized? Thank you Test_DynamicCloning.zip

I had a big long explanation typed up and accidentally it the back button. I don't fee like re-typing the whole thing so here's the shorter version. I have a reentrant VI that is launched multiple times. In development you can open a reference to the VI by full path, but in an EXE the path is unknown. So you open the VI reference by name, but for this to work the VI needs to be in memory. So attached is one technique I've seen to keep a VI in memory by putting it in a case that will never be executed. Just run the Main.vi click Make New Graph Window and stop when you are done. This code will work when built into an EXE because nothing is opened by path. Is this the right way, or are there other ways to force the compiler to add a VI as a dependency, so that a new reference can be opened by name? Reentrant Reference Test.zip

As part of my latest debug process, I've been building EXEs with a basic test platform and the necessary support files - hopefully cutting down on places to look for problems in each component. The test platform in each case is a basic UI where I can enqueue messages (start, stop, do something) or receive messages (data, status, errors) plus the control code I want to trace. I've been successful with debugging and building several components (temperature readout and calculations, stage control, voltage measurement), but have hit a wall with building the last (a pair of power supplies). I have changed no settings from build to build. For all components, I can do what I want in the development environment. With most, I can build and get the same expected function. With the power supplies, I can do what I want in dev, However, the build completes without error, but the EXE is broken. I get a "The VI is not executable. The full development..." error. The major difference that I'm able to discern is that the power supply test platform has reentrant VIs (some are inlined). Since I'm using OOP and dynamic dispatch, they're sharing clones. If I put a "diagram disable" box around the top level VI for one of the supplies, the app builds and runs successfully, albeit with only one supply functioning. I've looked on the web and the causes I've been able to find for the error aren't relevant for my test. I'm using an emulator for the supplies (no drivers), I'm not dynamically loading anything (path name failures don't happen), and there are no DLLs (I'm not that good yet). Has anyone else run into problems with this? Why wouldn't the error appear in the build process? I'm running LV2011.