Labview Call Library Node (DLL) Exception

[tbd]

Hi Ted,

Thanks for the 7.1 version!

Since the CLF specifies "C" calling convention, I think it would be proper to \0 terminate the string before calling the DLL.

Have you tried \0 terminating the string? 

[tpascaru]

Hello,

Yepper-- adding 0x00's was one of the first thing I tried. I appended several hundred 0x00's at the end of the string.

I'm trying to think why does renavigating to the file with the browse button fix the problem? Thats gotta be a major clue.

I'm going to try and recompile with the DLL path fix you suggested as well and see what happens.

Thanks so much!

Cheers
-Ted

[tpascaru]

Hello,

I would like to bump this thread if anyone can help. As of today, Macraigor (the company whos product I'm trying to interface via Labview) is claiming they do not have a bug, and not really returning my calls. This leaves me with a partially crippled system. If anyone here has any ideas, I'm all ears.

Regards
-Ted

[Allison_S]

Tpascaru, I have tried calling a simple text file outside of the target access folder and did not get the error.  I have also tried calling both the ocd file and the text file using a string constant instead of the translation from a filepath to string, this had the same behavior.  The strange thing that I noticed is that if the .ocd file is accessed from outside the targetaccess folder it doesn't error, and if I try and open the text file from within the targetaccess folder it does give the error.  We're going to keep looking into it, but there's a possible workaround -- openning the file from outside the target access folder if possible.

[Travis_M.]

Good afternoon Ted,

I'm not too sure how this could be happening.  The program appears to run successfully only after the path is reloaded by clicking to browse to the path, OR if the data file being read is not accompanied by other similar data files.  It seems to me that the code in the DLL is corrupting the path data that is passed in to the point that only reloading the path results in successful running of the code.  String data is passed in as a cstring -- an array of chars ending with a null.  I'm not too sure how the dll could be corrupting the string, but all you need to do is run the VI in both "working" and "failing" modes and check the path going to the DLL to make sure its valid.  If you can get this sort of thing to fail without any external code calls I would be extremely interested in how because that would point to an obvious LabVIEW problem.

Let us know how it's going over on your side -- we're happy to help!

[tpascaru]

Thank you for the inputs. Travis: I'm a little confused as to what steps you'd like me to take. However, the bug/feature Allison found might be somehow related to the problem. I had actually discovered the problem months ago when I tried to move the text file outside the targetaccess folder just for configuration reasons. However, what I found is that although the DLL exception error does not occur when I move the file, I get an error from the DLL instead when calling from Labview! So.. the ONLY way to get the DLL to work with Labview is to have the text file in the targetaccess folder. I mentioned this to the folks at Macraigor, and they said it should not be a problem. I then tried calling the DLL with their tools (they provide several tools to interface to the DLL), and indeed, I was able to call the DLL with the text file located anywhere.

So to summarize: If I move the text file outside the DLL folder, I don't get the exception error, but I do get a DLL error when calling from labview. When calling from the macraigor tools, I can move the text file anywhere and it works.

Sounds like this might all be related in some weird interaction between Laview and their DLL. I don't doubt that it's likely that there's a problem with their DLL, but since they cannot replicate it with their tools (i.e. calling from the command line, from a c program, etc), they're saying it's not a Macraigor bug.

Thanks
-Ted

[tpascaru]

Travis, after reading your post a little closer, I should say that the DLL takes a string as an input. I just convert the path into a string and then pass it into the DLL. I've tried wiring in constant strings as well as control strings directly (i.e. not using a path control), and the same problem occurs!

-Ted

[minnellac]

I am just going to throw this out there. To me it sounds like a Working Directory thing. You mentioned that browsing to the file works, but when you run the program without browsing first (using a constant or control wired to the call library node) it fails. One thing that I have noticed when working with external code is that browsing to a directory using any of the browsing controls actually changes LabVIEW's Working Directory. I haven't found a way to programmatically change the working directory in LabVIEW.

I didn't follow along with every step you tried, but I would suggest doing some experiments while thinking about what directory is the Working Directory. For instance, after browsing to the file (and changing the working directory) you can run your vi. Does it still work if you use a constant after doing that, say on the next execution of your program? If not, does the Working Directory change when you run your program (because of something the dll does)? You can check by clicking Browse on a path control (if you don't explicitly provide a Starting Directory, this will default to the Working Directory).

Another thing to try, does running the provided test applications work because of their location? Are they in the same directory as the file they need to access? Also, you can try adding the required path to your System PATH variable, and see if that helps.

Chances are this will either make a lightbulb go off, or I am way off base. Here's hoping for the former option!
Chris

[.avi file]

Greetings Ted:

    I am not sure if it was explicitly mentioned before, we tried placing any of the OCD or the any other text files (for instance) in a different folder other than the target access. We were able to access it from LabVIEW just fine.

Can you move ahead with a workaround of having to place your OCD file in another folder other than the targetaccess, or create a sub folder underneath and place it there.

 I am going to reemphasize what Travis mentioned, if we were able to reproduce this issue without involving external function calls (dlls) than its an obvious LabVIEW problem. Which from the thread appears to not be the case.

 Is there any thing else you are expecting from us on this issue further, else let assume this issue taken care.

Thanks
Avi Harjani

[tpascaru]

Avi,

Please see my reply to Travis' suggestion as to why moving the file doesnt work. While it averts the DLL exception error, it still causes the DLL to fail, albeit it a more graceful way. This phenomenon only happens when calling the DLL from Labview. I can move the OCD (i.e. text file) anywhere and call the DLL from say the command line, and it works just fine.

Thanks
-Ted