Labview VI behaving inconsistently

[blockheadjr]

This seems to be a common occurance for me:  I have a library node call function that queries a C program via a .dll file.  The function is used as a sub-VI for other larger Labview programs, and is quite simply a library node with outputs and an error in/error out line.  Nothing fancy.

The thing is, one program will use this VI successfully while another will result in the dreaded memory corruption error, located at the library node in question.  And it gets stranger:  a modified version of this library node VI was made for testing.  On day one, it worked like a charm.  On day two, memory corruption error.  The same damn program.  The only changes between day one and day two were a cleanup and consolidation of files, and I know that shouldn't pose a problem.

Other info:  the C code query initiates I/O with a power supply in every case above.  I have not mucked with the C code or the .dll file. 

Are there any memory corruption error vets out there who can recommend a plan of action?  Or, in lieu of that,  a novel way to vent my frustration with Labview?

And to add more fuel to the fire:

In the Call Library Function properties of the VI in question, the function name is "GrabLogData", but the function prototype is listed as GrabLogData@@YAHJAP000...@Z.  I have no idea where this suffix of letters, numbers and @'s comes from.  It certainly isn't in the C code that the function calls to. 

Thanks for any help anyone can lend.

[JLS]

Hello,

Not fun to receive such errors; let me get some information and hopefully we can find a resolution or at least begin working on one.

First, what version of LabVIEW are you using?  The following may be useful if you're using the LabVIEW 6.1 DSC module:

http://digital.ni.com/public.nsf/websearch/C351EA63DC26054A86256B480067CA32?OpenDocument

In any event, can you post your code, a screenshot of the error, and any other information you feel would be useful!  I'd like to recreate this if possible so that I can more directly address it.  To that effect, can you reproduce this with a dll you can also post (which doesn't require your hardware)?  Is it a GPIB instrument?  If so, you can check ni.com\idnet for a driver which may be a workaround!

In any event, I look forward to your reply!

Best Regards,

JLS

[Odd_Modem]

The funny letters in the function name might possibly be the result of 'function name mangling'. This is something that c++ compilers do (it appear to be a hack that has become a feature). There might be a more stable way to generate your dll by selecting certain compiler switches before the compile, or a wrapper dll can be created to call the c++ fucntions in the work of an interface to your LabVIEW code.

[blockheadjr]

JLS -

I'm not certain how much info I can give you.  I suspect the C code I'm using, along with the instrument I'm trying to communicate with, fall under confidentiality constraints.   I'll try to give you as much info as I can.

I'm using Labview 7.1 for this particular program.  I've posted a screenshot of the error below, with the Labview VI.  The .dll file is specifically for the hardware - gutting the hardware commands would defeat the purpose of the code (and of course, confidentiality comes into play).

The purpose of my query was to see if this might be a common problem with a general workaround.  I suspect it may be more specific an error, though.  So, in lieu of specific recommendations, some general ideas for troubleshooting would be helpful.  Even better, an idea what the error is specifically indicating would be a step in the right direction.

About the screenshot: the instrument control VIs are homemade and have been confirmed to work repeatedly in other programs (as well as in this program - the four VIs that start the program function fine).  The error occurs within the while loop - The iteration-to-stop line runs, as well as the error line and Time Delay 2.  The library call node doesn't budge.  Again, this very program worked fine before.

Thanks for your help!

(If the image isn't showing up, try pasting the url into your browser)

[blockheadjr]

OM - that may be the issue here.  The dll file this uses has been generated using MS Visual Studio (an interface I am woefully ignorant of).  I've had to rebuild dll's because the environment configuration wasn't right.  I may be using a different version of the same dll which was generated under a non-compatable configuration (which only reared its ugly mug now).  Another dll build is on my troubleshoot list.

[JLS]

Hello,

1. The link you provided doesn't actually show up as a link, rather, it shows as a forum error graphic indicating that the link/remote url is not accessible.  Can you post by attacheing it using the attachment fields below the posting text?

2. Did OM's suggestion help (if you've had a change to try this yet)?

3. I understand the confidentiality issue you are taking care of; can you past a screenshot of the call library function node configuration dialog at least?

Ok, looking forward to your post!

Best Regards,

JLS

[blockheadjr]

JLS -

I haven't had a chance to pursue the dll issue yet.

As far as the screenshot goes - my image server is on the blink, so none of my graphics are getting through.  As soon as I get it sorted out, I'll bump this topic.

[JLS]

Ok, I'd love to take a look if we can get it posted!

Thanks,

JLS