01-05-2018 12:03 PM
@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
01-05-2018 12:06 PM
Well, if you set parallelism for a FOR loop, it neither defines a deterministic order... right?
01-05-2018 12:25 PM
@Blokk wrote:
Well, if you set parallelism for a FOR loop, it neither defines a deterministic order... right?
Correct!
Ben
01-05-2018 12:34 PM
@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
01-05-2018 12:37 PM - edited 01-05-2018 12:40 PM
Thanks. I was posting by phone and could not search efficiently. (I vaguely remembered something with diagram tabs).
01-06-2018 03:02 AM
@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! 🙂
01-06-2018 11:40 AM
@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.
01-06-2018 12:54 PM
@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!
01-08-2018 08:04 AM
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