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

[cbutcher]

---

@liordavi wrote:

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

---

I think we're (at least I) am just checking that the device (oscilloscope) doesn't send some response to a command.

Sometimes (usually?) when you send a command to a device, it will give some response.

It might not be that important to you, but if every time you send a command, it sends back the same command (i.e. echoes) or sends some confirmation of receipt (e.g. "GOT-IT\n" (although that's not likely to be the actual text... 😉 )) then those responses will gradually build up in the Receive/Read buffer.

This leads to a memory growth (not exactly leak, but build-up...)

[billko]

I've never seen anything like this.  I think the whole method of communications needs to be revisited.  It sounds like a big kludge to get around an incomplete understanding of how to communicate with the instrument.

[RTSLVU]

---

@liordavi wrote:

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).

---

 I see you seem to be using raw SCPI commands. Have you tried finding any LabVIEW drivers for your scope? 

What oscilloscope make and model?

As others have said I think you are missing something here as in over a decade of instrument control using LabVIEW and VISA, I have never had to use the VISA CLR function. 

[liordavi]

I'm using SCPI commands indeed.

Scope model - DSAX96204Q

using drivers/VI's/SCPI from the keysight website 

[cbutcher]

Looks like a nice scope.

Any chance you can share the programming manual? The download requires a login... 

[billko]

If the instrument truly SCPI-compatible, then a rewrite of the communications strategy is definitely in order.

[billko]

If you go to the LabVIEW driver area and check out how they do the various plug and play drivers, you'll get a good idea of how to write SCPI-based drivers.  Some are written better than others, but you will see that, rather than trying to make one uberVI to handle all the different combinations of write and read, they have a subVI for each command.  Maybe you don't have to organize your project in a manner similar to these drivers (although this is good for consistency's sake), but try to emulate how they put their drivers together.

I felt the need to post this, because without this information, my last post sounds like I'm just lecturing you.