Persistent Data Value Reference (DVR)

[EthanStern]

I have long defended NI's decision to bind the lifespan of DVRs to their creator VI but, with the addition of malleability (totally awesome) and the fix in LV 2020 that allows "New Data Value Reference" to be called directly in an inlined VI (thanks, AQ), the ephemeral auto-cleanup behavior of DVRs is now a big blocker to a reference-based strictly-typed API.

I want to open a strictly-typed and malleable reference and keep that reference open until I choose to close it, regardless of whether the opener leaves memory. Without malleability, I could delegate the DVR creation to another thread/VI and get the persistent reference back by callback but I can't have the home-baked persistence and the malleabilty.

 

Please add a persistence/auto-cleanup flag to New Data Value Reference so I that reference can persist if I want it to. (I need both the persistence and the malleability to write some really cool code.)

Here's an old request for this feature that was declined, but things have changed a lot since then: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Persistent-DVR-s/idc-p/2856348#M27799 

[AristosQueue (NI)]

[wiebe@CARYA]

>Sorry... not a use case I've ever dealt with.

You never had dynamic loops that you'd abort to change while the main keeps running? That's one of the best features of LabVIEW.

At least with a DVR the code won't hang forever. I never noticed the DVR problem but it is indeed a problem.

Anyway, I avoid DVRs (and 1 elm. queues) at all cost, because they're not persistent. I can't open a sub VI, stop the main, test the sub VI. That's a deal breaker.

Maybe LV could facilitate a reference daemon in some way? I think some toolkits use reference daemons? Because this problem isn't just with DVRs. Daemons are quite tricky though, mostly because they have to be started and stopped when appropriate. 

[AristosQueue (NI)]

> You never had dynamic loops that you'd abort to change

> while the main keeps running? That's one of the best

> features of LabVIEW.

Nope. Never had cause to build a single app that was amenable to such a setup. The closest I come is some client/server systems involving two independent apps: the server app is running and I connect with a client app, do some work, then abort-restart the client without the server missing a beat. I've done a lot of that. But client and server wouldn't share any refnums -- it's all been network communications based (VI server sometimes, TCP sometimes, files pipes once, etc).

[wiebe@CARYA]

Well, I have. Guess we have to choose between:

1) 1 element queue: (possible) application lock

2) DVR: (possible) data corruption

3) Avoid "by reference"

I'll stick with 3)...

[drjdpowell]

A late reply: I actually think that s static DVR as discussed here is a worthy idea.  I also think there is promise in the above linked idea of an ACBR call on a malleable VI.  It would have to be an Async Call By Static Reference for reasons AQ discussed in that thread (can't have type adaption or compilation at runtime).

[wiebe@CARYA]

I've seen file being opened in step 1 of a wizard, and in step 2 the reference became invalid. Obviously, as step 1 stopped running. Not too hard to find nor fix, but still a hassle. Newbies would first see this as a bug, and would struggle for a solution.

Is a DVR significantly different from a file, queue or any other reference? (That's a real question, not rhetorical.)

I'd really like to make any reference independent of it's creator (TLDS), and optionally be re-attached to another:

I'm sure it's somehow dangerous and will lead to bad architecture 😂, but the tools we have now is very little...

[drjdpowell]

>I've seen file being opened in step 1 of a wizard, and in step 2 the reference became invalid. Obviously, as step 1 stopped running. Not too hard to find nor fix, but still a hassle. Newbies would first see this as a bug, and would struggle for a solution.

That implies you are using Async Call by Reference for your steps, with reference-sharing between the steps, which is both way beyond a Newbie and a strange way to make a Wizard (an inherently step-by-step synchronous thing).

>I'm sure it's somehow dangerous and will lead to bad architecture 😂

I agree.

[wiebe@CARYA]

>>I've seen file being opened in step 1 of a wizard, and in step 2 the reference became invalid. Obviously, as step 1 stopped running. Not too hard to find nor fix, but still a hassle. Newbies would first see this as a bug, and would struggle for a solution.

>That implies you are using Async Call by Reference for your steps, with reference-sharing between the steps, which is both way beyond a Newbie and a strange way to make a Wizard (an inherently step-by-step synchronous thing).

No, just a 'simple' Open VI Reference, set control and run method. I never use ACBR as it always made LabVIEW crash or leave my classes blocked (or both).

It seems from the questions on the forum that ACBR is used a lot by (and recommended to) newbies. (It usually can be avoided.)

So let's say intermediate users that can figure out VI Server might not know the fundamental details about references. I've been bitten by it a few times.

[MikaelH]

That sounds like this VI.

[drjdpowell]

Ah, old school.  I can't remember the details of using Run VI.  I wouldn't recommend any use of Open VI ref for a newbie, be it Run VI or ACBR.  Only an ordinary CBR on a strict-typed, static reference would be simple.