Having difficulty printing with Duet board via USB

I have a CoreXY printer with a Duet 0.6 board. This works very nicely over the ethernet connection, but I have never been able to print successfully by using Pronterface or Repetier-host over USB.

• My Linux Mint 17.3 machine knows where the printer's USB connection is, I have permission to read and write to it, and I can connect successfully from either of those programs.
• Originally I had problems getting temperature values back to the host program - until I chucked my old USB lead in the bin and replaced it with a known good lead (it's the one I use with my Prusa i3, so known to be good at the speeds used on both printers). Now I see sensible values.
• My desktop's host programs are set to communicate at 115200 baud (250000 doesn't exist in Linux, unless you make modifications to the kernel).

The symptoms are:

• It will print straight lines without problem.
• If it tries to print a circle the printer's motors make a nasty clattering noise, the head moves slowly, and the resulting circle is ragged.

I have checked the USB connector, and it is snug and firm (I use a very short extension cable to connect from the board to the printer's side panel - I have tried bypassing that lead, with no change).

My gut feeling is that this is a config problem between the desktop and the Duet board; when I've used this connection for other jobs like updating the firmware everything has worked properly. It's almost as if the connection is passing small blocks of data (e.g. the coordinates for a straight line) but blocking somehow when many coordinates come in (e.g. for a circle).

I very rarely use the USB connection as I prefer to use ethernet - but I hate having things that don't work properly. Any helpful suggestions?

Have you tried checking the "TCP stream" (or smth like it) in pronterface options?
I think it's a problem of speed: the duet processes commands faster than the rate the host sends them...

FWIW, I 'm seeing the exact same behavior on my RADDS board running RRF, controlling it through octoprint (i.e. US.

You need to configure the host NOT to wait for "ok" after sending each command, because that really slows the communications down and isn't needed by the Duet.

In Repetier host, you can do this by disabling "ping pong".

In Pronterface, enabling "TCP streaming mode" MIGHT have the same effect. If it doesn't, you will need to patch Pronterface. I posted details of the patch in a thread in the Ormerod forum a little over two years ago.

Edited 1 time(s). Last edit at 05/12/2016 01:27PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hmm... tried all the variations (there aren't many offered) but with no success. It seems as though I have an "almost" connection - it almost works, but not 100%.

Has anyone actually had success running a printer with a Duet board from a Linux machine via USB?

Quote
David J
Hmm... tried all the variations (there aren't many offered) but with no success. It seems as though I have an "almost" connection - it almost works, but not 100%.

- All the variations of what?
- and what do you mean by "almost works, but not 100%"?

btw you should also be able to print a file using "copy file.gcode /dev/whatever" where /dev/whatever stands for the name of USB port.

Most Duet users upload files to the SD card over the web interface, then print them from SD card. This has the advantage of making printing independent of the PC remaining turned on, connected, and not too busy doing other stuff to maintain a good data rate. However, I know of at least one user who prints over USB from Octoprint running under Linux.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
- All the variations of what?
- and what do you mean by "almost works, but not 100%"?

Sorry for the terse comments - I was getting annoyed! Mostly with Pronterface and Repetier-Host though. They offer very little in the way of configuring the port's protocols and general configuration. As for 'almost works' I meant that sometimes the printer behaves as though it's happy with what it's received, and other times it messes up and just seems to sulk. It behaves as though the comms parameters are nearly right, but not quite right enough.

Quote
dc42
btw you should also be able to print a file using "copy file.gcode /dev/whatever" where /dev/whatever stands for the name of USB port.

I'll give that a try, just for the fun of it!

Quote
dc42
Most Duet users upload files to the SD card over the web interface, then print them from SD card. This has the advantage of making printing independent of the PC remaining turned on, connected, and not too busy doing other stuff to maintain a good data rate. However, I know of at least one user who prints over USB from Octoprint running under Linux.

Not too worried about doing that, as working through the web interface is just as easy, and more reliable. I just like watching the host program drawing the part as it progresses, especially when diagnosing problems (e.g. is the printer doing what the host program thinks it should be doing).