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

daemon_fr

Hello!
I am in dire need of help.

Specs (everything from reprap.me):
bq Prusa i3 Hephestos
Diamond Hotend
Rumba
Heated bedRepetier 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!

Repetier

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_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!

Repetier

There is also a way to debug more detailed. Compile with

#define DEBUG_QUEUE_MOVEin 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.

Morpheus69

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.

Repetier

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.

Morpheus69

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

Repetier

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.

Morpheus69

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

Morpheus69

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

Repetier

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_SEGMENTSThis 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.

Morpheus69

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

Repetier

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.

Morpheus69

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

Repetier

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:-)

Morpheus69

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. :-)

Repetier

"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.

Morpheus69

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

Repetier

No image is not visible and dropbox link is for log file.

For perfect print you need to disable the debug log.

Morpheus69

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.