06-07-2018 12:28 AM - edited 06-07-2018 12:41 AM
I have a dll of a spectrum analyzer from which I have to automate a test procedure. Right now I am stuck in acquiring the data from the spectrum analyzer due to the wrong input commands for the function because I am confused between double* variable name and double *variable name. Ther required input command is Receive_Data_From_Dongle(int32_t hDongle, int32_t ID, double* rev_data, int32_t Data_Length); and what I am currently sending is Receive_Data_From_Dongle(int32_t hDongle, int32_t ID, double *rev_data, int32_t Data_Length);. Do I have to make any changes in the data type for input in the Parameter Type tab in call library function?
DLL file is also attached. Attached image contains the input commands for C and VB.
Solved! Go to Solution.
06-07-2018 04:03 AM - edited 06-07-2018 04:22 AM
Can you explain to me where you see a difference in your explanation between:
double* variable name and double *variable name
Similar what is the difference between:
Receive_Data_From_Dongle(int32_t hDongle, int32_t ID, double* rev_data, int32_t Data_Length);
and
Receive_Data_From_Dongle(int32_t hDongle, int32_t ID, double *rev_data, int32_t Data_Length);
Also from the prototype in your image it would seem that the declaration is rather:
uint8_t Receive_Data_From_Dongle(HANDLE hDongle, int32_t &ID, double *rev_data, int32_t &Data_Length);
This is c++ speak and in standard C the same as:
uint8_t Receive_Data_From_Dongle(HANDLE hDongle, int32_t *ID, double *rev_data, int32_t *Data_Length);
Aside from the missing reference for the ID and Data Length parameter, my guess is (and please note it is a somewhat informed guess as I have not seen the documentation for this function at all which should document this) that your rev_data needs to be a PREALLOCATED array of Data_Length number of elements.
So configure the rev_data parameter as an Array of 8-byte Double, passed as Array Data Pointer, place an Initialize Array function in front of the Call Library Node to create an array of the desired length and also pass the same number used to initialize the array length to the Data_Length parameter. Then after the function returns, resize the array to the length returned back in the Data_length parameter.
The first parameter is a handle, which is a pointer sized integer. Configure it accordingly as a Numeric, pointer sized (unsigned) integer and use a 64-bit (unsigned) integer on the front panel to pass this value between the different VIs. This makes this VI library future safe if you ever move to a 64-bit DLL and 64-bit LabVIEW version.
06-08-2018 12:47 AM
06-08-2018 03:49 AM
The manual is certainly interesting but makes not much sense before we have established that the VI itself doesn't have fundamental issues. So why is there often this hesitation to post the VI someone did?
Especially for Call Library Node issues there are many things that can be done wrong and only by looking at the actual VI is it possible to diagnose such problems. Do not post an image only as that does not show many of the settings of the Call Library Node and if you are already busy please make sure to not post the VI in the greatest and latest LabVIEW version. Not everyone has the luxury to install the latest version on a workmachine, as we do work on serious projects that often take more than a year to develop and changing LabVIEW versions halfway is a sure way to introduce trouble in such projects, and even installing a new version alongside poses a certain risk.
So open your VI, select "File->Save for Previous Version" and then choose at least two versions or more earlier when you post a VI on the fora.
06-08-2018 03:56 AM
Here is the vi which I have developed for the test.
06-08-2018 04:18 AM - edited 06-08-2018 04:29 AM
So lets go through the different parameters:
return value: signed 32-bit integer not really correct as the BOOLEAN corresponds to a 8-bit unsigned integer
hDongle; unsigned pointer sized integer great
ID: signed 32-bit nteger passed by Value wrong, passed as Pointer to Value
rev_Data: Array of 8 byte double, passed as array pointer great
Minimum size uses the value from Data_Length great
Data_Length signed 32-bit nteger passed by Value wrong, passed as Pointer to Value
I did point out that the C++ reference operator (&) needs to be treated the same as the standard C reference operator (*)
Also it would be useful to use the return value of that function as it will indicate if it was successful or if there was an error. Most likely the function considered the values it saw because of the mis-configured parameters as nonsense and simply returned with an error.
When the function indicates success.the Data_Length parameter on the right side will most likely contain the number of effectively copied data values, so you can use it to resize the array to the really relevant length.
Another recommendation is to not create a single VI that contains all the Call Library Nodes but make logical subVIs that contain one or sometimes two Call Library Nodes. This makes for a library of functions that you can easily reuse later on, rather than a single monster VI that you have to modify every time you want to change an aspect of your acquisition.
Another note: When calling Output_Serial_Number you pass in an empty string for the serial number. The function will attempt to write the serial string into that empty string and corrupt memory. You need to read the documentation for that function and see what is the maximum length this string can get and preallocate it in LabVIEW. The easiest way is to change the Minimum size in the Call Library Node to this number.
06-08-2018 04:30 AM
You may want to read my answer again. I did add additional information to it while you already accepted it as solution!
06-08-2018 04:37 AM
Thank you so much for your kind help, I was stuck in this since last 10 days. I am able to fetch the data now .