Frequent VISA: (Hex 0xBFFF0015) Timeout expired before operation completed

[liordavi]

Hi all,

I'm using long run automation (~7 days).

I'm getting random fails at VI's related to VISA commands, error:

"VISA: (Hex 0xBFFF0015) Timeout expired before operation completed"

I saw interesting solution regarding timeout adding:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAQKSA4&l=en-IL

* Picture attached.

But I want to make sure where to place it best (or multiple places needed after all VISA clear/ABC in VI? since I need to use Clear\Close VISA due to long automation).

* Picture of my suggested solution attached

My solution is attached, but need your opinion too.

Thanks all !

[cbutcher]

Clear won't affect the timeout setting.

If you close the connection, you need to set it for the new connection.

If you use VISA Configure Serial Port instead (assuming you're using a device that that is appropriate for) you can directly wire the timeout value.

I'm curious about your solution though - perhaps this is very simplified for the forum, but what are you trying to do when you mention "long run automation", and is this CLR > Write > Wait > CLR > Close a typical real pattern, or just for the forum?

[billko]

Where's you read?

[liordavi]

Thanks for the reply cbutcher,

Clear - used to reduce memory usage (Labview blown the memory with 4GB space). and it's working at the automation (I do not have problems with it) .

Long run automation - Something I'm doing QA for and the whole test (at Testand, the problem occurs on random VI's in the Testand sequence) takes roughly 7 days.

What did you mean by: "you can directly wire the timeout value" ?

Thanks

[liordavi]

It's a standard VI I've used. There is no read. Only operation is being sent through VISA

Thanks

[cbutcher]

Based on this

---

@liordavi wrote:

Clear - used to reduce memory usage (Labview blown the memory with 4GB space)

---

and the lack of a Read, I'd suspect that you're filling the Read buffer because the device you're communicating with is sending some sort of acknowledgement.

Perhaps just reading that (even if you then ignore it) is a better choice?

Regarding the timeout value, the link I gave to a specific VI allows the timeout to be set during the Open operation.

[liordavi]

*Memory issue was solved with VISA clear.

My problem is the connection timeout (I think), since I'm getting lots of VI's disconnections and I saw online that timeout is needed and I don't have it anywhere in my VI's.

I just want to make sure, where to add the timeout since I'm contacting VISA several times (clear/close & write).

My logic is to set the timeout with VISA write, but is it right ? or I need to place it somewhere else ?

*All the VI's was inherited to me and I'm new with it.

[billko]

I have absolutely no idea why you keep associating the VISA CLR with memory because it has absolutely nothing to do with memory.  I will say that having a VISA CLR can be totally messing up your communications, as it flushes the I/O buffers and sends a break.  It could be the whole reason for the timeouts.  Think about it.  Doing a flush of the input buffer right before a read.  Maybe it flushes your data before you get to read it so sometimes there's nothing to read any more.  That will cause a timeout.

You mention that the VISA CLR solved your memory problem, but maybe it was just masking it, instead.

What you've shown so far is a highly unusual VISA command sequence (I don't think I've ever used VISA CLR before, and I certainly would never use it anywhere except upon communications initialization, or maybe to recover from a comm error), which leads me to suggest that there may be an incomplete understanding of the communications protocol.

[crossrulz]

Generally, constantly opening and closing a VISA connection will cause issues.  It is best to open/configure your session at the beginning of your test run and only close it at the end (or in an error condition and you need to reset the connection).

The MANY clears is also very concerning to me.  What type of connection are you using (serial, GPIB, Ethernet)?  Where are you trying to read data from your device?  The only thing I can think of where the clears would fix a memory issue is if you never read back from your device after several commands and then suddenly ask for the data and there is a massive data backlog left in the buffer.  This would indicate that you are not properly following the device's command protocol.  What are you trying to communicate with?

[liordavi]

Thanks for the help guys.

It's hard to follow memory leaks, but after clearing the VISA (that the time where this automation was inherited to me) the memory consumption of Labview got down from 4.5GB~ to ~2.5GB which helped solving the stopping (crashing) of the Automation.

My device is Oscilloscope which is connected via LAN.

Sometimes I'm just sending command and sometimes reading. The sample shown above is the "sending command" VI (configuring the scope).