From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
LVOOP with DVR - Best Practices and Caveats
@thols wrote:
Yamaeda/Wiebe: The IPS is hidden. You can use it if you need, but since you have access to your attribute without using the IPS, and property creation/refactoring is also automated in G#, it is very rarely needed.
So I can access private data of my object without an IPS? I don't want to be forced to use accessor methods for every single peace of data I want access to. Not even when G# automates it for me.
Not sure what attribute access means in this context?
Search LabVIEW like a graph!
@thols wrote:
I too hope that G# should not even be needed, but we are still years away in actually being able to use NXG with by-ref, I think. And even then we will still need some add-on to be more productive. The LabVIEW operations on classes/methods/properties are just way to basic.
Agreed, but I can wait. I don't have a real need for it.
So there are (only
) two benefits to G#:
1) the IDE does a lot of work on the boiler plating (that is still there).
2) the DVR is probably created in a broker of some kind, so the ref stays valid when the top level VI stops.
I see why people use it, but I don't really have a problem with working in LabVIEW "by wire". I though maybe if the solution was "lean" (as in build in LV, but hidden), I could use it in some corner cases (like sharing large amounts of data).
+"So I can access private data of my object without an IPS?" (6)
3) Build in Icon generator/editor for fast and consistant Icons (i often use this even with standard code)
4) R-click menu in Project for many tasks as cloning functions in and between classes, changing inheritance and so on.
5) Garbage collect functionality as all objects gets registered.
6) You have a Get attribute function which'll give you the class data as cluster or IPS.
7) Automatic folder Creation with new class to help structure your code.
That's from the top of my head, i assume @thols can come up with some more. 🙂
(8. I assume there's a Set attribute function if you don't want to use IPS, but i've never looked for it so i'm not sure.)
/Y
@Yamaeda wrote:
So there are (only
1) the IDE does a lot of work on the boiler plating (that is still there).
2) the DVR is probably created in a broker of some kind, so the ref stays valid when the top level VI stops.
I see why people use it, but I don't really have a problem with working in LabVIEW "by wire". I though maybe if the solution was "lean" (as in build in LV, but hidden), I could use it in some corner cases (like sharing large amounts of data).
+"So I can access private data of my object without an IPS?" (6)3) Build in Icon generator/editor for fast and consistant Icons (i often use this even with standard code)
4) R-click menu in Project for many tasks as cloning functions in and between classes, changing inheritance and so on.
5) Garbage collect functionality as all objects gets registered.
6) You have a Get attribute function which'll give you the class data as cluster or IPS.
7) Automatic folder Creation with new class to help structure your code.
That's from the top of my head, i assume @thols can come up with some more. 🙂
(8. I assume there's a Set attribute function if you don't want to use IPS, but i've never looked for it so i'm not sure.)
/Y
3, 4 ,7 all falls under "the IDE does a lot of work on the boiler plating (that is still there)." although also useful for by wire classes.
5, 6 and 8 solve problems caused by G#, so how are those benefits?
BTW. Hope nobody's taking this too seriously. You are arguing with an engineer...
I'm not taking it too seriously, Wiebe. Your questions are valid and it is always good to take a step back and ask, "why?".
"5, 6 and 8 solve problems caused by G#, so how are those benefits?"
5: (Garbage collect functionality as all objects gets registered.):
Since you have a create/destroy you are able to control the lifespan of the objects, and that can be an advantage compared to letting LabVIEW do it when the top-VI falls out of scope. So it can be a benefit. Yes, there is a garbage-collection method, which gives you the option of destroying objects at that time instead, which gives you yet another possibility (though I've never used it). But, benefits compared to what? To other by-ref implementations? Definitely. To By-value classes in LabVIEW? I think so because of the IDE-support and since G# supports by-value as well, which I use when appropriate. Benefits to a future NXG-by-ref? Most likely no, except for the IDE-support.
6/8 (or IPS) are used instead of unbundle/bundle in a by-value class. Yes it would be nice to get rid of those, but on the BD its one node vs one VI, so not too much difference. If you can come up with an idea to improve, please do. Maybe an Xnode (lol)?
(btw, "wii-bee", great presentation at GDevCon!)
@thols wrote:
I'm not taking it too seriously, Wiebe. Your questions are valid and it is always good to take a step back and ask, "why?".
"5, 6 and 8 solve problems caused by G#, so how are those benefits?"
5: (Garbage collect functionality as all objects gets registered.):
Since you have a create/destroy you are able to control the lifespan of the objects, and that can be an advantage compared to letting LabVIEW do it when the top-VI falls out of scope. So it can be a benefit. Yes, there is a garbage-collection method, which gives you the option of destroying objects at that time instead, which gives you yet another possibility (though I've never used it). But, benefits compared to what? To other by-ref implementations? Definitely. To By-value classes in LabVIEW? I think so because of the IDE-support and since G# supports by-value as well, which I use when appropriate. Benefits to a future NXG-by-ref? Most likely no, except for the IDE-support.
6/8 (or IPS) are used instead of unbundle/bundle in a by-value class. Yes it would be nice to get rid of those, but on the BD its one node vs one VI, so not too much difference. If you can come up with an idea to improve, please do. Maybe an Xnode (lol)?
I guess you get the most from G# (and\or OpenGDS) if you (do want to) use by reference a lot. Don't think that will ever be a motivation for me.
I will at some point soon re-evaluate both, because the native IDE is indeed a bit spartan. I used to type binary code in the C64 debugger, because it was faster then typing the instructions, so I don't feel slowed down too much by the IDE. But some things are just missing, and take a lot of time every single day...
@thols wrote:
(btw, "wii-bee", great presentation at GDevCon!)
Thanks, that keeps me going!
The people behind those philosophies (including me 
) are usually highly opiniated. That's ok, just make sure you make your own choices and become highly opiniated yourself. But do try to keep an open mind.
Hi Wiebe, I agree with you and my main objective is to get possible approaches from experienced people and after that evaluating advantages and disadvantages and apply the concepts to my problem.
I will appreciate a lot your tips and approach when you find time to inspect the code 🙂
@AYanez wrote:
The people behind those philosophies (including me
Hi Wiebe, I agree with you and my main objective is to get possible approaches from experienced people and after that evaluating advantages and disadvantages and apply the concepts to my problem.
I will appreciate a lot your tips and approach when you find time to inspect the code 🙂
Of course the feedback might be biased by the title of the thread: "LVOOP with DVR - Best Practices and Caveats".
That is already leaning towards DVRs as a solution (which is OK if that's what you want).
I think we can all agree that if you are going for a by reference approach, G# and\or OpenGDS are almost a must. If not, it might still help.
