LabVIEW
LV Code to call specific clone VI
@natasftw wrote:
@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?
Private globals do have there uses, although refactoring them out is usually a good idea.
A good usage of a private class global (real global or LV2 style), is to make a singleton child from a normal parent.
So they can be useful (when private) if you are absolutely sure they are, well, global. But it's not on top of my list to teach as a good practise.
Search LabVIEW like a graph!
@MrShawn wrote:
I would like to use a simple DVR approach -
There are no simple DVR approaches.
At first you think: hey, that's nice, it works!
Yes, the code does what it should. That doesn't mean it works for you.
Then you figure out you can't debug sub VI's (the ref Is disposed when the code stops, like all refs), probes don't show values. Overwriting VI's is terrible. You might get memory leaks. You always need an init. And so on, and so on.
DVR's are nice in theory, but I found myself removing them from all my code. All but one or two (out of 280 classes) where "by wire" gives an overhead. Eventually, I'll investigate and remove those as well.
At least make a normal class first. Then make a DVR child that "wrappes" the parent. If you need to extend the functionality, you can make a new child of the parent, and make the DVR use that object.
Maybe my expectations of my code are just too high...
On a more constructive note...
If you have one loop that writes an object, and another that reads the object, I'd simply send the object from one loop to the other by a user event (or maybe a queue).
Yes, there will be copies of the object. Often that's what you want. In this example, do you really want the read to act on data that's being changes by the writer? Or do you want a snapshot (aka copy)? Often you want the snapshot. If you read for example the nr of objects, and then the objects, the write loop might have added or deleted an object. That's a problem.
So the synchronisation that was desired and the reason to use a DVR, becomes a problem instead of a solution... Just be warned: you might get what you whished for.
If you use a user event or queue don't forget to wrap it in a class. That way you can see by the wire where it's being used, and you can change the implementation. It doesn't get better that that...
wiebe@CARYA wrote:There are no simple DVR approaches.
DVR's are nice in theory, but I found myself removing them from all my code. All but one or two (out of 280 classes) where "by wire" gives an overhead. Eventually, I'll investigate and remove those as well.
All of G# is based on the idea of DVRing LVOOP to get a reference based system. It works really good. And yes, just like with all reference based code you'll need a Create/open-function.
/Y
@Yamaeda wrote:
wiebe@CARYA wrote:There are no simple DVR approaches.
DVR's are nice in theory, but I found myself removing them from all my code. All but one or two (out of 280 classes) where "by wire" gives an overhead. Eventually, I'll investigate and remove those as well.
All of G# is based on the idea of DVRing LVOOP to get a reference based system. It works really good. And yes, just like with all reference based code you'll need a Create/open-function.
/Y
But can you debug (run) sub VI's after the creator was stopped? That is the mean reason DVR's are a pain.
I think G# might have a "broker" system, that always runs. It might supply those DVR references, so they're still valid if the main was stopped. At the expense of memory leaks if you don't close the refs properly.
Not being able to run sub VI's when the main stops running is a deal breaker for me.
wiebe@CARYA wrote:But can you debug (run) sub VI's after the creator was stopped? That is the mean reason DVR's are a pain.
I think G# might have a "broker" system, that always runs. It might supply those DVR references, so they're still valid if the main was stopped. At the expense of memory leaks if you don't close the refs properly.
Not being able to run sub VI's when the main stops running is a deal breaker for me.
It's a kind of broker system yes, it's used for Garbage collection. If you run the debugging tool you can check live objects data clusters and see dependencies of those objects. But yes, sometimes it's hard to get at a sub-vi and you'll need to place a Breakpoint which can be annoying if you have several instances. Pros and cons, pros and cons. 🙂
/Y
