LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Automagically Run Dynamic Dispatch VIs

Solved!
Go to solution

Steve,

 

what i do not get is why the command_name is not a parameter....

 

Maybe it helps if you look into the Actor Framework. This is an configuration which sounds similar to your requirements... specificially the Message classes.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 11 of 29
(2,015 Views)

That's a logical question, for sure!

 

The guts of the command_name VI builds the command in G.  The output of the VI is the command reference.  If I made the command_name a parameter, then I'd have one dynamic dispatch VI in my method builder (good).  In it, I'd have a case structure for each and every command I want to deliver (bad).  In each case, the G-code that builds the command.  Then I'd have to build the complete API into each method builder (really bad).

 

Consider the case where Customer B's Cmd_Def_Shine_Shoes.vi is a little different than Customer A's.  All I want to do is define one VI in Customer B's class, "Cmd_Def_Shine_Shoes.vi".  When I load the customer from disk, I specify Customer_B.lvclass and voila, Customer B gets a cream polish instead of a paste polish.

 

Originally I didn't want to name names, so I just wrote, "I'd like to avoid one class per method".  In my mind, I was thinking, "Someon's going to throw NI's Actor Framework at this, and I don't want a class per method."

 

Thanks,

 

Steve K

0 Kudos
Message 12 of 29
(2,005 Views)

@Pie566942.0 wrote:
[...]In each case, the G-code that builds the command.  [...]

What does that code look like for most cases?

I currently image string handling (e.g. for TCP interface).....

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 13 of 29
(1,984 Views)

@Pie566942.0 wrote:

Does anyone know of a supported way to skin this cat?

I'm starting with the assumption that there's currently no way to call DD VIs dynamically. You could try using the old Control Value.Set + Run VI methods combo, but I haven't checked if that works.

 

Assuming it doesn't, if you're in LV, one option is to script it - have code which will basically generate a VI along the lines of your original code and run it. You could even have a scheme where this happens at run time and the VI is regenerated and reloaded if the list of VIs has changed.

 

I'm also ignoring the possibility of doing this a completely different way, as I haven't read your use case closely.


___________________
Try to take over the world!
0 Kudos
Message 14 of 29
(1,981 Views)

Thanks for taking a look Sir tst.  As I was implementing your Ctrl Val.Set suggestion, I was thinking about how hard I'd kick myself if it worked.  All the years I've spent calling that method!  Alas, it didn't work, at least not in how I implemented it (attached).  Interesting, I found, was that it wanted to work.  The method VIs had some knowledge of which class they belonged to, but they failed to dynamically dispatch the plugin's method.  I give it a silver star for effort!

 

Scripting...My fears are I'll either reach a similar result, or that I'll spend a lot of time joining class data from scripted objects with the object already loaded in my application.  Or both.

 

FWIW, the guts are not something I could distill into strings.  It's very G, which is why I'm writing it in LabVIEW 🙂

 

-Steve K

0 Kudos
Message 15 of 29
(1,966 Views)

Honestly, i am wondering why you work with classes at all. That setup seems to be ..... wrong by design.

 

However, if you re-wire the class input to Get LV Class Path.vi to the loaded class instead of the Basic.lvclass constant, i think the VI works as you originally thought it would.....

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 16 of 29
(1,961 Views)

I could see how, in a generalized snippet of this specific derived requirement, classes might seem wrong.  It's good to challenge design decisions.  This particular design has been vetted.  In all other aspects, native LabVIEW OOP supports my requirements well.  I tried to follow your suggestion (attached), but I obtained the same results.

 

Thanks again,

 

Steve K

0 Kudos
Message 17 of 29
(1,954 Views)

Steve,

 

the main VI in the V2 somehow looks very incorrect....

That is what i meant before:

CorrectClass.PNG

 

I hope you see the difference compared to your V1....

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 18 of 29
(1,951 Views)

That's cheating!  It's true, that version will run the plugin's methods, but AFAIK, it doesn't run the base class' methods.

 

-Steve K

0 Kudos
Message 19 of 29
(1,944 Views)

I should have wrote, "AFAIK, it doesn't dynamically dispatch anything."

0 Kudos
Message 20 of 29
(1,941 Views)