04-21-2009 12:12 AM
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)
Solved! Go to Solution.
04-21-2009 10:44 AM
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.
04-21-2009 10:51 AM
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.
04-21-2009 11:03 AM
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
04-21-2009 11:23 AM
04-21-2009 10:33 PM
04-22-2009 01:27 AM
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.
04-22-2009 01:35 AM
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.
04-22-2009 11:48 AM
04-22-2009 01:39 PM
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.