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:
I can see similarities with one project where we had an application that sampled lots of data on many channels, these were stored to tdms-files, but some parts (a buffer for the most recent time) were kept in DVRs (G#-classes) and sent through computational "filters" or analyzing algorithms (and that result was also kept in DVRs), and then the GUI could subscribe to those feeds. It works like a charm and with very high performance.
G# is found in VIPM
I assume you had data container classes and used the class references, as they are DVR's 'under the hood'? The Point i'm trying to get across to OP is that you don't really have to mess with DVRs, it's automatic/hidden in G#. (Though when creating data access functions you'll use the In Place Structures a lot)
/Y
@Yamaeda wrote:
@thols wrote:
I can see similarities with one project where we had an application that sampled lots of data on many channels, these were stored to tdms-files, but some parts (a buffer for the most recent time) were kept in DVRs (G#-classes) and sent through computational "filters" or analyzing algorithms (and that result was also kept in DVRs), and then the GUI could subscribe to those feeds. It works like a charm and with very high performance.
G# is found in VIPM
I assume you had data container classes and used the class references, as they are DVR's 'under the hood'? The Point i'm trying to get across to OP is that you don't really have to mess with DVRs, it's automatic/hidden in G#. (Though when creating data access functions you'll use the In Place Structures a lot)
/Y
But what is the benefit of the DVRs being "under the hood"? It's less work, but other then that isn't it exactly the same as using a DVR? What exactly is hidden by G#, if it doesn't hide the IPS? Just the init and close? (honestly interested in how this works).
What I heard (and I'm sceptic until I see it myself) is that OpenGDS actually hides the DVR completely. So everything will look exactly the same as a normal VI. That in itself might actually be a new problem, as nobody will be able to tell the difference. Pretty sure it's not like that, but please enlighten me.
Last hope is NXG will fix this, and have an option to make a class by reference. Then I might actually use one when called for (so still rarely).
Search LabVIEW like a graph!
wiebe@CARYAWhat I heard (and I'm sceptic until I see it myself) is that OpenGDS actually hides the DVR completely. So everything will look exactly the same as a normal VI. That in itself might actually be a new problem, as nobody will be able to tell the difference. Pretty sure it's not like that, but please enlighten me.
Last hope is NXG will fix this, and have an option to make a class by reference. Then I might actually use one when called for (so still rarely).
what is the benefit of the DVRs being "under the hood"? It's less work, but other then that isn't it exactly the same as using a DVR? What exactly is hidden by G#, if it doesn't hide the IPS? Just the init and close? (honestly interested in how this works).
You can check out the GitHub if you really want to dig down into it, but what's happening is that all classes only have 1 int-attribute, which is the DVR (type casted) to the class data, which is a class specific type def. When you access data you use IPS to extract it. Technically it clones the class and data with a wire split, but it's only 1 integer and it'll point to the same DVR, making it reference based.
In the IDE (which i see as the big benefit) we have functions for "create data read VI" which'll give you a template VI with the extraction and IPS prepared.
So, technically, the classes isn't reference based, but the data is.
/Y
...what's happening is that all classes only have 1 int-attribute, which is the DVR (type casted) to the class data, which is a class specific type def. When you access data you use IPS to extract it. Technically it clones the class and data with a wire split, but it's only 1 integer and it'll point to the same DVR, making it reference based.
As another reference, this is how JKI State Machine Object parents classes work as well. Their's was the first instance I saw of even using DVRs. They use a typedef to represent the private class data and then create DVRs from that typedef as the Class private data. It's an interesting pattern, and I'm not sure if the motivation behind it was because of memory management, or to have class-wire forkability. I'd be curious to hear their explanation.
@AYanez wrote:
@Yamaeda: I have tried to inspect G# but I have installed LabVIEW 2015, do you know where can I find a compatible version? Based on the explanation and without to see the code, the implementation is based on including a DVR in the private cluster data of the class? Thanks to expand the information about this toolkit.
There should be G# for LV2014+ on VIPM. Yes, that's a fairly accurate description.
/Y
@Yamaeda wrote:
wiebe@CARYAWhat I heard (and I'm sceptic until I see it myself) is that OpenGDS actually hides the DVR completely. So everything will look exactly the same as a normal VI. That in itself might actually be a new problem, as nobody will be able to tell the difference. Pretty sure it's not like that, but please enlighten me.
Last hope is NXG will fix this, and have an option to make a class by reference. Then I might actually use one when called for (so still rarely).
what is the benefit of the DVRs being "under the hood"? It's less work, but other then that isn't it exactly the same as using a DVR? What exactly is hidden by G#, if it doesn't hide the IPS? Just the init and close? (honestly interested in how this works).You can check out the GitHub if you really want to dig down into it, but what's happening is that all classes only have 1 int-attribute, which is the DVR (type casted) to the class data, which is a class specific type def. When you access data you use IPS to extract it. Technically it clones the class and data with a wire split, but it's only 1 integer and it'll point to the same DVR, making it reference based.
In the IDE (which i see as the big benefit) we have functions for "create data read VI" which'll give you a template VI with the extraction and IPS prepared.
So, technically, the classes isn't reference based, but the data is.
/Y
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).
G# and OpenGDS offer other goodies as well of course, but I'll probably wait for XNG to have native 'by ref' classes before I start using one occasionally.
@AYanez wrote:
It is currently an FGV with a DVR.
A FGV with a DVR? Hmm. I avoid both, but don't really get why you'd need to combine them?
As for the problem... It's a refactoring issue. So how do you go from A to X or Y or Z? So this makes it a challenge: you want to know a) what the end result will be, and b) how to get there.
Switching a complete application from one paradigm to another is hard. Not knowing what will work makes it even harder.
Often, the workload and not knowing will stop people from making an attempt. Although the application grows out of it's bounds, hacks are added to facilitate new features. That is undesirable (putting it nicely), so (virtual) kudo's on making an effort.
Not sure how well posting text messages will work on solving this. I might have a look at the code soon, and others will probably too. Just know you will probably get totally different solutions\suggestions, like use XYZ Framework (the 'F' word 
). Most suggested solutions will probably only take you half way. Worse you can do is combining them, as they probably all have different underlying philosophies.
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.
(just a morning rambling)
My advice to OP: try one approach - fail - refactor.
Ayanez: G# is available in VIPM. Just search for G#. It installs with lots of examples to explain how it works and how it can be used
Yamaeda: No need to get the code on github, the installed G#-classes are open, as in open-source...
But if you want to ask G#-related questions or want to contribute, go to the NI forum for G#.
Yamaeda/Wiebe: The IPS is hidden. You can use it if you want, but since you have access to your attributes without using the IPS, and property creation/refactoring is also automated in G#, it is very rarely needed.
Wiebe: About "what exactly is hidden" and "benefits of G#: I think the G#-help overview sums it up pretty well (I think the list is too long to paste here). 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, the very basic interaction with class/method management and refactoring will still require some add-on to be able to be more productive. Using only the LabVIEW class and method operations is just way too slow to cope with.
As long as the design is solid, I see no reason in combining philosophies (e.g. by ref/value). But you should investigate if a combination of frameworks will work seamlessly, or choose one that embraces/handles both/all.
My advice to OP: try one approach - fail - refactor.
Ayanez: G# is available in VIPM. Just search for G#. It installs with lots of examples to explain how it works and how it can be used
Yamaeda: No need to get the code on github, the installed G#-classes are open, as in open-source...
But if you want to ask G#-related questions or want to contribute, go to http://forums.ni.com/t5/G/gp-p/5049.
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.
Wiebe: About "what exactly is hidden" and "benefits of G#: I think the G#-help overview (https://www.addq.se/document/Gsharp/Overview.htm) sums it up pretty well (I think the list is too long to paste here). 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.
As long as the design is solid, I see no reason in combining philosophies (e.g. by ref/value). But you should investigate if a combination of frameworks will work seamlessly, or choose one that embraces/handles both/all.
(I just posted and edited and then my post was marked as spam, hopefully there will not be a duplicate now. And hopefully it will go better now without hyperlinks)
