LabVIEW
Get LV Class Parent Name
For what it's worth, here's how I'm doing things:
Each step in a sequence is an object. It references 0 or more code modules to be called. It also optionally references a typedef for an Aux Data input to the code module, and the step also has a variant that contains the value for that custom data. My step-settings dialog presents that step-specific custom data typedef in a sub-panel, and keeps it synced to the value in the variant. The template for code modules looks like this:
All code modules must have the same connector pane. In each code module, the "Aux Data" control is replaced by the custom typedef for the step (the step settings dialog keeps it synced with the step settings in the sequence). The code that invokes a step, copies the custom data from the sequence step to the "Aux Data" control in the code module before calling the it (the code module is called by reference so the executive won't abort if the code module aborts).
The Step IO class has a set of properties that are available to all steps:
So far, my hierarchy of step classes looks like this:
@drjdpowell wrote:
wiebe@CARYA wrote:
@drjdpowell wrote:
But other than just run it, what are you going to do with the reference? Otherwise, this just appears to be an overly complicated way to dynamically call a DD method. The simple, straightforward way of using a subVI seems much better, except for it not providing you with a reference.
The dynamic VI Server call allows you to start the VIs and continue without waiting for them to finish..
I didn't ask that. A dynamic VI Server call on a DD method is easily done with a simple subVI. Dynamically call the subVI and the subVI calls the DD method. That is simple. Why are you doing apparently much more complicated VI Server gymnastics to do the same thing?
Once you have a VI that does this in your toolbox, it isn't much work to use it.
I agree that making a VI and calling that dynamically is simpler. But if you have to do this a lot, at some point using VI that avoids the need for it starts to make sense.
Also, there are situations where you only get a name to call. The connector pane might not be known (only control names).
Search LabVIEW like a graph!
@LucianM wrote:
In the meantime I found a solution by calling 'Get Implementing VI Path' method from App -> LabVIEW Class. For some reason this seems not to work every time but could be something wrong in my code, I didn't have time to investigate in detail.
I don't recall if I tried that one, or that there was a problem with it.
It's just very unpractical that you have to give the scope as an input. In the scope of the class, who cares if the method is public, community or protected?
EDIT: It seems you can get the scope of the VI:
Of course that's useless if you only have a string... I usually use a static VI ref to the parent's method to call, so I can use it.
I do still have the need to climb up the hierarchy, because I want to get the class data (for serialization). Since none of the serialization functions return data if the class is default, I need to get it from the class's private data. So I need the class references of all ancestors.
@LucianM wrote:
@drjdpowell wrote:
Ah. You're trying to build an "Arbitrary LabVIEW VI Sequencer" which you can use as a "Test Sequencer", rather than just building a Test Sequencer.
It's not an arbitrary LabVIEW VI sequencer, it is a test sequencer that can control most instrument types that we use (using HAL), IVI instruments, create measurement files, reports, sequence variables, loops, conditions etc. I want to add the option to call any simple VI or class method VI for more flexibility.
I don't think Root Loop is going to be an issue. For the moment you cannot run multiple sequences in parallel (and not needed) and there is no UI updates to be done while the step with the VI call is executing.
So the more experienced traveler would simply not add this feature?
Sadly, the root loop also block when the user pulls down a VI menu...
I think the Run method doesn't wait for the root loop, but call by reference does. So I think you should be good.
@drjdpowell wrote:
wiebe@CARYA wrote:
Sadly, the root loop also block when the user pulls down a VI menu...
I think the Run method doesn't wait for the root loop, but call by reference does. So I think you should be good.
Unless they have changed things in recent versions, "Run" method requires Root Loop and Async Call By Reference (ACBR) does not (but opening a reference capable of ACBR requires Root Loop). Frameworks like the Actor Framework get around Root Loop by caching a pre-prepared reference to a pool-of-clones, so the Root-Loop blockable step only happens on startup.
Whether Root Loop is a problem depends on application: UI stuff, generally not at all, safety features, critical.
Ah, yes. I got it reversed.
Indeed, Run method uses root loop, Call By Reference doesn't.
Definitely a concern if you're planning on calling the Run Method in a loop. Menus (VI or control) will pause the sequence..
I to 'spawn' modules at start, so it doesn't bite me. Pretty sure that's intuition from being bitten in the past.
See Run Method should not run in the user interface thread - NI Community.
Also, One\Two Button Dialogs block the root loop: Change one and two button dialog windows do they do not block the root loop - NI Community
