LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView OOP - nest independent running VI in Object - bind vi execution to object


@szewczak wrote:

 

Is this similar to what you are trying to do?


No really. But all in all not bad.

 

The naming is a bit alien to me. Not sure if that G# or something, but I avoid class names in methods (like the plague). Same for the project organization. But that is probably just taste and customs.

 

I'd probably avoid getting the main.vi references by there name. Give each child an override method that contains a (static) VI reference. Use that instead of a reference opened by name. That way, each object is responsible for it's own reference. This opens doors... E.g. to cloning the objects, allowing multiple instances of the same window. Or you can let the object decide which front panel to use based on it's own logic, they don't need to be called main.vi anymore (although that would help keeping thinks clear).

Message 11 of 19
(671 Views)

I may have gone down the rabbit hole trying to play with this problem and I am calling it quits due to a specific limitation with LabVIEW Classes and Dynamic dispatching. Specifically:

dynamic dispatch.png

Which yields the error:

The connector pane of the strictly typed VI reference input includes a dynamically dispatched terminal,
which means it is part of a method of a LabVIEW class.
Dynamic member VIs are not supported by the Call by Reference node in this version of LabVIEW.

I think this is nail-in-coffin for using classes to organize your dynamic called processes in LabVIEW.

 

Thank you for your comments on file organizing in LVOOP. I looked up a style-sheet and now I am ashamed. 

________/~~~~~~~~*********~~~~~~~~\________
Certified delinquent LabVIEW developer. Recertifying at next NI Days
0 Kudos
Message 12 of 19
(653 Views)

@szewczak I think this is nail-in-coffin for using classes to organize your dynamic called processes in LabVIEW.

No, you just need a static VI that does nothing but call your dynamic-dispatch VI.

0 Kudos
Message 13 of 19
(646 Views)

Drdjpowell, correct that snippet only does what you described. But I included it to discuss the part I found frustrating about LVOOP, that objects with hiearchy cannot be used by call asynchronous tools like the one I. The snippet. I get why from a system management perspective this is so, but it means that organizing vis into a class hierarchy is not compatable with calling child object vis asynchronously.

________/~~~~~~~~*********~~~~~~~~\________
Certified delinquent LabVIEW developer. Recertifying at next NI Days
0 Kudos
Message 14 of 19
(641 Views)

@drjdpowell wrote:

@szewczak I think this is nail-in-coffin for using classes to organize your dynamic called processes in LabVIEW.

No, you just need a static VI that does nothing but call your dynamic-dispatch VI.


And that DD VI reference (called by the static parent VI) is returned by a DD VI in each child. Think we're on the same page.

0 Kudos
Message 15 of 19
(624 Views)

@szewczak wrote:

dynamic dispatch.png

I think this is nail-in-coffin for using classes to organize your dynamic called processes in LabVIEW.


I would like it a lot if call by reference would accept DD VIs. But usually, the call by reference call would be the exact same as a DD call.

 

In fact, it would be possible to refactor the dynamic call out. Simply start all objects in a parallel for loop. That loop won't quit until everything is done. Then use the VI reference to put the FP in a sub panel. Or better: send an event and let the object put itself in a sub panel. It's often overlooked that normal VI's (not dynamically started) can be put in a sub panel...

0 Kudos
Message 16 of 19
(623 Views)

@szewczak wrote:

Drdjpowell, correct that snippet only does what you described. 


I wasn't describing your snippet so I think you've misunderstood me.  You need to call-by-reference a static-dispatch VI with a child object passed in, then make a (not-by-reference) call to a dynamic-dispatch VI inside the static VI.  Multiple frameworks ("Actor Framework", "Messenger Library") do this.

Message 17 of 19
(615 Views)

@drjdpowell wrote:

@szewczak wrote:

Drdjpowell, correct that snippet only does what you described. 


I wasn't describing your snippet so I think you've misunderstood me.  You need to call-by-reference a static-dispatch VI with a child object passed in, then make a (not-by-reference) call to a dynamic-dispatch VI inside the static VI.  Multiple frameworks ("Actor Framework", "Messenger Library") do this.


Good one.

0 Kudos
Message 18 of 19
(611 Views)

Finally went and read the intro to actor framework, realized how much better that is for this kind of problem. Sorry for adding confusion to this thread!

________/~~~~~~~~*********~~~~~~~~\________
Certified delinquent LabVIEW developer. Recertifying at next NI Days
0 Kudos
Message 19 of 19
(607 Views)