Stuttering and Slow

This topic contains 9 replies, has 4 voices, and was last updated by  Ryan 4 weeks, 1 day ago.

Viewing 10 posts - 1 through 10 (of 10 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.

    • This topic was modified 4 weeks, 1 day ago by  Jamie. Reason: forgot to mention arc segments
    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.

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

You must be logged in to reply to this topic.