LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW .NET interface performance problem

Solved!
Go to solution

Hi,

 

I'm wondering if it is normal, that LabVIEW takes several hundred µs to access a property of a .NET-class.

 

The problem appeared while using my own .NET-class to communicate with some hardware and using LV to handle events and process aquired data. The "data arrived"-event fires about every 10ms. The event-callback has nothing to do but reading out some properties out of the eventargs and write to a queue. In my case this takes 2-3ms. This takes too long, cause I need this time to process the arrived data.

 

First I thought of a problem with my class, so I tested it with the standard-lib System::Timers::Timer. Reading out the Interval-property takes 300-400µs, so reading 5-6 properties lead to the 2-3ms in my callback-VI. So far so good.

 

Whats my question now: Am I doing anything wrong by read out these properties as simple as possible? Do I have to adjust anything in the VIs Execution options? Is there any other "trick"? Or is it just this way that LVs .NET-interface is not as fast as Ì wish it to be?

 

Oliver

0 Kudos
Message 1 of 5
(3,597 Views)
Unfortunately, the LabVIEW <--> .NET interface is a mixed bag in terms of performance. It's generally slow, but it has improved with newer LabVIEW versions. I haven't tested it out in LV 2009, so I can't say whether it's markedly better. Not holding my breath, though.
0 Kudos
Message 2 of 5
(3,583 Views)

smercurio_fc wrote:
Unfortunately, the LabVIEW <--> .NET interface is a mixed bag in terms of performance. It's generally slow, but it has improved with newer LabVIEW versions. I haven't tested it out in LV 2009, so I can't say whether it's markedly better. Not holding my breath, though.

Since the .Net guru has left I doubt there will be much of an improvement other than bug fixes.

 

Let's face it:

- the .Net interface works

- it is allowing to do things using .Net that can be done in other ways just as well, albeit on a lower (and mostly much more performant) level

- it does not really buy NI much to spend many more months of effort into this

- and .Net is although seemingly easy to get started with quite obscure at times, always possible to get into various version conflicts, and last but not least a big catch all steam roller to handle sometimes such subtle tasks as retrieving a simple system parameter

 

And I remember a post by Lycangeek, the above mentioned .Net guru, where he explained how LabVIEW does and actually has to interface to .Net and this has indeed some performance limitations.

 

Rolf Kalbermatter

Message Edited by rolfk on 08-11-2009 09:15 AM
Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 5
(3,566 Views)

Hi Oliver,

 

I just wanted to confirm that the communication between LabVIEW and .NET is indeed not as fast as a normal .NET call. It has to do with the way that LabVIEW makes the calls to .NET assemblies.

 

Regards,

0 Kudos
Message 4 of 5
(3,557 Views)
Solution
Accepted by topic author Oliver_R.
 Thanks! Knowing this for sure now, I will implement the dataprocessing part in .NET
0 Kudos
Message 5 of 5
(3,547 Views)