I am using TestStand with niRFSA.dll to call the function niRFSA_ReadPowerSpectrumF64. This function will make the NI RFSA takes a spectrum sweep and return an array of amplitudes, as well as a structure that contains the frequencies information. My teststand sequence file is attached. The sequence editor will execute this function call, and actually retrieve correct data from the RFSA, I can see all the data in the Locals variables. The data are correct. However, the sequence editor also throws out system error, with no further details.
See the error window also attached.
Once in a while, the sequence editor will work just fine, executing the same function call without throwing out error, this is less than 10% of the time.
I am using this on Windows 7.
Let me know if you have any insight.
You may want to set the Return Value parameter to a variable so that you can look and see if the function is returning an error.
The most likely explanation is that you either have the function prototype or the struct definition specified incorrectly on the TestStand side. Make sure that the struct doesn't require any special struct packing setting and make sure that you have specified it exactly correct on the teststand side. An incorrect specification can lead to crashes and/or memory corruption like what you are seeing.
Hope this helps,
Yes this is what I suspected also. Since the container type was a TS custom type I created to accept the C struct from the instrument. But when the data come back from the dll is a C struct, and there lays the conflict, I think its the packaging layer semantics have some conflict, even though each of the element in the C struct matches the TS type definitions, as I received all that data correctly in TS.
Is there a "#pragma pack" compiler directive in the header file with the structure definition? Did you look at every field in the teststand data type and make sure it matches the struct fields data types? Are you passing the parameter by pointer or by value? Which does the function expect? These are the things to consider as far as whether or not it is being passed correctly.
Not sure about the pragma pack compiler directive, but I can check it out.
The TS custom container type matches the C structure, and the correct data were passed in correctly from dll structure to TS container.
Sometimes the differences are subtle and still look like you are getting the correct data even when it doesn't match exactly. If it is not this though, then the next most likely problem is with the dll itself, or some code that dll is calling.