DVR accessing a Front Panel Control

[RavensFan]

What is wrong with queues or events?

I don't think there are any other choices.

[Eldon]

The Front Panel has an event already that takes care of user input. If you pass the data back as a User-Event then you are interfering with the responsiveness of the the FP.

If you use a queue, the data, which is already decoded, would have to be reencoded and another copy would be made. Then the dequeueing loop in the FP would have to decode the data and display.

So, it becomes a toss up of either using a queue or thread switching. I was looking for a different approach. I have it running with FP Ctrl Refs but I might try passing the encoded data directly to the queue. Then have queue loop do the decoding and writing to Local Variables. I would just like to keep the code that deals with the process in one place.

Thanks,
Eldon

[crossrulz]

---

@Eldon wrote:

The Front Panel has an event already that takes care of user input. If you pass the data back as a User-Event then you are interfering with the responsiveness of the the FP.

---

GUIs are slow because the users are slow.  Updating an indicator by recieving a User Event is not going to effect the responsiveness of a FP unless you have way too much happening in your GUI loop (which should be nothing but a Event Structure inside of a While Loop).  I use User Events all the time for status updates and I have never had an issue with FP responsiveness.

[rolfk]

Your definitely trying to optimize the wrong thing here. There is no way to get a free and cheap reference access to a user interface control on the front panel.

The DVR doesn't link to an UI control for one thing, so it falls off your list already.

The Control Refnum has to deal with race condition protection and all that, so it is indeed slow.

The local indicator is not available in a subVI.

The User Event Refnum is the logical choice here, but you don't like it.

Leaves no other option than abandoning LabVIEW and start programminig in assembly again 

Even in C you can't just go and access a GUI at will through a pointer reference. Any well designed GUI framework will require you to call object methods passing the data explicitedly, or sendinig some form of message to the control. Such is life. GUIs are not meant to update Megabtyes of data several times every second anyhow. Humans are only able to grasp a very small number of data points per second so any GUI trying to transport more data to a user is usually pretty misdesigned.

[tst]

I'm hesitant to add this, because for the most part I do agree with the others, but recently (~LV 2013) NI did add something which can do this - there's a primitive for setting a control's value by an index, which is supposed to ignore the UI thread and set the value in the transfer buffer (a technical term for Rolf, you can ignore it) directly. This essentially works the same as a local, but can be done from other VIs. I have no experience with it, so I can't add any more than that. I have no idea whether this is a good solution for your case.

[johnoc]

Forgive my ignorance, maybe I am not fully understanding the issue.

Can't you just bind the data to the control?

[crossrulz]

---

johnoc wrote:

Can't you just bind the data to the control?

---

You can bind a control/indicator to a Network Published Shared Variable.  But I try to avoid using those, especially in single machine applications, since they are a lot of overhead, are quite slow, and put the data out there for everybody to see (security issues).

I still hold to the simplest and most appropriate in this situation is to just use a User Event to send the data to the GUI loop and handle the data however it is needed.

[Yamaeda]

---

@Eldon wrote:

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.

---

You can have a slow loop (e.g. 50-100ms, usually in the main GUI timeout) in the main program that reads a DVR and updates all indicators, and update this DVR from any sub-vi. If you want more direct/responsive action to a value change you'll need queues and events, but for many cases a timed update if quite enough.

You would ofc have the same functionality by having all indicator data in an Action Engine and read/write from that.

/Y

[crossrulz]

---

Yamaeda wrote:

You would ofc have the same functionality by having all indicator data in an Action Engine and read/write from that.

---

At that point, you might as well get a little more performance with a Global Variable.