LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET Argument Out of Range Exception Error

Hi all,

 

I created a .Net dll in which a function takes in a string input and does nothing(Its name is DoNothing).

 

This dll has been invoked in my Labview 2009. The Application works in the following manner.

 

"The length of the string that is inputted to the dll gets increased by one for each iteration in the loop. This loop goes on forever as long as the user wishes"

 

The application throws an error which is attached when the length of the string which is passed to dll is 69556. When it is allowed to run further the same error occurs at 73652,77748 etc. That is exactly at an interval of 4096. I am not very sure about whether it follows a regular pattern but the error occurred is always frequent after the first error.

 

When we tried the same running in Labview 8.2.1, it throws an invoke node error(a .Net Exception). The labview 2009 error was atleast specific and detail.

 

When we did some more research on it, we found that it has nothing to do with any operation in the dll. When the length of string passed attains a limit as specified above the error gets thrown automatically. And also the outputted string from the dll can be of any length. It does not get affected by it so.Also the dll gets executed with out any discomfort when the error occurs.

 

 

Why does labview behaves in such a way on those scenarios ? Please answer it.We really need to solve this problem to proceed further development.

 

Please download the attachment and unzip it and run the vi.

Thanks,

Kandy.

0 Kudos
Message 1 of 7
(4,315 Views)
can you send the 8.2.1 version of the same?
Regards
Guru (CLA)
0 Kudos
Message 2 of 7
(4,311 Views)

Hi Guru,

 

Please find the attached 8.2 version vi.

 

Thanks,

Vaira Muthu & Kandy.

------------------------------------ 

0 Kudos
Message 3 of 7
(4,300 Views)
I did not encounter an issue calling your assembly at any of those values, but then I used a smarter testing method, as shown in the attached modification.
Message Edited by smercurio_fc on 12-17-2009 09:48 AM
0 Kudos
Message 4 of 7
(4,288 Views)

Hi smercurio,

The values that I specified seems to be changing to one my colleagues PC. Infact at 69564 it caused him an error. That is why we sent the vi starting from the first value. I think the number of times that we call a particular function could also be one criterion for the error to occur.

 

Did n't you encounter the error when running the vi that we sent? Please acknowledge for us to better understand it. 

 

Thanks

Kandy 

0 Kudos
Message 5 of 7
(4,263 Views)
For the record, I ran your VI under 8.2 but I encountered the errors at 69564, 73660, 77756, 81852. But when I ran the version I wrote using those same exact lengths of strings I got no error. This tells me it's more likely that the issue isn't with the assembly but rather with the testing method.  You've set up an artificial testing method which doesn't reflect how the assembly would ever be used in real life. The fact that you happen to get an error at this seemingly magical number of 69564 doesn't tell you anything especially if you can call the assembly directly with that same length string without an error using the method I did. The testing method causes a continuous memory increase usage because LabVIEW has to continuously reallocate memory due to the increasing string. The method I use has a single memory allocation. I don't know if this is the issue or whether it's an issue of how many times an assembly is called from LabVIEW, or if it's an issue of calling the assembly too many times within a certain amount of time. 
Message 6 of 7
(4,246 Views)

I know it's quite a while since this problem occurred and I'm not sure if you fixed it already. I got the same problem in a similar application. My error occurred not all the time and not really reproducible.

With your VI I could finally reproduce and invoke the error and try to fix it. During my own investigations I found the following information on the MSDN site:

Although it is not required that such source strings be terminated with a null character (as in native C/C++), the address is tested for startIndex+length+1 bytes to allow for a null terminator (http://support.microsoft.com/kb/971990) So why not terminate it with an empty string? I did this and it worked (see screenshot) The strings are the same but terminated with an empty string. So I stopped your StringPlay.vi at about 90000 characters without any error...

If you already switched to .NET Version 4.0 this error should be fixed (it's only a few weeks old, but who knows ;-))

 

br,

Christian

0 Kudos
Message 7 of 7
(3,906 Views)