Refresh rate for Numeric Indicator

[Paul J S]

I have application that displays 60 16 bit word of data in Hex format on the screen simulatanousely as I receive block of data at at approximately 10,000 times a second through USB. Obviously, at this 10,000Hz rate, it is an over-kill in terms of the human eye visually processing at that rate. Does anyone know what is the screen update rate for numberic indators and is there a way of controlling it. I was trying to see if I could set it for 10Hz.

Thanks.

Paul  

[waldemar.hersacher]

The screen update rate depends on your CPU and graphics card. There is no setting in the indicator to set the update rate.
What you can do is to put the terminal into a case structure and run the case with the terminal when a timeout expires. There is a Express VI "Elapsed Time" which allows you to manage the timeout.

[Pnt]

If you wire directly to the terminal, or to a local variable, Labview updates the visible value only around 30 times a second. You do not have to do anything.

If you use a property node, value ,Labview updates the visible value every time the property is called. (do not do it)

[altenbach]

By default, indicators are updated at a suitable rate, independent on how many time you write to the terminal. (You could set the indicator to "synchronous display" if you want to force an update with each write operation, so don't do that!)

You can always reduce the update rate further by placing the terminal inside a case structure that only turns true every 100ms. How are you reading the data?

[GollumGTH]

I realize this is an old thread but...

---

@Pnt wrote:

If you wire directly to the terminal, or to a local variable, Labview updates the visible value only around 30 times a second. You do not have to do anything.

If you use a property node, value ,Labview updates the visible value every time the property is called. (do not do it)

---

Is there a way to write to a control through a reference (i.e. property node) while maintaining the behavior of writing directly to the terminal (i.e. it updates at an appropriate rate)?

Thanks.

[smercurio_fc]

Yes, you can use the Value property to write to a control "asynchronously" (using your basic intention). You can also use a local variable, which would actually be faster. Either way, make sure you do not cause a race condition (i.e., read from the control before it's been written).

[altenbach]

---

@smercurio_fc wrote:

Yes, you can use the Value property to write to a control "asynchronously" (using your basic intention).

---

Maybe we are not talking about the same thing, but It was my impression that value property nodes execute synchronously.

(Of course you could defer panel updates, but that does not sound like such a good idea. 😉

[smercurio_fc]

Yeah, we're not talking about the same thing. I was (loosely) using the term "asynchronously" (hence putting it in quotes) to mean to update the control "on-demand", as opposed to continously updating in the loop that he has, which I assumed he had based on his description. Although I wasn't quite sure about why this was being done with a control, as opposed to an indicator, but I assumed it might have been a typo.

[FraggerFox]

I use the Defer Panel Updates Property to update the Front Panel "On-Demand". Whenever I want to update it, I will first set it to False and update the indicator, while in other cases I will set it to True.

[GollumGTH]

Let me clarify my question:

I have a project which could send data to the screen at a rapid rate (think oscope).  I do not want this to slow down the program more than necessary.  The data will be grabbed in a loop and displayed to the screen (and possibly enqueued for extra processing). 

It is my understanding that if I simply wire it to an indicator (yes I suppose this was a typo) or local variable it will be handled nicely, i.e. sent to an update buffer to handle screen updates at an appropriate rate.

However I would like to encapsulate my GUI (either using an action engine with USRs or a class) and so was planning on having references to all my controls and indicators within this encapsulation.

So again, my question is this: Is there a way to write to an indicator (or control) via the reference while still having the advantages (speed/display buffer) of a local variable?

Secondary question:

Where is the best place to find information on all the various efficiencies LabVIEW has built in.  For example, in my last project I was actually writing my data to a separate queue which was dequeued in a loop with a built in delay and only the most recent item was written to the screen and the rest deleted.  In other words, I had no idea LabVIEW already handled this in the background and I would like to know what else LabVIEW already takes care of for me.

Thanks.