LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FOR loop + Case structure to accommodate indicators in small space - performance?

Solved!
Go to solution

@Blokk wrote:

@altenbach wrote:

... 


This triggered an idea for a new structure, the "parallel stack". It would look like a stacked sequence, but would simply instruct the compiler to do all frames in no particular order and as parallel as possible. :D It would be just a cosmetic diagram organization tool and would be treated as if all frames were flattened out to the diagram. 😄 Hmmm....


If you put this on the idea exchange, i will vote for it! 🙂


Brace yourself for the questions coming from text coders converting to LV and not being able to figure out why that structure is not determining execution order...

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 11 of 19
(555 Views)

Well, if you set parallelism for a FOR loop, it neither defines a deterministic order... right?

0 Kudos
Message 12 of 19
(553 Views)

@Blokk wrote:

Well, if you set parallelism for a FOR loop, it neither defines a deterministic order... right?


Correct!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 13 of 19
(549 Views)

@altenbach wrote:

This triggered an idea for a new structure, the "parallel stack". It would look like a stacked sequence, but would simply instruct the compiler to do all frames in no particular order and as parallel as possible. 😄 It would be just a cosmetic diagram organization tool and would be treated as if all frames were flattened out to the diagram. 😄 Hmmm....

 

Frames could be freely named according to function and clicking would expose a pulldown with all frame names for direct access.


Already in the Idea Exchange: Parallel Execution Structure as opposed to Sequence Structure


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 14 of 19
(545 Views)

Thanks. I was posting by phone and could not search efficiently.  (I vaguely remembered something with diagram tabs).

0 Kudos
Message 15 of 19
(542 Views)

@altenbach wrote:

I agree with Ben that you won't notice an impact, these are just scalars. Updating the UI thread is asynchronous anyway.


The discussion spawned an extra question, and I am interested in your opinion people. So, I have also a time stamp indicator and a special custom boolean indicator besides the already mentioned numeric indicators (the boolean indicator is just a custom one with a "floppy disk" symbol on the True, and the False is set to invisible; when file rec is ongoing, this indicator is negated at every iteration to show a blinking floppy symbol).

 

Ok, because by default all the indicators are set to "Asynchronous display", I notice sometimes a tiny jitter in the Time stamp indicator (the seconds are not "equidistant"), and in the "blinking" of the Boolean one. This hurts my OCD a bit. Note, I measure the While loop iteration time, it is tightly 1000 msec.

 

Question: in such cases (like for Time stamp indicators), when we want to show nice tight synchronous display update to the user, should we just use the "Synchronous display" setting? Would this bite back, I imagine at this scale not? I just realized, I NEVER ever used this Sync display setting activated for any of my indicators since I program in LabVIEW. That is why I ask, what is the common practice here? Thanks! 🙂

0 Kudos
Message 16 of 19
(509 Views)

@Blokk wrote:
Ok, because by default all the indicators are set to "Asynchronous display", I notice sometimes a tiny jitter in the Time stamp indicator (the seconds are not "equidistant"), and in the "blinking" of the Boolean one. This hurts my OCD a bit. Note, I measure the While loop iteration time, it is tightly 1000 msec.

 


 

If the loop rate is 1000ms, I would think that the flashing should be quite regular unless you are really starving the UI thread. This can happen for example if you set one of the high priorities for the VIs, so make sure to leave it at "normal". It probably can also occur if a lot of things are happening in the UI thread (unsafe DLLs, property nodes, graphs with lots of data, etc. )

I sometimes see hesitations right after a VI is loaded (by double-clicking in explorer with LabVIEW initially closed) and run right away, probably because a lot of things are still executing in the background (e.g. loading of palettes, etc.). These things normalize quickly.

 

I am not 100% sure what the update rate of the UI thread is, but it is probably close to the typical refresh rate of the monitor. Synchronous display will slow down your code dramatically. Try a synchronous indicator in a tight loop. The difference will be many orders of magnitude. I never use it.

0 Kudos
Message 17 of 19
(498 Views)

@altenbach wrote:

@Blokk wrote:
Ok, because by default all the indicators are set to "Asynchronous display", I notice sometimes a tiny jitter in the Time stamp indicator (the seconds are not "equidistant"), and in the "blinking" of the Boolean one. This hurts my OCD a bit. Note, I measure the While loop iteration time, it is tightly 1000 msec.

 


 

If the loop rate is 1000ms, I would think that the flashing should be quite regular unless you are really starving the UI thread. This can happen for example if you set one of the high priorities for the VIs, so make sure to leave it at "normal". It probably can also occur if a lot of things are happening in the UI thread (unsafe DLLs, property nodes, graphs with lots of data, etc. )

I sometimes see hesitations right after a VI is loaded (by double-clicking in explorer with LabVIEW initially closed) and run right away, probably because a lot of things are still executing in the background (e.g. loading of palettes, etc.). These things normalize quickly.

 

I am not 100% sure what the update rate of the UI thread is, but it is probably close to the typical refresh rate of the monitor. Synchronous display will slow down your code dramatically. Try a synchronous indicator in a tight loop. The difference will be many orders of magnitude. I never use it.


I run the application as a built exe. We use a somewhat older laptop, i guess it has an Intel i3 CPU, and i upgraded it's RAM to 8GB. OS is Win 7 x64. I more often see this jitter when I take the laptop out from screen saver mode (sleep mode is disabled).

 

Thanks for the advices about these settings!

0 Kudos
Message 18 of 19
(492 Views)

I concur with the UI Thread suspicions.

 

If you want it to flash regular then it should be in its own loop and the indicator updated "synchronously".

 

G-Story that lead to me pushing the get the answer I posted in the "Duct Tape Required" thread.

 

I had an application that spawned off a background process to fetch updates from a bunch of FieldPoint units running LV RT. The fetching made use of a VI served Action Engine served by the FieldPoint units in order to realize hand-shaking that prevented any potential loss of historical data.

 

Elsewhere in the application, I had a picture ring that was incremented to present an animated indicator that showed network traffic was taking place.

 

All worked as I expected until the application was brought back-up after the PC had been shutdown. The animation would stall for long periods even though the network traffic was happening as it should. It turned out the heavy use of VI server and massive amounts of history data being fetched the UI thread was being swamped.

 

So...

 

Suspect the UI thread.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 19 of 19
(467 Views)