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-real-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.

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.


×
×
  • Create New...

Important Information

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