Error:(VISA: timeout expired before operation completed).

[Devu_9]

Hi,

I have recently started working on LabVIEW. I am trying to connect an instrument using LabVIEW, but while running the code its showing a timeout error. The timeout error occurs when i try to establish a socket type connection. The identification query responds well, when the i establish the connection without configuring the port number. I tried enabling the termination character, but the same error persists. What could be the probable reason? I am attaching the correspoding screenshots.

[billko]

Is there a specific reason you want to make a "socket type connection"?  I mean, go with what works, right?

[JÞB · Accepted solution]

I'm going to assume the device is a Kepko power supply.

I don't have the manual handy for me to read however I see some clues here.

Somebody thought enabling ther term char would be a good idea as well as adding a \n in the write string while not showing any display formatting information so we don't know if that is a littoral "\n" or an escaped newline character.

Yet, the commonest teletype termination is carriage return newline (placing the carriage at home on a blank line of paper).

• Right-Click the string constant and bring up the editor 
• Show Display style select escape codes (\)
• Use "*IDN?\r" 

LabVIEW Ninja trick .... place a string constant linefeed on the block diagram and use typecast to a U8. Wire that to the termchar property and enable termchar. 

[Devu_9]

In order to control the instrument we need a socket type connection. Only identification query works with the other.

[billko]

---

@Devu_9 wrote:

In order to control the instrument we need a socket type connection. Only identification query works with the other.

---

Forgive me for being skeptical about the truth of that statement, but if one command works, they all should.  (Unless, of course, you are trying to use some kind of proprietary driver and not just some SCPI commands, which IMO are probably going to be easier to use.)

[jason-cce]

Maybe put a delay between "write" and "read".

Write -> wait 100ms -> Read

[billko]

---

@jason-cce wrote:

Maybe put a delay between "write" and "read".

Write -> wait 100ms -> Read

---

Unless specifically called for in the communications protocol, needing a hardcoded wait usually means you don't completely understand how to communicate with the instrument. 

[jason-cce]

Billko is right, I'm not familiar with this protocol.

Since it's timeout error, maybe the problem comes from the number 1024, the command "*IDN?\n" will not respond that many character, so please check the manual to find out exactly how many character should be.

Or try to put a delay.

[rolfk]

Images are useless to debug anything. We need the VIs or it is usually only possible with a lot of guessing and back and forth to maybe arrive at some solution.

Bytes at Port is wrong. Totally and completely if you are using a Socket resource name, which would imply TCP/IP. Bytes at Port is a Serial port only property. It is still totally wrong in about 99.9967 % of the cases if you use a serial port. And chances that your instrument is among those 0.0033% is absolutely none!

It only works sort of if you add that totally ugly delay. Ugly because you slow down your communication unnecessary that way as in most cases your instrument probably responds much faster but even 100ms can be sometimes to short and you end up having random communication errors. You could increase the delay to indefinite to avoid that problem but that would make your communication also impossible. So basically if you start to use Bytes at Port there is simply NO way to create a really reliable communication. You don't want to make the delay to short as you would get tons of problems that way, but no matter how long you make it it can always be to short.

You did set the termination character in the earlier picture and your command "seems" to contain a \n character, which is decimal character code 10. But since it is an image and since you did not enable the display style glyph we can not see if your string is set to "Display \ codes". If it isn't you do not send an "*IDN?<LF>" string to the device but a literal "*IDN?\n" and your device is waiting until the hell freezes over for that termination character you believe to be a line feed before it will start decoding the command and then send a response back, which most likely will be an error indication as it does not understand what \n means.

If your termination character setup matches what your device would like, AND if your string is setup to display backslash codes, the 1024 won't matter. VISA Read will simply wait until one of theses four events occurs, whichever is the first.

1) the number of requested bytes has arrived -> returns the requested amount of data

2) the termination character has been encountered -> returns the data up to and including the termination character

3) a driver function returned an error -> returns an according error and no data

4) the configured timeout has occurred -> returns your timeout error and no data

[billko]

---

@jason-cce wrote:

Billko is right, I'm not familiar with this protocol.

Since it's timeout error, maybe the problem comes from the number 1024, the command "*IDN?\n" will not respond that many character, so please check the manual to find out exactly how many character should be.

Or try to put a delay.

---

The VISA Read byte count only specifies the maximum amount of bytes to read before it returns a warning (not an error), so that is not the reason.  Far more likely is that you are sending the characters "*IDN?\n" instead of "*IDN?" with a linefeed.  Pay CLOSE ATTENTION to Jay's remarks in his post a few posts up.

Edit: Sorry it sounded so harsh.  I was just trying to emphasize that his post is very important and probably contains the info you need to fix things.