DLL calling problem

[flocern]

Hi,

I am trying to call function from a DLL in LabVIEW and am struggling to call certain function. The DLL is an API to run a host program controlling a X-ray tube and interface with the host program. The API is downloaded from here: http://amptek.com/products/mini-x-x-ray-tube-software/ and also attached to the post.

I have created VIs from the DLL with the Import DLL tool of LabVIEW 2015. According to the programming manual, the API uses standard C calling convention. I am using run in UI thread.

There is a function to start the host program (Open Mini X.vi) and one to check if a host program instance is running (is Mini X Dlg.vi). Calling these two functions seems to work as I am getting a return value of 1 indicating that a host program instance is started. However, calling any other function afterwards (e.g. Send Mini X Command.vi to switch on the device or set parameters) fails and returns the error 1097 in LabVIEW. 

As calls to some functions seem to work, calling functions from the DLL within LabVIEW seems work somehow but I cannot understand why only some functions would work and others give the mentioned error pointing at problems with the calling of function.

If anyone could offer some insight and suggestions what might cause this error to be thrown for certain function I would be grateful!

[majoris]

Not sure about this, but if there are exceptions coming form the code, you probably wanna wrap the exceptions in try blocks and deal with them in C++ land. Labview wants its DLLs to be C only (boring error codes only please). On that note,

static CString GetMiniXStatusString(byte monitorMiniXStatus)

is a function that Labview might not be able to handle because the return type is probably a class.

[majoris · Accepted solution]

Did you try changing the calling convention out of curiosity? I tried changing the convention to WINAPI (which seems to be suggested by the header file) and it seemed to maybe work a bit better (Read Mini X Monitor gave me some values).

[flocern]

Thank you for the suggestion of changing the calling convention. I have tried that and not seen any difference in the behaviour (getting the same error code). Have you seen any change, i.e. what values did you get from Read Mini X Monitor? 

The miniX status string should be one of the values listed in the enum MiniX_Status in the manual so I think that should not be a problem as return value.

[majoris]

Specifically, mxmReserved being 123.456 seems unlikely to be an accident.

[flocern]

I am getting the same return values incl. the 123.456 but the 1097 error at the same time. It seems you are not getting the error suggesting that indeed things work well on your side. Did you import the DLL yourself and use any specific settings?

Are you using any delays or something else in the VI used to test or just the sequence of opening and then reading the monitor?

[majoris]

Initially when I was calling things with C calling convention it crashed Labview. So I changed them all to stdcall (WINAPI). I am also using a different version of Labview - 2017 32-bit. Besides that, I don't think I changed anything interest. If I remember something I'll let you know. I am just using the DLL supplied in the Original API folder.

[majoris]

Missed your edit. I am calling these manually. So I manually called open, etc. So I didn't put them all on a block diagram. I can try that to see if anything happens.

[majoris · Accepted solution]

There does seem to be a slight dependence on how soon I call the other VIs after I call open. For instance, when I first call Open after starting Labview and then right after call Monitor, either the program hangs or it produces what seems like junky data. However, if I wait for 1 second after open, I get more sane information out of Monitor. Also, callling Monitor is fairly slow. It seems like maybe it takes >200ms on my machine but perhaps that is because I am missing whatever hardware this is.

[rolfk]

CString definitely won't work. That is a C++ class and LabVIEW has no ways to deal with that (and no you do not want LabVIEW to support such types in the Call Library Node as the according configuration dialog to handle that would be about 10 times as complicated as now and as it is, it is already to complicated for the majority of users).

You'll have to write a wrapper DLL that will convert those datatypes to standard C types and/or LabVIEW native types in order to call those APIs. Or if the supplier has a .Net driver instead then use that. .Net assemblies contain enough meta data over the exported methods and their parameters, that LabVIEW can create the necessary conversion interface automatically and just provide you with method and property nodes to access them directly.

A DLL interface contains nothing of this except the function name itself and even the according C header file contains way to little meta data to make a safe automatic interface.