Terminal emulation in Netlinx

chill

I find myself in the unenviable position of having to parse VT100 escape sequences from an extra-stupid piece of gear. The VT100 was introduced almost 30 years ago and so the protocol is very well documented online, but the reality of doing this on a control system is harder than it looks.

I have a client who wants me to dial VTC calls - and some do other things - on an Adtran imux. The problem is that this model (Atlas 830) is controllable ONLY via a VT100 compatible terminal. There is no command interface as such, and a dumb terminal won't work. The "terminal" is supposed to use the arrow keys to navigate through a menu structure until the desired function is highlighted.

Has anyone ever done this sort of thing before?

Thanks in advance.

DHawthorne

I haven't had to do exactly that, but a command string is a command string - once you get the syntax down, it shouldn't be hard. As I recall, VT100 uses ESC sequences for a lot of those special key commands, which just boils down to sending the hex string for those sequences. I think it uses $08 (backspace) for ESC instead of $33, but beyond that it's just whatever hex codes are needed.

jweather

Ignoring the VT100 part, using arrows to navigate menus is a recipe for disaster. Give them an upgrade route to a newer, more controllable piece of gear.

I'm not clear on what you mean by VT100... are you talking to the device via IP or RS232? If IP, are you talking about telnet negotiations (sometimes called Network Virtual Terminal)? When a device will talk to a telnet client but not to an AMX system, the solution is to respond to the telnet negotiation sequence, generally with WONT answers. This document may help: http://www.ics.uci.edu/~rohit/IEEE-L7-v2.html

chill

DHawthorne wrote: »

I haven't had to do exactly that, but a command string is a command string - once you get the syntax down, it shouldn't be hard. As I recall, VT100 uses ESC sequences for a lot of those special key commands, which just boils down to sending the hex string for those sequences. I think it uses $08 (backspace) for ESC instead of $33, but beyond that it's just whatever hex codes are needed.

The strings to be sent are trivial and, as I said, well documented. The problem is in reliably interpreting what comes back. What the Adtran sends back is codes describing the changes to be made to the "screen". These are VT100 escape sequences like "$1b,'[15;26H',$1b,'[7mUser Term'" meaning to put the text 'User Term' in reverse video on line 15 starting at character 26.

There aren't any command strings as we know them. For example, with a Tandberg MXP, you can just tell it "'dial 847035551212',$0d" and it will make the call. With the Adtran, you have to do a horrible dance with arrow and enter keys, and I feel I need to parse the response in order to keep track of where I am in the menu structure. Oh, and it's pretty slow as well - it can take a full second to redraw the screen at 9600 baud.

I was just asking whether I really need to reinvent this particular wheel, and it looks like I do. Thanks anyway.

jweather wrote: »

Ignoring the VT100 part, using arrows to navigate menus is a recipe for disaster. Give them an upgrade route to a newer, more controllable piece of gear.

I agree 100%. Problem is that this gear is customer-furnished, and they are already using it at six sites with more to come.

I'm not clear on what you mean by VT100... are you talking to the device via IP or RS232? If IP, are you talking about telnet negotiations (sometimes called Network Virtual Terminal)? When a device will talk to a telnet client but not to an AMX system, the solution is to respond to the telnet negotiation sequence, generally with WONT answers. This document may help: http://www.ics.uci.edu/~rohit/IEEE-L7-v2.html

RS232. VT100 as in the "smart" terminal introduced by DEC in the late 1970s; http://vt100.net/. My NI has to pretend to be one. But thank you for the link.