Why do I get 'Bad Calling Dll Convention' ?

[Rafi2003]

Hi jason

Attached is a project with "real" dll I've created with a vi made by somebody else.  It only uses Double and string inputs and 2 double outputs.  However, I can't make it to work......

Coule you please have a look at it?

Thank you very much

Rafi

[JasonWhite]

Rafi,

It looks like your prototype in VB is using "Long" as the variable type.  A "Long" is a long integer, an int32 in LabVIEW.  I believe that you need to change this from "Long" to "Double".

I have admittedly not tried running your code with this change but I'm pretty confident that it's where your issue lies.

Jason 

[Rafi2003]

Hi,

Please disregard my previous mail.  I found my error and fixed it.

The problem in the attached project is that, although I get the display I'm supposed to get, it does not "behave" the way I expect it.

At first, I used the vi the way I received it.  The result was, vi does the job, display the graph and disappear from the screen. 

I tried to find some property to make it stay put and when I didn't find it I added a wile loop that I can terminate with a button. 

Now the graph is displayed but it's "running" all the time.  I'd like to display a "frozen" picture of the graph and than to be able to expand it, move it along the scale etc...

Can you help me to fix this problem?

Thanks

Rafi

[JasonWhite]

Rafi,

If you think about what's happening when you make that DLL function call, your VI *has* to be running.  That's just code that's executing from the VB process.  It just takes a really long time to return from that function call because of your added while loop.  If you want to make the graph editable, etc, you either need to a) write that into your program or b) use a different method for invoking your LabVIEW code.

Besides using a DLL, you can also use the VI server functionality in LabVIEW to open a VI, set some front panel control values, and execute it.  There's more code on the VB side but it's not terribly difficult.  It leverages ActiveX automation which VB supports nicely.  The key difference in doing this is that VB and LabVIEW are running in two different processes, independently.  Once the VI runs, you can pull data back from it but also leave it open even when it's not running.  This is probably an easier path to get what you want. 

If you search ni.com for examples, you should be able to find some.  I just searched for "VI Server Visual Basic" and came up with a couple of links that look like they should get you headed in the right direction.

http://zone.ni.com/devzone/cda/epd/p/id/1396

http://zone.ni.com/devzone/cda/epd/p/id/1182

Jason 

[Rafi2003]

Hi Jason,

thank you for the new information.  WHile I'm considering this new approach, I still want to activate the dll made the "normal" way.

Attached is a new vi (my associate is an expert LV programmer and he make the vi per my specifications...).  The only addition is a 'Stay' input -- Boolean in LV and I made it Byte in VB.

It doesn't work.  I get a message "Run-Time error 453.   Can't find DLL entry point....."

Can you have a quick look and advice me for the problem?

Many thanks and appreciation for you time

Rafi

[Rafi2003]

Never mind....problem is solved

Thanks anyways

Rafi

[simon76]

Hi Rafi,

Don;t mind to share how you solve your "Can't find DLL entry point....."

thanks and regards,

Simon

[Rafi2003]

Hi Simon,

it wasn't anything inteligent worth sharing.  It was some stupid mistake...name of file or path or something like that.

Regards

Rafi

[simon76]

Hi Rafi,

I do believe i make the same mistake as you're....

So, i have solve my problem...

regards,

[JasonWhite]

Simon,

Things to double check:

1.  Make sure that you are exporting from LabVIEW using the standard calling convention (ie. stdcall) and not C-style (cdecl) or any other means.  This is likely the most common reason to get this error.  If you use the wrong calling convention, there are two issues that come up.  First, the name is "decorated" differently when exported from the DLL.  Second, the parameters may not be placed on the call stack the same way.  You'll either get an error (more likely) or a crash if you mess this up.

2.  Make sure that your function parameters and return value match between LabVIEW and VB.  I usually take the function prototype that shows up in the LabVIEW window where you set up the function exports and paste it into VB as a comment.  That helps provide me with a place to double check.  Again, the issues that you may run into with getting the prototype wrong are that you have unexpected information on the call stack which will either result in a funny error or again a crash.

I don't know if this is the problem that Rafi had but thought I'd at least help with what I've seen in the past.

Jason