small corners dont print smoothly (raspberry pi)

[LangBalthazar]

Hi,

I have had a couple of gear prints that fail get bad print results when using OcotPrint. The same gcode in repetier via a pc works perfectly without any small stops or hesitations in the movement.

This is one of the gears in thing:243278

example images of full print from pc/repetier vs stopped print OcotPrint.

A video of the problem. Long straight or circles work without any problems but a few seconds in when it prints the "gears" it starts to stop mid movement.
https://www.youtube.com/watch?v=tbUntyq7djY

The log from the heart gear print
https://gist.github.com/LangBalthazar/11037683

The gcode from the heart gear print:
https://gist.github.com/LangBalthazar/11037928

I am running Branch: devel, Commit: bf9d5ef

I have done a update and upgrade (so the pyserial should be 2.7 and work on baud 250000, correct or could this be my problem?) My printer is a Velleman K8200 / 3drag.

Any ideas on why this happens when printing from octoprint?

Best regards
Balthazar Lang

[foosel]

You are printing from the Pi, right? You might simply crash against it's
limitations there. For toolpaths with a lot of small lines (e.g. lots of
rounds and direction changes, as in gears) you will have a lot of gcode
lines generated, each only moving the head a tiny fraction. Now, all those
lines of gcode need to be transfered to the printer, and that quite fast.
On a regular work pc, you won't run into problems here. On a pi though,
transfer plus house keeping can be too much. Personally, I've taken to
doing prints like that from SD instead of streaming them via USB. Serial
communication is a bottleneck. Printing slower might help.

[CptanPanic]

It might be better than just stating that raspi might be too slow, then maybe Octoprint can detect that it is falling behind, and report an warning or such.

[foosel]

Suggestions on how to do this (without making the whole processing even
slower) are welcome

[Salandora]

First suggestion is you could (while anaylsing the gcode), try to detect Perimeter Movements, e.g. by Speed, and check if there are many "small" movements after each other. Just one suggestion, I believe if I think that further I'll find a few more ways to check that.

[CptanPanic]

If the errors are happening because the processor gets too loaded, maybe just having a graph showing the processor utilization?

[Salandora]

Hello,

I had an idea about speeding up the whole Analysis Process and even detecting for small movements... I don*t know if it's a good idea so i post it before doing any programming.

Idea:
Do the analysis in the browser before uploading everything to Octoprint.

e.g.: I want to upload File XY, i drop it onto the Browser, now a Javascript Gcode Analyser will process the whole file, sending all necessary informations with the file (as a comment or JSON-Data), Octoprint wouldn't need to do anything anymore.
If you notice areas with many small movements you could inject a Gcode to slow things down, make a Comment, or warn the uploader.

[foosel]

The problem I have with this approach is that it's moving too much of the core work over to the client. This is critical due to two reasons.

1. Never trust the client
2. My guess is that this would make uploading from a mobile device or remotely (think: cloud slicer) way more complicated/close to impossible.

IMHO the gcode analysis should be the server's responsibility (and right now it doesn't add much anyways besides some stats, which is why it's done asynchronously and should never be done when printing), as should be anything to do with file processing.

Recognizing small movements might be possible on the fly during printing, so we could display a warning in such a case. What I want to prevent though is adding even more detection code and stuff in the send loop that will put even more strain on the poor CPU and make serial communication even more fiddly (which it already is anyways thanks to the protocol), which is why I'm quite reluctant to add large "am I slow now?" detection mechanisms in there. This is also the reason for my backtalk above ;)

I'm not even sure if a software solution is the best approach here to be honest (due to the serial bottleneck and also the fact that as said above, anything done in Software will only put more strain on the system). A small part of me is rather thinking in the direction of emulated SD card attachments connected via hi-speed-USB to the host.

In any case, at the current state it's a non trivial issue.

[vdesmedt]

anyway to compress gcode before sending it over the wire ?

[foosel]

Does this problem still occur in OctoPrint 1.2.x? I backported a lot of the fixes I did on the commRefactoring branch (which sadly proofed after a lot of work on it to be unviable), so the problem shouldn't exist as much anymore (although the serial line will still always be a bottleneck the smaller the segments get, there's nothing I can do about that).