Passing double arrays from VB to LV

[andres]

Hi

I would like to pass double arrays of data from VB to LV / LV to VB. I use an ActiveX DLL created in VB. When I integrate this component into LV with automation open, the double array apears as a Variant datatype . Converting this array into a double array in LV is very slow . Using the same ActiveX component inside VB is very fast in comparison.

Does anybody know why LV is so much slower handling an ActiveX Calls? Is there a faster way to pass arrays of doubles between LV and VB?

Thank you for helping!

[Rolf Kalbermatter]

Hi

I would like to pass double arrays of data from VB to LV / LV to VB. I use an ActiveX DLL created in VB. When I integrate this component into LV with automation open, the double array apears as a Variant datatype . Converting this array into a double array in LV is very slow . Using the same ActiveX component inside VB is very fast in comparison.

Does anybody know why LV is so much slower handling an ActiveX Calls? Is there a faster way to pass arrays of doubles between LV and VB?

Thank you for helping!

Probably not. Visual Basic does everything that does not fit into a string or a single variable with VARIANTs. VARIANTs are not so fun to deal with directly and you need a whole bunch of Windows OLE functions that are not available on non Windows 32 bit systems. Therefore LabVIEW chooses to convert incoming variants into its own binary format (well not really its own but the format used by virtually any real compiler, which of course leaves out Visual Basic) and reconvert them back when handing them back.

The only real solution to speed these things up is to not use Visual Basic and/or Active X for such cases (or do everything involving such arrays in Visual Basic). My choice would be the first as I try to avoid ActiveX at almost all costs for its famous stability, version interchange compatibility, and lean and mean runtime system, not to mention its unparalleled multi-platform nature :-).

Rolf Kalbermatter

[andres]

Probably not. Visual Basic does everything that does not fit into a string or a single variable with VARIANTs. VARIANTs are not so fun to deal with directly and you need a whole bunch of Windows OLE functions that are not available on non Windows 32 bit systems. Therefore LabVIEW chooses to convert incoming variants into its own binary format (well not really its own but the format used by virtually any real compiler, which of course leaves out Visual Basic) and reconvert them back when handing them back.

The only real solution to speed these things up is to not use Visual Basic and/or Active X for such cases (or do everything involving such arrays in Visual Basic). My choice would be the first as I try to avoid ActiveX at almost all costs for its famous stability, version interchange compatibility, and lean and mean runtime system, not to mention its unparalleled multi-platform nature :-).

Rolf Kalbermatter

Hi Rolf

thanks for your anwser! The background of my question is, that we have actually such a COM Component integrated in our project, the imc COM Components from www.imc-berlin.de. If I understood your anwser than calling this component inside VB is faster than calling the same componet from inside LV, right? When it comes to convert the VARIANT's in LV I loose again time... a lot! :thumbdown:

Is any COM Component slower inside LV than inside VB? Also if the COM Component was build with a real compiler such as Visual C? I only try to understand a little bit more about the background of the low speed for this component using LV.

Andi :thumbup:

[Rolf Kalbermatter]

Hi Rolf

thanks for your anwser! The background of my question is, that we have actually such a COM Component integrated in our project, the imc COM Components from www.imc-berlin.de. If I understood your anwser than calling this component inside VB is faster than calling the same componet from inside LV, right? When it comes to convert the VARIANT's in LV I loose again time... a lot! :thumbdown:

Is any COM Component slower inside LV than inside VB? Also if the COM Component was build with a real compiler such as Visual C? I only try to understand a little bit more about the background of the low speed for this component using LV.

Andi :thumbup:

Well, I do think Visual Basic does usually work directly on VARIANTS but am not sure. As such it would not need to convert a VARIANT array to another representation before doing some stuff on it. If using such a COM object is much faster in VB than from LabVIEW I don't know. Last time I touched VB is more than 10 years ago. COM itself does not mandate VARIANTS per se, but if it is going to be an Active X interface or a COM object which can be marshalled over network you need to limit yourself to the supported datatypes (and I'm not sure if Active X can marshall VARIANTS, I know that it can't easily do that for structures.)

Basically COM was not designed with data acquisition applications in mind and trying to use it in such environments creates all sorts of problems and limitations. Using Visual C to build the COM component likely will speed up the execution time of such a COM component and you don't necessarily need to restrict yourself to VB supported datatypes (although wanting to allow such a component to be used in VB you probably want to at least provide alternate VB compatible access methods). VARIANTS definitely wouldn't be my choice of data transport if I ever would write a COM component.

While a DLL interface may seem cumbersome at first it definitely is still the most flexible one and allows all sorts of fast and reliable data transfers. Also it is the most versatile in terms of interfacing as there are almost no software environments that can't link to a DLL (and if they can't link to a DLL they very likely can't link to a COM object either). The only advantage of COM or actually rather DCOM here is that it supports seamless networking (at least if you limit yourself to data types that it can marshall).

Rolf Kalbermatter