Stuttering and Slow

This topic contains 25 replies, has 7 voices, and was last updated by  Ryan 3 weeks, 6 days ago.

Viewing 26 posts - 1 through 26 (of 26 total)
  • Author
    Posts
  • #100862

    Jamie
    Participant

    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 8×8 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.

    Attachments:
    1. ocrb_hand2.gcode
    #100878

    Jamie
    Participant

    Success!

    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 8×8 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.

    #100883

    Guffy
    Participant

    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.

    #100884

    Guffy
    Participant
    #100895

    kd2018
    Participant

    Sounds like you’ve narrowed in on it being a firmware problem but I’m curious what you’re using to send the gcode?

    #100896

    Guffy
    Participant

    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.

    #100899

    Jamie
    Participant

    I’m using pronterface. I know it’s probably not the best but I’m familiar with it since the time I started with 3d printing.

    I’ve got more experiments to do fully understand the working of jerk vs. junction deviation… I’ll update later on what I find.

    #100915

    Ryan
    Keymaster

    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.

    #100927

    Jamie
    Participant

    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 8×8 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.”

    #100931

    Ryan
    Keymaster

    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.

    #111847

    Dirt Merchant
    Participant

    Hello everyone!

    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.

    #111860

    Ryan
    Keymaster

    Three posts this morning already about this. Try doubling my junction deviation setting and see how it goes.

    #111864

    Dirt Merchant
    Participant

    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.

    #111978

    Dirt Merchant
    Participant

    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.

     

     

    1 user thanked author for this post.
    #112458

    Ryan
    Keymaster

    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.

    #117850

    Marinus
    Participant

    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.

    1 user thanked author for this post.
    #117866

    Jamie
    Participant

    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.

    #117911

    Marinus
    Participant

    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.

    • This reply was modified 4 weeks, 1 day ago by  Marinus.
    • This reply was modified 4 weeks, 1 day ago by  Marinus.
    #117918

    frosty
    Participant

    I can’t fix this. Marlin seems to just choke on G02 and G03 commands using i and j.

    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.

    #117931

    Jamie
    Participant

    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.

    #118013

    Marinus
    Participant

    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.

    What are you referring to as 411? I’ve been trying to understand but I’m kind of missing it 🙂

    I have converted my script to output segments instead of curves and now it works flawlessly even though there are way more segments than there were curves before. And you still see artifacts of the technique which I don’t like.

    The filters on the images are kinda heavy so causes blocky artifacts but it’s working okayish.

    IMG_POCO_F1_20191015_231910_DRO-01

    IMG_POCO_F1_20191015_230052_DRO-01

    • This reply was modified 4 weeks ago by  Marinus.
    • This reply was modified 4 weeks ago by  Marinus.
    1 user thanked author for this post.
    #118117

    Ryan
    Keymaster

    411 refers to my firmware version. Currently it is at 412, you can see it in the config file, when you connect a program to your board, or if you have an LCD plugged in it shows on the marlin screen.

    I have your text file as a tester for the arcs but maybe we need a better test. Or not use arcs again for a while. There has been a lot of updates to Marlin (laser timing!) so Maybe I will make a 413 in the next few days. We need a stable version in a bad way that works with arcs.

    #118178

    Marinus
    Participant

    411 refers to my firmware version. Currently it is at 412, you can see it in the config file, when you connect a program to your board, or if you have an LCD plugged in it shows on the marlin screen.

    I have your text file as a tester for the arcs but maybe we need a better test. Or not use arcs again for a while. There has been a lot of updates to Marlin (laser timing!) so Maybe I will make a 413 in the next few days. We need a stable version in a bad way that works with arcs.

    Ah yes, like I thought, I couldn’t upload the latest version of Marlin due to an error in compiling so I wasn’t able to check the LCD or check it through the serial connection sadly. I’m using the raw version of Marlin by the way, it seems you are talking about the firmware specifically for the v1engineering machines 🙂 I am completely DIY but still find this forum to be very good for the information that is supplied. Hope that’s ok.

    #118181

    Ryan
    Keymaster

    No problem for other builds!

    What date did you compile your firmware that the arcs work again?

    #118201

    Marinus
    Participant

    No problem for other builds!

    What date did you compile your firmware that the arcs work again?

    Sadly no working arcs yet, only straight line segments. I tried different combinations of MM_per_arc_segment or something like that and jerk, both the old vs the new jerk method with calculated settings. But it seems my controller just gets choked up on G02 and G03. I was advised to try out Klipper but for Klipper you need a Pi.

    #118245

    Ryan
    Keymaster

    You can go back to my 300 version of firmware, I am pretty sure they worked fine then.

Viewing 26 posts - 1 through 26 (of 26 total)

You must be logged in to reply to this topic.