Using "New Data Value Reference" in a loop

[beavercreek]

Hello all,

I've just read about Data Value References (DVR's?) and I'm trying to use them with functional global (see attached).

I don't think I'm doing it right.  The end goal is a pseudo producer/consumer.  My concern is that I don't feel executing the New Data Value Reference primitive and re-stuffing the result into the FGV, should be happening every loop.

Of course I could "broadcast" the data with a single element gueue (where enqueuing the new data would occur every loop).  I just thought I'd play with these.

[tyk007]

Agreed; your "init" could effectively create the DVR, removing the need for the "set".You don't need a new reference (DVR) every time - just update the data it points to.

[crossrulz]

It looks like you just completely missed the point of a DVR.  A DVR is a reference to a point in memory.  You could store the reference in a FGV, but the reference itself will not need updated.  So you do not need to be constantly writing to the FGV.  Just init the DVR once.

---

beavercreek wrote:  The end goal is a pseudo producer/consumer.

---

Perhaps you should describe what your actual goal is here.  There is likely a much better way.

[beavercreek]

My confusion is that in the attached code, Ch2 is the one that functions (ie I must stick a new data value reference into the FGV every loop).

Ch1 sits at a value of zero when read by data_reader.vi.  Ch2 is updated as data_source runs.

I expected the location of "Loops" to stay in one location so I could use a stale reference to "Loops" to read its value over and over again.   I didn't think I would have to update the reference (or the FGV) every loop.

[RavensFan]

It seems like you are confusing the value, which would change all the time, with the a data value reference.  There is not need for the reference to ever change.

Think of the reference as a pointer to a particular memory location.  The value is the value stored in the location that the reference points to.

You certainly don't want to continually generate new references every loop iteration where you are not deleting them.  You are eventually going to run out of memory.

[crossrulz]

Based purely on your example diagram, what is wrong with just using a Global Variable?  You are only updating the value in one location (the "Producer" loop), so there is not really any race condition.

[beavercreek]

Thanks for the Replies!

>There is not need for the reference to ever change.

Agree 10000%!  which is why I don't understand were my simple example is going wrong?!

I think we are arguing the same point, but I fail to understand why it doesn't work the way I expected it to.  I view DVR (and Queues) like a pointer, simply a way the other vi can know where the data is.  The data we're after is over here.  So, why doesn't Ch1 work in the data_reader.vi?

If we can get Ch1 to work in data_reader without re-creating and re-writing the reference into the FGV every loop (which is what Ch2 does), we will either find whats wrong with my vI's or I'll learn something that is still eluding me.  I hope to slap myself in the head this afternoon yet 😛

>Based purely on your example diagram, what is wrong with just using a Global Variable?

Nothing!  I'm just trying (and so far failing) to use the DVR to achieve the same functionality.

I have and do use globals occasionally, I just get tired of creating flat sequence structures around all the read operations to make sure they happen when they should.  Would be great if global/local variables had error buses like property nodes for controlling the signal flow.

[crossrulz]

---

@beavercreek wrote:

I have and do use globals occasionally, I just get tired of creating flat sequence structures around all the read operations to make sure they happen when they should.  Would be great if global/local variables had error buses like property nodes for controlling the signal flow.

---

An alternative would be to use the Current Value Table library the NI Systems Engineering put together.  It also uses named lookups and uses the error clusters.  So it looks like the CVT should have everything you are looking for.

[tst · Accepted solution]

---

@beavercreek wrote:

I think we are arguing the same point, but I fail to understand why it doesn't work the way I expected it to.  I view DVR (and Queues) like a pointer, simply a way the other vi can know where the data is.  The data we're after is over here.  So, why doesn't Ch1 work in the data_reader.vi?

If we can get Ch1 to work in data_reader without re-creating and re-writing the reference into the FGV every loop (which is what Ch2 does), we will either find whats wrong with my vI's or I'll learn something that is still eluding me.  I hope to slap myself in the head this afternoon yet 😛

---

You're missing a basic idea - the function you call creates a reference which points to a specific value. To actually interact with that value (read/write) you need to use the IPE structure. Right now what you're doing is creating one reference for ch1 (which you then do nothing with) and creating multiple references for ch2 (where with each iteration you're replacing the reference in the FGV, so you're basically losing the old reference), so instead of having two DVRs, you actually have N+1 DVRs (where N is the number of iterations your loop runs).

For your code to work as you want, you only need to create two DVRs (probably before the loop), then get them inside the loop and use the IPE structure with the R/W DVR nodes to set the value in the DVR.

For instance:

There are other issues with the code, but this covers the DVR issue.

[beavercreek]

Thanks tst!  Now I'm squared away.

I knew I shouldn't be creating the reference repeatedly which is why this was so frustrating.

>There are other issues with the code, but this covers the DVR issue.

Reminds me of this quote  "Software is never really finished, it's just an acceptable level of broken"  (stolen from Josh (JW-JnJ) sig.)

I guess the big take away for me is that the DVR is NOT  a pointer to the memory address where a wire/control/indicator is in memory, so there is NO need to hook it to the actual data you want to reference, you just need to create it wired to the the same data type.  Then to get the reference to update, you must write in the new values.

Updated the code to functional!