VISA Serial versus TeraTerm

[Jay14159265]

---

@RTSLVU wrote:

Using Teraterm I send the command "data?list=[{"3036":"I0"},{"3034":"F18000"},{"3035":"F1000"},{"3040":"I5"}]"
The UUT returns "[{"3036":"I0"},{"3034":"F18000"},{"3035":"F1000"},{"3040":"I5"}]"as expected

But using VISA Serial I send "data?list=[{"3036":"I0"},{"3034":"F18000"},{"3035":"F1000"},{"3040":"I5"}]"
The UUT returns "data?list=[{"3036":"I0"},{"3034":"F18000"},{"3035":"F1000"},{"3040":"I5"}]"

The "data?list=" is still there using visa and I don't understand why.

---

For $20 you can see exactly what the device is sending: 

https://www.sparkfun.com/products/18627

[tst]

---

@Jay14159265 wrote:

---

---

For $20 you can see exactly what the device is sending: 

https://www.sparkfun.com/products/18627

---

While a logic analyzer can be useful, a simpler and faster option would be to just use a sniffer program running on the PC to monitor the communication and see what the difference is between sending in TeraTerm and sending in LV. This has some caveats, but will probably work well enough.

Since the OP is using VISA, they likely already have NI Spy/NI IO Trace installed, which should be able to do this monitoring.

[Jay14159265]

---

@tst wrote:

---

@Jay14159265 wrote:

---

---

For $20 you can see exactly what the device is sending: 

https://www.sparkfun.com/products/18627

---

While a logic analyzer can be useful, a simpler and faster option would be to just use a sniffer program running on the PC to monitor the communication and see what the difference is between sending in TeraTerm and sending in LV. This has some caveats, but will probably work well enough.

Since the OP is using VISA, they likely already have NI Spy/NI IO Trace installed, which should be able to do this monitoring.

---

Sure, but where is the fun in that : ) I always like a good excuse to use a logic analyser or oscilloscope. 

[JÞB]

We still need to know the information about the remote device!  Everything else is just a guess about what that device's engineer implemented. 

Although,  sometimes we guess really well!  Empirical Evidence! (Especially that evidence supporting documentation provided by the [ir]responsible engineer) or that sniffer, cannot be disproved.

Again, Empirical evidence cannot be disproved!

[RTSLVU · Accepted solution]

Well after I quit listening to the firmware engineer on this project and did some investigation...

I discovered:

When I send data to the device I have to use CR (x0D) as the termination character

That means the remote echo also sends back CR (x0D) as the termination character
When the device sends a response to a query it uses LF (x0A) as the termination character

So I ended up doing this:

The response from the firmware engineer was "Sorry for the inconsistency"

[crossrulz]

---

@RTSLVU wrote:

I discovered:

When I send data to the device I have to use CR (x0D) as the termination character

That means the remote echo also sends back CR (x0D) as the termination character
When the device sends a response to a query it uses LF (x0A) as the termination character

---

What if you send a CR and a LF for your commands?  If the firmware is done correctly (ie it does a Trim Whitespace or similar on the read lines), then this would prevent the need for you to constantly change the termination character.

[RTSLVU]

---

@crossrulz wrote:

---

@RTSLVU wrote:

I discovered:

When I send data to the device I have to use CR (x0D) as the termination character

That means the remote echo also sends back CR (x0D) as the termination character
When the device sends a response to a query it uses LF (x0A) as the termination character

---

What if you send a CR and a LF for your commands?  If the firmware is done correctly (ie it does a Trim Whitespace or similar on the read lines), then this would prevent the need for you to constantly change the termination character.

---

When I discovered this the first thing the firmware engineer said was "Well send both then" but that did not seem to work as the device I am communicating would ignore commands sent with EOL instead of CR as the termination.

[crossrulz]

Firmware engineers...

My next option would be to leave the termination character as LF.  This would cause you to read the echo and the response in one read.  You can then use Match Pattern to find the CR to separate the echo from the response.

[JimB.]

---

@RTSLVU wrote:

---

@crossrulz wrote:

---

@RTSLVU wrote:

I discovered:

When I send data to the device I have to use CR (x0D) as the termination character

That means the remote echo also sends back CR (x0D) as the termination character
When the device sends a response to a query it uses LF (x0A) as the termination character

---

What if you send a CR and a LF for your commands?  If the firmware is done correctly (ie it does a Trim Whitespace or similar on the read lines), then this would prevent the need for you to constantly change the termination character.

---

When I discovered this the first thing the firmware engineer said was "Well send both then" but that did not seem to work as the device I am communicating would ignore commands sent with EOL instead of CR as the termination.

---

Weird. There is no "EOL" character, it's a CR followed by a LF. So that would mean it is ignoring the CR if followed by a LF, which seems like pretty odd behavior.

That said, if you set the termination character to CR/LF in LabVIEW, are you sure it's not just the receive that just isn't working? If I'm understanding correctly what you said that it echoes your command with CR and then responds to the query with LF then that means the query data comes in between the two characters. I'm pretty sure using CR/LF as the terminator only works when the two characters appear immediately together.

Anyway, I would not use the EOL Constant for serial comms because it is platform dependent. On Linux it should only be LF. (You are on Windows, right?)