DVR Read and Write Malleable VIs - Simplify Your Block Diagram

[the_mitten 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 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

[crossrulz 66]

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.

[the_mitten 3]

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.

[smithd 146]

11 hours ago, crossrulz said:

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

DVRs are dynamically created

[pawhan11 6]

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?

 

[Rolf Kalbermatter 448]

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.

[pawhan11 6]

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.

[Rolf Kalbermatter 448]

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.

[the_mitten 3]

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.

[pawhan11 6]

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.

[Rolf Kalbermatter 448]

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.

[DTaylor 28]

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.