search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.18k stars 19.21k forks source link

[1.1.8] Bad acceleration+jerk in travel moves (opposite in bugfix) #9728

Closed fbarcenas closed 5 years ago

fbarcenas commented 6 years ago

Bug Report 1.1.8 version

While is printing not problem happen, is only when you move manually.

In version 1.1.3 not fail, another version or bug fix today not tested

ghost commented 6 years ago

Yes and the same , when you move on UBL mesh edit , all is brutality in movements

thinkyhead commented 6 years ago

Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see where it stands. If the problem has been resolved then we can close this issue. If you still see the bad behavior we should investigate further.

fbarcenas commented 6 years ago

All absolutly solved with actual Bugfix of today.

Talking in general terms, I think than the actual bug fix must be 1.1.9 immediately. 1.1.8 have fails than need solved urgently, and already is solved in the bug fix.

thinkyhead commented 6 years ago

the actual bug fix must be 1.1.9 immediately

1.1.9 will be released very soon.

fbarcenas commented 6 years ago

I want reopen this problem, after do some test i have the follow conclusion.

Same machine, same config, same file gcode

Sebastianv650 commented 6 years ago
fbarcenas commented 6 years ago
Sebastianv650 commented 6 years ago

I checked the planner only a short time ago,it was fine on my machine back then. I will recheck with latest rcbugfix tomorrow.

Please tell me your jerk values so i can see if there is something related to them in special.

It's only a noise that leads to you conclusion of having a problem isn't it?

fbarcenas commented 6 years ago

Acceleration: 500 Jerk: tested with 1.0 and 0.5

Sorry i don't understand your question, could you rewrite again? sorry for my english

Sebastianv650 commented 6 years ago

1.0 and 0.5 for xjerk, yjerk and ejerk?

My question was: you wrote you have problems with the moves, as it would crash (=a hard sound). Is this the only problem, or do you get also shifted layers for example?

fbarcenas commented 6 years ago

X jerk: 0.5 and 1.0 tested Y jerk: 0.5 and 1.0 tested Z jerk: always 5.0 Sound crash yes and also you can see like the layers also is shifted/moved (like around 3 or 4mm)

Sebastianv650 commented 6 years ago

I can't reproduce something like a stop with too high jerk. In fact, I'm seeing quite the oposite without having a real answer at the moment. I wrote a test gcode file containing 3 loops around a 30x30mm square. First one without extrusion, second loop like a print move and third loop with retractions. With this, I set XY jerk to 5 and E to 1 first, then switching the values. While the calculated max junction speed looks fine, the set initial and final step rates are nearly always MINIMAL_STEP_RATE (=120):

jerk

I have to dig a little bit deeper..

Sebastianv650 commented 6 years ago

@fbarcenas please add your Configuration.h file here for download, I have maybe fixed a problem but I guess there is also a problem in your configuration.

fbarcenas commented 6 years ago

Well, i do new test... and this is horrible. I think than the best is i try to explain all from the first.

I do more than 30 prints with 1.1.8, i only have problem in no-printing movements. Never i have a problem with printing movement.

I upload bug fix version 28feb (and i check than the no-printing movements are fixed!) and i do a new print:

So i upload the 1.1.8, and i start the same file gcode. Now the fail happen!! but in the axis X-, the layer is shifted more than 100mm!!!

Problem of file? Problem of jerk? What happen? I upload:

Sebastianv650 commented 6 years ago

That's a big printer! I guess the mass of this printer might be the reason why a small jerk error count lead to such high shifts, but it's realy strange nevertheless. I'm aware of reports about hard movements with bed leveling enabled, but no one with this issue with disabled ABL.

Maybe #9914 will give us some knowledge, but in fact it's more in the oposite direction as I don't see any jerk without that PR in current bugfix branch.

thinkyhead commented 6 years ago

With Sebastian's PR merged (and feeling extra confidence because it's more like the 1.1.5 planner code) please give the latest bugfix-1.1.x another go and see if we now have good movements in both LCD/manual and regular G1/printjob movement. I suspect it will be good.

fbarcenas commented 6 years ago

I am sorry to say than the problem not is fixed. With 1.1.8 i have shifted layers in X axis With Bugfix 28Feb and 8 March i have shifted layers in Y axis. I want clarify than with Bugfix version i don't have problems in no-printing movements Same file, same machine.

I don't know than say....

thinkyhead commented 6 years ago

Try setting MINIMUM_STEPPER_PULSE to 2 and see if it helps.

fbarcenas commented 6 years ago

I test with bug fix today than include this, but fail... I see and the fail is always in the same points... When do a curve non-hard, is like apply wrong acceleration or jerk value and the stepper don't do acceleration....And i can see like must do a big movement without acceleration. I attach a example of gcode.

In this, fail a lot, is continuously. In the inner perimeter especially test.gcode.zip

If i use a weird value of jerk like 0.20 seem than work...

Some ideas?

fbarcenas commented 6 years ago

Is like: instead of do a curve, do a lot of little lines without acceleration...

thinkyhead commented 6 years ago

That G-code looks pretty screwy. You should provide a simpler example that's not composed of small, disconnected segments and not way off-center.

fbarcenas commented 6 years ago

I attach new gcode, more easy and simple. testeasy.gcode.zip

is ok now?

thinkyhead commented 6 years ago

The segments in that G-code are quite small; as small as 0.1mm for long runs, which is problematic. Try modifying your slicer settings or altering the model so that the facets are a bit longer (at least 0.5mm), or slow down your printing speed so that the planner won't starve.

fbarcenas commented 6 years ago

Answer of support software slicer: "It sounds like what you are attempting is a reduction in the complexity of the mesh to minimize the amount of small moves. This can be accomplished using the mesh reduction tool found in the Mesh menu in the top toolbar but it is surprising that movements of the above mentioned .1mm length are causing issues. I would also please keep in mind that .5mm is a fairly large distance for curved objects and will result in faceting of the part."

thinkyhead commented 6 years ago

I seriously doubt a segment length of 0.5mm will result in any obvious faceting.

Anyway, we still hope you will try the things we suggest to see if it makes any difference. Your testing helps us to narrow down the issue.

VanessaE commented 6 years ago

I seem to be having this issue also (bugfix-1.1.x, at commit de5f69b2852e0e2fadd02f3c5a8d19f41ab2194e)

A typical print move is fine, but travels frequently sound like they're being slammed up to speed without acceleration, which causes lots of stalls/skipped steps (the result is shifted layers, similar to a typical nozzle crash). Speeds are usually 60 mm/s on coarse features, 30 mm/s on fine details, and 200 mm/s travels. Even 240 mm/s print moves don't stall (not that my bot prints all that great at that speed :smile: ). Only travel moves are affected.

My X/Y acceleration is at 2000 mm/s², jerk is at 10. The hardware's mechanical limit is around 350 mm/s, 6000 mm/s², and somewhere north of 40 for jerk.

Sebastianv650 commented 6 years ago

Maybe you can isolate one occurrence in the gcode? It might help to set print and travel acceleration to a very low number like 200. This way it makes nice sounds during acceleration and deceleration so it's easy to hear when an acceleration is missing. A sample gcode section with the travel move +-2 lines or so would be helpful.

VanessaE commented 6 years ago

It seems to be pretty random, but I have a hunch that it's related to the bit of LIN_ADVANCE that intentionally reduces X/Y acceleration when needed.

Running the print at 1000 mm/s², all else being equal, seems to be enough to avoid stalls.

As a test, load the attached model into Slic3r, turn on supports (threshold 20 degrees or whatever your overhang limit is). Slice, set a high acceleration, a LA K value of around 0.2, and print.

Overhang_Angle_Test_30-85.stl.zip

(this model is actually meant to be printed without support, as a test of your printer's limits, but it's useful as a basic support material settings test piece too)

Sebastianv650 commented 6 years ago

It seems to be pretty random, but I have a hunch that it's related to the bit of LIN_ADVANCE that intentionally reduces X/Y acceleration when needed.

This could only affect print moves and it's also only able to reduce accelerations. I'm more on the side to think it's another hickup of the jerk calculation (#10341).

It can take one day or two until I can do the test print, but I will do it if necessary.

VanessaE commented 6 years ago

That (10431) sounds plausible, yeah, though I don't experience the slow->fast pauses the author's getting.

As for that test print, there's no big rush; dropping to 1000 mm/s² is a usable workaround (besides, when print speeds are down in the 30/60 range, increasing acceleration gives diminishing returns).

EDIT: I wrote 1500 here and in my previous post when I meant to write 1000. Corrected.

boelle commented 5 years ago

@fbarcenas still having issues with latest bugfix 2.0?

boelle commented 5 years ago

@fbarcenas i think your issue is that you try to print faster than the hardware can

i had similar issues and when i lowered speeds it started to work

github-actions[bot] commented 4 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.