NI VISA Read returns ASCII backspaces (0x08) that do not appear in PuTTy

[RavensFan]

Changing the settings might cause things to appear differently in the log.  But it doesn't change the fact that the device is sending those characters.  There is no logical reason for any device to send a backspace character (except if you were looking at valid bytes within a stream of binary data).  Vitesse needs to explain it.

[Ben]

---

@RavensFan wrote:

Changing the settings might cause things to appear differently in the log.  But it doesn't change the fact that the device is sending those characters.  There is no logical reason for any device to send a backspace character (except if you were looking at valid bytes within a stream of binary data).  Vitesse needs to explain it.

---

I caqn not explain but I can speculate...

If the switch thinks it is talking to a VT-102 then the back-spaces would be used to update a screen. It was common back "in the day" to paint screen to look like a form and then do updates of the screen using back-space and then over-writting the text at a fixed location on the screen.

in the case discussed in this thread, I would investigate if the serial port of the switch be configured to think it is talking t a TTY (teleytpe) or a line printer.

Ben

[mikethemartian]

I appreciate everyone's responses.

I spoke to an engineer at my company who has worked with Vitesse. He does not use LabVIEW at all but came across the same problem while communicating with the device using the Minicom terminal program on a Linux system. So now I know the issue isn't related to LabVIEW or NI VISA. He thinks what is happening is that the device's response handler is timing out waiting for the full response to be ready to be written to the port. The response to the "platform debug allow" command is the repeated command and then a long string including a warning about using the command. He thinks that the handler is timing out waiting for a carriage return (CR) and prematurely starting to write the "platform debug allow ..." but then it gets the CR or some other trigger and instead of just appending what it already wrote it tries to erase it and write over it. So in PuTTy I am only seeing the net result even when I log it. If I could really turn down the baud rate to a few Hz I would probably see the backspaces being written out. Apparently the log that was produced is only a copy of what was on the display and did not show all the details as LabVIEW is showing. The other program I was using was probably also doing the same thing even in the Hex view. It was likely just showing the Hex of the characters on the display and not the details.

Thanks again for everyone's assistance.

[RavensFan]

Is this something you will have to deal with in your LabVIEW code?  Or just something peculiar about their device you can just ignore?

If you need to handle it in LabVIEW code, then what you do is read the string it gives you.  Search through the string byte byte within a loop.  If it is not a backspace, then build the character onto a new string.  If it is a backspace, then delete the last character from the string.  Now when your loop for processing the message is done, the string should look just it would on the Putty terminal display.  Then you can move on and do what you need to with it from there.

[mikethemartian]

I will have to write a handler. As long as the error is consistent I shouldn't have much problem. As you said I can just have LabVIEW emulate how PuTTy works.

Thanks again

BTW I just got a response this morning from the manufacturer (formerly Vitesse now called Microsemi). They said they have seen the same behavior but they would have to investigate further to determine the exact cause.

[RavensFan]

Good luck.

*byte by byte is what I meant to say in my last message.

It may be easier to turn the string into an array of U8's.  Then when you find an element that is the backspace character, delete it and the element before it in the array.

[Ben]

Hi Bill,

It has been years but ...

I should voice a thought that would complicate your outlined solution, that being ...

I do not think the "backspace" = "delete" for  VT-102 type interface. the backspace was a carige control command that moved the cursor in the screen buffer similar to up-arrow etc.

The VT-102 had a 2-D character buffer that would store the charcters displayed on the screen so...

I will let the reader complete the exercise with that trivia in the event that the switch is really talking "VT-102-ish".

Ben 

[RavensFan]

Hi Ben,

That's an interesting thought.  Back in the day, what would have been the method to delete the character before the cursor like we know the backspace as today?  Would it have been backspace to back the cursor up and then delete to remove the character after the cursor?  Or was there no method to delete a character that would draw the characters after it back?  That each character on the screen was "box" that held a character, or if it didn't, held a space?

What you were saying about characters essentially overwriting each other makes sense.  In the example the OP showed,  something was "typed", backspaces were done  (whether to delete them, or just back up the cursor like you are suggesting now), then the equivalent number of spaces were entered (were they spaces like we know now, or just a method to clear out the characters on the terminal screen).  Then the same number of backspaces again followed by the original characters plus some more.

Whoever created the programming on this device, they were sure doing something that makes no sense by any modern standards (and by modern, probably the last 30 years.)  Whatever the backspace might have meant in the terminal, I don't think it will matter much to the OP since at the end of the day it should wind up with the same result either way.

[GerdW]

Hi,

as said before I just filtered the data stream of such a device with a VT emulation:

(cursor movement uses escape sequences, backspace char was used too…)

Maybe it wasn't the most efficient implementation, but fast enough to handle data for 3 screens/s… 😄

[Ben]

A cut-n-paste from here

http://www.columbia.edu/kermit/backspace.html

____________________________________________

First some terminology. "Backspace" might (or might not) be the name of a key. For example, it is printed on the keytop of the large key at the upper right of main keypad on the PC 101 keyboard. On the DEC keyboard, the same key is labeled with a symbol (<X]) instead of a word.  "Backspace" is also is the name of an ASCII control character (ASCII value 8), which might or might not be associated with the Backspace key. "Backspace" is also an abstract concept relating to computers, terminals, and typewriters, having at least two distinct meanings:

• To erase the character left of the active position (cursor), and simultaneously move the cursor to the position previously occupied by that character. This is called a destructive backspace.
• To move the cursor one space to the left into the same position as the character that was previously to its left, without erasing that character. This is a nondestructive backspace. Nondestructive backspacing is usually done with the Left Arrow key, discussed elsewhere.

To confuse matters even further,

____________________________________________

All of this talk of VT-102 may be a distraction if the switch is not set-up to talk to a terminal emulator like a VT-102 of course.

again "back in the day" people did not hve their own CPU as in the form of a PC but shared a common CPU that was often called a mainframe to which whre connected "dumb terminals" via serial connections. Baud rates were low and CPU's were just stating to get fast so all of the work associated with maintaining a porper "screen" was off-laded to the terminal. Updates where done using a minimal number of characters sent over the serial line so just back-spacing and over-writting the old character was much faster than sending the entire screen contents.

This URL hs the VT-102 user manual page explaining the backspace just moved the cursor one space to the left.

http://www.vt100.net/docs/vt102-ug/appendixc.html

Ben