07-27-2010 02:19 AM
Hi,
I'm much more of a C programmer then a Labview one.
I've been tasked to convert some sections of a Labview 7.1 program into C DLLs. To speed up the Labview program. I have started working on a small section of the code and have already encounter a couple of speed related issues I need some advice on.
I need to call the DLL using complex double multiple dimensional matrices. As Labview DLL calling conventions do not allow complex data arrays (and the adapt to type will not work for these data element either). I have been converting them into signal dimensional double arrays. So the first step is to convert them into a signal dimensional arrays. The next is to covert them to double. I have found that using the typecast function to do this ridiculously expensive. It seems to be much more efficent (about half the time) to de-interleave the real and imaginary and then re-interleave them (see picture below)
I'm then having to do the same process in reverse. This seems like quite a wast does anyone know a better way.
The next problem is simply to do with calling the DLLs. I need to look into this more (as it could be all my type casting stuff which is causing it). But calling DLLs seem to have an overhead of about 5ms has anyone else noticed this.
Any help/advice is much aprciated.
Pev
07-27-2010 04:10 AM
Actually Adapt to Type supports complex numerics and arrays of them, but you get the native LabVIEW array data handle then, not a C array pointer.
And I can assure you that the overhead of the Call Library Node itself is much more in the order of fractions of microsconds than what you seem to think it is.
07-27-2010 04:23 AM
Hmmm your absoultly right. I could of sworn I tried adapt to type on complex numbers and the DLL crashed. However I just tried it and everything work great. My DLL function appears to be taken 1 to 2ms now.
I didn't mean to wast your time thanks for your help and quick reply,
Pev
07-27-2010 05:29 AM
Well if your DLL crashes you should always search it in your DLL or a type mismatch between how you configured the Call Library Node and how you prototyped the DLL function. If LabVIEW wouldn't support a specific datatype you would get a broken arrow, not a runtime crash.