Open lokster opened 7 years ago
lokster
commented
7 years ago A workaround for this issue, which works if you don't use different accelerations for the different types of print moves, is to just set the desired print / travel accelerations from the printer itself, an disable acceleration control in Cura (but still make the values match between the printer and the slicer - this will make time estimation accurate).
konvoj
commented
7 years ago If I'm not mistaken, this is either the same issue as #2429 or very similar.
Ghostkeeper
commented
7 years ago The difference arises because Repetier and Reprap support different acceleration states for travel and printing. I mean, you can set the travel acceleration and the print acceleration differently.
For all other g-code flavours there is no distinction there, so if you're alternating between travel and extrusion, you're going to need to put new acceleration/jerk commands in between every time.
As far as I'm concerned this is a don't-fix. If you're running into a buffer overflow/underrun in Octoprint then I suggest that you disable acceleration altogether or set the travel acceleration to be equal to the print acceleration.
lokster
commented
7 years ago According to Marlin's docs for M204, this is not the case: http://marlinfw.org/docs/gcode/M204.html and M204 can set the acceleration for the print/travel accelerations separately. So I would not consider this as "wontfix".
M204 [P
Ghostkeeper
commented
7 years ago Turns out that this was changed in March 2015: http://reprap.org/wiki/G-code#M204:_Set_default_acceleration
The behaviour is different there in just about every branch that supports the command... Acceleration per axis or total, which axes can be set individually, PID regulator parameters, etc...
We have no way to implement/test all that here in the Cura team since the Marlin version we're all using branched off before March 2015. If you can find a way that works for current and previous versions of Marlin g-code flavour and doesn't alter the others, we can merge that in and get it fixed.
lokster
commented
7 years ago Seems rather odd that "Marlin" in Cura does not equal to "the official marlin". Rather, it's some unknown branch which you/the team use. The acceleration control can work in the same way it works in Repetier - it's a matter of using the same logic that's used for Repetier's acceleration control, and replacing Repetier's "M201 X Y" with "M204 P" (print moves; single value for both axes), and M202 X Y with "M204 T". And use that for the "Marlin" machine type. Btw, in the official marlin "M204 S***" still works - it sets both print & travel accelerations. If the Marlin branch you use is different/special, then just add it as a separate machine type. Anyway, I don't think this issue should be closed. It exists, and it can be fixed.
Ghostkeeper
commented
6 years ago Fair enough, but it's going to have to come from the community as we have no way to test this at work (and I don't have a printer with a modern Marlin at home either). I'm fine with splitting of Ultimaker Original's Marlin from the "Marlin" g-code flavour. Perhaps we'd have to include version numbers in the g-code flavours to differentiate.
CCS86
commented
6 years ago Another vote to allow some way to support M204 P R T commands. Even if it requires a "new" gcode flavor.
TurboChum
commented
6 years ago just noticed the same issue and took a look to see if anyone else noticed
tschundler
commented
6 years ago I wonder if that's a separate bug, but I too noticed lots of M204's to set acceleration then set it back to what it was before, like this, effectively a no-op.
Ghostkeeper
commented
6 years ago That's a separate bug, yeah. It should never output two M204's after each other. I'm not able to reproduce that though.
I have observed this on Cura 2.7:
When the gcode flavor is Repetier, Cura sets the print / travel accelerations just once in the beginning of the file. If you use different accelerations for the different types of print moves, the acceleration is set only when necessary with M201 (print moves) / M202 (travel moves). Which is OK.
On the other hand, when the flavor is Marlin, you have "204 Sxxx" before every single block of travel and print moves. This leads to a lot of overhead - even in small files, and results in a slowdown & degraded print quality in some situations. Take the picture below for example. I'm using Octoprint, running on Pi Zero. I have ultra fast movements while printing the bottom pattern when the gcode flavor is Repetier, and VERY jerky movements with Marlin flavor (looking like a buffer underrun). With identical settings.