Serial trouble

Speaking as someone who hasn't even seen a plotter in a very long time, here's my 2 cents -- I think you still have a flow control issue. Plotters are EXTREMELY SLOW devices, head movement may take SECONDS, so as you have noticed, even slow baud rates will not give you enough time to handle the stream real time, you need to stop the flow so the mechanical parts can catch up. RS232 serial had at least 2 hardware and one software flow control mechanism, so you have to match what the plotter is using. If no plotter docs, check the serial connection that works from the Windows side, then use stty to set the equivalent on the linux device. Use the command "man stty" to see what's available, stty -a will output an example of what the console is using --
the "start = ^Q; stop = ^S;" is the old XON/XOFF software flow control, etc.

Hi - Ubfan.

Thanks for the good answer.

Tryed to match settings from windows side - it was set at 38400 and hardware flow control.

But the same settings did not work on ubuntu.

A bit strange - all other things work - never had any troubles before i got the new vinyl cutter plotter.

It is as if ubuntu is not applying my settings - or something goes wrong in the process off setting the parameters.

Maybe its the ln command that is messing up with things, but it has to be there, as the software only knows the first 4 com ports.

Maybe i have to use other linux flavor :-)

So for hardware flow control, you should see crtscts in the output (and
NOT -crtscts) of:
stty -a -F /dev/ttyS0
Change the setting with stty, maybe turn off the software flow control too
if it is set.

On Sat, Jan 28, 2012 at 4:01 PM, tolletrolden <
<email address hidden>> wrote:

> Question #186091 on Ubuntu changed:
> https://answers.launchpad.net/ubuntu/+question/186091
>
> tolletrolden posted a new comment:
> Hi - Ubfan.
>
> Thanks for the good answer.
>
> Tryed to match settings from windows side - it was set at 38400 and
> hardware flow control.
>
> But the same settings did not work on ubuntu.
>
> A bit strange - all other things work - never had any troubles before i
> got the new vinyl cutter plotter.
>
> It is as if ubuntu is not applying my settings - or something goes wrong
> in the process off setting the parameters.
>
> Maybe its the ln command that is messing up with things, but it has to
> be there, as the software only knows the first 4 com ports.
>
> Maybe i have to use other linux flavor :-)
>
> --
> You received this question notification because you are a direct
> subscriber of the question.
>

Thank You Ubfan. You are very helpfull.

This is what i get from dmesg when i plug in the plotter.

[ 350.033012] usb 2-1.1: new full speed USB device number 4 using ehci_hcd
[ 350.591138] cdc_acm 2-1.1:1.0: This device cannot do calls on its own. It is not a modem.
[ 350.591191] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device
[ 350.591688] usbcore: registered new interface driver cdc_acm
[ 350.591692] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Is there any way i can copy what ever happens on ttyS0 to the screen, while i plot? Then i can see if its special kombinations off data or ..... try to see some pattern, when the plotter hangs.

Also i have doubts - when redirecting the port from ttyACM0 to ttyS0 - which port must i then set speed for?

Thanks.

Since the ttyS0 is just a link, I don't think it matters on which device
you set the speed or flow control.
Set the speed and look at both of them with
sudo stty -a /dev/xxxx
  Don't know much about tracing serial lines, wireshark is probably
overkill, maybe just run the program with strace and trace the file
descriptor calls with "-e trace=desc" (from the man strace pages).
Since you need the bi-directional capability (for flow control), it would
take more than a tail-f |tee, but a simple program might work (then it
would matter which device gets the speed if you replace the link).

On Sun, Jan 29, 2012 at 1:45 AM, tolletrolden <
<email address hidden>> wrote:

> Question #186091 on Ubuntu changed:
> https://answers.launchpad.net/ubuntu/+question/186091
>
> tolletrolden posted a new comment:
> Thank You Ubfan. You are very helpfull.
>
> This is what i get from dmesg when i plug in the plotter.
>
> [ 350.033012] usb 2-1.1: new full speed USB device number 4 using
> ehci_hcd
> [ 350.591138] cdc_acm 2-1.1:1.0: This device cannot do calls on its own.
> It is not a modem.
> [ 350.591191] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device
> [ 350.591688] usbcore: registered new interface driver cdc_acm
> [ 350.591692] cdc_acm: USB Abstract Control Model driver for USB modems
> and ISDN adapters
>
> Is there any way i can copy what ever happens on ttyS0 to the screen,
> while i plot? Then i can see if its special kombinations off data or
> ..... try to see some pattern, when the plotter hangs.
>
> Also i have doubts - when redirecting the port from ttyACM0 to ttyS0 -
> which port must i then set speed for?
>
> Thanks.
>
> --
> You received this question notification because you are a direct
> subscriber of the question.
>

Hmm - now i have tryed all the suggestions - no change.

I installed Fedora 16 - same problem.

It must be in the inner linux kernel the problem is to be found, since it does not matter wich flavor off linux i try.

I have nothing more to try - i think.

To be sure, i have tested the .plt file by using a memory card to set into the plotter - then the file gets plotted fine. Same file also works fine when in windows.

i had a usb > seriel thing - but it is not compatible with linux, so no luck there. Its mounted on ttyUSB0 but nothing happens when i copy file to it. I think its the chip inside the converter thats the problem.

Is this a dead end?

THANK YOU - it worked - now i can plot.

What is the problem then - buffer error or kernel error?

Thank You again - i meant a lot for me to be able to use linux for this job.

Probably neither. It's a handshaking issue between the two bits of hardware. You need to get the software at both ends to agree on the means to signal when the sender should stop sending because the receiver's busy and any more data would be lost. That method has to be compatible with the wiring of your cable between the two.

So it's a cable and configuration issue. I doubt there's bugs in the software at either side.

Note, my shell pipeline may fail sometimes; you might just want to send a plot where the plotter takes an absolute age in the middle of sending and data still gets lost. It was really a proof of concept to show that it is the speed of sending bytes that's the issue.

Maybe You are right Ralph.

But when the exact same hardware works without troubles, in windows, then i blame linux.

I also wonder, if its a buffer problem, as it only when plotting large files, the problem comes.

But now i can use the plotter - its fine for now.

> But when the exact same hardware works without troubles, in windows,
> then i blame linux.

Windows has been told by you, or its defaults happen to match, the
correct handshaking method to use. Linux hasn't. This isn't a Linux
bug by the sound of it but a configuration problem; just like getting
the baud rate wrong when talking to devices that don't auto-adjust.

> I also wonder, if its a buffer problem, as it only when plotting large
> files, the problem comes.

It's when one of the buffers along the route, probably the one in the
plotter, becomes full that the handshaking will kick in. The plotter
will shout "Stop, I can't take any more!" but because of disagreement
over the protocol the sender continues and the plotter has no option but
to discard what it receives until it has managed to make space once
more.

> But now i can use the plotter - its fine for now.

Good.

Well You are right - i am sure.

I have changed settings numerous times, and no matter how i set flowcontrole, it is as if the settings not reach the hardware.

Plotter behaves exactly the same no matter what i set the port at.

What i can read, in the user manual, the settings should be 38800 8n1 and flowcontrole is auto.

I must do some testing with the port settings - and read about it - maybe i am doing somethinge wrong.

> What i can read, in the user manual, the settings should be 38800 8n1
> and flowcontrole is auto.

I have played with serial ports in a while but I've never heard of an
"auto" flow-control. What make and model is this plotter? (I think you
might mean 38,400.)

Yes off course - 38400 :-)

This is the plotter: http://vicsign.com/Products/View.asp?id=41

I think i have read in the user manual, that it finds what ever flow control is available. But i could be wrong. (Or supplier)

Else the plotter have good data, and work great. I have done a lot off cutting vinyl, and i would very much like to move to inkscape and inkcut.

Now i am using kubuntu 11.10 - works great when installed on ssd-drive :-)

kde sometimes give a error or two - mostly it stops responding to mouseclick on buttons until restarted.

But now i will go test some flowcontrole .......

I'd forgotten you're using a USB cable to connect, not serial. What's the output of the command `lsusb' with the plotter plugged in? Perhaps cdc_acm isn't the ideal kernel module for it?

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 147e:1001 Upek
Bus 002 Device 003: ID 1cbe:0002 Luminary Micro Inc.

Its the last line.

[ 8406.552681] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device
[ 8406.553094] usbcore: registered new interface driver cdc_acm
[ 8406.553099] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

is the output from dmesg.

On linux-usb.org it can be found in the list

Sorry it took so long time to answer - we have had visitors all weekend - very busy

Thanks for the "1cbe:0002 Luminary Micro Inc". I had a bit of a search but didn't turn up anything useful WRT flow control problems. It may be this improves with later Linux kernels/Ubuntus. Or you could decide to take it up with the Linux USB mailing list, http://www.linux-usb.org/mailing.html, but they will want quite a bit of detail; see that FAQ.

Thanks for all Your help Ralph.

I installed moserial, and did a lot off testing. Its easy and quick to change the settings here.

No matter what speed i choose, or what flow control i choose, the result is the same.

I can send small pieces off the plotter file, and it will sometimes go well, but as soon as i send more than few instructions, the plotter head will do something silly and make strange sounds.

I will try the mailing list.