PL2303 and the mystery of the selectively mute Adam.
by Drone91 from LinuxQuestions.org on (#5DBY3)
Hello.
I'm running on a Debian 9 box, kernel 4.9.0-14-amd64. Recently, I've been among other things trying to communicate with an ADAM 4022T controller, which has a RS-485 port, and an ADAM 4561 RS 232/422/485 to USB converter, currently running off a Windows 2000 box. (hint: I'm messing with it precisely to try and replace that box, or at least make it replaceable).
Now, fortunately, the controller is in ASCII mode, and for starters, I decided to test basic communication. Both the old ADAM .NET utility and regular ol' PuTTY hitting up the virtual port in the windows 2000 rig has it respond nicely to commands sent, with regular old settings of 9600baud, no parity, 8bit, one stop, no flow control.
This, however, is not the case on my Linux box - although I've used all of R&S VISA, libserialport and regular ol' PuTTY to communicate with USB-to-serial converters before, I seem to be able to write to this one, in the sense that say, viWrite or sp_nonblocking_write says it wrote the size of the string sent, but it fails to send back a meaningful response.
I've made sure the configuration is right, I've fiddled with trying to add an \r before every \n, and a host of other moderately useless things, but no cookie. However, this gets more interesting.
The serial (albeit rs232) adapter that works perfectly happens to have Prolific PL2303 innards, and can you guess what shows up when I plug in the ADAM converter? Yes, also Prolific PL2303. The situation gets more interesting when I've started up my Windows XP virtualbox install which has a regular old prolific driver installed (rather than the advantech one)... if I call PuTTY up to the virtual port there... yes you've guessed, it works and the machine on the other end happily responds.
I've read up on some issues with PL2303X devices which look like PL2303 but work different and cause driver issues from a couple years back.. .but not only does this fix seem to have been incorporated in the kernel, but, based on some details obtained from lsusb -v on the devices in question, it seems that the PL2303X is in fact the nicely obedient Gembird 232-to-usb cable, not the 4561.
Trying to look at stty -a < /dev/ttyUSB0 produced
Code:
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 21;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel
-iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho
-extprocfor the unfriendly converter and
Code:speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel
-iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho
-extproc
for the functional one - I'm not really seeing any significant differences, to be honest.
If anyone would find it helpful,I can post both lsusb full identifier strings - really the big difference is that the hostile converter has bMaxPacketSize0 8 which is what suggests it's a 2303 rather than 2303X.
Does anyone have any advice in what I might possibly be doing wrong?
I've already ordered a relatively cheapola USB-RS485 converter in case this one proves completely refractory, but frankly, if this turns out to be something of a PEBKAC problem I'll be all the happier.
Thanks in advance!
I'm running on a Debian 9 box, kernel 4.9.0-14-amd64. Recently, I've been among other things trying to communicate with an ADAM 4022T controller, which has a RS-485 port, and an ADAM 4561 RS 232/422/485 to USB converter, currently running off a Windows 2000 box. (hint: I'm messing with it precisely to try and replace that box, or at least make it replaceable).
Now, fortunately, the controller is in ASCII mode, and for starters, I decided to test basic communication. Both the old ADAM .NET utility and regular ol' PuTTY hitting up the virtual port in the windows 2000 rig has it respond nicely to commands sent, with regular old settings of 9600baud, no parity, 8bit, one stop, no flow control.
This, however, is not the case on my Linux box - although I've used all of R&S VISA, libserialport and regular ol' PuTTY to communicate with USB-to-serial converters before, I seem to be able to write to this one, in the sense that say, viWrite or sp_nonblocking_write says it wrote the size of the string sent, but it fails to send back a meaningful response.
I've made sure the configuration is right, I've fiddled with trying to add an \r before every \n, and a host of other moderately useless things, but no cookie. However, this gets more interesting.
The serial (albeit rs232) adapter that works perfectly happens to have Prolific PL2303 innards, and can you guess what shows up when I plug in the ADAM converter? Yes, also Prolific PL2303. The situation gets more interesting when I've started up my Windows XP virtualbox install which has a regular old prolific driver installed (rather than the advantech one)... if I call PuTTY up to the virtual port there... yes you've guessed, it works and the machine on the other end happily responds.
I've read up on some issues with PL2303X devices which look like PL2303 but work different and cause driver issues from a couple years back.. .but not only does this fix seem to have been incorporated in the kernel, but, based on some details obtained from lsusb -v on the devices in question, it seems that the PL2303X is in fact the nicely obedient Gembird 232-to-usb cable, not the 4561.
Trying to look at stty -a < /dev/ttyUSB0 produced
Code:
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 21;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel
-iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho
-extprocfor the unfriendly converter and
Code:speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel
-iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho
-extproc
for the functional one - I'm not really seeing any significant differences, to be honest.
If anyone would find it helpful,I can post both lsusb full identifier strings - really the big difference is that the hostile converter has bMaxPacketSize0 8 which is what suggests it's a 2303 rather than 2303X.
Does anyone have any advice in what I might possibly be doing wrong?
I've already ordered a relatively cheapola USB-RS485 converter in case this one proves completely refractory, but frankly, if this turns out to be something of a PEBKAC problem I'll be all the happier.
Thanks in advance!