LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA -1073807338 can anyone give me a better definition of what causes this error, other than the description provided in LabVIEW help?

I have been seeing a recurring instance of this error recently, that I am not completely understanding. Can anyone better explain what may be occurring when this type of error occurs.

 

Feel feel to speculate, but I was hoping maybe a designer might chime in on this.

0 Kudos
Message 1 of 7
(4,109 Views)

Without a clue to what you are trying to do (i.e. without a VI to inspect), who can say? 

0 Kudos
Message 2 of 7
(4,087 Views)

Well, if I were the designer of the error code, I think I could probably give an idea of what kinds of circumstances might cause this error to occur, regardless of the application.

 

However, if it helps, here is the problem. I have an ATE program that performs thermal cycling for a UUT using VISA calls to a GPIB controller which communication with 3 different instruments. The test itself runs fine for long periods of time, and then I start to see this error occur. However, the program appears to continue to run after I press 'OK' from the pop-up dialog ackowledging that the error has occurred. There appears to be no evidence of a memory leak that could possibly be contributing to the problem, or at least none that I have detected, and the error description itself is very vague. So basically what I am looking for is a better understanding of what MIGHT be causing this type of error. I would not expect a specific cause for my particular application, because as Bob was so kind to point out, I hadn't offered much information in my original post. What I was really looking for was a better understanding of the error itself, from a 30kft point of view.

 

Thanks Bob_Schor for pointing out the deficiencies of my original question, it's posts like yours that make this discussion board a wonderful place to have a professional discussion. 

Message 3 of 7
(4,077 Views)

Another example of a "general error code" that can be called from a more "specific" problem!  My favorite (NI) "error code" is the "We apologize for the inconvenience" message when (for some not-very-obvious-and-not-always-reproducible reason) LabVIEW crashes while developing a VI.

 

I've also encountered some of these "not-so-helpful" messages.  What you can sometimes do is to look at the code you've written, find the function (I presume it would be a VISA Read or a VISA Write) that is generating the error message, and simply open the function.  In some cases, you can actually inspect the "guts" of the function, including seeing under what specific circumstances it generates a -1073807338 message.

 

You are correct that there are, of course, a specific set of circumstances that causes the code to throw this error.  However, going "up" a level or two to the User's code, there might be a variety of circumstances that would cause this specific set of circumstances, leading the LabVIEW Development Team to devise a more generic message such as the one you saw in the LabVIEW Help.  For a more specific view, examine your more specific code.

0 Kudos
Message 4 of 7
(4,071 Views)

That's actually exactly my problem, the VISA Read that is causing this issue is in a loop and executes without error for I'd estimate 10-12 hours of a 250ms exection rate, and then I start getting this error, almost if to say that there is some finite space in some overflow buffer that finally "fills" up, unfortunately I don't have visibility to the memory allocation that LabVIEW/VISA makes, that is assuming that is what's going on, when this error occurs, was hoping someone would be able to shed some light on what "might" be happening, so I could make a more educated plan to move forward, than I currently have now.

0 Kudos
Message 5 of 7
(4,061 Views)

I don't have specific knowledge of this error. In case it's helpful, some things to try are:

 

 - flush the buffers when this error occurs

 - close and reopen the connection when the error occurs

 

It seems odd that it happens on VISA Read instead of VISA Close. You could drop a property node on the VISA ref just before the read, and log some of the properties over a long run.

0 Kudos
Message 6 of 7
(4,031 Views)

Using the I/O Trace tool, the program was experiencing a lot of I/O completion errors, so I changed all of my VISA calls to "Synchronous", and that seems to have fixed the problem. I'm thinking there is some amount of finite space that VISA allocates for thread execution that eventually just overflows.

 

Anyway, it has been running now flawlessly for twice as long as it before I started having these problems.

 

Thanks all.

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