LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV Code to call specific clone VI

Hi,

Basically I have an LV2-Style Global that I am using in a class.  I have child classes inherit from the parent class access to the global.  However - I did not expect the two distinct child classes to access the SAME global (it makes sense after that this should be the default behavior).  In order to deal with this behavior I want to control the clone instance that the child classes call so that they will have their own distinct version of the LV2-Style global.

 

I am able to use a static VI ref and spawn a clone, and reopen that same clone with that reference.  The problem is I wish to hard code in the ability to open a specific clone reference because I cannot pass the wire containing the reference (assume I do not have the ability to access the data via other means i.e. queues or notifiers).  For example I want child class 2 to know to always open clone #2.  

 

I see there is a preallocated reentrant setting but I do not know how to set this up properly.  I suspect my solution lies in doing something like that, controlling which one of the preallocated instances I access.

 

I hope someone can help, thank you.

-MrShawn

0 Kudos
Message 1 of 16
(4,120 Views)

I would suggest that you get rid of the LV2-Style global and use DVRs (Data Value References) in your class instances. This gives you much better control over your data and ensures nothing else can access it unless you allow it. Each child would have its own DVR to the type of data you want. Each DVR points to a specific instance of that data.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 2 of 16
(4,109 Views)

Also of the opinion of getting rid of the LV2 Global/FGV.  But I would just put the data in the parent's private data.

 

Lesson learned here: glabal data do not belong in classes.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 16
(4,097 Views)

@crossrulz wrote:

Also of the opinion of getting rid of the LV2 Global/FGV.  But I would just put the data in the parent's private data.

 

Lesson learned here: glabal data do not belong in classes.


^^^^

 

What's the purpose of using OOP, which creates objects with their own copies of things, to then make some convoluted "global" structure where you're trying to force each to call their own instance of the global... when you could easily make said property?

0 Kudos
Message 4 of 16
(4,076 Views)

If memory serves, if you place a real Global in the class it'll be instantiated. It can atleast be set to Protected so not everyone can access it.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 16
(4,061 Views)

@Yamaeda wrote:

If memory serves, if you place a real Global in the class it'll be instantiated. It can atleast be set to Protected so not everyone can access it.

/Y


The problem there is that ALL instances of that class will access the same glabal variable.  Exact same issue that the OP already has.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 16
(4,052 Views)

You're saying that you want each individual object (being very careful with terminology here: an object is a single unique instance of a class type) to have its own separate copy of some set of "global" data, where each object knows to access only the data it personally owns.

 

Well, that's exactly what private class data is for!  Each object has its own copy.  That data travels on the object wire, inherently maintaining the 1:1 correspondence between an object and its data.  So there's no need for LV2-global clones and suchlike.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 7 of 16
(4,044 Views)

Guys tyvm for the responses.  

 

I would like to use a simple DVR approach - however the problem is I would still need to run the wire into the class methods because as far as I am aware I will still need to run the wire which carries the reference...  I am attempting to design my code such that all my classes are actually wire free as far as the calling VIs are concerned, and calling specific objects are possible in subVIs as well.  

 

 

I gave up trying to specify which clone to call on the first time running a constructor...  Instead I use a notifier which basically houses the reference to that clone.  The notifier is named specific based on my class so that each class knows which notifier to look at and find the reference to its instance of the LV2 global.  So far, this approach is working well - I tested it with creating two separate child classes.  It may seem redundant because the LV2 global actually houses a reference to the object.  The reason I simply don't use the notifier is because the lv2 global acts as a multiton to control the number of instances that exist and prevent me from overwriting a non-destroyed class instance.

 

Actually if anyone has any feedback on this I'd be happy to hear it, I have only been working in labview for a little less than 2 months now - so while I am trying to get actual work done I am also experimenting with different ways to do things in the process.  

0 Kudos
Message 8 of 16
(4,026 Views)

@MrShawn wrote:
I am attempting to design my code such that all my classes are actually wire free as far as the calling VIs are concerned, and calling specific objects are possible in subVIs as well. 

Just stop right there.  You are trying to circumvent the whole data flow paradigm that makes LabVIEW work so well.  Just use the class wires.  It will make your life A LOT simpler on many fronts.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 16
(4,015 Views)

@MrShawn wrote:

I am attempting to design my code such that all my classes are actually wire free as far as the calling VIs are concerned, and calling specific objects are possible in subVIs as well. 

 

Actually if anyone has any feedback on this I'd be happy to hear it, I have only been working in labview for a little less than 2 months now - so while I am trying to get actual work done I am also experimenting with different ways to do things in the process.  


As it appears you understand OOP, I'll assume you've used it in other languages.  If not, feel free to correct me.

 

Let's pretend we're using Java instead of LV.  You have a class there.  You have a private property and another class can't access it.  Which of the following would you do:

1) Create getter/setter methods so you can access the method and allow the class/object to maintain control of its own data

2) Decide that you don't like getters and setters, think they don't make sense, and eliminate any private scoping by making them all public.  That way, you can just access the properties from ANY class without worry?

 

I'm going to hope you'd choose option 1.  So, why would you ever consider option 2 here?

 

As a result, you're making crazy decisions.  The DVR simply doesn't make sense.  It doesn't make sense if you have to keep each reference as part of the data.  It doesn't make sense if you try to change it to a global variable where each one tries to reference its own individual instance of the data.

 

None of it makes sense.  Just stop.  You need to do one of two things at this point:

1) Embrace that LV is a data flow language and use it as it's intended

2) Choose a different language/programming paradigm.

 

What you're doing now isn't beneficial to anyone.  If your work/project requires LV and you hate it, you'll hate it a whole lot more if you keep trying to force it to do things that don't make sense just so you feel better that you don't see wires.

Message 10 of 16
(3,996 Views)