Jump to content
the_mitten

DVR Read and Write Malleable VIs - Simplify Your Block Diagram

Recommended Posts

I can't say I support the use of the Write DVR Value.  The point of using a DVR is to protect critical sections of code (ie avoid race conditions).  If you are just randomly writing a value to a DVR without doing the Read-Modify-Write protection, you might as well use a Global Variable and get better performance.

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, crossrulz said:

I can't say I support the use of the Write DVR Value.  The point of using a DVR is to protect critical sections of code (ie avoid race conditions).  If you are just randomly writing a value to a DVR without doing the Read-Modify-Write protection, you might as well use a Global Variable and get better performance.

That's a good point that I hadn't considered. In my mind the usefulness of the Write VI is more of the case of quickly initializing or otherwise performing a reset/overwrite of the existing value of the DVR, and to be used in conjunction with the IPE structure and the read/modify/write paradigm as normal. An example for me recently is needing to ensure that a DVR used throughout the application was initialized to defaults after a certain sequence had executed. Hence, wiring a constant to this VI was much more convenient. Does that seem more reasonable, or still prone to error rather than helpful?

I definitely see how this could be misused such that the critical code is placed outside of the IPE. I'll work on coming up with a better example to show more of the specific use case and provide a clearer explanation of when it could be helpful.

Share this post


Link to post
Share on other sites
11 hours ago, crossrulz said:

you might as well use a Global Variable and get better performance.

DVRs are dynamically created

  • Like 1

Share this post


Link to post
Share on other sites

Seems nice but last time I have checked there were some serious bugs using this read only feature.  CAR 671221 and I think 3 others. Is there a link at NI site where we can see all bugs and if they were solved?

What is the performance boost when using this read only feature compared to normal read and write?

 

Share this post


Link to post
Share on other sites

The performance boost can be from more or less negligible to serious. It really depends what else you are doing on that DVR. If there is no other access to the same DVR at the same time, the gain from just locking the DVR for the value read rather than the duration of the entire IPE structure really won't matter at all. There is no other code that could be blocked waiting for the DVR and consequently nothing that could be slowed down. If you have many concurrent read only accesses to the same DVR then you will see a significant improvement.

Before the read only access, each DVR IPE access had to wait for any previous IPE access to that DVR until it was finished. You could achieve similar behaviour before by just using the IPE structure to reference the necessary data in the DVR and do any further processing outside of the DVR. As such the only advantage of the read only access is that the DVR doesn't need to be accessed a second time before leaving the IPE.

If there is a IPE non-read-only access to the DVR active however any read-only access still needs to wait for the write access to finish and therefore can be blocked.

Edited by Rolf Kalbermatter

Share this post


Link to post
Share on other sites

Makes sense. I remember one project based on GDS and DVR template. We used IPE to read some data all the time. Each IPE was just to unbundle data outside the structure, no processing done inside to avoid longer locks.

It would be nice if the compiler could detect and optimize this when LV is upgraded to new version, so we wouldn't have to go to each IPE and remove write wire.

Share this post


Link to post
Share on other sites
8 minutes ago, pawhan11 said:

Makes sense. I remember one project based on GDS and DVR template. We used IPE to read some data all the time. Each IPE was just to unbundle data outside the structure, no processing done inside to avoid longer locks.

It would be nice if the compiler could detect and optimize this when LV is upgraded to new version, so we wouldn't have to go to each IPE and remove write wire.

I'm pretty sure that the IPE structure where the DVR wire was directly wired from the left access node to the right access node without doing anything else with the wire (except a unbundle to get some data out of the DVR content) was already optimized by LabVIEW to be more or less a NOP (no operation) for the right access node. The only real impromvement with read-only setting is that the DVR doesn't need to be locked for the entire IPE but only for the read acces at the left access node.

Share this post


Link to post
Share on other sites
On 7/14/2018 at 6:30 AM, pawhan11 said:

Seems nice but last time I have checked there were some serious bugs using this read only feature.  CAR 671221 and I think 3 others. Is there a link at NI site where we can see all bugs and if they were solved?

 

CAR 671221 was fixed in LabVIEW 2017 SP1. The best place to look is in the bug fixes list for the appropriate LabVIEW version (here is 2017 and 2018) or in the patch details (2017 and 2018).

 

As you'll notice, this specific CAR number is not called out on any of these pages. Not every CAR that is fixed is published online, but you can always contact the support team to determine if a specific CAR was fixed.

Share this post


Link to post
Share on other sites

Thanks fo reply.

Can I also check list of all bugs still to fix?

Knowing what was fixed without what is still reported/to fix is limiting. 

Sometimes I start an discussion and someone from NI reports this is known bug that will be fixed. If we had acces to reported bugs it could save a lot of time.

Share this post


Link to post
Share on other sites
On 7/16/2018 at 7:39 PM, pawhan11 said:

Thanks fo reply.

Can I also check list of all bugs still to fix?

No that information is generally only available to people outside of NI on a limited "needs to know" base and the decision for that is handled by AEs for simple issues or the product manager for the product in question for more involved issues.

Share this post


Link to post
Share on other sites
On 7/13/2018 at 9:17 AM, crossrulz said:

I can't say I support the use of the Write DVR Value.  The point of using a DVR is to protect critical sections of code (ie avoid race conditions).  If you are just randomly writing a value to a DVR without doing the Read-Modify-Write protection, you might as well use a Global Variable and get better performance.

I think it can be useful in cases where you don't need RMR protection and the DVR is part of some sort of data structure that you may have more than one of, making globals not an option or a poorly scaling option.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • 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 jhoehner
      Hello All,
      First time LAVA poster here with my first question. Why do some LabVIEW programmers insist on wiring the error cluster to the bottom of their VI as opposed to the sides as shown in most NI documentation. Is there any benefit to it? Is it 100% a preference thing? Is there a way to make LabVIEW connect error wires like this automatically?
      I've only seen it in advanced LabVIEW code from experienced programmers and some parts of the Actor Framework.
      Your insight and experience is appreciated! 

    • By IpsoFacto
      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?
×
×
  • Create New...

Important Information

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