LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Passing Arrays by Reference in to a dll

Solved!
Go to solution

Hello,

I have a dll function shown below

 

FI_API uint8_t FI_capture_settings_init_wrapper(uint32_t* cap_set, uint32_t* sen_set, uint32_t* rec_set, uint32_t* exp_set)
{

*cap_set = (uint32_t)55;

*(cap_set+1) = (uint32_t)56;
cap_set[2] = (uint32_t)57;
sen_set[0] = 54;

return 1;

}

 

I call the library function from labview. I Initialize a global variable array and pass it to the  FI_capture_settings_init_wrapper() . After, I displays the values of the array using an array indicator as shown in the image. The value is suppose to change in Labview. The API returns success. But array is not been changed in labview. Please see my camerainit.vi

 

 

Download All
0 Kudos
Message 1 of 3
(3,791 Views)
Solution
Accepted by topic author skariaroy

Your shared variable is an external resource that contains some data so when you read the shared variable, LabVIEW retrieves the data and copies it into a local array that is then passed to the DLL function. Since the array is not used after the DLL call, it is simply thrown away then. Then you read the shared variable again and LabVIEW retrieves its data, which hasn't been changed since and copies it again in a local array to show on the front panel indicator. If you want the shared variable to represent the new data, you have to write the right terminal of the Call Library Node explicitedly back into the shared variable. And reading the shared variable again right after is obviously completely wrong performance wise since the wire that came out of the Call Library Node already contains the data and should therefore be wired through for further use.

 

So your first problem is that you treat a shared variable as something that LabVIEW could treat as a pointer internally which it can't, the shared variable is hosted by the shared variable engine which is a seperate process and access through the data is over a TCP/IP based protocol. Even if it was a control on the front panel the code wouldn't do what you think it should do, since LabVIEW as a dataflow language will copy the data from the control into a local array and pass that to the DLL, and unless you write the modified data that comes out of the right side of that terminal back into the control, the control data will NOT change.

 

So learn how dataflow programming works! LabVIEW does generally not treat data as a reference that can be changed by reference through a function. Whenever LabVIEW suspects that a function could modify the data passed in, it MUST create a copy of the data in order to not throw the dataflow concept that is the fundamental base of LabVIEW programming out of the window. Forget shared variables, globals and even locals in LabVIEW as general programming construct, especially when you come from a traditional programming language like C(++), VB or C#. A LabVIEW wire is THE variable and you only should use the global and local variables if it is strictly necessary for something. Especially a shared variable as an external resource that is interfaced through TCP/IP is an absolute performance killer and should only be used if you need to transfer and access data between different (possibly network connected) processes.

Rolf Kalbermatter
My Blog
Message 2 of 3
(3,761 Views)

Thank you so much. It helped a lot.

0 Kudos
Message 3 of 3
(3,697 Views)