Darren's Weekly Nugget 11/06/2006

[Darren]

As I mentioned in last week's nugget, I've been working a lot with the Picture Control lately.  The other day, I was debugging what I *thought* was a race condition in my code for a long time.  But ultimately, my code was fine...it was my lack of understanding of a little-known LabVIEW quirk that was causing the problem.

Have you ever noticed the "Synchronous Display" option on controls and indicators?  You can find it by right-clicking on a control or indicator and going to the "Advanced" submenu.  Well, I remember when I first learned LabVIEW almost eight years ago, I noticed the Synchronous Display option in the right-click menus, and I always wondered what it was, but I never really took the time to figure it out.  Well, it turns out the LabVIEW Help has a great description of what Synchronous Display actually means, and this help topic ultimately gave me the answer to my problem.  

To summarize, all controls and indicators default to Asynchronous Display...in other words, the "Synchronous Display" option is unchecked.  What this means is that, when you give LabVIEW a new value for that control or indicator (usually via its control terminal or a local variable), it will update the appearance of the front panel object with the latest value whenever it gets a chance, i.e. whenever the user interface thread gets a chance to run.  In other words, some draws may never happen.  If you select Synchronous Display, however, you are essentially forcing LabVIEW to update that control or indicator immediately upon its value being changed on the diagram.  There's a really simple way to see the effect of this option.  Create a VI with a For Loop that runs 10000 times, and wire the iteration terminal to a numeric indicator.  Run the VI...it should return instantaneously.  Now right-click the indicator and choose Advanced > Synchronous Display.  Run the VI again.  It should take a LOT longer, because you are forcing LabVIEW to update the appearance of that indicator every single time its value is changed.

So in my case, I was drawing different components of a Picture Control, with the "Erase First" option deselected...this means that new images are drawn "over" old images, and the old images remain in the Picture Control.  Well, if two draws happened in quick succession (which was possible since I was keying off of Mouse Move events to do some of my drawing), sometimes, the first draw would never happen, due to the Asynchronous Display behavior.  As a result, portions of my picture that needed to be there from the first draw would never appear.  Now you see why I thought it was a race condition...depending on how fast my Mouse Moves occurred, I might see my first image, and I might not.  My problem was fixed simply by enabling Synchronous Display on my Picture Control. 

-D

P.S. - Check out past nuggets here.

Message Edited by Darren on 11-06-2006 11:18 AM

[kehander]

Intriguing!

Could there be a quick way of checking which of one's indicators are set to synchronous display (that is, quicker than right-clicking each of them and selecting the Advanced submenu)? I wonder if my programs are being slowed down because I accidently left that setting on in the wrong places.

[WNM]

It's not very likely that a control would end up being set to synchronous if you didn't  knowingly configure it that way, since they default to asynchronous. It would also seem that you do not have to worry about synchronous controls on the front panels of subVIs if those front panels are not displayed. Anyway, the attached VI was quick enough to put together since I had 95% of it sitting around for another purpose and it will make the check that you ask for over all the controls on an individual VI. I'll leave it to you to extend it to check an entire VI hierarchy 😉

[Darren]

By default, Synchronous Display is disabled, so unless you actually changed the setting on any of your controls or indicators, you should be safe.  But for those of you VI Analyzer 1.1 users out there, I've attached a VI Analyzer test below (saved in LabVIEW 8.0 format) that will return a failure on any control or indicator in a VI that has the Synchronous Display option set.  You can copy this LLB to your [LabVIEW Data]\VI Analyzer Tests folder and it will show up in the Tests tree the next time you use the VI Analyzer.

And not to be picky, but Warren's example above won't catch controls or indicators inside Tab Controls or Arrays.  The attached VI Analyzer test will find all those cases.

-D

[WNM]

Ok, point taken. The attached VI does pick up the stuff in those structures now too.

[AristosQueue (NI)]

Darren:
Do you think we should file a bug report such that if the user turns off "Erase First" then "Synchronous Display" is automatically turned on? I've read your post and I'm trying to imagine a case where I've turned off "Erase First" where my draw *doesn't* depend upon getting all previous draw updates, and I can't imagine one. Since I need all previous draw states, then I better stop and wait for them to all get there before I process the next one. It seems like these two options need to be tied together.

-- Stephen

[Darren]

I thought about that too, but it seemed to me that there would be no easy way to indicate to the user that the two options are linked in that way.  If we can figure out an easy way to link the two options, then I think it would be a good idea...it would have saved me a lot of erroneous debugging.

-D

[Bob_Preis]

I'm curious if switching your VI's execution system from "Standard" to "User Interface" would have solved your problem, since the "synchronous display" option simply forces the UI thread to run when data is written to the picture control terminal.

I tried a simple For loop with an indicator - synchronous display off, UI execution system - and the VI finishes instantly, just like it did in standard execution system.  My guess is changing to UI execution system but leaving synchronous display off would not solve your problem, even though I'd expect it to based on the help description:

"user interface—Handles the user interface. Behaves exactly the same in multithreaded applications as in single-threaded applications. VIs can run in the user interface thread, but the execution system alternates between cooperatively multitasking and responding to user interface events."

[AristosQueue (NI)]

Making the VI run in the UI thread wouldn't fix the draw problem since it would still only actually do the draw when there was no other work to be done. In fact, since the VI is now tying up the UI thread, if the VI goes to do some long disk operation, which would normally give the UI a chance to update, I would guess that setting the VI to be UI would result in fewer updates of the screen controls. This is just a guess, not something actually based on studying the code behind the option.

[AristosQueue (NI)]

> I thought about that too, but it seemed to me that there would be no
> easy way to indicate to the user that the two options are linked in
> that way.  If we can figure out an easy way to link the two options,
> then I think it would be a good idea...it would have saved me a lot
> of erroneous debugging.

This is one of those cases where I shrug and say, "Why bother indicating that link?" Suppose that when a user turns on Erase First, LV recorded the current state of Synchronous Display and then turned on Synchronous Display. When the user turns off Erase First, we restore whatever the previous state of Synchronous Display was. When they look at the Advanced popup menu, the Synchronous Display is checked and grayed out. Add a note in the online help about what Synchronous Display does that Erase First always turns it on (and why).  I doubt that anyone would object to the setup.