I’ve been playing with plotting lately and for the last week or so I’ve been struggling to understand and fix the stuttering and slow drawing behavior.
This is something I have seen several people encounter. At first I thought it was due to a very large number of very small movements, which in theory could saturate the 250kbps USB link between the PC and RAMPS. But actually calculating the expected throughput throughput (in one case for movements of about 0.1 mm) seemed to show that the 250kbps throughput is not close to saturation and can’t explain the stuttering.
Now I’m seeing stuttering and slow behavior with an extremely low command rate, so there is no way this could be the USB link. This particular file (attached) has G2/G3 arc commands which Marlin internally splits into many small segments. So I began to think perhaps it was the CPU or some internal per-segment rate bottleneck. I tried a number of settings in Marlin and none of them seemed to make a difference. These are the things I tried:
Minimum segment time (M205 B<nnn>)
Disable JUNCTION_DEVIATION (uses jerk method instead I guess?)
Increase BLOCK_BUFFER_SIZE (processed movement queue)
Increase BUFSIZE (unprocessed lines of g-code)
(I tried increasing jerk but I don't think I did it right)
Disabled G2/G3 in Estlcam, lots of short straight segments produced almost identical behavior
Tried increasing MM_PER_ARC_SEGMENT and other values for coarser arcs
Finally I got one of these MAX 7219 8x8 LEDs that allows debugging of some of the internals, specifically the movement queue. Without this I had no way to really know if it was the CPU getting overloaded or if it was something else. The outcome is that the CPU is NOT being overloaded. When the drawing slows down, it's not because the queue is being depleted. But it still leaves me at a loss to explain the behavior.
I am thinking it is something similar to minimum segment time, perhaps not the M205 setting but something else that is having the same effect.
I’m going to keep looking but I am also wondering if anyone has any other thoughts or suggestions for something I haven’t tried.
First, I made a mistake in my previous post where I said G2/G3 arcs was equivalent to a huge number of small line segments from Estlcam. With the 8x8 LED debugging, I was able to see that the small line segments were indeed depleting the movement queue, and on closer inspection, the behavior was worse than the G2/G3 version.
What finally solved it for me was disabling JUNCTION_DEVIATION. There might be a solution leaving it enabled with a different setting for JUNCTION_DEVIATION_MM, but I haven’t got my head around the meaning of this value so I am turning it off for now. This reverts to the classic “jerk” method for cornering.
I had tried disabling junction deviation earlier, but in doing so I had made another error (oversight): the firmware switched to the jerk method, but the EEPROM values were not initialized for X Y Z jerk, and the jerk limit for Y and Z was zero. After I set them to a reasonable nonzero value my drawings got much faster on the same gcode.
You may write a script to generate a set of concentric polygons with increasing number of sides. So you probably may find dependance between movement turning angle and speed deviation.
I guess may be 8 bit board just too weak to calculate so much subsequent junction points that exists in those small curves. Or algorithm calculates the path too safely where jerk-based approach just doesn’t care. To check this you need to try same marlin on 32 bit board if you have.
Interesting. If you run from an SD it make no difference, meaning it is a purely a processing issue? This might be the straw that pushes me to ditch the Rambo for the Archim1 (32 bit) completely.
I have an SD interface (and lcd) on the way so I will confirm that running from SD makes no difference with the G2/G3 version. The commands are so sparse, I can’t see how it could be a communication bottleneck.
Even so, my current belief is that it’s not a processing issue either. Marlin processes the commands (which may be complex) into an internal queue of simpler straight segments that are processed by the real time ISR that drives the steppers. As long as this internal queue is not depleted, the CPU is keeping up. The 8x8 LED array is showing the internal queue state (two rows of mostly solid red) so I think it is fine. When running a huge number of very short segments, the queue does get depleted and the machine stalls momentarily.
I have a smoothie board on another machine that I haven’t used in about 3 years, but I’m reluctant to go to all the trouble just yet. First I’ll try enabling junction deviation with different values and see if I can get behavior equivalent to my current jerk settings, which I think would confirm that the CPU is sufficient to handle junction deviation.
To sum up, my belief is that its neither communication nor CPU, but that the settings are causing it to slow down too much at the corners “on purpose.”
Ohhhh, Yeah I did not test the values extensively. I found a good explanation of them and went with the suggested. Did a test and it seemed good so I left it.
Just to chime in - I am also getting this issue with the SKR PRO V1.1, a 32 bit board + TMC5160 Drivers (bigtree v1.2).
I have also suspected that junction deviation is the culprit, but want to try some additional settings for the feature before I give up on it. I expect there must be some optimization left for the technique as used in the marlin firmware. I was hoping the additional horsepower would allow me to run all of these features without issues, but so far no such luck.
Just completed my build yesterday - so it’s early days - will update here after I try a few things.
I have given that a shot - actually went to 0.02, still have strange feedrates around the crown. I also just tried to disable junction deviation all together - still same issue.
I havent ruled out that my problems are my own;)
I’ll keep working out various issues - and try fusion’s CAM instead of Estl as well. Will report back when the machine begins to behave as expected.
OK gents, I thought I shared this issue - however I was mistaken. My problems were indeed my own - verify that your Estlcam settings are sending mm/m and not mm/s values to the board… (at least in my case).
Good news is that I’ve now got a verified good Marlin build for the SKR PRO with TMC 5160 drivers.
Perfect thanks for steering me back here. That chunk of gcode can serve as the tester to try and figure out if the junction deviation is a value thing or if it needs to be disabled.
Hi all, first post here. Just wanted to say I’m experiencing similar issues. Both with 8-bit and 32-bit controller (Ramps 1.4 and SKR v1.3).
On my DIY LotusXY pen plotter:
These speed changes are causing all kinds of artefacts such as rippling in lines and unevenly distributed ink.
What I am about to try is changing: #define MM_PER_ARC_SEGMENT and set it to 3mm instead of 1mm.
In my setup JUNCTION_DEVIATION was not enabled. I did however enable S_CURVE_ACCELERATION. Can S_CURVE_ACCELERATION also cause more stress on the CPU of the controller?
I’m about to reupload the firmware and changed a couple of settings (I know, I should only change one factor each time, but hey, I’m lazy sometimes). Right now I’m using an inkscape plugin to generate the gcode with. It depends on the work that I generate, there is only one kind of issue and it’s on the G2/G3 curves. All of my other work gets plotted fine without any issues.
Did the original poster manage to fix the issues? Because, in my settings junction deviation was already turned off and I still had the issues. So I do not expect that was the issue.
I had “solved” it to my satisfaction but i have seen reports about G2/G3 (https://www.v1engineering.com/forum/topic/g02-g03-commands-yes-or-no-or-do-i-miss-something-else/) that seem different from what I experienced in the past. This makes me wonder if G2/G3 has seen a firmware change. I haven’t gotten into this on version 411 to see what is going on. That might be something worth trying: compare 402 with junction deviation off and see if the behavior is the same. (Make sure to double check settings for classic jerk.) If there is a difference then it points to a possible new problem with Marlin’s G2/G3.
I can’t fix this. Marlin seems to just choke on G02 and G03 commands using i and j.
I got it to run smooth but now I’m regenerating my code with only G01 code and sadly vertexes instead of curveVertexes (in processing). This means that my lines are not curvy but they are actually just straight lines. The end result is a drawing that has ugly segmented lines.
Somehow Marlin just chokes on this stuff. I should try a new firmware. Maybe Repetier or RepRapFirmware? Anyone has some experience with these in conjunction with G02 and G03 codes?
The interesting thing is that Marlin doesn’t choke on circles only going one way. For example only sending G02’s.
Can you create a simple .gcode file using G2/G3 commands that demonstrates the issue? If so, take a video of the issue and post a link to it and the .gcode as an issue on the Marlin github page. I believe they would be very interested in knowing about this problem.
I did some cuts last night, one of the first jobs I’ve done since upgrading to 411 and the rounded corners seemed slower and jerky compared to what I was expecting. I’ll dig into this more. I’m starting to suspect the defaults for 411 might not be the best.