LabVIEW and C++ Pointers

[rolfk]

---

@BartSchroder wrote:

A related question:

I have an asynchronous data acquisition system. A DLL function expects a pointer to an allocated byte array, and returns immediately. After some time the byte array is filled with values. Another DLL function is used to determine when the data has been placed into the byte array. I can easily allocate a byte array (say as a shift register in a while loop), and pass a reference to it into the DLL. However, because no DLL function explicitly passes data back to the shift register (it being normally done in the background by the DLL asynchronously), I cannot find a mechanism which allows the normal Labview dataflow structure to see that data has been passed into the array, and how to let the array know how many values are in it. Does anyone know how to solve this problem?

All the references I have looked at have the dll pass the data to the shift register directly by wiring the output of the DLL CIN to the shift register.

The DLL is a third party one. I guess I could write a wrapper in CVI, but that means learning a bit more C, which I would like to avoid right now!

---

This is a bit tricky but I have done this in the past without wrappers just using simple LabVIEW diagrams. The trick is to keep the array alive until after you have made sure it is filled and then read it. You can do that in LabVIEW by using some sort of artificial data dependency. Call your function with the allocated array pointer. Wire the right side of the Call Library Node (CLN) array parameter to a fucntion inside a Sequence that reads the interesting part of your arary. Now create a data dependency from the first CLN to the second (probably in a loop) that checks for the array filling to be finished. Then make sure that there is also a wire dependency from an output from the second CLN (or the loop) to the sequence containing your array read.

It is important to NOT branch the array wire as that would create a copy of the original array before it is filled or possibly (depending on the dataflow in your program) WHILE it is filled. And as explained above, data dependency needs to make sure that the data in the wire stays alive until it is not used anymore.

It is some sort of hack and there is a chance that future changes to LabVIEW to improve performance even more might break the particular implementation you have chosen, but the alternative is to create a wrapper function or two that allocates the buffer and later copies the data to LabVIEW deallocating the buffer again.

Rolf Kalbermatter

Message Edited by rolfk on 01-18-2007 11:37 AM

[Joe_Gerhardstein]

---

@rolfk wrote:

On the other hand .Net has a whole slew of new types of pointer types, some of which can be automatically converted, some are at least managed and can be properly although explicitedly dealt with and then you have the ones that you have to do everything on your own. I for one do understand quite a lot about C interfacing, but would never attempt to give advice in something like what the original poster asked with .Net, since I simply do not know enough about .Net to really understand that (and honestly I do hope I can keep it that way for some time in the future ;-).

---

Being the original poster and having worked with .Net and LabVIEW for about 2 years now, I would have to say that .Net is so much easier to work with than regular C .dlls that I would in all cases choose .Net assemblies over a C or C++ dll.  NI really has done a great job of making this interface workable.  If you are used to C/C++, .Net is a different paradigm so there is some learning curve, and you have to deal with the CLR (similar to the LabVIEW RunTime engine).  However .Net has greatly simplified all my data interchanges and interfacing with the non-LabVIEW world.