Labview Call Library Node (DLL) Exception

[tpascaru]

    Hello,

I cannot seem to find a way to cure this strage problem. I have a very simple Vi that does a DLL call to my 3rd party application (a PowerPC debugger tool). The vi's input is only a string which consists of a file location that initializes the debugger. I simply use a convert file path to string routine to call the DLL (see enclosed vi. gif file).

Here's the problem: If I start up Labview, and call the routine with the default file path, I get an exception error (An exception occurred within the external code called by a Call Library Function Node --- see enclosed error.gif). However, if I click on the file browse button, and re-navigate to the same file, the DLL calls works! It will continue working until I shut down Labview and restart it! (i.e. if I keep making the vi call subsequent to renavigating to the filename, it wil work).

I'm really stuck on this one... I haven't seen much on this type of problem in the forum. If anyone has any ideas, please please let me know.

Thanks
-Ted

[AG123]

Hello Ted,

You are encountering this problem because of memory allocation issue stemming from the way by which you are sending your input string.  To overcome this, please refer to the example shipped with LabVIEW called Call DLL.vi.  Please run the VI, and choose the LabVIEW Data Type as String.  The VI that will open (see attached dll string input.gif file) will give a clear indication how to allocate sufficient memory in LabVIEW such that you do not receive the exception errors you have encountered. 

Hope this helps,

AG

[tpascaru]

Thank you for the reply AG. If I understand the example vi you referenced, the string allocation is done to create space for a string that is to be returned by the DLL (it's a DLL output). For my scenario (see the attachment in the original post), the DLL does not output any strings, it just takes one in as an input, and it just returns an integer describing whether or not the function suceeded.

Please let me know if I can still apply your example to my scenario.

Regards
-Ted

[AG123]

Dear Ted,

Just to verify, are you specifying the correct DLL path the first time you run this?  If you post your VI and the DLL I could try to reproduce the error, and find a solution.

Regards,

AG

[tpascaru]

Hi AG,

Thanks for the interest on this. I've replicated the problem on another machine to ensure it's consistent even without the external hardware that is normally required (a debugger tool that plugs into the parallel port).

I am enclosing the vi (TargetAccess Setup.vi), but you'll need to install the following software to get the DLL and all it's components:
http://www.macraigor.com/downloads/targetaccess.exe.

Just start the vi and execute it with the default values, and you'll see the exception error. Then, if you click on the browse button of the "OCD" control, renavigate to the same spot via the file browser and execute the vi, it should work (you'll get a different error, but that's expected since you dont have the real device hooked up to the parallel port).

In the C:\Program Files\Macraigor Systems\TargetAccess folder that is created by the installer, they have the C source to the DLL if that helps at all.

Best Regards and thanks!
-Ted

[tbd]

Hi Ted,

      I can't see your VI (LV7.1 here) so I can't see the default path.

  I noticed that path-to-string converts the "\" path delimiter to "\\"

- is it possible the default (string) path isn't using double-slashes for delimiters? 

Cheers

[tbd]

... er, scratch that.  Slashes always appear as double-slashes - when "\"-Code Display is enabled!

[tpascaru]

TBD.. if you want to check it out, here's the vi for v7.1 It would be interesting to note if the problem follows version 8, or also exists in 7.1

Thanks
-Ted

[gnilsson]

hello Ted
I tried it in LV71, same result! (error first then ok after browsing), at least some runs, (this sugest that uninitialize memory are referenced)
I tried to lengthen the input string, so it would not be so sensitive to overwriting, didn't  help.
So its probably the dll that writes to bad pointer, trashing labviews own memory.


In the source file targetaccessdll.c I see one problem (Bug) that perhaps could explain:
    if (dll_full_pathname[strlen(dll_full_pathname) - 1] != '\\')
    {
        dll_full_pathname[strlen(dll_full_pathname)] = '\\';
    }

    strcat(dll_full_pathname, targetaccess_dll);
IF dll_full_pathname indeed does not end with  \, they append it, BUT the fail to append an '\0' char
so the next statement,  strcat, will start appending at the first  \0  it finds ,  and that can be way out of range.
however i guess that dll_full_pathname resides  far away from labviews data, so this is a far out guess, however a serious bug!
Furthermore the error handling in targetaccessfll.c is flawed, only the last assingment to return_value matters. This is of course not a problem if all goes well. But its a BUG
Then i dont fully understand the processes of Loadlibrary of the very same dll that are calling, (maybe I missread the source)
I havent seen this done before, but maybe the try to load a different version, and I'm unsure of if global data

All in all the code are NOT good, maybe you could get an update
Its a bit tricky to debug even with Visual C and Windows Debugger, so I cant be more specific

If its realy urgent to you a could give it another try.

[tpascaru]

Hello, and thanks for the inputs. I guess I can try and recompile the routine: I do have visual C, although I'll be hacking around. What's interesting though is that they provide several sample programs that access the DLL (all in the targetaccess folder), and all those programs work just fine: TADelphiDemo.exe or TAMscppDemo.exe both provide a way to access the TargetSetup function, and it works every time. I don't doubt there's a problem with the c code, but it must be something that only manifests itself when Labview is doing the calling.

Cheers
-Ted