Weird cRIO Behaviour with DVRs
-
Similar Content
-
By Axelwlt
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?
-
By Ram Prakash
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.
-
By Zyl
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
-
By jdeantx
With exciting projects in oil and gas, aerospace, utilities, and other industries, Vertical AIT is looking to hire skilled LabVIEW developers and architects in the Houston area. We are an Alliance Partner, and we specialize in embedded development.
Requirements:
- US citizenship (required by our contracts)
- Industry experience in production software development
- Embedded cRIO development experience (Real-time and FPGA)
- Certification (CLD, CLA, and/or CLED) preferred
- Must be meticulous and detail-oriented
We offer great benefits, and we prioritize a healthy work/life balance.
Learn more about Vertical AIT at www.VerticalAIT.com, and please send resumes to jobs@verticalait.com.
-
By the_mitten
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
-
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.