LabVIEW Craft
  • Blog
  • About
  • Contact
  • Tools
  • Resources

The Root Loop: Stung?

2/11/2015

10 Comments

 
Jon McBee
If you were paying close attention as you went through the blog post on the root loop you may have noticed a little slight of hand.  I may have been stung, but I'm not sure.
Picture
During the Open VI Reference video clip you may have noticed that as the Start Asynchronous Call by Reference and Wait on Asynchronous Call by Reference nodes were executing and I was opening context menus to show that the root loop didn't come into play that I skipped over the calendar popup on the time stamp control. Here is why:
Picture
From this test it looks like the calendar popup actually does interfere with execution of the Wait on Asynchronous Call node.  FYI, this test was done in LabVIEW 2014, but I see the same results running it in LabVIEW 2013.  Taking a look at the detailed help for that node we see:
Notice the last bullet point, this node should not require the user interface thread to execute, and in fact it doesn't for everything I have tested aside from the calendar popup.  I don't know if this can be pinned on the root loop or not, in fact it is entirely possible that I am missing something simple here (chime in if you see it).

Something Simple (Kind Of)

Thoric noticed the something simple I was doing wrong and mentioned it in the comments below, I'm adding his observation to the blog post so that people don't miss his thoughts in the comments below.  Here is what he noticed:
OK - try moving the Close Reference outside the final for loop. That changes things. It appears Close Ref is halted by the presence of the calendar dialog window. Not sure why yet...
It was a great observation and shows that the blocking has nothing to do with the Wait on Asynchronous Call node.  We can instead show that the blocking happens while the close reference node is executing.  Here is an updated video clip:
As Thoric suggested, I have moved the Close VI Reference node out of the for loop containing the Wait on Asynchronous Call node.  There is no reason not to wire the array of VI references directly to the Close VI Reference node, I put it in a For Loop to make it easier to show that it is in fact being blocked by the calendar control.  Why does the calendar control block the Close VI Reference node?

Jon McBee is a Principal Software Engineer at Cambridge NanoTech and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, Certified TestStand Developer, an NI Certified Professional Instructor, and a LabVIEW Champion
10 Comments
Thoric
2/11/2015 03:27:11 am

I don't have an answer, but interestingly if I take your VI (an identical mock-up), and use a boolean to fire an event to launch <resource>/dialog/picktime.vi (which is the Time Stamp control's Set Date and Time dialog) then it doesn't interfere with Wait on Asynchronous Call. This means the calendar control is specifically doing something interfering and it's not necessarily the dialog that pops up that's to blame. Figuring out that particular call mechanism could glean another clue?

Reply
Thoric
2/11/2015 03:36:30 am

OK - try moving the Close Reference outside the final for loop. That changes things. It appears Close Ref is halted by the presence of the calendar dialog window. Not sure why yet...

Reply
Jon McBee
2/11/2015 03:40:36 am

Great catch! I had a feeling I was playing some role in the issue. Now, onto why the Close Ref is halted...

CRoebuck link
2/11/2015 03:46:37 am

Intriguing, firing up LabVIEW......3....2...1.....

Reply
Jon McBee
2/11/2015 04:25:58 am

Any idea how the picktime.vi is used by the dev environment? If I edit that file, save it, and restart LabVIEW I dont see my changes taking hold. Makes me wonder if the dev environment isnt using the copy of the vi in the resources directory.

Reply
Jason Case
3/4/2015 05:09:06 am

The problem above is not actually a root loop related problem. It is just a UI thread issue.

The Set Time and Date dialog is preventing anything to execute in the UI thread. In your example, this is the Close Reference function. However, you could easily put a simple property node before the Close Reference or even a VI that specifies the UI thread as the execution system. (VI Properties >> Execution >> Preferred Execution System >> user interface).

Several CARs/bug reports have been created for this over the years. I know it has been investigated before, but the issue has previously been rejected as the dialog was hogging the UI thread and did not allow UI code to execute.

Reply
Jon McBee
3/17/2015 06:13:54 am

Hi Jason,

Thanks for the information. Can you provide any insight into how the dialog is being launched? I'm curious as changing the source VI's for the date time picker does not effect the popup dialog.

-Jon

Reply
Jason Case
3/17/2015 07:22:13 am

The dialog you see is a VI we have saved in a resource. When the button is clicked, we have C++ code that runs in the UI thread that will load and call the resource VI.

When we call a VI from C code, we prevent/limit unrelated G code from executing in parallel in the same thread. We do this to make a VI call from C behave more similar to a C function call. By that I mean, if you call the C function Foo, the function Bar will not be called simultaneously (cooperatively) on the same thread (unless Foo calls Bar).

LV previously did not restrict code execution in this way but that lead to many problems over the years. We decided to make VI calls from C not execute other G code from the calling thread.

Jason Case
3/24/2015 07:03:46 am

After posting the response about why this is a problem, I had an idea on a possible fix for this specific problem. I'm not positive my idea will work, but I think it should. I reopened a bug report on this issue and now it is a matter of scheduling time to try my fix.

Thoric link
3/24/2015 10:06:04 pm

Good luck with the CAR Jason, great stuff that you're seriously looking into this. We all want LabVIEW to be the best that it can be! :-D




Leave a Reply.

    RSS Feed

    Tags

    All
    Abstract Messaging
    Actor Framework
    Agile
    AI
    Asynchronous Programming
    Best Practices
    C#
    Complexity
    Continuations
    Control Values By Index
    Craftsmanship
    Dependency Inversion
    Dependency Viewer
    Futures/Promises
    Genetic Algorithm
    Liskov Substitution
    Malleable VIs
    Mediator Pattern
    .NET
    Object Oriented
    Object-Oriented
    Packed Project Library
    Parallelism
    Polymorphism
    Pub/Sub
    RawCap
    Root Loop
    Scrum
    Task Parallel Library
    TCP/IP
    TDD
    Test Engineering
    UML
    Unit Test
    VI Scripting
    VI Server
    WireShark

    Archives

    October 2019
    April 2019
    July 2018
    October 2017
    March 2017
    February 2017
    January 2017
    December 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    August 2015
    February 2015
    January 2015

    LabVIEW Blogs

    Eyes on VIs
    LabVIEW Hacker
    VI Shots
    LabVIEW Artisan
    Software Engineering for LabVIEW
    ​Wiresmith Techology
Picture
Powered by the Panda Ant

  • Blog
  • About
  • Contact
  • Tools
  • Resources