error 1097 in executable VI

[MikeNuke]

Hi!

I am building an executable version of the VI I created with LabVIEW 2010 to control an oscilloscope we use in our laboratory.

The acquired data are passed through pointers, and the VI uses the DSNewPClr function to create the pointers and the MoveBlock function yo make the data available.

If I run the VI with LabVIEW, I have no problems and everithing works fine.

If I build the executable, I find two problems:

- the program does not find the two functions unless I put a copy of the LabVIEW.exe file inside the same folder (I have the runtime engine installed);

- both functions return a 1097 error, so that the oscilloscope is properly working, but the data are not accessible.

The first problem is solved, but I was wondering if there is a better way to do it.

The second problem makes the program useless...

Is it a known problem or am I doing something wrong?

Thank you for your help!

[rolfk · Accepted solution]

If you call any LabVIEW memory manager functions through the Call Library Node make sure to define in the Library Name "LabVIEW" sans quotes, and the upper/lowercase is important. This tells LabVIEW to link to whatever kernel is currently executing your VI code. If you enter LabVIEW.exe (case is unimportant under Windows) instead, the Call Library Node correctly wants to see a file LabVIEW.exe to link to. However that will likely cause all kinds of nasty problems since the heap manager in LabVIEW.exe executes in a different process space than your build executable which uses lvrt.dll to execute.

Also be aware that just because you do not get any errors doesn't necessarily mean that your code is correct. Memory pointer management on your own is a very tricky business to do and it is very easy to mess up there. That does not always have to result in an error that LabVIEW can detect to generate the 1097 error, but it will always in some ways corrupt memory.

[James_W]

Help>Explain Errors>type 1097 in the popup box and you find you have an invalid Call Library function node breaking your EXE.

your Project should list the dependencies, so add the dlls listed in the dependecies to the project (or just the ones you know you need if you can narrow it down)

in your EXE build definition:

on the "Source files tab" , Add the required DLLs to "Always included"

on the "Source file settings" tab , ensure that they are going where you want them (The default "data" support folder is fine)

when you have done this correctly, you EXE is correctly configured to work as a stand alone piece of SW with just the additional installers you need lije the run-time engine, VISA-servers etc!

(It isn't as simple as you haven't defined an installation with the correct additional installers is it? - If you are using instrument comms you need more than just the run time engine!)

Regards

James

[Dennis_Knutson]

I'm curious as to the make and model of the scope and the connection type that requires this sort of access.

[rolfk]

Dennis, that is another question. Most likely there is not even any need to use DSNewPtr et al. A properly placed Initialize Array with the correct datatype (likely U8) would most likely do.

[MikeNuke]

Hi!

@James_W: Thank you, I checked just to be sure that everything was ok.

@rolfk: Thanks for the advice, I didn't know this difference. I changed the Call Library Nodes as you said and now the executable is working properly.

@Dennis_Knutson: The program controls PicoScope oscilloscopes by PicoTech. They can both pass values directly or use pointers, but for our work we have to use the RapidBlock acquisition mode that divides the device buffer into segments, each of them requiring a pointer.

Thank you again 🙂

[James_W]

Well this was definitely worth helping out with - thanks RolfK

I get to play with PicoScopes in the next fortnight!!