Search the Community

The introduction of parallel, read-only access for DVRs in LabVIEW 2017 adds a great deal of flexibility to using DVRs to monitor values in parallel executions of code. Fo\The downside of this, of course, is the necessity of using the In Place Element (IPE) throughout your code simply to read the value. Having IPEs throughout your code just to read a value both takes up block diagram real estate and also takes more clicks than desirable to insert. Similarly, though less frequently, there are times when you only need to update the value within a DVR without actually performing any logic inside of the IPE. This situation is less frequent, at least for me, as I am usually using arrays or classes with DVRs such that I actually need to modify the existing data rather than simply replacing it. A more preferable solution to the above situations would be to have Read/Get and Write/Set VIs for the DVRs to simplify the process of working with them. This way, and IPE on the block diagram would only be needed when you were actually modifying the existing data within the DVR, rather than simply overwriting or returning the current value. Thanks to the power of malleable VIs and the type specialization structure that is now officially released in LabVIEW 2018, a better solution is now available. I’ve created two malleable VIs, Read DVR Value (Parallel) and Write DVR Value that allow you to perform a write and a parallel read on any DVR data type. Now, you can use a single VI that you can insert via Quick Drop to read or to write DVR values. Download the attached ZIP file to access the two malleable VIs and example code, and please let me know your thoughts in the comments! DVR Read and Write VIs 1.0.0.zip

Hi I am reading big TDMS files (~1GB) and I try to minimize memory usage. I read a signal once and I want to keep it for later usage, so I tried to write it to a DVR in the hope that I have only one instance of the data in memory. However the task manager tells me that uses 2 times more memory than it should. I think the problem is that the array is not deallocated although I don't need it after writing it to the DVR. Is there a solution to make sure I don't have copies of data?

Can anyone please tell what a DVR [ Data value reference ] is ? I want to know at what situation it will be used and what are the advantages we get by using DVR. I am really confused in this topic . If someone has any code in which they have worked with DVRs. kindly share it to me. Thank you.

Hi everybody, I'm running into something I don't really understand. Maybe you can help me here ! I've got a LVLIB that is used as an 'Interface': it exposes public VIs which wrap around public functions of a private class (see code attached) . The class is private because I want to force the users to use the 'interface' functions. In one of my interface VI, I create a DVR on the private class (Interface_init). The DVR is stored into a typedef (FClass_DVR.ctl) and this typedef is the 'reference' that link all the interface public functions. In TestCode.vi (which is not part of the lvlib and illustrates the standard code that a user can create to use my driver), I can call my public interface functions and link them without any problem. But as soon as I create an indicator on that reference (to create a state-machine-context-cluster for example), my TestCode VI breaks ! The error returned is : This VI cannot use the LabVIEW class control because of library access scope. The LabVIEW class is a private library item and can only be accessed from inside the same library or libraries contained in that library. I understand that the class is private. But the DVR is contained into a public control. Using an In Place structure on that DVR into TestCode would not work, since the class is private. So why is the DVR control problematic at that point ? Creating it do not breaks any access protection... Am I missing something ? DVR Private POC.zip

I've got some weird stuff going on with a cRIO project I'm working on wanted to get some opinions on it. The basic architecture is a set of classes that do some process. That process registers with a server. The internal data of the process is held in a DVR and the server get's access to that DVR. Clients use TCP to ask the server to do something, the server makes a call against the classes DVR and returns a response to the client. To simplify the issues I'm seeing I created a class that internally just increments an integer every 500ms. The client asks the server what's the current count, the server asks the Counter class and returns the answer to the client. This works perfectly fine when running the VI in the IDE. When built it connects, will get the JSON message back, but always gets a default value from the DVR call (zero, in this case). As soon as I open a remote debug panel to the cRIO, everything is working. The count is correct, the client calls work, just like normal. As soon as I right-click, close debug, it goes back to zero. Open debug works, close debug, back to zero. I know the DVR isn't getting dropped because the count continues to increment while not in debug, the process is still running happily with no issues. Here's a few screenshots of the code; Count Class process (get the count, increment, write it back to the DVR) - Counter Class process You can see the DVR vi's are actually vim's using a cast. I can't imagine that's the issue. Server Side call - Server Side calls All this does is get the count from the DVR (same as above) and wraps it in JSON and passes it back to the client as a JSON string. I also implemented an Echo class that ignores the process and DVR's, it just takes whatever string you sent form the client to the server and passes it back with a prepended "@echo". This works when running as an executable with the debug turned off so I know the client, server, and the server/class calls are all working as expected. Any thoughts here would be welcome, thanks. edit: I added the any possible errors coming from the variant cast to the JSON reply. When the debug is open there are no errors, when the debugger is closed it throws error 91, but the in-place element structure reading the DVR does not throw any errors. How can a variant not exist until a debugger is opened and than it magically exists? edit: the internal data dictionary is a wrapper around a variant attribute, I wired out the "found?" terminal all the way out to the JSON reply and if the debugger is open the attribute is found, but not if the debugger is closed. Anyone have issues with Variant Attributes in Real-Time?

I've been working a lot lately with by-reference architectures that still cooperate completely with LabVIEW's implementation of OOP and polymorphism. I've also recently taken an interest in trying to speed up development with secondary providers (similar to GOOP) to enable automatic creation of accessor VIs hidden behind the DVR, automatic creation of the private data type and constructor/destructor, etc. within the project window. I'm generally not a fan of the extra stuff that goop adds in to classes, I'd prefer to keep the source code looking as close to a normal class as possible. That said, I've started on my first ever XNode and it's a cross between an unbundle by name node and the -> operator in C. It functions just like a normal UBN, however it was also pull items out of DVRs. Having to plop down a UBN to pull out the reference from the class, an in place node to dereference, and then another UBN to pull the data out gets tiresome after about the 100th property VI gets written. So far I've gotten the node drawing completed (except for data type coloring of the labels), the type inferencing from the input wire, and the popup menu for selecting an item. Next up will be the menu selection code so that the names will finally show up in the terminals! Then I get the daunting task of scripting up the GenerateCode ability >_> Anyone interested in something like this? Following this will be a match to the Bundle by Name node that serves the same purpose except to write the items.

I'm not able to solve DVRs problem. See project file. 1. IO.lvlib exists in two versions: one with single variables + processSimulation.vi that simulates process/machine i.e. takes outputs, calculates process behaviour and writes inputs; the second version of IO.lvlib has variables as IOaliases. Simply swaping these two versions allows to run project on real target with machine or to run project on PC without target/machine. Thats why I use these IO.lvlib variables. 2. Every subsystem is an object/class with method DoSomething that calculates response to inputs and writes outputs. 3. I¨d like to call these objects DoSomething.vi method in one loop. Thats why it's not possible to have inputs/outputs as terminals of DoSomething.vi 4. I've tried to solve the problem with DVRs: every object is created by constructor including inputs/outputs DVRs initializing. However I'm not able to use DVRs inside DOSomething method. What am I doing wrong? One solution is to avoid loop call and spread all (about 50) DoSomething.vi calls including inputs/outputs terminals onto block diagram. But this is definitely not well arranged solution. Do you see anything wrong concerning my solution in general? How to access DVR inside class method? Any other ideas, comments? Thanks. IOrefs.zip

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why? See the attached code (LV15) for an example. I don't want to use the ACBR node right now because I want to set some control values of the VI ref on a different diagram than the one that will run it. (I just want to pass the VI ref between calling diagrams, not all the values that'll be passed into it.) DVRtest.zip

I have some old VIs to which I need to give some love. All the error clusters were unwired, so I am working on that... I am wondering what would be the best practice when it comes to DVR. The IPE structure gives an error cluster on both the left and the right data node. The attached picture shows all the error handling I can think of, but I wonder if it's not an overkill. Here is the breakdown: 1) Outer case structure: If there is an error before going inside the IPE, it just skips the IPE altogether and propagate the error cluster. 2) IPE left data node: I don't need to merge it with any incoming cluster since we are in the "no error" case (what about warning? am I speaking too quickly?). 3) Inner case structure: as long as the code inside it knows how to deal with the error (likely skipping its own code and propagating the error), I probably don't need this structure. What do you think? 4) IPE right data node: in what scenario would it actually give en error? If the DVR is bad, the left data node will take care of generating the error... Is it there is case the DVR becomes bad during the IPE execution? If I wire the right data node, then I need to merge it with the error cluster coming from the code inside the IPE... Any comment more than welcome!

Hello all! I am new to LAVA, but I have been lurking for many years and have gotten a lot of great advice and insight into LabVIEW programming here. I recently got my CLD, and I'm trying to get a better handle on doing things the Right way. One issue I run into regularly is how to deal with class private data. I typically use device classes, where each class represents a different embedded device that my application communicates with. One main loop is used to send/receive data from each device, and then other loops handle the UI updates, background calculations, etc. I think that is all pretty standard. Due to the by-value nature of wires, I cannot create a device class and pass it to several loops without forking the device private data. When the main update loop updates the class's private data, all other loops do not see this change due to the class having been forked. So what I've ended up doing is putting DVR references in each class's private data, and then the get/set accessor VIs use an IPE structure to access the data via the DVR ref. This all works pretty well, but on many forums (especially NI forums) I see seasoned LV programmers saying that DVRs + IPE should almost never be used. I've considered using FGVs instead of the DVR, but that seems similar in that the data would be stored in the FGV instead of the class's private data DVR, so what is the difference? I feel like I must be missing something here. It seems that class private data should be a DVR by default, otherwise what is the point if the class wire is forked? How do you guys deal with this issue?

Hi, I would like to play an idea out to you about having a composite class put itself back in its owning object by a DVR. Is that a good or a terrible idea? Background I need a class that represents some different LabVIEW files, and which can offer some operations on those files; LVFile.lvclass. LVFile.lvclass has some children (LV file types) and it owns a composite object LVFileRefs.lvclass: LVFileRefs LVFileRefs contains the following: - An enum stating the file type. - A reference to the LabVIEW file (class reference, library reference, project reference, or VI reference). - The path to the file on disk (if it is saved to disk). - Info if the refnum was created by the object or passed in from the outside (used by the Close method). I need LVFileRefs as a composite object (instead of that data living inside LVFile) since New starts by instantiating an LVFileRefs object before New can decide which child to instantiate: One of the responsibilities of LVFileRefs is to keep disk path and file reference synchronized. This means that you could start out with a VI in memory for instance, and create an LVFile object for that. This does not yet have a File Path. If you then save that VI, then LVFileRefs will update its internal File Path field from <Not-A-Path> to the proper path. If for whichever reason the original file refnum goes stale, LVFileRefs will also be able to open a new refnum from File Path if possible. All transparent to the user. So LVFileRefs maintains a firm grip of the file whether it being in memory only or on disk, and it can tell you which type it is (some types take more programming to tell apart than others, and type can change as well). All stuff that makes writing apps that handle many different file types simpler. No DVR approach Normally I wouldn't expose a naked refnum to the user, but one of the features of LVFile is actually to serve the proper refnum, so in this case I do. That is currently done with accessors on LVFile, and then an LVFileRef method: Since LVFileRefs can update its embedded refnum it is important to write the LVFileRefs object back into the owning LVFile object (or else Close for instance wouldn't close the correct refnum, and several other issues). DVR approach Having to write back the LVFileRefs object is error prone - the user could forget to do it, and having to do it in the first place is irritating. I'd rather you could omit the write back step: The idea is to have LVFile embed a DVR to itself inside its LVFileRefs object, with which LVFileRefs can write itself back into its owning LVFile object with whenever LVFileRefs has updated itself. There shouldn't be any racing possible, as LVFileRefs is actually the representation of the LV file, and DVR access is mutexed. Am I insane considering this? Cheers, Steen

Hi Everyone, This is my first post and am just beginning to learn OOP so please bear with me. I was curious on whether when you use a DVR to encapsulate a class i.e. force an initialization to occur before other methods, and then close the reference to that DVR. Is the class removed from memory completely or is it just the reference that is cleared. Thanks!

I'm working on a large project and have run into a quandary about how to best deal with a large shared data set. I have a set of classes that define 3 data structures. One is for a script read from disk that the application executes. Another is the output data from the program, generated as the script is executed. The last is a summary of the current state of execution of the script. The first two can be significant in size and are unbounded. In my application, I have one actor (with sub actors) responsible for reading the script from disk, executing it and collecting the data. It also updates the summary status data. Let's call this the control actor. I have another actor that takes the data and displays it to the user, allowing them to navigate through it while the script is being executed. Lets call this the UI actor. The last actor is responsible for communicating the summary to another application over the network. We will call this the comm actor. So, the control actor is generating the data and the other two are consumers of the data. I had originally thought to have all the data stored as state data in the control actor and then as it is updated/created just message it to the other actors. But then they would essentially have to maintain a copy of the data to do their job. This seems inefficient. Then I thought I could wrap the data classes in DVRs and send the DVRs to the other classes. That way they could share the same data. The problem with that is they would not control when their data gets updated. And I am violating the philosophy of actors by creating what is essentially a back channel for data to be accessed outside of messages. Also, I could block the 'read' actors when I am writing to the DVR wrapped class. I would have to be careful when updating subsections to lock the DVR in an in-place structure to do the modify and write. Then comes the question of how to best alert the readers to changes made to the data by the writer. Simpy send them a message with the same DVRs in it? Or send a data-less message and have them look at the updated values and take appropriate action? So, any best practices or thoughts on how to resolve this issue? I appreciate any feedback.. -John

[cross posted to forums.ni.com] Greetings LVOOP masters. I realise this is not a simple question but I would really appreciate your opinion please. I'm trying to make some data handling improvements to a test sequencer application that I've written. User defined tables determine how much data is acquired. Long tests can easily generate 100's of MB's of data. Collecting, analyzing, reporting and saving that data tends to create copies and we can easily run out of memory. It's currently written without any LVOOP methodology but that is about to change. I'm new to OOP but have been reading alot. I have 2 objectives in refactoring the data handling VIs: 1) Enable different measurement types to be collected, analyzed and saved according to their unique properties. Presently any measurement type that isn't a dbl waveform is shoehorned into one and treated exactly the same. XY style data is resampled losing resolution and digital data is converted to dbl. This results in a lot of extra data being generated for no good reason other than to fit in a waveform. 2) Reduce data copies. Because the measurements are shuffled around from one module to another the copies become a problem. I'm hoping to use DVRs to the objects and pass around the references instead, reducing copies. I'm quite comfortable with objective 1, it's number 2 I'm not sure about. After reading this excellent whitepaper here I feel I need to get some expert advice on whether my approach is correct. In particular these two statements have raised questions in my mind: "Be aware: Reference types should be used extremely rarely in your VIs. Based on lots of looking at customer VIs, we in R&D estimate that of all the LabVIEW classes you ever create, less than 5% should require reference mechanisms." "LabVIEW does not have "spatial lifetime". LabVIEW has "temporal lifetime". A piece of data exists as long as it is needed and is gone when it is not needed any more." Q1. With that in mind, will all my effort to use DVRs actually reduce data copies significantly in my case? I plan to have a single FGV VI where the objects are created and stored in an array. Then when other modules need access to the data, a DVR is created and handed out. Once these modules are finished with the captured data, they flag it as deletable and the measurement FGV deletes the DVR and removes the object from the array. Q2. Is that the right way to go about it or am I missing the point of LVOOP and DVRs? Below is a simplified mockup of the way measurement data is currently used in the application. LVOOP Experts: Your feedback/suggestions are much appreciated. LVOOP DVR Measurement Optimization.zip

This thread is a follow up to the point discussed in another thread. I opened a new thread to avoid polluting the previous thread with a second discussion. The link is http://lavag.org/topic/16669-universal-fgv/?p=103311 and I want to react to a message from JohnMc86: Hi, I get the advantage of working with both DVR and Objects. However I am still very sceptical about the use of the in place structure to read the object directly in the main VI. I see the DVR Based Objects a really safe way to work with class while making sure they are initialized and to avoid data copies. Working with In Place on the main VI theoriticaly gives me the right to remove an initialized object from a reference and replace it with another object from the class or, even worse, a non initialized object. I am really sceptical on the "well coding" of this based on that point and also based on the fact that you are then manipulating an object outside a method. Is it really the best way to go? Would it not be prefearable to write this function in a method (like "Copy Object" where the object in the reference is duplicated and both object and reference are output. Or a "To Object" and "To Reference" Method with some error handling algorithm to make sure the object input of the "To Reference" method has correctly been initiated or is the same instance than the one that has been called from the "To Object" method)? I ma still "new" to the GOO world, so there might be some subtlety I do not see. Cheers

Is it a good practice to keep objects as DVRs within another object as shown below In this case I am loading different drivers within HAL and I have no intentions to void dataflow by using DVRs rather I want to keep less memory for HAL.