LV2017 Parallel DVR Access Bug?

[G-CODE]

I just posted this over on the NI forums. Can anyone else confirm. This seems really strange, but I still think I might be missing something. I've got a probe on a block diagram that doesn't agree with the data coming out of the VI that is the source.

https://forums.ni.com/t5/LabVIEW/Parallel-Access-DVR-Bug-LV2017/m-p/3696695#M1039519

 

 

[LogMAN]

I get the same behavior on my machine using your sample project (attached to the post on the dark side). As in your picture the indicator of the Sub-VI changes its state, but the indicator on the Main VI doesn't.

However, I created a VI from scratch with the exact same block diagram as "ReadDVRData" (created manually) and it works fine. Copying the block diagram doesn't work as well as reconnecting and replacing the terminal doesn't work. This is something NI should be concerned about. Looks to me like the terminal assignment is broken or some other weird optimizations failing. Did LabVIEW crash during development by any chance?

[G-CODE]

Glad someone else is seeing the same behavior in the example I posted. The fact that you were able to create a new VI and couldn't reproduce the behavior is indicative of what I've been experiencing. These bugs are intermittent, but the example I posted on the NI forums wasn't the first time that happened to me. LabVIEW didn't crash while I was working on the example I posted. I've got another example that exhibits the same behavior and uses code from the actual project I was working on. I haven't yet determined what will cause the code to compile that way, but imagine how difficult and strange it is to track down these bugs when all of a sudden your code just stops working.

Another strange artifact I've seen by creating accessor methods this way is that sometimes LabVIEW has changed these VIs to reentrant execution and turned on inlining. I can't tell you how many times I've examined the execution properties and found these settings changed, yet I had never changed them. I definitely wouldn't turn on inlining unless there was a good reason to do it.

What I've concluded from this is that DVR parallel read-only access is really buggy and shouldn't be used. It seemed innocuous enough that to turn it on for a read method shouldn't have caused any problems.

After spending quite a bit of time developing a project in 2017, I agree with Neil Pate's sentiments expressed last week. The LV 2017 editor has some issues. I'm going to keep moving forward with this project in LV 2017, but if I had to start again from scratch, I'd pick LV 2015. The editor in 2015 seemed to remain responsive and snappy on big projects, unlike 2017 which will (at times) slow down to a crawl when all you're trying to do is move something across a block diagram. Additionally, I haven't mastered exactly when to press the 'W' key to turn of maintaining wire connections so that feature seems like more of a hindrance than it is helpful.

 

[Rolf Kalbermatter]

Disable the live drag feature as is mentioned in the thread from Neil. This will get rid of the potentially long and jerky refresh and according bad drag drop behaviour that you can get in larger projects and VIs with this feature.

 

Also another question: What happens if you don't pass back the DVR reference into the class wire? I generally don't do that at all but simply use an unbundle to get the DVR from class private data and then an IPE structure to dereference the DVR, without putting the DVR reference back into the class after. I agree that this should still work, but I have a hunch that this particular use case might have been overlooked during testing of the read only flag for DVRs.

Edited October 2, 2017 by rolfk

[hooovahh]

On 9/30/2017 at 11:19 AM, planet581g said:

What I've concluded from this is that DVR parallel read-only access is really buggy and shouldn't be used. 

I'm starting to feel the same way.  I was super excited when this came out cause I had some real places that I could start using it right away.  But I found a bug on RT (which I've submitted no CAR yet) which can cause RT applications to crash if you access a reference that is no longer valid (Queue or DVR).  This is bad but the answer for now is just don't access invalid references until this is fixed.  The problem is I've seen plenty of times where after I enable read-only DVRs, the reference goes invalid in some places causing a random crash.  Debugging these crashes is really hard, and isolating it into a small reproducible project that NI and others can test with is also hard.  But it is also difficult for NI to fully test these new features on a large production level project because that's not what NI does, we do.  Thank you for posting it to NI, hopefully we get a fix as an F patch.

[DTaylor]

On 9/29/2017 at 7:55 PM, planet581g said:

Can anyone else confirm.

I can confirm as well. Parallel read-only access is broken until this is fixed.

I played around with the bug a little bit, and it appeared as though up-to-date data fails to make it out of the SubVI when parallel read mode is enabled (super weird).

[hooovahh]

I did find a work around for this.  If you add an Always Copy to the ReadDVRData.vi coming out of the read function, this VI appears to work as expected.

[G-CODE]

I'm happy to report that the bug seems to have been fixed. I opened the example code I originally posted using 17.0.1f1 (32-bit) and the buggy behavior has gone away.

[jacobson]

1 hour ago, planet581g said:

I'm happy to report that the bug seems to have been fixed. I opened the example code I originally posted using 17.0.1f1 (32-bit) and the buggy behavior has gone away.

Didn't see the CAR reported in the NI forum listed on the bug fix list but the behavior was fixed as part of CAR 654700 which is in the list.