LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

dynamic dispatch and reentrant

Solved!
Go to solution

I want to be able to call a LVOO dynamic dispatch vi that is reentrant, but labview does not let me do both of these things.  Specifically, I want to have an array of objects, each of which overrides a state machine of the base class, and I want to be able to iterate through all those objects and call launch their state machines.  Clearly to go through the array this can't be a blocking call.

 

As a smaller question, if I have a string with the name of an a vi in a class, can I call it (i.e. vi server for classes)

0 Kudos
Message 1 of 10
(5,193 Views)

To run a VI without waiting for it to end, you have to use the Run VI method and set the control values using the Set Control Value method. I didn't check, but I'm pretty sure that this won't work and that you will need to open a reference to the override VI in the specific class.

Which brings us to the next part of your question - yes, you can. You need to append the class name and a colon (like this: myclass.lvclass:myVI.vi). To get the class name, you should probably implement another override VI in each class which will hold a static reference to the override VI and will use that to get its name.


___________________
Try to take over the world!
0 Kudos
Message 2 of 10
(5,170 Views)

Thanks, the colon notation will cover me for calling subVI's.  However, using the run call won't fix the main problem which is I need to run several overridden state charts simultaneously, and you can't be both dynamic dispatch and reentrant as far as I can tell.

 

 

0 Kudos
Message 3 of 10
(5,168 Views)
Solution
Accepted by topic author peabody124

peabody124 wrote:

...you can't be both dynamic dispatch and reentrant as far as I can tell.


 

That is not true.  There is no restriction against setting a dynamic dispatch VI to be reentrant.  This is how class member VIs can be recursive (in LabVIEW 8.5 and later).  Can you explain where LabVIEW is not allowing you to make a reentrant dynamic dispatch VI?  Also, which version of LabVIEW are you using?
Chris M 
0 Kudos
Message 4 of 10
(5,165 Views)
Crap, it was because I was trying to make the vi preallocate for each clone, which can't happen at the same time as reentrancy.  Changing to shared execution fixed the problem - thanks!
0 Kudos
Message 5 of 10
(5,161 Views)
Ok, I can't actually get the vi server to call the class methods.  When I try something like basename.lvclass:viname.vi in the open reference input, it inserts a \ after the : and then throws an error about can't find the vi.  Is there a way to easily call an overriden vi and not have it stall the execution?  I have two overriden vi's per class - one that has the path hardcoded to the child vi and the other that is actually run, but that seems very inelegant.
0 Kudos
Message 6 of 10
(5,136 Views)

The colon notation only refers to libraries which are in memory where you use a string to identify the VI. It's simply the fully qualified name of the VI, because different libraries can include VIs which have the same name.

 

If you want to open the reference by the path, you need to use the full path to the VI, while ignoring the library name. This works, because each VI knows which library owns it.

 

 

If the VIs are already in memory, you might be able to simplify the process by moving the first VI to the parent class. It will use the Get LV Class Path VI (from the class palette) on its class input to get the name of the current class and will simply build a string made up as myClass.lvclass:myVI.vi. You could even do this without having them in memory if you mandate that the VI you want to open is always in the same relative location to the class which owns it, because then you can simply use strip path and build path.


___________________
Try to take over the world!
0 Kudos
Message 7 of 10
(5,123 Views)

You can actually probably simplify it by creating a single VI in the parent class called "Run child statechart" which will perform all the operations.

 

Also, note that my original suggestion was NOT for a hardcoded path. I said that you can use a static reference to the VI and get the path from that. Hard coded paths are generally a bad idea, especially if you plan to build the application into an executable.


___________________
Try to take over the world!
0 Kudos
Message 8 of 10
(5,121 Views)
So I've done something pretty similar to this.  The parent class has a method "Run async" which then uses the Class path and build path to get the path to an overridden vi, and launch it through vi server.  This works fine if every level of inheritance has overriden that function, but if only the parent and grandchild have, calls to the child get a file not found error.  The only way around this I can think of is to have the Run async.vi to launch a static method of the parent class, which then calls the real method on the object and lets the run time environment sort out the call.  This just seems horribly cludgy (having two layers of wrapper functions).  There are no ways to directly get the path to the right level of overriden vi, or to call the methods without waiting for it to return?  Ugh...
0 Kudos
Message 9 of 10
(5,101 Views)

Run Async.vi does NOT need to be dynamic dispatch. It should only exist in the parent class. It will recognize at run-time that you wired a child class into it and Get LV Class Path.vi (from the palette) will return the path of the correct class.


___________________
Try to take over the world!
0 Kudos
Message 10 of 10
(5,090 Views)