Calling a VI using VI Server - The VI is not in a state compatible with this operation :(

[crelf]

Hey all,

I'm using VI server to load and run a VI dynamically, but I'm getting:

Error 1000 occurred at Invoke Node in Start Threads.vi

The VI is not in a state compatible with this operation

I know the VI is fine (it's not reserved for executiong, I can run it manually, and it's idle when I try to call it).

Note the image over the title of the type specifier - I wonder if this is trying to tell me something?

Anyway - see the attached files: unzip the zip file to a new folder and point the path control of LittleBugger.vi to that new folder - I can't understand why the Motion (Linear) Thread.vi won't run...

Download File:post-181-1141424835.vi

Download File:post-181-1141424750.zip

[WMassey]

I never have convinced myself that LV v8 was worth it, so I cannot poke at your VIs but I've seen something like this problem in LV v7.1.

What I have seen (in more than one case) is that VI "A" in dynamically invokes (as a separate process) VI "B".

Both VIs share many subVIs but each one does have a few unique subVIs.

Both "A" & "B" work without problems when the VIs are running under the LabVIEW development system.

"A" can also start "B" without problems running under the development system.

Both "A" & "B" work without problems when each is run as a standalone application.

But when "A" (running as a standalone application) tries to start "B" (also running as a standalone application) then "B" will open up broken.

I discovered that in this circumstance "B" thinks that some of its subVIs are missing.

Once I figure out which ones those were, I added them to a commented-out section of code (LV8 handles this differently I understand) in VI "A" and after that "A" starts "B" without problems.

[jpdrolet]

To use the Run method, don't input a type specifier when you open the reference. You need a type specifier only for calling the VI with the invoke node.

[crelf]

But when "A" (running as a standalone application) tries to start "B" (also running as a standalone application) then "B" will open up broken.

Thanks for the explination - I agree: I've had the same issue in the past, but the problem that I'm currently having happens in the development environment - I haven't even tried it as a built exe yet

To use the Run method, don't input a type specifier when you open the reference. You need a type specifier only for calling the VI with the invoke node.

I know that I I don't need to use a specifier to just run a VI dynamically, but I'm using it this way so the error cluster allows me to determine if the opened VI is of the correct type to use as a plug in.

[jpdrolet]

I know that I I don't need to use a specifier to just run a VI dynamically, but I'm using it this way so the error cluster allows me to determine if the opened VI is of the correct type to use as a plug in.

You don't just don't need it, you can't wire it to use the Run method. Wiring the type specifier reserves the VI for Call and you can't Run it. However you can check the connector pane by opening with type specifier, close the refnum. If no error, open a VI refnum for Run method without type specifier.

[Jim Kring]

I know that I I don't need to use a specifier to just run a VI dynamically, but I'm using it this way so the error cluster allows me to determine if the opened VI is of the correct type to use as a plug in.

As Jean-Pierre mentioned, VI Server knows whether a VI reference was opened strict, and it uses this to know whether you can or cannot use a CBRN to invoke the VI. What I suggest that you do, is open two seperate references: one strict, and one non-strict. Use the strict reference, only for validating that the VI's con-pane is correct (matching your plug-in conventions). Use the non-strict reference to invoke the Run method. Make sure that both references are opened before closing the strict reference, or you may incur the overhead of loading the plug-in VI into memory twice.

BTW, why are you not using the CBRN to invoke the plugins? If you are enforcing a strict con-pane adherance of plug-ins, then this might be the best approach.

[crelf]

You don't just don't need it, you can't wire it to use the Run method. Wiring the type specifier reserves the VI for Call...

Ahhhhh - of course it does! Thanks for your help!

...why are you not using the CBRN to invoke the plugins? If you are enforcing a strict con-pane adherance of plug-ins, then this might be the best approach.

I'm not useing the CBRN because I need the plugin to run in parallel to the rest of the app - if I use the CBRN then I need to wait until it's completed exectuion for my main to keep running (don't I?)

[B Chavez]

I know that I I don't need to use a specifier to just run a VI dynamically, but I'm using it this way so the error cluster allows me to determine if the opened VI is of the correct type to use as a plug in.

If you're not using the CBRN, why do you need a specific connector type?

[Jim Kring]

I'm not useing the CBRN because I need the plugin to run in parallel to the rest of the app - if I use the CBRN then I need to wait until it's completed exectuion for my main to keep running (don't I?)

You could create a "wrapper" VI for the CBRN that you invoke using the run method. Make the wrapper VI reentrant and pass 0x08 (prepare for reentrant run) to the "options" input of Open VI Reference, when you open the wrapper, to allow multiple instances of the wrapper (and therefor multiple plugins) to be spawned. Make sure to set Auto Dispose Refnum to TRUE, so that the lifetime of the wrapper is decoupled from the VI that spawns it.

[crelf]

Thanks everyone - the double reference solution works perfectly:

Also, I don't need to use the CBRN as each plugin runs autonomously - no interaction via the connector pane, but a couple of functional global queues...

[Rolf Kalbermatter]

Thanks everyone - the double reference solution works perfectly:

Also, I don't need to use the CBRN as each plugin runs autonomously - no interaction via the connector pane, but a couple of functional global queues...

It is a good idea to always close any explicitedly opened refnums!

Rolf Kalbermatter

[Jim Kring]

It is a good idea to always close any explicitedly opened refnums!

Rolf Kalbermatter

I think that you wouldn't want to close the process reference in the "spawning" VI, since this could kill the process (since Auto Dispose == TRUE). What I usually do, is pass the reference to the spawned process (via Set Control Value) and let the process (explicitly) close its own reference.

[jpdrolet]

I think that you wouldn't want to close the process reference in the "spawning" VI, since this could kill the process (since Auto Dispose == TRUE). What I usually do, is pass the reference to the spawned process (via Set Control Value) and let the process (explicitly) close its own reference.

It is done automatically. From the Run Method Help:

Auto Dispose Ref: If TRUE, the target VI detaches the reference from the main VI. When the target VI finishes executing, LabVIEW automatically disposes the reference, along with the parallel data space. The default is FALSE.