LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Call by Reference Runs in UI thread

Solved!
Go to solution

Hi,

I'm having a hard time with the code below being executed in the UI thread.

UIThread.png

I've read the following article:

https://www.winemantech.com/blog/the-ui-thread-root-loop-and-labview-what-you-need-to-know/

 

It suggests that using the Call by Reference should enable me to run in any thread, but it also mentions that if I use a type specifier the code will run in the UI thread.

 

Any help on how I could convert the following code to code that can dynamically run a VI in any thread would be greatly appreciated!

 

Thanks,

Maciej

 


0 Kudos
Message 1 of 6
(5,019 Views)

Doesn't it follow the VI setting? Usually it's 'Same as caller', but what happens if you set it to 'Data thread' in that Driver-vi?

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 2 of 6
(4,942 Views)

This thread may help.

 

In that thread I posted the answer that I got from a similar inquiry.

 

Warning!

 

Duct tape required.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 6
(4,921 Views)

Hello Yameada,

 

Thanks for your reply.

I've made an example (LV2014) that replicates my problem.

 

If I run directly, and interact with the GUI, for example by opening one of the LabVIEW menus, and waiting for a little bit here is what I get. The UI thread is getting in the way of the call extending the time for the vi to return the value.

 

UI Thread Issue.png

 

If I call the same VI directly and interact with the menus it works correctly.

 

What I saw from the LabVIEW help is 

"If you wire a path, LabVIEW waits until the user interface is idle to load the VI from disk. If you wire a name string, LabVIEW does not need to wait until the user interface is idle, as it does not load a VI from disk. LabVIEW will only search in memory for a VI with a specified name. "

 

I am not wiring a path I'm wiring a string with the VI name.

 

Hopefully the example will help to understand what I'm struggling with, and what am I doing wrong?

 

Thanks

 

 


0 Kudos
Message 4 of 6
(4,918 Views)
Solution
Accepted by topic author Mac671

@ Ben,

 

Thanks I read that thread but I didn't have enough duct tape.

After I've made the example to show the problem I think I figure it out.

The issue is that I'm opening and closing the reference in my DAQ loop.

 

If I open it Before and Close it After the UI thread won't come into play, as it hangs by Open VI reference no the actual Call by Reference.

 

Thanks I think I'm sorted!


Message 5 of 6
(4,915 Views)

@Mac671 wrote:

@ Ben,

 

Thanks I read that thread but I didn't have enough duct tape.

After I've made the example to show the problem I think I figure it out.

The issue is that I'm opening and closing the reference in my DAQ loop.

 

If I open it Before and Close it After the UI thread won't come into play, as it hangs by Open VI reference no the actual Call by Reference.

 

Thanks I think I'm sorted!


That makes sense. Opening and closing files requires the OS to map virtual memory to the sectors of the file on disk. That is kernel mode work. You may be able to see this further if you use the Task manager >>> performance and enable "Show kernel times". I would expect to see bumps in the kernel times when files are opened and closed.

 

Far deeper than just the UI thread. In kernel mode no interrupts are serviced or exceptions allowed.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 6 of 6
(4,910 Views)