Jump to content

LabVIEW 8.2 crashes when running file created in LV8.6


Recommended Posts

hello,

I created a vi that works just fine in LabVIEW 8.6 I then saved it for a previous version and gave it to my co-worker who has LabVIEW 8.2 on his machine. He is able to open the VI but when it gets to a certain function call it crashes. The function call is calling a c++ dll (which he has in the same location as I do on my machine) the parameters of the function are:

String (c string pointer),

double,

long,

double,

*short

Not sure why its unable to call one function and the other is making it crash....frusty.gif

Thanks for any and all help

CK

here is the function call that is causing LabVIEW 8.2 to crash.......It was created in LabVIEW 8.6 and saved for a previous version.

-CK

post-15930-127325203464_thumb.jpg

Link to comment

I mean our DLL's and folder structures are the same but the computers are not exactly the same themselves......we also tried building the function call from scratch in 8.2 - it wouldn't work then either......

Link to comment

I mean our DLL's and folder structures are the same but the computers are not exactly the same themselves......we also tried building the function call from scratch in 8.2 - it wouldn't work then either......

That would lead me to believe it's a problem with your buddy's machine, not LabVIEW.

By identical, I meant operating system, hardware, etc.

Link to comment

We were able to find out what it was.....the DLL that we were calling uses winapi calling conventions, LabVIEW 8.6 is smart enough to realize this so you don't have to set that when configuring your library function node - so I did not have this configured in 8.6 and it was still working, LabVIEW 8.2 is not smart enough to realize this......so since that was not set in LabVIEW 8.6 once it was saved for 8.2 it thought it was supposed to use the C convention instead of winapi ......after we changed that it worked fine.

thumbup1.gif

Thanks

CK

Link to comment

We were able to find out what it was.....the DLL that we were calling uses winapi calling conventions, LabVIEW 8.6 is smart enough to realize this so you don't have to set that when configuring your library function node - so I did not have this configured in 8.6 and it was still working, LabVIEW 8.2 is not smart enough to realize this......so since that was not set in LabVIEW 8.6 once it was saved for 8.2 it thought it was supposed to use the C convention instead of winapi ......after we changed that it worked fine.

Most likely this is because of the name decoration Visual C uses by default for WINAPI functions. Those functions have in fact by default (but it can be suppressed) an @n appended where n is the number of bytes the function takes on the stack for parameters. LabVIEW has been smart enough to accept undecorated function names(just as it also accepts prepended underscores which is the default name decoration for cdecl functions) and map them to the according decorated name for ages. Apparently they added in 8.6 the smartiness to use WINAPI automatically when the function has this decoration. I guess it can byte your ass as you have found out, but it is not a bad improvement. Of course the backsave feature would be even better if it knew this smartness too, but I have a feeling, that may not have been foreseen in the backsave feature, so it may not even be possible without a lot of extra work.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.