LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Variant to Data function

We are having a speed issue with the Variant to Data function.
We have devices that generate an agregate 2 milion samples per second and
have
run into
a bottle neck at the Variant to data function.

The process in general goes like so:
A call is made to one of our COM componants called the �Data Store�. one of
the
properties that
it returns is �available scans�.

At this point in LabView I initialize an array of singles to the �available

scans� size and pass the newly
Initialized array into our �Data Store�s �fetchdata� method along with the
available scans parameter.

This is the Prototype(?) of our COM FetchData method
HRESULT FetchData([in, out] SAFEARRAY(float)* DataBuffer, [in,
defaultvalue(0)]
long DesiredScans, [o
ut, retval] long* ReturnedScans)

For the purpose of bench marking this problem we have fixed available scans
at
2 million.

Looking at a variant indicator, wired right before being passed into the
Variant to Data function,
This is what is displayed.

Variant Type -> VT_ARRAY|VT_R4
Value -> Array(Non Displayable)

Also for the purposes of benchmarking we have put the �Variant to Data�
function into its own sub VI
So we could use the profile function and check some execution times.

On average it takes about 720 mS to execute the Variant to Data Function.
Obviously it wont take long
To get into and overrun condition at this rate.

For validation purposes I wrote a small VI just using a 2 million point
array
of sinlges did a �To Variant�
On that array and then ran the �Variant to Data� function this completed in

about 60 mS.

Any Ideas?

Regards To All
0 Kudos
Message 1 of 2
(2,998 Views)
When using the variant data type, speed is an inherent cost. In order to accommodate different types of data into the variant data type, many operations are required in the conversion, which makes the process pretty slow compared to 2MHz. Furthermore, making calls to COM code slows down the code even more because the of the command switching and matching that must occur. Unfortunately, both bottlenecks are unavoidable.

So you're actually getting a double whammy in the speed department with your code as described. To speed up the process, I would recommend looking at ways to bypass the bottlenecks. Is the 2MHz speed absolutely necessary? Is there a specific reason why you're making COM commands? If you are simply doing data storage, you could just stream to d
isk using a binary file in LabVIEW without making COM calls. If it is data analysis you are wanting to do in COM, I would recommend waiting until the data acquisition is complete and the data is saved to disk.

Most important: Strictly typed data types are an order of magnitude quicker than weakly typed ones. I would recommend looking at moving towards that area.

Eric Sulzer
Applications Engineer
National Instruments
http://www.ni.com/ask
E. Sulzer
Applications Engineer
National Instruments
Message 2 of 2
(2,998 Views)