›

Discontinuous (not-smooth) X/Y movement on Prusa i3

daemon_frdaemon_fr
edited September 2016 in Repetier-Firmware

Hello!

I am in dire need of help.

Specs (everything from reprap.me):
bq Prusa i3 Hephestos
Diamond Hotend
Rumba
Heated bed

Repetier 0.92.9 and slic3r combo is really nice and all is good with color mixing and everything (quite satisfying results, within realistic expectations) but there's a problem i can't seem to shake:

The X/Y axis motions are not smooth, and wherever there's a vertex in the 3D model, i get a tiny, itsy bitsy small brake or stutter, and thus, a little bit of extra, unwanted extrusion. This causes every vertex to be visible, and it's especially annoying in curved surfaces, like circles but not only. Vertical spines or edges go up and down along my prints, right until the polygons are so tiny and vertices almost overlapping, that this problem appears to disappear. Small/high poly objects print nicer.

The only thing that seems to mitigate this is really slow print speeds. Printing perimeters at excruciatingly slow 10mm/s yields some not as bad results.

Also, by slowing down prints, the stuttering is even more easily noticeable. You can hear the motors accelerate and decelerate to a short pause. Instead of LINE-LINE-LINE-LINE it goes LINE-PAUSE-LINE-PAUSE-LINE-PAUSE, where LINE is a g-code instruction and the PAUSE is a matter of milliseconds, but long enough to cause the issue.

I haven't been able to pinpoint the issue to some specific setting. I've tried various perimeter speeds, extrusion, jerk, acceleration, feedrate values, belt tensions, but what i get is that straight lines (with no vertex interrupting the flow) get printed correctly, as opposed to curved surfaces, which get a jagged, wavy outline. I think it's a firmware/settings issue but i'm at my wits' end. I have a RapMan 3.2 and Micro M3D printer that had no such behavior ever.

Please help!
Thank you!

image

«1

Comments

  • RepetierRepetier
    Sounds like you convinved firmware to reduce speed on every corner. The speed at joining lines is defined by xy jerk and angle change. You could also add
    #define ALTERNATIVE_JERK
    to activate a different jerk computation that results in more realistic computation, reducing less
    for small changes. Since it also happens on low speeds I think your jerk is way too low. Try 20 which
    normally works for most printers. Also check in eeprom what the value is. Accerlaeration for print
    should be in range 1000-3000 depending on how your printer shakes.
    Lastly, you could try dev branch, not that it I have changed path planning for a while, but that version I
    could debug. But I don't see it on my printers so I assume it is just jerk too low.

  • daemon_frdaemon_fr
    Thanks for you quick answer!

    I have changed Max Jerk from 20 to values from 0 and going into the hundreds, and there's no change in that regard.

    I will try your advice and report back.

    Thank you!
  • RepetierRepetier
    There is also a way to debug more detailed. Compile with






    #define DEBUG_QUEUE_MOVE

    in your configuration.h. If you then enable echo it will show a very detailed log about move computations including start/end speed and acceleration steps. It is too much for a complete run with it enabled but you could make 2 longer dummy moves to fill queue and then 10 lines of a circle segment. That should exactly show what internal stage it tries to copy.

  • Morpheus69Morpheus69
    Hi, i have the same problem...prusa i3 with new diamond hotend mounted...in my case only arc or circle come out how the cone in previous photo, instead line and vertex are perfect like cube. I noted also that in simulation (Dry Run) the movement are totally fluid, the problem is present only in real print. Sometimes in dry run the problem is still present, but with a reset of printer disappear and is fluid again. I tried to reduce microstep of all motor to reduce arduino load  without result, also reduced speed for test, but nothing changed.
    Just for info i used the same parameter like acceleration, feedrate etc that used before...(with marlin and single extruder)
    I tried the detailed log with #define DEBUG_QUEUE_MOVE if is necessary i can post the result.



  • RepetierRepetier
    If dry run makes it fluid we could assume the extruder setting is the problem. What steps per mm do and filament diameter do you have? Only very high values could make it so dominant that it gets speed problems, but then I'd expect it in fast parts not in corners.
  • Morpheus69Morpheus69
    Hi, infact initially my setting was at 1/32 and i reduced at 1/8 for test, but is exactly the same.The diameter of filament is 1.75. But the strange things is that the "jitter" is present only in the arc o circle printed and is regular, like a gear with a lot of small teeth, so it don't seem a problem of speed, otherwise i think the the problem should be irregular...
  • RepetierRepetier
    In fact it could be the computation of max. join speed. We need this to be near print value to not get blobs from accelerating/decelerating. So if there is a special case that reduced the join speed too much we could get this. If you have a simple case = 3 longer lines to fill buffer and then the problematic curve you could use
    #define DEBUG_QUEUE_MOVE 
    to see what join speeds are. Alternatively find the gcode and enable echo just before and disable echo afterwards
    M111 S1 ; echo on
    M111 S0 ; echo off

    don't use it for longer periods or you get crazy interpreting it. Also output could be slower then print which will slowdown speed as well.
  • Morpheus69Morpheus69
    edited September 2016
    I made the test with just a circle, so the trace start from home go at the center make a circle and finish, so i performed the test 2 time, the first like dry run and the second in real mode. I tried to compare, and don't understand much, it seems that speed are different in real mode, at least the "start speed", I linked files here, so if you can and if you want can give it a look to understand what happen

    https://www.dropbox.com/s/5nx9l73f034loj9/Test.zip?dl=0
  • Morpheus69Morpheus69
    Just for test i compiled a new firmware for only one extruder, like a normal printer to understand if the problem was centered on the diamond extruder management, but nothing change, so I tried to change every firmware option that could be interested in the problem, like jerk (from 13 to 20), i put 5ms of  delay on stepper with quad stepping on/off, i switched off any features except arc support and g10/11 support, but the problem still the same...

  • RepetierRepetier
    Ok, it happened what I feared. The output takes longer then the move so no buffers build up and start/end speed are just jerk/2 (if it is 14.4 for your tests). So you get always accelerations on every segment. Dry run seems to free up some buffers as it sometimes also joins with 35mm/s. Maybe it's the time required for controlling extruder that helps here.

    Can you retry with
    #define DEBUG_PLANNER
    instead of DEBUG_QUEUE_MOVE. This output is more usefull and also shorter. If it still does not build up a buffer you could try increasing circle diameter so each move takes longer.

    In the dev version we are experimenting with new optimizations for the problem. You could try printing with







    #define ALTERNATIVE_JERK

    #define REDUCE_ON_SMALL_SEGMENTS

    This makes some optimizations for bad generated gcode with very short moves. It then reduces jerk even more in case it is a fast turn (REDUCE_ON_SMALL_SEGMENTS). Maybe not exactly what helps here while ALTERNATIVE_JERK should do less reduction on curved parts.















  • Morpheus69Morpheus69
    edited October 2016
    Well, in my first test the jerk was 13, now i used 20 and i made the new tests in this sequence dry and "wet" in all cases
    1) small circle 4cm diameter
    2) big circle 12cm diameter
    3) small circle, dev firmware with option enabled how you suggest
    At the first look, logs are similar. the start speed seems always at 7.7, but now the jerk is 20. what does it mean? buffer always down? with a big circle also....
    Somethings is different instead in log dev firmware, it seems everithings zero.

    https://www.dropbox.com/s/cfbuhmz4v46okkz/PLANNER.zip?dl=0
  • RepetierRepetier
    Ok, that logs are much better to analyse, also some files have liens cut at 80chars somehow.

    One of the parameter in log is maxJunctionSpeed and that is 0 for dry run. Only difference in computation of this is






        float eJerk = fabs(current->speedE - previous->speedE);

        if(eJerk > Extruder::current->maxStartFeedrate)

            factor = RMath::min(factor, Extruder::current->maxStartFeedrate / eJerk);

    so my assumption is that your maxStartFeedrate = extruder start speed is set 0 or very small for your printer. Normal values would be 20-40 since extruder has nearly no mass it can start very fast. But with low setting it enforces low speed where not needed. Then speed is increased to minimum speed as it seems instead of 0 from computation. 

    So increase extruder start speeds and the problem should be gone. Never thought of that.

  • Morpheus69Morpheus69
    edited October 2016
    YES !! It is gone. It is the first test, but i think is solved. Thank you very much.
    I this point i want understand if is it my mistake...( i forgot to set right value ?) or my printer is "strange" and it wants a non zero value...
  • RepetierRepetier
    Extruder min speed should never be 0. You did non set it correct and I did not test for the error. So who made the mistake:-)
  • Morpheus69Morpheus69
    Fifty-fifty ?? no,no. It's my fault! end of story. :-D
    Finally it's a circle not a gear...i made some test with normal and dev firmware with alternative jerk and reduce on small circle and in any case it seems pretty smooth to the touch, but visually there is still some discontinuity shadow...
    If this is found not to be then maybe I made some other mistake, which does not surprise me at all. :-)
  • RepetierRepetier
    "discontinuity shadow..." how does that look like?

    Maybe now the most prominent error is gone you start to see the next quality issue:-) We have still vibrations and some less prominent accelerations.
  • Morpheus69Morpheus69
    edited October 2016
    Surely this is also true as you say. :-D
    Anyway just don't seem crazy...

    https://www.dropbox.com/s/ld7u843lftfv3aq/test.jpg?dl=0


    On left side you can see the original problem, on right side the actual condiction.
    Well, i can accept this condiction surely, but becouse your firmware is awesome, it disturb me that i can not get perfection. :-)

    P.S.
    I'm not sure if image is visible,  so...

    https://www.dropbox.com/s/5nx9l73f034loj9/Test.zip?dl=0
  • RepetierRepetier
    No image is not visible and dropbox link is for log file.

    For perfect print you need to disable the debug log.
  • Morpheus69Morpheus69
    edited October 2016
    OMG ! Sorry link error.

    https://www.dropbox.com/s/hos4oin3s1y55xc/test.zip?dl=0

    Now should be correct. It's a image...
    ...and , yes debug log is off.
  • RepetierRepetier
    What a difference!

    Right image looks good. You even see the segments of the circle, which is ok since it is in the gcode file.
    You see seam positions a bit, something that is hard to avoid. You could align them but then you have a very visible row instead. Looking at the original you might see more, but for me it looks quite well.
  • Morpheus69Morpheus69
    Yes,yes i know. it's quite good really, but i don't understand why with my delta or with prusa before this mod the same object  (monocolor off course) come out without this "light" segmentation.
    Anyway never mind, i'm satisfied. i aim for perfection, but i'm happy for the result i get. ;-)
    Thank you for your time.
  • daemon_frdaemon_fr
    so my assumption is that your maxStartFeedrate = extruder start speed is set 0 or very small for your printer. Normal values would be 20-40 since extruder has nearly no mass it can start very fast. But with low setting it enforces low speed where not needed. Then speed is increased to minimum speed as it seems instead of 0 from computation. 

    So increase extruder start speeds and the problem should be gone. Never thought of that.

    That fixed it for me, thanks a million!
  • Nandox7Nandox7
    Hi guys,

    I'm having the same issue (or at least seems so), I have read all discussed here and I also had the value lower than 20.
    Since then I have moved it up to 35, it is true it did improve the prints but the wavy effect is still there.

    I'm using a RADDS controller with RAP128 drivers on a Prusa i3 printer.
    I have tested many settings and option and so far I can't figure out why this happens.

    The problem happens in both axis X and Y in the same regular intervals so I can disregard a mechanical issue.
    So I link this to something in the extruding process, one fo the tests was to reduce the steps of the drivers just in case tey were to many, so now it is using 370 steps/mm. That to be fair is nothing as for the X & Y I use 640 and for the Z is 32000.
    Still nothing changed.

    I thought it could be the infill pressing out the filament, so I made a test part with just one external wall, still the same.

    Some examples. (all done at the same speed with 0,2mm layer)
    Partial cube, no 0 infill, so it only has a single external wall.

    Two different cubes printed and the wavy pattern matches perfectly.

    Test cube while during the print I changed the value of the extruder start feedrate.
    From left to right, started with 35 then 65 , 75 and for last 100.

    No visible change, appart from a line that seems to have happened during the change  from 35 to 65.

    This is one model, but I see this with any other STL used. I'm just using a cube because the walls are straight and
    don't have multiple segments like for example in a sphere.

    Any ideas what this migth be?
  • RepetierRepetier
    Is your current setting correct? If your stepper position is incorrect from not being able to move to a position exactly you get different speeds between full steps. Full steps need less current then holding substep position so this can cause smaller irregularities repeating with each full step. Higher speeds shoudl reduce such effects.

    If you try a bigger cube (0% infill) you could also see if it is infill pulling through or if it is from vibrations during direction change. In that case the waves get lessprominent over the side.
  • Nandox7Nandox7
    edited November 2016
    Thanks for the reply.
    It should be caused by infill as all the tests I have made I was careful to not have any, exactly prevent that.

    In regards to current I believe is well adjusted, this is a bQ Hephestos (well it's core, as it has so many upgrades now) and what I did was use their current settings reference for the Aleggro drivers and convert it to the RAPS128 formula.

    But could be that, this was the last test from yesterday. Made a cube, single shell and changed speed during printing.
    Started with 100% (60mmm/s) > 50% (30mm/s) > 200% (120mm/s). 200% is the last bit on the left, that does seem to look a bit smoother.



    BTW, could the RAPS128 decay setting cause any impact? 
    Documentation for is is almost null, they just say medium setting, but there is not even a voltage reference value to measure.

  • RepetierRepetier
    I guess decay could have influence, but that is something I never understood and gladly never needed to turn my attention to. It has to do with speed of current change or something like that and that might influence torque and therefore precision of position.
  • Nandox7Nandox7
    edited November 2016
    Yeah, there is no proper detailed information about it. 
    Or at least in regards to how properly set it up or what values to use.

    I mentioned as someone reported similar problem with the DRV8825 and the decay, where people hack the driver to fix it.

    I have made a few more tests. Bumped the voltage/current to the max recommended 1.6v for X & Y and Extruder.
    I even made it halfway during a print but didn't notice any difference at all.
    Then I proceed to do the same but changing decay in the extruder.

    Now after all these changes the wavy marks look smoother and much better defined. So at least something changed. :)

    Of course my approach was the worse possible, so next steps will be putting back all as before and start from one end.
    I'll try different things.
    - swap drivers
    - reduce microstepping to 1/32
    - change current & decay during a print 
    - try back to my old RAMPS1.4 controller.

    I want to find out what's causing this.

    Btw one random thought, I have/use auto-level could the correction cause something like this?
    I guess not as to happen it would be smoother and linear no with this pattern.

    More ideas welcome! 
  • RepetierRepetier
    Autolevel means speed is also constrained to z move, but normally you correct such small errors that this is no issue.

    The fact that decay has an influence is interesting. Reducing microsteps will probably do nothing. If it can only hold 1/32 but not 1/64 then 1/64 would more or less be identical, so I do expect it to have much influence.

    Drivers are normally working on 5V and 3.3V so you could also use the RAMPS driver on RADDS. That should give exactly the same result as on RAMPS except you have more speeds available.
  • Nandox7Nandox7
    Ok, so I can discard that.

    In the mean time I have tried all I could think off. Even ended up swapping the RADDS for my old RAMPS (drivers as well)
    And the problem remains.
    When I asked a few friends that also have 3D printer to do the test, they also see the same happening. 
    (btw they use completly different extruders and hotends)

    So I'd say there is a problem somewhere, but have no idea where. :)
  • RepetierRepetier
    If you know a few moves that show this - you need some before to fill up move buffer - you can try debugging it with
    //#define DEBUG_QUEUE_MOVE
    /** write infos about path planner changes */
    //#define DEBUG_PLANNER

    when echo is enabled both option sgive lots of informations. I would start with only DEBUG_PLANNER whcih gives smalle rreports. It returns speeds computed in path planner. Only makes sense if you know what you are currently sending, which is why I said small example. DEBUG_QUEUE_MOVE gives much more informations and on small moves it may even influence speed from the big output.
Sign In or Register to comment.