Jump to content

Search the Community

Showing results for tags 'dvr'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW Community Edition
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
    • OpenG
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help

Categories

  • *Uncertified*
  • LabVIEW Tools Network Certified
  • LabVIEW API
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
  • LabVIEW IDE
    • Custom Probes
  • LabVIEW OOP
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 16 results

  1. 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?
  2. 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.
  3. 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 in
  4. 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 no
  5. 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
  6. 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. Tha
  7. 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.
  8. 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
  9. 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
  10. 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 pr
  11. 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 refe
  12. 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!
  13. 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
  14. [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 readin
  15. 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 I
  16. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.