Do Controls/Indicators in all display tabs get updated even if not visible?

[tootalled]

I have a pretty simple Labview VI that I need to run at a 10 ms loop. Currently, I can only get it to run at 17 ms. It has a RS422 that has to send and receive a message every 10 ms. I have a lot of troubleshooting indicators on a Debug Tab. I am wondering if these indicators are being updated even though they are not on the currently displayed tab. If so, will changing the "visible" property node of all these indicators speed up execution?

Thanks,

[crossrulz]

I'm pretty sure the values will get updated, but they won't be drawn.

Can you share your code?  There are some tricks we could help with that could get your loop rate down.  But even then, running on a Windows system you will not be able to get a very consistant loop rate.  And adding the RS422 doesn't help at all either.

[tootalled]

Thanks for the quick response. Unfortunately this is an ITAR restricted program. So unless I can confirm your location and I put the ITAR restriction legends on my code, I cannot share it.  The main purpose of this VI is to provide commands to a electronic controller via the RS422 messages running at 38400 and display the status response from the controller. Accurately timed loops is not critical and I know I can get that with "Real Time". One option I have is that once everything is working at a 20 ms rate, is to strip out the unnecessary Debug code, but I don't want to do that if I don't have to. My hope was that making things invisible might speed up the loop. The loop is controlled by a "Wait til next multiple" timer with a numeric control driving it. So I can dial down the loop time until it stops working.

The whole program mostly builds message strings, transimits them, parses the received strings, and displays them. I realize the RS422 xmit/rcvr probably takes up to 6 ms alone.

Ed

[crossrulz · Accepted solution]

Well, there are other tricks, such as putting your reading from the RS422 into another loop or going Producer/Consumer on the read data for processing.  Without seeing actual code, it is hard to give any more advice.

[tootalled]

I have attached a copy of a VI from a different program that has the exact same issue.

Thank you for your time,

Ed

[Kaleb_A]

Hello tootalled,

Do you happen to have synchronous display enabled?  In most applications, having asynchronous display enabled significantly speed up execution without affecting what the user sees. For example, you can update a Boolean value hundreds of times in a second, which is more updates than the human eye can discern. Asynchronous displays permit the execution system to spend more time executing VIs, with updates automatically reduced to a slower rate by the user interface thread.

If you want asynchronous displays, right-click the control or indicator and select Advanced»Synchronous Display from the shortcut menu to uncheck the menu item.

Please see this document regarding VI execution speed: http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/vi_execution_speed/

Like crossrulz said, I also recommend using the Producer/consumer architecture. This way, you can process your data in one loop, pass the data via a queue, and update your indicators in a separate loop that does not affect the speed of your processing vi. 

[RTSLVU]

One thing I have done is put all my measurments in a "Functional Global" then use a case to only update indicators on the tab that is currently visible.

 

[ToeCutter]

10ms is likely down below the 'Windows Jitter Threshold' (TM). If you're worried about the effect of the debug indicators, make a copy of the project, rip them out and see if it buys you anything.

Writing to indicators could definitely choke your application. Producer/consumer as already mentioned is a smart way to go. Sometimes if I have a fast spinning loop and I want to update a 'real time' graph from it, I just put the graph in a case statement that only executes e.g. every 1s, every 100th loop, or whatever. You can also try upping the priority of your VI in execution options.

P.S: Please don't use the 4 letter word around here- it causes fear in these parts. 😉

[mikeporter]

If you are concerned about the update time associated with indicators on tabs the simplist solution is not to use tabs -- except maybe as a switch.

Instead use subpanels that each display the data that is associated with one tab. Then the problem is simple. If the subpanel isn't running, it isn't updating.

Alternately, if the tabs all have the same indicators on them, simply have one set of indicators and use a selector to pick the data source that is driving them.

Mike...

[crossrulz]

---

@mikeporter wrote:
the simplist solution is not to use tabs -- except maybe as a switch.

---

I was waiting for that comment from Mike as soon as I saw the question.