How to pass address value when calling dll?

[mebelove333]

Hi,

     I want to use LabvIEW dll node to call a exteral dll, the prototype of the dll function is 

     "Functon (FLOAT input, FLOAT &output)",

     I try to use "point to value" as the output data type, but it return an error "1097", which explains "memory error".

     I think the problem is that the prototype want an address but I give a point, but there seems no other way to pass address.

     I had tried use "import dll tools" to use dll and its header files to generate VIs automatically, but it would use pointer as output datatype to match address, and it still report a 1097 error.

     So is there a way to use address(like & ) as parameters in calling dll? 

     If I can not modify the dll, how can I use it in LabVIEW?

Thanks

Yang

[wiebe@CARYA]

Post what you have.

Note that the calling convention is important. If it's wrong, every function with more then 1 parameter will very likely crash.

[rolfk]

Your guess about the source of the problem is wrong. A pointer to a variable is synonym to the address of that variable or also the reference to that variable. So that is not it!

But your FLOAT datatype is a non-standard C type, but defined by the Microsoft SDK to be equivalent to float, which is a single precision floating point value. If you try to use this on a 32-bit system and defined a double instead for these parameters I can see how that would nastily corrupt your stackframe, which will of course result in your 1097 error being reported by LabVIEW. But since the syntax of the prototype you show looks a bit strange for a C prototype it may be also some Visual Basic or similar prototype definition? If so the meaning of FLOAT could be different depending on what language that definition is meant for. Or your header file defines its own meaning of FLOAT, which is always another option too. Basically the information you provide is very meager, pretty inaccurate and leaves room for lots of guessing.

If that doesn't fix it, you also need to check the calling convention as pointed out by Wiebe. The prototype you show doesn't show any calling convention declared which by default means that the function uses cdecl, unless the project file configures a different non-default default calling convention of course, but since we don't have the project build file available that is always a guess.

LabVIEW 32-bit for Windows defaults to stdcall calling convention since that is what Microsoft Windows APIs usually use, so it's quite easy to get that wrong too.

[mebelove333]

Hi, Thanks for help

I base on your instruction I had made some test, here is what I had tried:

System: window 7, 64 bit

LabVIEW: 2020.0.0 32 bit.

I had change the data type like 4 bit single, 8 bit double to define parameters to match the function in dll, but still got error of 1097.

Here is the details about calling the dll:

1. About dll to call in LabVIEW

Dll function prototype:

ENGRTMOD(float TIME,float STEP,float KQDKG,float HZ,float MZ,float DTHCT, float GTO,float GTF,float FI1,float FI2,float FKP,float AI1, float AI2,

float &N1,float &N2,float &T1,float &P1,float &PHCT, float &T21,float &P2,float &P4,float &T4);

it was published by VC6++ and used to be called by VC6++.

Here is all the files about the dll files, in LabVIEW node, only ENGTMOD.dll is used.

2. How I call dll in LabVIEW and error:

I use dll node and put it in a while loop which is same mode when it was used in VC6++, all the initial parameters are the same.

Here is error and details:

3. Here is the setup using dll node in LabVIEW:

 Thank

Yang

[mebelove333]

Thank you for your reply, I had collect what I had tried and put it below.

Yang

[wiebe@CARYA]

The code in the dll can throw an exception.

Any exception, like a divide by zero, or a manual "throw" will be passed to LabVIEW.

So, even if your setup could is correct, you can still get an exception.

Even if all parameters might be passed correctly, the values might be wrong.

You are calling a decorated C++ function, with a mangled function name. I don't see why that wouldn't work for this function, but it's pretty high on the list of 'do not do this'...

[mebelove333]

Hi，Thanks for reply.

       One action we had tried is that we newly develop a simple c++ file to call this dll, and try to see if it works. and this would work fine. So we think this dll is ok and all the initial value for the parameters should be ok.

       We try to find a way that mak

e a better configuration with the LabVIEW dll node to use the dll, so we have tried different way. so one thing we begin to think about the difference between the "pointer" and "&", when we change the "&" to "*" as a point in c++, it would not work like LabVIEW.

      The last thing we want to think it some thing wrong inside dll, but we could do nothing about this.--We have thought that might be something happen inside the dll, thare are 3 functions in side the dll, in the picture we show above is the entrance function, it would call the other 2 functions inside,but  the dll is a packaged dll, so we are not clear what had actually happen inside, but if this is the cause of the error, it seems that we could not use this dll in LabVIEW. 

Yang

[rolfk]

One very weird fact I see in your function name is that it is prepended with an underscore that is often used by C compilers when compiling cdecl calling convention functions and a @88 postfix which is usually done for stdcall functions. So which is it? It is not C++ name mangling though, but simple standard C name decoration.

Also @88 would indicate that the function has 88 bytes of stack parameters and your function has 22 parameters 13 of them are 4-byte single precision floats and 9 of them are references, so you are obviously using a 32-bit DLL (well considering that you still use Visual C 6 that is logical, it can't create 64-bit code).

Something is definitely weird about this but you seem to be onto something top secret here, indicated by the wiped out function names, so it will be up to you to figure this out. Without the DLL and VIs there is not much more we can do for you.