Labview 64bit Runtime Engine & Picoscope 5244A

[WayneR1]

I am using 4 PicoScope 5244A scopes in a project that is using TestStand 2014 64bit and Labview 2015 64bit. In the development environment all is working as expected but when I try and use the Labview Runtime engine I can no longer access the ps5000a.dll and I get errors in TestStand .

I have tried building a standalone Labview executable, to remove TestStand from the problem, with just one call to PicoScope5000aOpen.vi which builds ok but when run the .exe it can not access the ps5000a.dll, but again is OK in the development environment.

I have copied the ps5000a.dll to the Labview resource directory as well as the user, system32, sysWOW directories just in case there was a path issue but nothing is working.

Any help at this stage would help me out no end.

Thanks in advance.

[RavensFan]

Is there a reason you are using 64-bit LabVIEW?

Unless you have a special need like processing large data files or images, then you'd be better off using 32-bit LabVIEW.

My guess is that your .dll was compiled for 32 bit and 64-bit LabVIEW can't work with it.

[WayneR1]

I am capturing and processing many large data files so need the memory capability that the 64bit version brings.

The dll in question is meant for 64bit and works in the development environment it is only when i am using the runtime engine i get a problem. 

[altenbach]

Are you calling the dll natively or by path? Is it included in the build? (e.g. is it in the "data" folder next to the executable?)

[rolfk]

This sounds like there is something that this DLL does, which is not quite standard. I have created many DLLs myself and used them in both the development environment and in a runtime application and also integrated several third party DLLs with LabVIEW and never seen this happen.

So I think you have to take this up with the makers of that DLL. They are the only ones who can actually debug this in the source code and see what might be the actual trouble. For everybody else it is just tapping in the dark and guessing all kinds of things, like copying the DLL around in many possible and impossible places, which I think is not proper debugging.