LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Root Loop, Time/Date Browse and DAQmx Watchdog

Solved!
Go to solution

I've just run into the issue where the time/date browse calendar control blocks execution of my system.  See here for discussion about this problem.

 

I've got a data aquisition loop running that uses the DAQmx watchdog, and opening that browse window is causing my watchdog to starve, thus causing my application to shut down.  Curiously, when I open drop down menus, as Jack illustrates in the aforementioned thread, I do not see the same behavior.  It's not really clear to me what is causing it to block, but the dropdowns don't.

 

I'm wondering if anyone has any further explanations, or suggestions for workarounds. 

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 1 of 7
(3,978 Views)

Curious.  I've only used a Watchdog on a Real-Time Controller with LabVIEW-RT, and such code doesn't have an interactive Front Panel.  If you are interacting with the Front Panel's Calendar control, do you want to have Data Acquisition running?  Will changing the Date in the middle of the acquisition be OK?  If not, then the easy thing to do is to disable the Calendar Control so that this cannot happen.  This might be a good idea in any case (and you should dim it as well, as a visual indication that it is temporarily unavailable).

 

BS

0 Kudos
Message 2 of 7
(3,966 Views)

I'm running the watchdog on the relatively new (I think) cDAQ9188-XT.  I do want to have the data acquisition running, because I like to allow the user to peruse their database (where the calendar control is located) while a test is in progress.  The DAQ and the calendar control are doing two completely different tasks that do not really interact, so having them both run should be fine for me.

 

 

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 3 of 7
(3,956 Views)
Solution
Accepted by elset191

One solution I did in the past to solve this was to create my own Data/Time dialog in LabVIEW and hide the native button and add a normal button to the front panel which invoked this dialog. Since that makes the dialog a normal VI the root loop problem is not present with that. There is a VI in resource/dialog/picktime.vi that looks like the dialog used in the date/time picker but it isn't since making changes to this VI won't appear in the native dialog. LabVIEW seems to use an internal C implemented dialog which is the root cause of the root loop being blocked since the dialog message handler is running in the same thread as the root loop.

 

Creating a copy of this VI in your own project and adding it through your own custom time browse button should solve the problem.

Rolf Kalbermatter
My Blog
Message 4 of 7
(3,926 Views)

It's worth having a read of this, one of the best articles I've read about the 'root loop': http://www.labviewcraftsmen.com/blog/the-root-loop


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 5 of 7
(3,910 Views)

Sam,

     Thanks for pointing out that fascinating article!

 

BS

0 Kudos
Message 6 of 7
(3,893 Views)

Thanks, Rolf.  That's also what Aristos suggested in the idea exchange thread I linked to.

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 7 of 7
(3,879 Views)