Hi All, I'm having some trouble making expect work. I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port. When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything. Any ideas? Thanks. My expect script looks like this: #!/usr/bin/expect -f # device set modem /dev/ttyUSB0 # keep it open exec sh -c "sleep 3 < $modem" & # serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup # connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} } set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } } set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
are you using a USB to Serial dongle? for some time now they've been a standardised SoC that apparently handles breaks poorly... so if the system is expecting a break... (found this out for Unify PABX and Cisco serial - in the latter case, dropping the speed to 2400 and holding down space bar for 15 seconds was enough to fake a break - go figure... weird ) On Mon, 20 Aug 2018 at 10:29, cory seligman via luv-main < luv-main@luv.asn.au> wrote:
Hi All,
I'm having some trouble making expect work.
I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port.
When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything.
Any ideas? Thanks.
My expect script looks like this:
#!/usr/bin/expect -f
# device set modem /dev/ttyUSB0
# keep it open exec sh -c "sleep 3 < $modem" &
# serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup
# connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} }
set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }
set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
Yes, I am using a USB serial dongle. It's a known reasonably good quality brand that otherwise works fine interactively. On Mon, Aug 20, 2018 at 10:33 AM, Paul van den Bergen < paul.vandenbergen@gmail.com> wrote:
are you using a USB to Serial dongle? for some time now they've been a standardised SoC that apparently handles breaks poorly... so if the system is expecting a break...
(found this out for Unify PABX and Cisco serial - in the latter case, dropping the speed to 2400 and holding down space bar for 15 seconds was enough to fake a break - go figure... weird )
On Mon, 20 Aug 2018 at 10:29, cory seligman via luv-main < luv-main@luv.asn.au> wrote:
Hi All,
I'm having some trouble making expect work.
I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port.
When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything.
Any ideas? Thanks.
My expect script looks like this:
#!/usr/bin/expect -f
# device set modem /dev/ttyUSB0
# keep it open exec sh -c "sleep 3 < $modem" &
# serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup
# connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} }
set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }
set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
Yeah, that's probably fine - but it's still something I'd look at for workarounds... that whole "connect then fail to interact" thing sounds familiar... it's waiting for something that never comes, or the return is swallowed by the USB serial chip... On Mon, 20 Aug 2018 at 10:47, cory seligman <coryms.luv@gmail.com> wrote:
Yes, I am using a USB serial dongle. It's a known reasonably good quality brand that otherwise works fine interactively.
On Mon, Aug 20, 2018 at 10:33 AM, Paul van den Bergen < paul.vandenbergen@gmail.com> wrote:
are you using a USB to Serial dongle? for some time now they've been a standardised SoC that apparently handles breaks poorly... so if the system is expecting a break...
(found this out for Unify PABX and Cisco serial - in the latter case, dropping the speed to 2400 and holding down space bar for 15 seconds was enough to fake a break - go figure... weird )
On Mon, 20 Aug 2018 at 10:29, cory seligman via luv-main < luv-main@luv.asn.au> wrote:
Hi All,
I'm having some trouble making expect work.
I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port.
When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything.
Any ideas? Thanks.
My expect script looks like this:
#!/usr/bin/expect -f
# device set modem /dev/ttyUSB0
# keep it open exec sh -c "sleep 3 < $modem" &
# serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup
# connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} }
set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }
set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
-- Dr Paul van den Bergen
the ones I played with used the CH340 chipset: https://sparks.gogo.co.nz/ch340.html https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF do you know what chipset it's using? On Mon, 20 Aug 2018 at 11:32, Paul van den Bergen < paul.vandenbergen@gmail.com> wrote:
Yeah, that's probably fine - but it's still something I'd look at for workarounds... that whole "connect then fail to interact" thing sounds familiar... it's waiting for something that never comes, or the return is swallowed by the USB serial chip...
On Mon, 20 Aug 2018 at 10:47, cory seligman <coryms.luv@gmail.com> wrote:
Yes, I am using a USB serial dongle. It's a known reasonably good quality brand that otherwise works fine interactively.
On Mon, Aug 20, 2018 at 10:33 AM, Paul van den Bergen < paul.vandenbergen@gmail.com> wrote:
are you using a USB to Serial dongle? for some time now they've been a standardised SoC that apparently handles breaks poorly... so if the system is expecting a break...
(found this out for Unify PABX and Cisco serial - in the latter case, dropping the speed to 2400 and holding down space bar for 15 seconds was enough to fake a break - go figure... weird )
On Mon, 20 Aug 2018 at 10:29, cory seligman via luv-main < luv-main@luv.asn.au> wrote:
Hi All,
I'm having some trouble making expect work.
I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port.
When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything.
Any ideas? Thanks.
My expect script looks like this:
#!/usr/bin/expect -f
# device set modem /dev/ttyUSB0
# keep it open exec sh -c "sleep 3 < $modem" &
# serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup
# connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} }
set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }
set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
-- Dr Paul van den Bergen
-- Dr Paul van den Bergen
the alternative (read "proper") is FTDI http://forum.arduino.cc/index.php?topic=189239.0 On Mon, 20 Aug 2018 at 11:37, Paul van den Bergen < paul.vandenbergen@gmail.com> wrote:
the ones I played with used the CH340 chipset: https://sparks.gogo.co.nz/ch340.html https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF
do you know what chipset it's using?
On Mon, 20 Aug 2018 at 11:32, Paul van den Bergen < paul.vandenbergen@gmail.com> wrote:
Yeah, that's probably fine - but it's still something I'd look at for workarounds... that whole "connect then fail to interact" thing sounds familiar... it's waiting for something that never comes, or the return is swallowed by the USB serial chip...
On Mon, 20 Aug 2018 at 10:47, cory seligman <coryms.luv@gmail.com> wrote:
Yes, I am using a USB serial dongle. It's a known reasonably good quality brand that otherwise works fine interactively.
On Mon, Aug 20, 2018 at 10:33 AM, Paul van den Bergen < paul.vandenbergen@gmail.com> wrote:
are you using a USB to Serial dongle? for some time now they've been a standardised SoC that apparently handles breaks poorly... so if the system is expecting a break...
(found this out for Unify PABX and Cisco serial - in the latter case, dropping the speed to 2400 and holding down space bar for 15 seconds was enough to fake a break - go figure... weird )
On Mon, 20 Aug 2018 at 10:29, cory seligman via luv-main < luv-main@luv.asn.au> wrote:
Hi All,
I'm having some trouble making expect work.
I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port.
When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything.
Any ideas? Thanks.
My expect script looks like this:
#!/usr/bin/expect -f
# device set modem /dev/ttyUSB0
# keep it open exec sh -c "sleep 3 < $modem" &
# serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup
# connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} }
set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }
set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
-- Dr Paul van den Bergen
-- Dr Paul van den Bergen
-- Dr Paul van den Bergen
Oh, it’s genuine FTDI. That part is fine. I’ve had it dumping masses of data successfully if I manually start the transfer. Sent from my VT100
On 20 Aug 2018, at 11:37 am, Paul van den Bergen <paul.vandenbergen@gmail.com> wrote:
the ones I played with used the CH340 chipset: https://sparks.gogo.co.nz/ch340.html https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF
do you know what chipset it's using?
On Mon, 20 Aug 2018 at 11:32, Paul van den Bergen <paul.vandenbergen@gmail.com> wrote: Yeah, that's probably fine - but it's still something I'd look at for workarounds... that whole "connect then fail to interact" thing sounds familiar... it's waiting for something that never comes, or the return is swallowed by the USB serial chip...
On Mon, 20 Aug 2018 at 10:47, cory seligman <coryms.luv@gmail.com> wrote: Yes, I am using a USB serial dongle. It's a known reasonably good quality brand that otherwise works fine interactively.
On Mon, Aug 20, 2018 at 10:33 AM, Paul van den Bergen <paul.vandenbergen@gmail.com> wrote: are you using a USB to Serial dongle? for some time now they've been a standardised SoC that apparently handles breaks poorly... so if the system is expecting a break...
(found this out for Unify PABX and Cisco serial - in the latter case, dropping the speed to 2400 and holding down space bar for 15 seconds was enough to fake a break - go figure... weird )
On Mon, 20 Aug 2018 at 10:29, cory seligman via luv-main <luv-main@luv.asn.au> wrote: Hi All,
I'm having some trouble making expect work.
I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port.
When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything.
Any ideas? Thanks.
My expect script looks like this:
#!/usr/bin/expect -f
# device set modem /dev/ttyUSB0
# keep it open exec sh -c "sleep 3 < $modem" &
# serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup
# connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} }
set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }
set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
-- Dr Paul van den Bergen
-- Dr Paul van den Bergen
On Mon, Aug 20, 2018 at 10:29:46AM +1000, cory seligman wrote:
I'm having some trouble making expect work.
expect itself is a complete PITA. IMO you are better off using one of the expect-like modules for a general purpose programming language like perl or python. Also IMO, the time and effort you put into learning expect are better used learning a general purpose language - expect has only one use which you'll probably only need a few times in a decade at most, while perl or python or whatever has any number of uses. The only reason to use expect is because a) you are already an expert in it, or b) you like tcl. Everyone else should use their favourite programming language. Perl has several to choose from - the most generic is Expect.pm[1]. There's also application-specific ones like Device::SerialPort[2]. or for specific network protocols with, e.g., Net::SSH[3] and Net::Telnet[4]. Device::SerialPort has some basic expect-like functionality built in (e.g. the "lookfor" method), or can be used with Expect.pm. Python has Pexpect[5] google for "yourlanguage expect" for other languages. [1] https://metacpan.org/release/RGIERSIG/Expect-1.21 [2] https://metacpan.org/pod/Device::SerialPort [3] https://metacpan.org/release/Net-SSH [4] https://metacpan.org/release/Net-Telnet [5] http://www.noah.org/wiki/Pexpect craig ps: i used to know expect. I gave it up about 20 years ago when I first discovered Net::Telnet and now use perl now whenever i need to do that sort of thing. -- craig sanders <cas@taz.net.au>
On Mon, Aug 20, 2018 at 01:31:26PM +1000, Craig Sanders wrote:
Perl has several to choose from - the most generic is Expect.pm[1]. There's also application-specific ones like Device::SerialPort[2]. or for specific network protocols with, e.g., Net::SSH[3] and Net::Telnet[4].
Device::SerialPort has some basic expect-like functionality built in (e.g. the "lookfor" method), or can be used with Expect.pm.
Another one worth looking at is Net::CLI::Interact https://metacpan.org/release/Net-CLI-Interact Don't be fooled by the Net:: prefix, it works for serial connections too - the tutorial says: Introduction Automating command line interface (CLI) interactions is not a new idea, but can be tricky to implement. Net::CLI::Interact aims to provide a simple and manageable interface to CLI interactions, supporting: * SSH, Telnet and Serial-Line connections * Unix and Windows support * Reusable device command phrasebooks The module exists to support developers of applications and libraries which must interact with a command line interface. The SYNOPSIS section of Net::CLI::Interact has an overview of the commands demonstrated in this document. This has sub-modules for dealing with specific hardware vendors and models (e.g. cisco) craig -- craig sanders <cas@taz.net.au>
This is probably good advice. In the past I think I've made expect work, but I've wasted enough time on it now that I could have just written some code to do it. On Mon, Aug 20, 2018 at 1:31 PM, Craig Sanders via luv-main < luv-main@luv.asn.au> wrote:
On Mon, Aug 20, 2018 at 10:29:46AM +1000, cory seligman wrote:
I'm having some trouble making expect work.
expect itself is a complete PITA. IMO you are better off using one of the expect-like modules for a general purpose programming language like perl or python.
Also IMO, the time and effort you put into learning expect are better used learning a general purpose language - expect has only one use which you'll probably only need a few times in a decade at most, while perl or python or whatever has any number of uses.
The only reason to use expect is because a) you are already an expert in it, or b) you like tcl. Everyone else should use their favourite programming language.
Perl has several to choose from - the most generic is Expect.pm[1]. There's also application-specific ones like Device::SerialPort[2]. or for specific network protocols with, e.g., Net::SSH[3] and Net::Telnet[4].
Device::SerialPort has some basic expect-like functionality built in (e.g. the "lookfor" method), or can be used with Expect.pm.
Python has Pexpect[5]
google for "yourlanguage expect" for other languages.
[1] https://metacpan.org/release/RGIERSIG/Expect-1.21 [2] https://metacpan.org/pod/Device::SerialPort [3] https://metacpan.org/release/Net-SSH [4] https://metacpan.org/release/Net-Telnet [5] http://www.noah.org/wiki/Pexpect
craig
ps: i used to know expect. I gave it up about 20 years ago when I first discovered Net::Telnet and now use perl now whenever i need to do that sort of thing.
-- craig sanders <cas@taz.net.au> _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
On Mon, Aug 20, 2018 at 10:29:46AM +1000, luv-main wrote:
Hi All,
I'm having some trouble making expect work.
I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port.
When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything.
Any ideas? Thanks.
My expect script looks like this:
#!/usr/bin/expect -f
# device set modem /dev/ttyUSB0
# keep it open exec sh -c "sleep 3 < $modem" &
# serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup
# connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} }
set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }
set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
What a mess. Could you tidy it a little, or a lot? You don't need slow send with these short character sequences. You can do the shell lines before you start expect (as I'll demonstrate). I used to do a lot of (USB or not) serial stuff and never found I needed that sleep 3 thing. Once you set serial line params, they stay that way until a process changes them. Tcl open does not change them unless you tell it to. Anyway, sleep 3 <$modem is likely sucking up response characters. *exp_internal 1* is your friend when debugging expect scripts, Cheers ... Duncan. =================== #!/bin/sh # expect sees the next line as a comment continuation \ # You can put shell lines here as long as you end them semicolon backslash \ modem=${modem:-/dev/ttyUSB0};\ export modem;\ stty -F $modem 2400 raw -clocal -echo -istrip -hup;\ \ # Really start expect \ exec expect -- "$0" "$@" puts "connecting to $env(modem), exit with ~," spawn -open [open $env(modem) r+] ;# rw, no truncate exp_internal 1 ;# Comment-out once working interact { {~,} {exit} {~~} {send "\034"} } # and so on
Thanks for this. the exp_internal bit was helpful. I ended up working out that it wasn't progressing past the interact statement. This works fine now: #!/bin/sh # expect sees the next line as a comment continuation \ # You can put shell lines here as long as you end them semicolon backslash \ modem=${modem:-/dev/ttyUSB1};\ export modem;\ stty -F $modem 2400 raw -clocal -echo -istrip -hup;\ \ # Really start expect \ exec expect -- "$0" "$@" puts "connecting to $env(modem), exit with ~," spawn -open [open $env(modem) r+] ;# rw, no truncate exp_internal 1 ;# Comment-out once working set timeout -1 match_max 100000 send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
On Mon, Aug 20, 2018 at 2:24 PM, Duncan Roe via luv-main < luv-main@luv.asn.au> wrote:
On Mon, Aug 20, 2018 at 10:29:46AM +1000, luv-main wrote:
Hi All,
I'm having some trouble making expect work.
I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port.
When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything.
Any ideas? Thanks.
My expect script looks like this:
#!/usr/bin/expect -f
# device set modem /dev/ttyUSB0
# keep it open exec sh -c "sleep 3 < $modem" &
# serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup
# connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} }
set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }
set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
What a mess. Could you tidy it a little, or a lot?
You don't need slow send with these short character sequences.
You can do the shell lines before you start expect (as I'll demonstrate).
I used to do a lot of (USB or not) serial stuff and never found I needed that sleep 3 thing. Once you set serial line params, they stay that way until a process changes them. Tcl open does not change them unless you tell it to.
Anyway, sleep 3 <$modem is likely sucking up response characters.
*exp_internal 1* is your friend when debugging expect scripts,
Cheers ... Duncan.
===================
#!/bin/sh
# expect sees the next line as a comment continuation \ # You can put shell lines here as long as you end them semicolon backslash \ modem=${modem:-/dev/ttyUSB0};\ export modem;\ stty -F $modem 2400 raw -clocal -echo -istrip -hup;\ \ # Really start expect \ exec expect -- "$0" "$@"
puts "connecting to $env(modem), exit with ~," spawn -open [open $env(modem) r+] ;# rw, no truncate
exp_internal 1 ;# Comment-out once working
interact { {~,} {exit} {~~} {send "\034"} }
# and so on _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Hi Cory. I note the "-clocal" which is telling stty to honor the modem control signals, and I'm not sure what state "raw" leaves the "crtscts" and "cdsrdsr" options in. It couldn't be something as silly as CTS/RTS, DSR/DTR flow control doing its thing could it? Without knowing what signals are in use on the interface, I can't guess what may or may not be critical. The signals may be jumpered into a fixed state, required, or not even present. An RS232 tester could also prove useful in dignosing the issue. (The ones with the dual colour LEDs for the the various pins. They are not as common as they used to be, but they should still be a part of the toolbox for anyone that needs to deal with older RS232 technologies. Amazon show a couple of options including one that is a USB to Serial adapter with built-in LEDs, but that one doesn't have the two colour LEDs, so only tells half the story.) Morrie. From: luv-main [mailto:luv-main-bounces@luv.asn.au] On Behalf Of cory seligman via luv-main Sent: Monday, 20 August 2018 10:30 AM To: luv-main Subject: expect script Hi All, I'm having some trouble making expect work. I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port. When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything. Any ideas? Thanks. My expect script looks like this: #!/usr/bin/expect -f # device set modem /dev/ttyUSB0 # keep it open exec sh -c "sleep 3 < $modem" & # serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup # connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} } set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } } set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
Hi Cory, On Mon, Aug 20, 2018 at 05:21:38PM +1000, luv-main wrote:
Hi Cory.
I note the "-clocal" which is telling stty to honor the modem control signals, and I'm not sure what state "raw" leaves the "crtscts" and "cdsrdsr" options in. It couldn't be something as silly as CTS/RTS, DSR/DTR flow control doing its thing could it?
Without knowing what signals are in use on the interface, I can't guess what may or may not be critical.
The signals may be jumpered into a fixed state, required, or not even present.
You can set these in the Tcl "open" command you are using by e.g. open -handshake rtscts|none|xonxoff in your script line spawn -open [open $modem w+] See *man n open*
An RS232 tester could also prove useful in dignosing the issue.
(The ones with the dual colour LEDs for the the various pins.
They are not as common as they used to be, but they should still be a part of the toolbox for anyone that needs to deal with older RS232 technologies. Amazon show a couple of options including one that is a USB to Serial adapter with built-in LEDs, but that one doesn't have the two colour LEDs, so only tells half the story.)
Morrie.
From: luv-main [mailto:luv-main-bounces@luv.asn.au] On Behalf Of cory seligman via luv-main Sent: Monday, 20 August 2018 10:30 AM To: luv-main Subject: expect script
Hi All,
I'm having some trouble making expect work.
I need it to talk to some vintage equipment over usb serial, and I think I'm getting hung up on opening the port.
When the script runs, it just connects to the device and sits there. I can drive it interactively, but it doesn't attempt to automate anything.
Any ideas? Thanks.
My expect script looks like this:
#!/usr/bin/expect -f
# device set modem /dev/ttyUSB0
# keep it open exec sh -c "sleep 3 < $modem" &
# serial port parameters exec stty -F $modem 2400 raw -clocal -echo -istrip -hup
# connect send_user "connecting to $modem, exit with ~,\n" spawn -open [open $modem w+] interact { ~, exit ~~ {send "\034"} }
set force_conservative 1 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } }
set timeout -1 match_max 100000 send -- "\r" send -- "\r" expect ">" send -- "p 7d91\r" expect ">" send -- "p b2ff\r" expect ">" send -- "h\r" expect ">" send -- "td\r" expect "td\r 18 215 12 24 33\r
" send -- "gd 215\r" expect eof
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Cheeers ... Duncan.
participants (5)
-
cory seligman -
Craig Sanders -
Duncan Roe -
Morrie Wyatt -
Paul van den Bergen