0

I've got this spectrum analyzer from the 90's that has a telnet client on it. I can telnet in with the Linux telnet CLI, and that works great...controls the machine as expected.

I'd like to automate this thing to do 100's of different measurements in a set-it-and-forget-it style setup, so Python is natural.

I'm looking at the telnetlib module, and am having some conflicting results...mind you, I'm still in the prototyping phase of this, so I'm using iPython to do this work.

Basically, I can connect and enter an interactive client with telnetlib.interact(), and that works just about as well as the Linux telnet CLI. However, when I copy the exact debug output to the telnetlib.write() method, the instrument doesn't respond. Actually, it says something like, undefined header in it's diagnostic output, so the message isn't being transmitted to it correctly.

Here's an iPython session output:

In [2]: import telnetlib

In [3]: HOST = "192.168.0.118"

In [4]: tn = telnetlib.Telnet(HOST, "5024")

In [5]: tn.set
tn.set_debuglevel                   tn.set_option_negotiation_callback  

In [5]: tn.set_debuglevel(2)

In [6]: tn.interact()
Telnet(192.168.0.118,5024): recv b'Welcome to Telnet SCPI Server: agilent\r\nAgilent Te'
Welcome to Telnet SCPI Server: agilent
Agilent TeTelnet(192.168.0.118,5024): recv b'chnologies, N1996A, US45310134, A.02.03\r\n\r\nSCPI>\xff\xfb'
chnologies, N1996A, US45310134, A.02.03

SCPI>Telnet(192.168.0.118,5024): recv b'\x01\xff\xfb\x03'
Telnet(192.168.0.118,5024): IAC WILL 1
Telnet(192.168.0.118,5024): IAC WILL 3
Telnet(192.168.0.118,5024): recv b'\xff\xfc\x01'
Telnet(192.168.0.118,5024): IAC WONT 1
Telnet(192.168.0.118,5024): recv b'\xff\xfc\x03'
Telnet(192.168.0.118,5024): IAC WONT 3
freq:star 110khz 
Telnet(192.168.0.118,5024): send b'freq:star 110khz\n'
Telnet(192.168.0.118,5024): recv b'SCPI>`
SCPI>

however, if I send the same thing with

tn.write(b'freq:star 110khz\n'),

nothing happens...or, if I send

tn.write(b'freq:star 110khz\n\n'),

nothing happens...no error messages or anything on the instrument. It's like nothing even happened.

I've seen some issues on stackoverflow that indicate that timing is an issue...I have no idea how to fix that other than by adding the tn.set_debuglevel(2) as a workaround to add delay, but this is probably misunderstanding on my part as well.

I do know that this instruments is expecting to see things in character-by-character mode and doesn't say whether is supports line-by-line mode, which is how I assume tn.write(foo) sends stuff.

Any ideas where I'm going wrong?

testname123
  • 1,061
  • 3
  • 20
  • 43
  • To begin with, if you look at the text lines you receive the newline is not simply `'\n'`, it's `'\r\n'`. Using that when you send text might be a good start. – Some programmer dude Jun 08 '16 at 13:47
  • That fixed it...I'll add an answer, but first to make sure I understand it correctly and don't give wrong information, why does sending something in the client that just has a `\n` work? What makes the inital reading more accurate that shows `\r\n`? – testname123 Jun 10 '16 at 14:16
  • Please [see this old answer of mine](http://stackoverflow.com/a/14606871/440558) which quotes (and links to) the Telnet standards about "newlines" in the Telnet protocol. – Some programmer dude Jun 10 '16 at 14:26

1 Answers1

0

This is a duplicate of this

Needed to add an \r to the newline binary portion of the message, so tn.write(b'freq:star 110khz\r won't work, but tn.write(b'freq:star 110khz\r\n will.

Community
  • 1
  • 1
testname123
  • 1,061
  • 3
  • 20
  • 43