Page 1 of 1

Debug USB-to-Serial Port Errors on OS X?

Posted: Sun Mar 13, 2016 6:54 am
by opfeifer
Hi,

is there any way to find out what's *sometimes* going wrong with my serial communication?

I use CoolTerm to send HPGL Plotfiles (Simple ASCII-Files) to a HP DraftPro EXL Pen-Plotter from 1988 through a USB to Serial Adapter with a Prolific Chip and the relatively new PL2303 Driver from Prolific, using hardware handshake (CTS), since Xon/Xoff seemed unrelieable. In general, this works well. The files are typically below 5MB, and they take between one and up to 5 hours to be drawn; since there is practically no buffer, they must be sent *very* slow. Normally CoolTerm shows the CTS/DSR lights shortly flashing every 2 seconds or so and sends the next packet, etc.

While it works most of the time, every few hours a fatal communication failure of some sort occurs:
  • - the plotter stops working (and never starts again)
    - CoolTerm shows CTS=on, so it continues to send until EOF
If I disconnect and reconnect afterwards, I receive a 'permission denied' error. After unplugging and re-plugging the USB to Serial cable, I get a 'port not found' and after a while I can reconnect. I was able to immediately send new instructions to the plotter sucessfully afterwards without resetting the plotter, so I assume the culprit is the USB to Serial Adapter, or it's driver. Does that sound familiar?

These glitches seem to happen at pretty random intervals, unrelated to the actual data that is being sent.
If I was able to find at what point during the transmission the errors occur, I could at least try to pick up resending the file at the right position (it would not have to be exact, since it's ok to plot some lines twice).

So my question would be: is there a way to make CoolTerm protocol the transmission and the CTS signals received?

Re: Debug USB-to-Serial Port Errors on OS X?

Posted: Tue Mar 15, 2016 11:44 pm
by opfeifer
EDIT: I tried a differnt, FTDI-Chip based USB-to-Serial adapter. While there is a built-in driver in Mavericks for this adapter, it does not work at all for my plotter: it prints out garbage (mostly random lines), something that happens with the Prolific PL2032 based one only when flow control is set to Xon/Xoff or DTS. Unfortunately I don't have a nullmodem cable so I can loop the output back in order to analyze ... :x

Re: Debug USB-to-Serial Port Errors on OS X?

Posted: Sat Apr 09, 2016 11:31 am
by roger
There currently isn't a way to log when transitions on CTS (or any of the other signals occur). I'll give it some thought to see if such functionality could possibly become part of a capture file used for data logging in a future release.

Re: Debug USB-to-Serial Port Errors on OS X?

Posted: Sat Apr 09, 2016 11:35 am
by roger
It is possible to capture the transmission. Turn on local echo in the connection settings, and enable "Capture local echo" in the text capturing options. Make sure you start a file capture using "Connection/Capture to Textfile/Start...". This will record everything being sent and received.

Re: Debug USB-to-Serial Port Errors on OS X?

Posted: Sat Apr 09, 2016 11:36 am
by roger
opfeifer wrote:EDIT: I tried a differnt, FTDI-Chip based USB-to-Serial adapter. While there is a built-in driver in Mavericks for this adapter, it does not work at all for my plotter: it prints out garbage (mostly random lines), something that happens with the Prolific PL2032 based one only when flow control is set to Xon/Xoff or DTS. Unfortunately I don't have a nullmodem cable so I can loop the output back in order to analyze ... :x
You may have to update your FTTI driver, you can find download links to the most recent drivers here: viewtopic.php?f=4&t=506

Re: Debug USB-to-Serial Port Errors on OS X?

Posted: Sat Apr 09, 2016 2:01 pm
by opfeifer
Thank you for your comments, Roger, I appreciate. Meanwhile I developed the theory that my very long serial cable might cause some of these problems, and lowered the Baudrate to 4200, which still seems faster than the plotter can plot anyway. Since then, I have not had any interrupted transmissions.