TCP mess

[MaSta]

Hello all!

I just wanted to have it confirmed that this is "normal" with LabView or that I probably have some wrong thoughts. My goal is to send a batch of SCPI commands through Ethernet to my device. After every command a certain waiting time is inserted. If the command is a query command, the response is read from the device after the waiting time, which elongates the waiting time by a few milliseconds.

The whole thing works good with a waiting time of 1 s or longer. When using, like, 50 ms the mess starts. What kind of mess? In Wireshark I can see that outgoing (!!!) messages not only contain one command each time, but two or three or even more. See attached image.

With this being a wrong command, the device will of course not respond, but process and put an error into its error queue. At a first glance it looks like LabView is messing up the buffer data that is used by the system to be sent via TCP.

Using the same batch processing via USB (COM) port runs fine, even with 10 ms or less waiting time.

[Blokk]

Could you share what device you are talking about?

edit: I mean the manufacturer/model info...I can see it is a function generator.

[Minions]

Try appending either the newline character "\n" or a semicolon ";" to each command that you send.  The instrument on the other end requires a standard termination character to let the instrument know that the command being sent to it is complete.

[Blokk]

---

@Minions wrote:

Try appending either the newline character "\n" or a semicolon ";" to each command that you send.  The instrument on the other end requires a standard termination character to let the instrument know that the command being sent to it is complete.

---

Yes. And if we know what model we are talking about, we could open the manual, where the proper termination character is presented 🙂 Plus all the communication protocol. There is a good chance, that official driver is available for the unit. Usually in such drivers all these "nuances"  are implemented, so I never try to re-implement the comm protocol from scratch, only if the driver is silly...

[Minions]

The command termination options are standard in the SCPI protocol.

[Minions]

If the instrument is SCPI compliant and allows the

*OPC?

command query, then append each non-query command with

;*OPC?\n

This command will respond with a "1" informing the user that the instrument has properly processed up to the previous command.  A response of "0" implies that it is still processing previous commands.  Obviously, you should only place a single query "?" within a command string.

[MaSta]

---

@Minions wrote:

The command termination options are standard in the SCPI protocol.

---

No, they're not. The standard only defines the syntax, not the transmission. What you have in mind should be GPIB. But this is about TCP on Ethernet. TCP is a packet based communication protocol, so I don't need a termination character.

[MaSta]

---

@Blokk wrote:

Could you share what device you are talking about?

edit: I mean the manufacturer/model info...I can see it is a function generator.

---

Does not matter. It is one of ours (no function generator), but this is general TCP related problem on the PC side, when using LabView. I unfortunately don't have another tool that can send Ethernet message repetetively within a certain time.

[MaSta]

---

@Blokk wrote:

---

@Minions wrote:

Try appending either the newline character "\n" or a semicolon ";" to each command that you send.  The instrument on the other end requires a standard termination character to let the instrument know that the command being sent to it is complete.

---

Yes. And if we know what model we are talking about, we could open the manual, where the proper termination character is presented 🙂 Plus all the communication protocol. There is a good chance, that official driver is available for the unit. Usually in such drivers all these "nuances"  are implemented, so I never try to re-implement the comm protocol from scratch, only if the driver is silly...

---

The Wireshark log clearly shows that outgoing (from PC to device) messages are corrupted.

[JensG69 · Accepted solution]

As far as I know that's a standard feature of TCP/IP (and not directly LabVIEW). The underlying TCP/IP driver will try to minimize the traffic and try to maximize the data content within one TCP/IP packet. If you want to ensure that even small messages are sent directly than it might be a good idea to turn on the Nagle algorithm for that connection. If you google for Nagle and LabVIEW you'll find how to do that.

Regards, Jens