Return array data from running DLL to Labview

[nz_mark]

Hi All,

I have a C++ DLL that should run continuously collecting new data from some hardware.

I can call the DLL with no problems from Labview, but I would like to access some numeric array data in the DLL back in Labview (either the caller, or another VI) while it is running.

Working towards this, I have already got the event posting working, i.e. triggering messages from the running DLL in the caller VI using PostLVUserEvent().  This would solve my problem (perhaps inappropriately) if I only needed a scalar or string from each event (which works fine).

I then tried passing some small integer arrays via the event (correctly changing the input type to Create User Event in LV), but this didn't work out (either empty arrays, or crashes...oops!).  Perhaps events are not the way to send large arrays (say 10^4-10^5 integers) anyhow...

Can anyone suggest a way to achieve this?  Are there any functions for manipulating the values in a LV control/indicator from the running DLL?

Many thanks for any assistance, MT

[smercurio_fc]

I thought PostLVUserEvent was a function for CINs. But you said you have a DLL.

??

[rolfk]

---

smercurio_fc wrote:

I thought PostLVUserEvent was a function for CINs. But you said you have a DLL.

??

---

CIN or DLL makes no difference. CINs are in fact specialized DLLs. However CIN's are legacy and should be avoided by all means for new development.

To the OP, PostLVUserEvent() expects to be passed a LabVIEW datatype. So you can't just simply pass a pointer to your data back. You do need to allocate a LabVIEW array handle with the correct size and fill in the data. And I believe once PostLVUserEvent() has been called it takes ownership of the handle. That means you can't just allocate a handle somewhere and keep it around and pass it over and over to PostLVUserEvent(). PostLVUserEvent() being an asynchronous function, where the parameters that you pass to it can and usually will be only evaluated after the function returns to you, can not work with referenced data, but needs to own the data it is passed, so it can deallocate it when it needs to, not when you as caller think it is right to do so.

[nz_mark]

Hi there,

Thanks for the info, Andy.  Yes - I got the feeling trying to send data via the event was a bit shady.

Do you think it could work in principle if I am careful to allocate memory and use the right kind of variable?

In any case, I am still on the hunt then for an alternative way to send back info to Labview. 

Some possibilities that I have seen briefly elsewhere:

- TCP/IP or VISA

-  Windows "memory mapped file" in DLL, to share data between DLL calls

Does anyone know if one of these options might work?

Regards, MT

[smercurio_fc]

---

rolfk wrote:

---

smercurio_fc wrote:

I thought PostLVUserEvent was a function for CINs. But you said you have a DLL.

??

---

CIN or DLL makes no difference. CINs are in fact specialized DLLs. However CIN's are legacy and should be avoided by all means for new development.

---

OK. Wasn't aware the function could be used in a DLL as well. Haven't written a CIN in about 15 years.

[rolfk]

---

nz_mark wrote:

Hi there,

Thanks for the info, Andy.  Yes - I got the feeling trying to send data via the event was a bit shady.

Do you think it could work in principle if I am careful to allocate memory and use the right kind of variable?

In any case, I am still on the hunt then for an alternative way to send back info to Labview. 

Some possibilities that I have seen briefly elsewhere:

- TCP/IP or VISA

-  Windows "memory mapped file" in DLL, to share data between DLL calls

Does anyone know if one of these options might work?

Regards, MT

---

Not sure what is shady about passing data with an event. You just need to understand the LabVIEW datatypes and their handling. It's in fact even all documented in the manuals although not in a way that takes you by your hand and tells you step for step how to do it. On the other hand if they wanted to make it this way, especially will all the features that can be accessed through the C interface, then the LabVIEW manuals would get a few GB larger, and even more people would not even bother to look for any informationin there.

All the options you name are a possibility with their advantages and disadvantages. In all cases you will not be able to avoid data copies. Full by reference data in a dataflow language is virtually impossible, unless you want to be bothered with every nitty gritty detail about memory management in LabVIEW personally.

Message Edited by rolfk on 10-20-2009 05:21 PM