VISA flush I/O buffer error 1073807194

[stwlee]

I've connected the computer to a router which is then connected to a device via RJ45 cables. This way, the device can be controlled via LabVIEW using the IP address. The first time I try communicating with the device using the proper IP address, everything works fine. Once the program has run for a while (run continuously) I run into this VISA Flush I/O Buffer error -1073807194. No matter what I do after that, the device does not communicate back. If I close LabVIEW completely (i.e. close out all windows and the startup window that pops up at the end) and rerun the program, the connection is re-established only to fail again after a certain amount of time.

I tried to see if the removing the VISA Flush I/O Buffer section would solve anything, but the same thing happens except now the VISA Write fails and gives the same error. Again, the the problem is resolve if LabVIEW is completely exited and restarted.

Could anyone explain WHY this occurs, specifically why it occurs after a certain period of time LabVIEW has been running? And if possible, a nudge in the direction of a solution?

Thanks.

[crossrulz]

Connection was lost.

Can you share your code?  Maybe there is something weird in there.

---

@stwlee wrote:

Once the program has run for a while (run continuously)...

---

If you are actually using the Run Continuously button to run your code instead of having an actual loop in your code, you need to fix that.  That could be causing all kinds of interesting things when it comes to instrument IO.

[stwlee]

The code is relatively simple (attached). It's rather simple, so I don't know where the problem is unless there's some kind of communication issue.

It's not running in a loop. This particular code (subVI) is placed within an event diagram that activates via latched boolean. The code itself does not run continuously, but rather LabVIEW itself so I don't have to keep clicking run.

EDIT:

Just to clarify, I'm not sure if connection was actually lost or anything; that's just my assumption because the device stops responding and I get this error.

Also, the connected device remains visible on the attached devices list when accessing the router settings, so it's not a loss of connection at that point.

[crossrulz]

Your error code means that there was a lost connection.

As I said before, DO NOT USE THE RUN CONTINUOUS BUTTON.  Make a loop for your code and stop it properly (not with the abort button).

How are you initializing your VISA Resource?  Are you closing it?

[stwlee]

I've put the entire program in a loop and am no longer running continuously.

The VISA is initisalized using IP address and port number for the device. Strangely enough, other similar devices connect and communicate just fine; it's just this one particular type of device that seems to be having the issue. 

Also, I've noticed that the wait time until the communication fails isn't limited to while the program is running. If the program has stopped but LabVIEW itself is still running and the program is restarted, the same error occurs.

Now I'm really stumped...could this all just be some kind of problem on the device's end that I can't figure out?

[Kimchi-Taco]

Hello, 

Would it be possible for you to attach the VI?

Thanks,

Jonathan R.

Applications Engineer

National Instruments

[Dennis_Knutson]

Why are you using a router instead of a direct connection? What else is connected to the router? At the very least, I would debug the code with a direct connection first.

[stwlee]

...I feel really stupid and shameful now. Turns out in my rush to get this program up and running, I've omitted a few simple things that kept causing the communication to fail.

Thanks for your help and patience, and I apologize for any inconvenience ^^;;

[Dennis_Knutson]

Why don't you explain what you did so others can avoid the same mistakes?

[stwlee]

Well...reading over crossrulz post again I realized that in my tests I've completely forgot to initialize my VISA properly and close it properly, then there were certain settings on the actual device itself that kept getting things mixed up.