DVR accessing a Front Panel Control

[Eldon]

Can somebody explain to me why this does not work or how to make something like this work.

Thanks in advance,

Eldon

[altenbach]

---

@Eldon wrote:

Can somebody explain to me why this does not work or how to make something like this work.

---

What is "something like this"? Define what you mean by "work"!

How are you using this program, what are you expecting, and what happens instead.

The local variable "Numeric 2" just defines the datatype of the DVR, it's value is irrelevant. If you want to read out the value from the DVR, hook up the indicator.

[Eldon]

Very simple put, Changing the value of the control does not change the value of the indicator.

Thanks,

Eldon

[altenbach]

Your indicator is not connected anywhere!

As I already explained, your local variable just provides the datatype (DBL), it does not somehow provide a magical link to the indicator.

I guess you are completely misunderstanding DVRs. Here's a very primitive example how you could e.g. write to the DVR in one place and read the DVR value elsewhere, e.g. in a different loop.

 

[Eldon]

A DVR gets the memory reference/address of a location. When you assigned the DVR to a constant it still is having to create a location in memory. So, what you are telling me is that the "Create DVR" creates a new memory location and returns that location. It does not actually return the location of the variable that you are attaching to it. Thus, it is not a "True" pointer to a memory location but a pointer to a memory location that it creates.

Is this correct?

What I am trying to avoid in the "Bigger" picture is duplicating the second loop that you created to make this work.

Thanks,
Eldon

[altenbach]

Yes, a DVR is just a memory location that you can access via the read/write DVR node of an in place element structure. The IPE protects from concurrent access. While one operates on the DVR value, no other IPE has access. This prevents race conditions. 

An indicator is a front panel object that has it's own data copy and gets updated asynchronously via a transfer buffer, thus there will be multiple copies in memory. I just looked at the help pages and I agree that the example choice is misleading.

A DVR does NOT involve anything on the front panel and there is exactly one copy, making it much more efficient.

[Eldon]

Thanks for confirming my suspicion. I was trying to avoid using a Ctrl Ref to the FP control for upating purposes. The process that needs to update the FP control is in another process so it does not have access via a local variable.

Later,

Eldon

[natasftw]

What exactly are you trying to do?  From what you've shown here so far, it sounds like you're trying to do something in a strange way.  If you can explain your problem, rather than ask guidance on the current solution, we'll likely be more help to you.

[altenbach]

Well, he already said that he wants to modify the indicator value from a "different process" (this is probably the wrong term,. I am guessing e.g. from within a subVI as typically done with control references).

[Eldon]

To make a long story short, I do not like using Ctrl Refs to FPs because they have to use the UI thread to execute thus causing "Alot" of context switching.

I have a loop decoding a polled response from a device that is running in an asyncronious VI. I was trying to find a way to easily acces the FP ctrls that need to be updated. Please do not tell me to use queues or events. I was looking for something that did not generate either alot of memory copies and/or decoding.

Thanks,
Eldon