LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Force to call .NET in non-UI thread

I am having an issue with embedding .NET function in my VI.

According to this page, .NET call is done from UI thread if I create a .NET container on a front panel.

Since my .NET call takes some time (a few hundred msec to one sec), I observe that during this function call the UI thread is effectively stops.

Since my application is large, I do not want .NET call to perturb other processes running on UI thread.

I was wondering how I can force .NET call to be done in some other thread.

The referenced page above suggests a workaround along with a example vi, but unfortunately I do not understand how this works.

 

Actually, I do not need to have a .NET container on my front panel. All I need is a reference to the .NET library.

If I use a .NET reference constant, instead of front panel object, does LabVIEW still execute the calls on UI thread?

 

Any help/suggestions?

0 Kudos
Message 1 of 4
(4,012 Views)

The link you provided refers specifically to .NET UI controls (more specifically, .NET controls derived from the Windows Forms framework that has shipped with .NET since 1.0).

 

If your .NET assembly does not inherit from any member of the Windows Forms framework then it is quite likely you can instantiate objects and call properties/methods using the nodes. In that instance the thread that runs the code in the assembly depends on the Execution System of the VI that hosts the nodes. If it is not set to User Interface then it will run in one of the other ES and the UI thread will not be consumed with the call.

 

I could give a better suggestion if you could give some details on the assembly you are using.

Message 2 of 4
(3,997 Views)

Hello tyk007,

 

Thank you for your advice.

I am not familiar with the convention of .NET at all, so I guess I'm a little bit confused.

Let me rephrase my problem in more detail.

 

I am using this software (Kinesis 32bit) and to integrate this in my VI I followed this tutorial.

 

Since I need to access just a few functions to move the stage and query current position, I do not need to have a .NET container on my front panel.

In addition, if I understand correctly, if I put .NET container on the front panel of my main VI then all function call has to be done on UI thread.

 

Now, following this link, I tried to create .NET object on my block diagram to eliminate .NET container from my front panel and hopefully tell LabVIEW to use threads other than UI thread.

When I run the program with VI execution setting 'same as caller', I get this following error message.

Error 1172 occurred at Constructor Node Error creating instance of KCubeBrushlessControl in assembly Thorlabs.MotionControl.Controls.KCubeBrushlessControl, Thorlabs.MotionControl.Controls, Version=1.9.3.0, Culture=neutral, PublicKeyToken=c7ec6d6d6e2435e7, (System.InvalidOperationException: The calling thread must be STA, because many UI components require this.)

 

Does this mean that I can only call this .NET object on UI thread?

Indeed if I specify 'user interface' in VI execution setting, my program runs properly...

0 Kudos
Message 3 of 4
(3,949 Views)

@tomoyukinko1008 wrote:

Hello tyk007,

 

Thank you for your advice.

I am not familiar with the convention of .NET at all, so I guess I'm a little bit confused.

Let me rephrase my problem in more detail.

 

I am using this software (Kinesis 32bit) and to integrate this in my VI I followed this tutorial.

 

Since I need to access just a few functions to move the stage and query current position, I do not need to have a .NET container on my front panel.

In addition, if I understand correctly, if I put .NET container on the front panel of my main VI then all function call has to be done on UI thread.

 

Now, following this link, I tried to create .NET object on my block diagram to eliminate .NET container from my front panel and hopefully tell LabVIEW to use threads other than UI thread.

When I run the program with VI execution setting 'same as caller', I get this following error message.

Error 1172 occurred at Constructor Node Error creating instance of KCubeBrushlessControl in assembly Thorlabs.MotionControl.Controls.KCubeBrushlessControl, Thorlabs.MotionControl.Controls, Version=1.9.3.0, Culture=neutral, PublicKeyToken=c7ec6d6d6e2435e7, (System.InvalidOperationException: The calling thread must be STA, because many UI components require this.)

 

Does this mean that I can only call this .NET object on UI thread?

Indeed if I specify 'user interface' in VI execution setting, my program runs properly...


Thanks for providing this, it is very useful,. Basically yes, you are using .NET objects that hark back to a UI framework (probably Windows Forms) and thus must have access to a Windows Message Loop. This is why LabVIEW's control container exists. It also explains why running the code in the User Interface thread works.

 

This is not just a LabVIEW thing, its at the core of developing applications in Windows. Virtually all Windows frameworks require that any access to a UI element/control to only be performed on the thread that created it and that thread must have access (directly or indirectly) to the message loop. This is true of Windows Forms, Windows Presentation Framework, Universal Windows Platform etc. There are good reasons for this rule although it has caused no end of confusion for new developers.

 

The simple options for you are two either run with the Container (which forces the interaction to the UI thread) or run the code that works with the class in the UI thread. You could create "wrapper" VIs around each of the calls to the classes in question and set the Execution System of just those VIs  to the UI subsystem. That would limit the amount of time your code spends on that thread, freeing it up for other tasks like user interaction.

 

I'm not familiar with the library you are using but it is also possible that it exposes an API that does not require the use of controls or UI elements, and can thus be run by any LabVIEW thread.

Message 4 of 4
(3,945 Views)