TCPIP communication with instrument worked only once, failed for the second time ...

[William1225]

Hi

I have a programmable power supply, and I'd like to use TCPIP protocol to communicate with that instrument.

I can send command and get the response at the first time, but failed when I try to send the second command and get the response.

For simplicity, I demonstrate my question by querying "*IDN?" command two times.

It failed as the following error message.

However, I can do it successfully by enabling one of the querying process and disabling the other.

I'm very confused why it failed to communicate with the instrument by the second querying, something like the TCPIP session is closed.

But when I tried it by Putty, it works to query twice.

Does someone has any suggestion about this issue?

I just do not want to use the workaround to open and close the TCPIP session for every querying.

[wiebe@CARYA]

You're reading 50 characters, and the string could be more then 50 characters.

It could be that the 51-52th character are \r\n. You'd read those the 2nd time, and the string would be there, but on the 2nd line that is hidden. A probe would clear that up as well...

I'd check if the reply strings are \r\n terminated. It would be very hard to communicate with if it isn't, as you don't know for sure how long the reply will be. So usually, it's \r\n terminated. Then, read (much) more characters, and wire a CRLF to the mode of the TCP read function.

It might be required to also send a \r\n after the commands you are sending...

[crossrulz · Accepted solution]

Try adding a wait between your queries.  I have seen plenty of instruments "puke" when they get commands/requests too quickly together.

[William1225]

Hi wiebe@CARYA,

Very thanks to your reply.

I think it is correct that the "bytes to read" for my response is 50 bytes.

I've tested by two ways:

1. Set the "bytes to read" to 51 instead of 50.

It will turns out to be "Timeout" and the response is still the 50 bytes of data.

2. Set the "bytes to read" to 25 in two successive querying process.

It will turns out to be half data separated in the two response.

So... if there are some characters, such as \r\n, are not read, I can read them in the second time.

In my case, the second querying process has no response at all and timed out.

It is wield but the Putty works.

[wiebe@CARYA]

---

@William1225 wrote:

So... if there are some characters, such as \r\n, are not read, I can read them in the second time.

In my case, the second querying process has no response at all and timed out.

---

If the 2nd line started with a \r\n, all characters would have 'fallen off' the 2nd indicator, and might well go unnoticed. 

Reading 2X25 characters doesn't prove this, as a \r\n might still be send after the 2nd read.

As long as you're sure (the other tests seem solid), I'm OK with it (also if you're not sure btw ).

What does the manual have to say about this? I think \r\n termination is pretty common. Have you tried sending "*IDN?\r\n" (\r\n in escape mode of course)? How would this work if the device doesn't have ethernet? You'd still be expecting 50 characters, and they won't come in...

[crossrulz]

---

@William1225 wrote:

1. Set the "bytes to read" to 51 instead of 50.

It will turns out to be "Timeout" and the response is still the 50 bytes of data.

---

This convinces me (along with counting the characters you have read and the Putty output) that a Carriage Return (\r) and a Line Feed (\n) are being send by your instrument.  So I very highly recommend you update your TCP Read to read more like 100 bytes and set the mode to "CRLF" (enum input on top of the function).  This way you will be covered if an extra byte is sent or a byte is dropped for whatever reason.

---

@William1225 wrote:

In my case, the second querying process has no response at all and timed out.

It is wield but the Putty works.

---

You are doing things manually in Putty.  You are relatively slow compared to compiled code.  So I am 99% certain your instrument just doesn't like getting multiple messages within X ms of each other.  Again, add a wait between your queries.  I would use 50 or 100ms.

[wiebe@CARYA]

---

@crossrulz wrote:

---

@William1225 wrote:

1. Set the "bytes to read" to 51 instead of 50.

It will turns out to be "Timeout" and the response is still the 50 bytes of data.

---

This convinces me (along with counting the characters you have read and the Putty output) that a Carriage Return (\r) and a Line Feed (\n) are being send by your instrument.

---

There are 48 readable characters, to the other two making 50, are very likely \r and \n...

(Just to make this very, very clear)

Put those string indicators to show escaped characters to actually show this.

I'd try to add \r\n to the "*IDN?". That might be a deal breaker too. Putty ,might (optionally) add this automatically. Or add it because you actually press "enter".

[jamiva]

I'm not sure if anyone else mentioned this, but the default mode for the TCP Read is "STANDARD" mode i.e. No termination character. Try changing it to CRLF

EDIT- Oops Crossrulz already mentioned this

[billko]

Can you communicate with it using VISA?  That would probably be a whole lot easier (not to mention it would be more scalable, too).  Try communicating with it in NI-MAX.  I'd try something like "TCPIP::192.168.1.8".

[William1225]

Hi crossrulz,

Actually, I had tried to add waiting time between two querying process, but it didn't work "that time".

Since I read the manual and found it mentioning waiting time is 50ms, so that I added 50ms and 100ms that time and failed.

After I read wiebe@CARYA's message, I was wondering what if I sending "/r/n" between the two querying process(just like the processes in the Putty, I sent the first command and got the response, and pressed "Enter" key and sent the second command...??), it somehow works.

And when I started to reply your message, I'd like to exerggerate the waiting time(1000ms) to demonstrate the waiting time might be no help but it worked surprisingly.

After some trials, I found 250ms is safe waiting time to ensure the second querying process work.

Very appreciated to your advice.