DuetWifi stutters when printing over USB
-
I have a DuetWifi that I need to print with over USB. The reasons why I cannot use the web interface are not important and not something that I want to discuss. I need to get USB working. My problem is that the print does not run smooth, that is to say it stutters a lot. It basically looks like the firmware is not buffering commands causing it not to do path planning but the buffer does still appear to work because after stopping the print, it still runs for a while. My current setup is Repetier Host at 115200 baud rate though I have tried other systems only to get the same result. I have also configured the firmware to emulate the Repetier interface but it did not help. Is there anything else I can try?
-
Configure Repetier to not wait for an OK response after sending each gcode command. AFAIR you do this by turning off "ping pong" or something like that.
Don't expect this to be a complete solution. All 3D printers suffer from stuttering when printing over USB under some conditions, depending on the Gcode, which is why printing from SD card is standard practice.
-
Could that not cause the buffer to overflow if sending too fast? Also, why is it that Repetier firmware works with acknowledgements but RPF doesn't is the time when "ok" is sent different?
-
It seems Repetier was not using ping-pong. I know this is an inherit limitation but this is currently 100 times worse than Repetier firmware on an Arduino Mega.
-
The Duet uses a true USB connection, which has flow control, so the buffer won't overflow.
RRF doesn't prioritise sending messages back to the USB port the way Repetier does. In part this is to make sure that the firmware doesn't stall waiting for the USB to become ready if the attached PC goes to sleep during a print and a message is sent to the USB port. We could probably make sending the OK back quicker most of the time, but as printing over USB is generally regarded as poor practice, and the OK isn't needed for flow control anyway, there seems little point.
-
Ok that makes sense. Unfortunately I think it's impossible to use Repetier Host in that way because in not-ping-pong mode it still waits for oks to send commands when it thinks the buffer has filled up. I'll check if I can another host working though. I have noticed that debug mode tends to come on the whole time and possibly destroys the serial bandwidth? I have no idea what is causing it but will keep searching.
-
Also, how does it work when using the hardware serial port like with a PanelDue because if I remember correctly it doesn't have hardware flow control lines?
-
Ok that makes sense. Unfortunately I think it's impossible to use Repetier Host in that way because in not-ping-pong mode it still waits for oks to send commands when it thinks the buffer has filled up. I'll check if I can another host working though. I have noticed that debug mode tends to come on the whole time and possibly destroys the serial bandwidth? I have no idea what is causing it but will keep searching.
The Duet does send the OK response so it does work if you disable ping pong.
Repetier seems to turn debug mode on by default but you can turn is off again, you just need to press a couple of buttons in the UI.
PanelDue doesn't send high volumes of data, so it doesn't need flow control.
