how to set ftdi driver buffer size?

[Steven Pickles]

Hi there,

i'm using an FTDI USB-RS232 cable to talk to Hackerspace Adelaide's MDX-20 mill. The mill has known problems dealing with USB serial devices, possibly because of its small internal memory and the comparatively large buffer sizes used in USB-serial devices meaning that its flow control messages aren't being heeded fast enough. 

Anyhow, I will persist with the USB-Serial cable, because that's what I have (no clunkers with hardware serial ports lying around).

Anyhow, i was wondering if anyone knows of an "easy" way of twiddling the current buffer size of an FTDI device under Linux. Ideally it would be an existing command-line tool would be great, otherwise I'll have to throw something together using python-ftdi.

Any help appreciated,

Thanks,

pix

[Thomas Sprinkmeier]

It's been a while since I've messed with RS232.

Last time I played with it errors were usually due to a combination of
 - baud rate too high
 - cable too long

 - earthing problems

 - flow control not configured
 - flow control lines not passed through (i.e. nasty crossover cables)

 - dodgy USB dongles

I assume the setup is

PC(linux) <-> USB dongle <-> RS232 cable <-> mill

Does the buffer side on the Linux box matter? (assuming the PC is fast enough to keep up with the mill)

If RS232 flow control is being used then it shouldn't matter how big the buffer on the PC is. flow control means "stop sending bits over the wire" not "stop putting bits into the output buffer".

HW flow-control is usually pretty solid, i.e. the UART on the mill should automatically munge CTS when the input buffer is above the HWM which should stop the USB dongle from sending within a byte or 2.
(SW flow control (Xon/Xoff) is a bit more iffy and rarely used these days).

Do you have an RS232 breakout box (i.e. can you keep an eye on CTS to see if the mill is even trying?)

Can you drop the baud rate?

Are you sure it's a buffer overrun and not a cheapo-USB dongle doing something dumb (like using TTL voltages when the mill expects RS232 levels)?

Thomas

--
You received this message because you are subscribed to the Google Groups "HackerSpace - Adelaide, South Australia" group.
To post to this group, send email to hackerspac...@googlegroups.com.
To unsubscribe from this group, send email to hackerspace-adel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hackerspace-adelaide?hl=en.

--
Quis custodiet ipsos custodes?

[Steven Pickles]

Hey Thom,

It's a "known" problem. The mill works until half way through a long job. When I was using a PL2303 based cable, the job would just halt, with an FTDI cable, it starts getting corrupt data, resulting in random moves. The fact that it works most of the time means it is unlikely to be any of the things you mentioned which would normally result in it just not working (or being ustable) from the beginning. The baudrate is already 9600 and I have no control over it.

A breakout board would be handy (though boring as it's a good 15mins into a pass when things go awry).

Apparently problems can be minimised by reducing the buffer size that the FTDI chip is using. There is an alternate FTDI driver supplied by Roland which somehow manages to overcome the problems, but it's windows only... so, f'that.

http://vonkonow.com/wordpress/2012/08/bringing-a-12-year-old-roland-mdx-20-up-to-date

pix

[Tamsyn Michael]

This may be stupid, but in my experience when electronics go from working perfectly, to dodgy, over time it's often due to over heating.  Do any of the chips start getting hot?

[Steven Pickles]

Hmm, any hot chips would be inside the mill, and I'm avoiding actually taking it apart. It lives in the shed, not really an exposed-electronics friendly environment. And anyhow, as I've said, the buffer thing is a known problem caused by a buggy (or atleast unforgiving) RS232 implementation in the mill, and not dodgey hardware AFAIK. It has been solved under Windows by means unknown, and I'm trying to replicate the fix in linux land.

If I had nothing else to go on, yeah, I would already have started taking the mill apart.

pix

On 9 January 2013 14:18, Tamsyn Michael <tamsyn.j...@gmail.com> wrote:

This may be stupid, but in my experience when electronics go from working perfectly, to dodgy, over time it's often due to over heating.  Do any of the chips start getting hot?

--

[Jonathan Wheare]

Hi pix,

Most of my fiddling with serial devices has been using the setserial
command. From taking a quick look at the man page it doesn't seem that
you can set the buffer size directly, but you may be able to change the
detected UART type. From memory most UARTs are backwards comptible with
the old 8250 - if you set it to this mode that may disable practically
all of the buffering (of course this may also cause other issues). This
page on comms with clock sources seems to show this will work:
http://support.ntp.org/bin/view/Support/KnownHardwareIssues

J.

> --
> You received this message because you are subscribed to the Google
> Groups "HackerSpace - Adelaide, South Australia" group.
> To post to this group, send email to
> hackerspac...@googlegroups.com.

> To unsubscribe from this group, send email to hackerspace-adelaide
> +unsub...@googlegroups.com.

[Ken]

Could you humour us hardware-suspicious types, pix, and put a DSO/CRO on the serial lines?

My experience with USB-RS232 convertors is that their output lines typically either don't go below 0v, or else swing only a fraction of the specified RS232 levels.
Mix that with some noise, changes due to temperature, change to a 'heavy' bit pattern, etc etc, and you have a recipe for unexplained behaviour if the receiver thresholds are on the edge.

It may be that one difference between the Windows driver and the Linux driver, is speed.  Windows may be slower to feed data out.

Ken.

[Steven Pickles]

Ugh, sounds like work ;)

I'll borrow my Quad from the space, and if I don't get anywhere faffing about in software, I'll start humoring the hardware skeptics.

pix

[Damien P]

I was going to suggest looking at a serial express card, but since they have USB lines in them most are probably usb->serial converters in disguise.

When writing the code for my laser projector, a few weeks ago I noticed in the FTDI datasheet that it can send up to 4 characters after you stop transmission with flow control.  Maybe this is enough to stuff up the mill.

[Peter Wintulich]

Hello Pix,

I have a hand full of mini X86 (486SX class) pc's that run XLinux from ICOP.
They run from 5V DC 2A Plug Pack and have 2 Serial, 1 Parallel,  3x USB, ethernet, VGA, PS2 mouse/ KB., 32MB IDE Flash Drive.
One could be set up as a job manager.

Other wise may be a Raspbery Pi with a TTL to RS232 level converter from the I/O connector.

Peter

-- 

Peter Wintulich

Voicetronix Pty. Ltd.
Level 1, 246 Pulteney Street,
ADELAIDE  5000
South Australia
AUSTRALIA
+61 8 8232 9112