06-16-2016 05:23 PM - edited 06-16-2016 05:24 PM
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
Solved! Go to Solution.
06-17-2016 03:35 AM - edited 06-17-2016 03:46 AM
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.
06-23-2016 03:57 PM
Thank you so much. It helped a lot.