xiangfu has quit [Remote host closed the connection]
astr has joined #qi-hardware
Luke-Jr has quit [Excess Flood]
Luke-Jr has joined #qi-hardware
atommann has joined #qi-hardware
viric has quit [Read error: Connection reset by peer]
viric has joined #qi-hardware
atommann has quit [Quit: Leaving]
<DocScrutinizer05>
hey, maybe somebody here can help me out. Trying to control a PSU (PPS-11xxx Voltcraft http://www.reinhardweiss.de/german/sonstiges.htm) via shell, and everything finally works with "echo -e GMOD\r >/dev/ttyUSB0". But I can't for the life of mine find the right stty setting to set up the tty so it does convert <ENTER> into a "\r" (e.g. a "cat >/dev/ttyUSB0" simply doesn't work, no matter what I do via stty). Am I suffering some
<DocScrutinizer05>
misconception there regarding what stty can do and that it maybe doesn't work at all for cat>somwehere, or is there a trick how to use the stty parameters?
<DocScrutinizer05>
in short: what do I need to do so the "\r" in "echo -e GMOD\r >/dev/ttyUSB0" is not needed anymore?
jekhor has joined #qi-hardware
pcercuei has quit [Ping timeout: 250 seconds]
<roh>
DocScrutinizer05: forget stty and similar pita. (serials termios suck).. take pyserial and hack up a python script
<roh>
also some drivers forget the settings on serial close, so you cannot properly set stuff on shellscripts
<DocScrutinizer05>
well, you can, opening tty on evak on fdN
<DocScrutinizer05>
eval 4<ttyUSB
<DocScrutinizer05>
been there, done that. but it seems stty and/or ioctl of tty doesn't work like supposed to
<DocScrutinizer05>
I wrote a stepper motor controller a while back, and I ran into exactly same problem back when. Seems tty doesn't obey what man 1 stty suggests onlcr etc are supposed to accomplish
<DocScrutinizer05>
I wasted 4 hours trying to talk to that sucker PSU via minicom
<DocScrutinizer05>
no luck, probably just because I wasn't able to terminate COMMAND by \r
<DocScrutinizer05>
there must be a bug in tty driver since 2007
<DocScrutinizer05>
at least
<DocScrutinizer05>
but hey, you might be right, I tried to set ourput properties before output channel (fd) been opened
<DocScrutinizer05>
nope :-/
<DocScrutinizer05>
I seem to recall some settings in /dev/tty* were sticky and stty didn't take effect on second time. But I forgot what to do to reset the tty, except the obvious powercycling
jekhor has quit [Read error: Connection reset by peer]
jekhor has joined #qi-hardware
jekhor has quit [Read error: Connection reset by peer]
jekhor has joined #qi-hardware
viric has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
LOL
<wpwrak>
i'm speechless :)
viric has joined #qi-hardware
<kyak>
every kid's dream :(
<wpwrak>
DocScrutinizer05: (serial) roh has a good point there - you often need more control over the comm channel with this sort of devices than you may expect. it's VERY common to run into subtle communication problems.
<DocScrutinizer05>
ok, now I know *I* have a problem (=bug), not stty.
<wpwrak>
and yes, what i meant is bugs :) e.g., my fluke sometimes fails to answer. then you have to restart the connection. but that sometimes fails too, but only after the next operation.
<wpwrak>
the rigol DS1xxxCD has a whole catalog of such issues, apparently caused by lack of internal flow control. `C, ~D, and ~E probably, too. (same platform)
<wpwrak>
these are the two i use(d) the most. so i know their bugs best. i think the picotest DMM (usbtmc) also has some quirks
viric has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
well, whatever
<wpwrak>
naw, you really want to know exactly which bytes are going over the line and when. with shell scripts you're at a far too high level.
<DocScrutinizer05>
I'm not able to grok what's going on with \r on my shell
<wpwrak>
e.g., you'll probably also run into timing constraints. things like having to wait for the unit to process a command before it can accept the next (without overrunning buffers). etc.
<DocScrutinizer05>
echo -e 'GETDx\n' | tr x \r >/dev/ttyUSB0 fails
<wpwrak>
you can see with strace what really happens underneath
<DocScrutinizer05>
is \r a delimiter that gets handled even in pipes?
<wpwrak>
but it's easier just to write these things in C
<DocScrutinizer05>
I find backup-20090831/usr/share/paroli/services/hardware/power.pyo and /usr/lib/python2.7/site-packages/synaptiks/monitors/power.py
<DocScrutinizer05>
Written by Werner Almesberger <werner@openmoko.org> -- hehe
<DocScrutinizer05>
ta
<wpwrak>
power.py is a (very simple) class for power supplies. you could add yours there. the infrastructure gives you communications and "active" variables
<DocScrutinizer05>
much appreciated
<wpwrak>
yea, these were the old days :)
<wpwrak>
the basic idea is that you have a "nice" python interface on top to model your instrument, and C at the bottom to get low-level comms right
<wpwrak>
if you look at telnet.c, you'll see what nightmares may await you down there :)
<eintopf>
everywhere you will find code written by werner
<eintopf>
cool
<wpwrak>
eintopf: maybe i should sue poettering for stealing my trademark ;-)
_whitelogger has joined #qi-hardware
<eintopf>
wpwrak: you are like "eric s. raymond" for me, I stumble sometimes also much on "eric s. raymond" patches
<eintopf>
and then I am "raymoning" again, something like "rickrocklling"
<wpwrak>
hmm, i guess that's what i deserve from comparing my style with poettering :)
<eintopf>
maybe we should introduce "almesbergering"
<DocScrutinizer05>
hmmm >> These libraries are not documented yet, but there is a number of annotated examples in the demo/ directory.<<
<eintopf>
everytime you stumble over code by you
<wpwrak>
but i have to admit that i'm a happy and very regular user of fetchmail :)
<DocScrutinizer05>
don't tell me it's written by poettering
<wpwrak>
DocScrutinizer05: yes, i left them out in the "migrated" version (from openmoko). examples are for sissies :)
<wpwrak>
(fetchmail) no, by esr
<DocScrutinizer05>
I dunno if I want to use stuff that I basically have to read top-down every single line, to understand _how_ to use it. Prolly simpler to fix tty.ko and write stuff myself ;-)
<roh>
eeeh.. are you flushing the tty buffers?
<roh>
no /n means no automatic buffer flush. when you have so few chars, they are prolly still idling in your fifo :)
<roh>
i urge you. do it in python or C. speaking anything not crlf-auto-default linefeeds in shell is breaking your knees madness
<roh>
also every > /dev/serialdevice call opens and closes the serial once. some serials 'forget' some details of their config inbetween (bad drivers i guess). so using stty doesnt help
<roh>
open, config termios (thats what pyserial does for you then, yay!!1!) then your 'traffic' and close when done is what one wants to do.. to avoid weird drivers/hardware
<DocScrutinizer05>
my problem is with \r, NOT with \n
jekhor has joined #qi-hardware
<DocScrutinizer05>
and that's the only problem I have, rather it's an inconventience since nothing on linux is ever sending a \r when EOL
<DocScrutinizer05>
I don't even see how pyserial would help there
<DocScrutinizer05>
still would need the equivalent to talk2controller(){echo -en "$@\r"}
jekhor_ has joined #qi-hardware
<DocScrutinizer05>
and I told you even shellscript is capable of keeping a file handle open: eval 5>/dev/ttyUSB 6</dev/ttyUSB
jekhor has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
my problem is that neither minicom nor screen nor any other approach is capable to allow me talking interactively to device, for testing stuff.
<DocScrutinizer05>
cat|tr \\n \\r>/dev/ttyUSB0; however should do
<DocScrutinizer05>
just it sucks donkeyballs
<DocScrutinizer05>
no, it doesn't. Here buffering kicks in
<DocScrutinizer05>
obviously tr needs EOF on STDIN to print filtered stuff to STDOUT
<DocScrutinizer05>
btw prolly smarter than previous version: while read; do echo $REPLY|tr \\n \\r; done >/dev/ttyUSB0;
<DocScrutinizer05>
still pissed why stty onlcr doesn't work
<DocScrutinizer05>
ok, so much for "improving UI via remote control". The PSU has no switch to conveniently beak output for a short period of time (like 1s or 2). Using power switch is a PITA since it a) takes ages to deplete the primary side buffer caps of SPSU and b) the device runs a full selftest on power-up which again takes 10s or sth
<DocScrutinizer05>
however SOUT1 instantly breaks and SOUT0 instantly enables output
<DocScrutinizer05>
of course a VOLT060 is also more conventient than fiddling with that incremental turn dial
wolfspraul has quit [Quit: leaving]
pcercuei has joined #qi-hardware
pcercuei has quit [Ping timeout: 240 seconds]
jekhor has joined #qi-hardware
viric has quit [Read error: Connection reset by peer]
viric has joined #qi-hardware
wej has joined #qi-hardware
wej_ has quit [Ping timeout: 250 seconds]
jekhor has quit [Ping timeout: 260 seconds]
viric has quit [Remote host closed the connection]