SetWireInValue() with MATLAB+Frontpanel 64-bit works, 32-bit fails without error?

FrontPanel
1

Hi,

is there anything that can go wrong when switching from Frontpanel 64-bit to 32-bit?

Well, obviously, since in my case (win7 x64, Frontpanel 4.0.3, MATLAB 2011a win32 and x64) SetWireInValue() calls from MATLAB x64 with the 64-bit frontpanel dll work nicely, but nothing seems to happen (i.e. values don’t get transferred at all or in a totally wrong way) on MATLAB win32 with the 32-bit dll on the very same machine. I’m using MATLAB’s loadlibrary() and calllib() functions, the arguments passed to the library call are declared as uint32 in MATLAB. All library calls return “OK_NoError” , and no other error messages are generated. My board is a XEM3010-1500.

I don’t have any idea anymore on how to debug this, I can only list what is NOT the cause:

  • it’s not the firmware or clock config, since everything works when using the 64-bit dll.
  • it’s not an issue of 32-bit windows vs 64-bit windows. tried both.
  • it’s not the firmware download. An FPGA configured from 32-bit as well as 64-bit can be controlled using the 64-bit API call, but not the 32-bit one.
  • it’s not the compiler that MATLAB uses in the background. Tried both the built-in one and MS VisualC++ 2010

So, what can go wrong when using the 32-bit fronpanel dll?? Anything concerning byte order or endpoint bit width that I should know? Any clues?

Devastated,
minplanck

2

minplanck-- Just as a sanity check, have you tried a 32-bit C++ application using the 32-bit DLL on your machine? This should work fine and would tend to point the area of concern towards Matlab if it works for you and your setup.

3

Hi,

thanks for your quick reply.

Yes, using a C++ program that calls the 32-bit frontpanel dll works fine. So it has to be MATLAB. I’ve tried to declare the parameters passed to okFrontPanel_SetWireInValue() as various MATLAB data types (uint8, uint32), which doesn’t change anything.

I’ve tried to make the frontpanel wrapper .cpp output the values it received in some way, e.g. using printf(), but this doesn’t show up in the MATLAB console. Could you maybe provide me with an altered frontpanel dll that somehow returns/prints the values it receives (e.g. written into a string using sprintf or so)? Any other ideas?

Regards,
minplanck

4

Hi,

ok, I resolved the issue. The problem was that okFrontPanelDLL.h #includes windows.h: The scripts used in the background by loadlibrary() in 32-bit mode fail to properly parse the typedefs in windows.h and hence default to a wrong datatype when generating the so-called prototype file. Specifically, the UINT32 typedef used in okFrontPanelDLL.h doesn’t get translated to a 32 bit int data type, but to something shorter (a data type called “error” in MATLAB).

This problem doesn’t arise when loading a 64-bit library, because MATLAB does entirely different things in that case (it generates a thunk file and compiles it using an external compiler, Visual C++ in my case).

There are two possible resolutions:

  1. have MATLAB explicitly generate a prototype file (not just a temporary one in the background), correct the datatypes in it and then load the library using that corrected prototype file instead of the frontpanel .h file. See the loadlibrary() docs for details.
  2. change okFrontPanelDLL.h by manually re-defining the data types after the line #include windows.h (near the top of the file):

... #if defined(_WIN32) #include typedef unsigned char UINT8; typedef unsigned short UINT16; typedef unsigned int UINT32; ...
Then load the lib into MATLAB as usual using loadlibrary(). The datatypes get translated correctly.

I attached the warnings generated by MATLAB when parsing windows.h and a corrected version of okFrontPanel.h

Note that I don’t know whether my manual data type definitions are sufficient on all windows platforms.

Yes: computers really help us avoid a lot of dirty work…
minplanck

matlab_warnings_loadlibrary_frontpanel.txt (5.8 KB)

okFrontPanelDLL.h.txt (18.9 KB)