USB printing

Thx
Daryl

---

RS Ormerod #299

The old version of pronterface I run with non-Ormerod printers waits for "OK" before sending a new gcode line. The printer controller sends OK until it's move buffer is full, if it gets a command when the move buffer is full, it blocks there.
This is how the flow control works with the USB-FTDI converters, and CTS/RTS is not used on the serial interface.

With native USB on the printer controller, if the controller does not read the USB pipe it blocks, and the PC won't send more data. That is why the "copy .. COM" works. So you could set pronterface to not block waiting for OK, but block on a write() to the com port, but that won't work with most existing printers.

The optimum scheme for native USB controllers may well be different to the "old" method (still in widespread use of course), so it seems like a good idea to have a configurable option. There is a way for the host to interrogate the printer controller to see what features are available, I'm not sure anyone uses that though. It think it would be better way to have it configured automatically without the user having to set it, or have special versions of host software for different printers.

Edited 1 time(s). Last edit at 01/11/2014 03:35PM by bobc.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

Hi bobc, I've sorted this now, and started a new thread here. You are right, Pronterface was waiting for the OK response, and I had to patch it.

---

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].

Hi
I am using a USB hub, leaving the micro USB in the Duet.
I have 2 cards and both are under warranty ...
Today I watched with macro lens and they seem ok.

I do not want to bandage my head before breaking it.

Just a question ...
Is not Pronterface that requires 250000?

Dario

It works for me equally well at 115000 and 250000, with the changes I describe in this thread.

---

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].

I try it now!

Great .... Thanks dc42!
Homing brilliant!

Hello guys,

I'm having the same problem printing from USB. In my case would be fine to print from the SD card. However, when I load the same file on the SD card the printer gets stuck after the first movement.
I'm using the default Pronterface settings provided with my firmware version (FIRMWARE_VERSION:0.65b ELECTRONICSuet DATE:2014-05-07
)

Do you guys have any idea which can be the problem?

Thanks!

Hi abelrodriguez,

The first thing I suggest you try is to update your firmware, either to the latest RRP official release (which was 0.65e last time I looked), or to the latest version of my fork, currently 0.59c-dc42 and described in another thread.

---

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].

Thanks a lot DC42,

I will update the firmware and post the result back.

Thanks again.
Abel.

From other posts it appears that the latest RRP firmware has a bug that stops it processing after an E movement that is faster than a certain amount.

Dave
(#106)