I am having difficulty loading the FrontPanel dll into matlab for use. I get the feeling that I am overlooking something fundemental, but I have not been able to figure out a solution.
When I try to load the front panel library using loadlibrary as set out in the sample code, I first get parsing errors when setting up the preprocessed c file (okFrontPaneldll.i). The first several lines are:
[INDENT][I]Type ‘EXCEPTION_DISPOSITION’ was not found. Defaulting to type error.
Found on line 3229 of input from line 44 of file C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\excpt.h
Failed to parse type ‘void * __ptr64 PVOID64’ original input ‘void * __ptr64 PVOID64’
Found on line 7366 of input from line 222 of file C:\Program Files (x86)\Microsoft Visual Studio 8\VC\PlatformSDK\include\winnt.h[/I][/INDENT]
It goes on in this vein for quite some time. Matlab then creates and compiles the thunk file (seemingly without error) and then fails as it tries to load it. The error it gives is:
[I][INDENT]??? Error using ==> loadlibrary at 480
There was an error loading the library “\projects…\API\Matlab\okFrontPanel.dll”
The specified module could not be found.
Caused by:
Error using ==> loaddefinedlibrary
The specified module could not be found.[/INDENT][/I]
When I open the thunk dll in Dependency Walker I get the following errors:
[INDENT]Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.[/INDENT]
I almost get the feeling this a problem with my c++ compiler (Visual Studio 2005 Standard Edition) and not the ok panel library, as the two dependencies listed are ntdll.dll and kernel32.dll (both x86 CPU) when I should have all the dependencies be x64 CPU (right?).
All of this is occuring using Matlab 2010a and a Windows 7 64bit operating system.
Any ideas? All comments and suggestions are greatly appreciated.
That’s a new one to us. I’m not sure exactly what Matlab does to interface to a 64-bit DLL. Is Matlab, in fact, a 64-bit application or 32-bit?
Going out on a limb, have you tried the 32-bit FrontPanel DLL with Matlab?
Damn, I had hoped this would be easy.
I am not sure if Matlab is 32 or 64 bit (I think it is 32 bit), but all my available systems are 64 bit, and therin lies the rub. From the Matlab load library comments and help file:
[QUOTE]MATLAB generates a thunk file, which is a compatibility layer to your 64-bit library. The name of the thunk file is:
[INDENT]BASENAME_thunk_COMPUTER.c[/INDENT]
where BASENAME is either the name of the shared library or the mfilename, if specified. COMPUTER is the string returned by the computer function.
MATLAB compiles this file and creates the file:
[INDENT]BASENAME_thunk_COMPUTER.LIBEXT[/INDENT]
where LIBEXT is the platform-dependent default shared library extension, for example, dll on Windows.[/QUOTE]
Going through the loadlibrary code, I could force it to think my system is a 32 bit system, but I think this will just cause other problems (I will try this later today anyway). It always creates the thunk file for 64 bit systems.
Do you have any 64 bit windows 7 systems you have tried the MATLAB library with?
Looking through the forums, it looks like other people have been successful with Windows 7 and the matlab library, so I am just hoping if I can determine what is different about our cases. I am growing more sure that it is not Windows 7, Matlab, or the OK panel library, which is leading me toward the C++ compiler. I am using the standard version, but Matlab says the professional version is required. I am going to cross post this on the mathworks forums to see what they say there, but I would love an existence proof that I can use this with my systems…
Well, if Matlab is a 32-bit app, it may be restricted to communicating with 32-bit DLLs only. You can install the 32-bit version of FrontPanel and use the DLL from that installation instead.
Unfortunately, we do not have a license for Matlab, we only provide the DLL. Matlab support should be able to answer the question for you, though.
It looks like I have fallen into DLL Hell (Here is a good article in Dr. Dobbs Journal).
I have had several programmers more knowledgeable than I look at my problems and it appears that my C++ compiler is not able to link to the correct shared libraries in WinSxS. This is not a problem with Opal Kelly, or Matlab (though their method of loading shared libraries could use some improvement), but it is really a problem with Windows. I am sure that a solution is possible (including the shared MS dlls privately and bypassing the SxS manager), but it is just not worth the time.
Thanks for the responses.
Are you accessing the DLL directly from Matlab or are you trying to build a MEX with it?