Marlin: BEZIER_JERK_CONTROL/ S-CURVE

[warbunnies]

Is the only step to activating the Bezier_jerk control uncommenting: #define S_CURVE_ACCELERATION in the config file?

I have done experiments: measuring noise level & blind quality test on friends and not noticed any defining difference between having this feature on or off.
I torture tested my printer up to 7000mm/s acceleration and could not see a difference. (which is honestly a testament to marlin 2 cause my sbase with smoothieware could only do about 1400mm/s for same quality)

The only clue I have that something is different is that the print is 5-10 seconds faster with s-curve enabled. So something is different... I just don't know what.

Has anyone used this feature & actually gotten noticeable noise and quality differences?

[warbunnies]

Nvm on a hunch I looked at my planner_bezier.ccp and found #if ENABLED(BEZIER_CURVE_SUPPORT)
so I should put:

define BEZIER_CURVE_SUPPORT

instead of

define S_CURVE_ACCELERATION

Edit:

planner.ccp uses #if ENABLED(S_CURVE_ACCELERATION)
& planner_bezier.ccp uses #if ENABLED(BEZIER_CURVE_SUPPORT)

should these match eachother?

[iosonopersia]

Yes, they should. Make sure to download a fresh copy of 2.0 bugfix

[warbunnies]

The new copy has the same issue. I looked it up.

[warbunnies]

Also does Junction Deviation conflict with S-curve?

I decided to try both out and the movements cause very odd vibrations. I'll try just s-curve when I get home.

[gloomyandy]

Doesn't BEZIER_CURVE_SUPPORT enable the support for the G5 gcode operation (cubic splines), rather than anything to do with acceleration or jerk control> That is what it looks like from the source:
https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/gcode/gcode.cpp#L205

So I think you only need S_CURVE_ACCELERATION if what you want is the acceleration control.

[warbunnies]

Seems your right. must have mixed those up Bezier_jerk control with G5 support "bezier curve"

If BEZIER_CURVE_SUPPORT is only for g5, then I'd love an example of s-curve acceleration doing something... cause it does not affect my delta.

Edit: clarity

[FiCacador]

The bigger the acceleration you use, the less time it takes accelerating to the desired speed. The lower the desired speed is, also the less time it takes to get there. The the less time it takes, the less you can notice it.
If you want the S curves to be noticeable, try printing or moving really fast with a really low acceleration.

You should try also enabling junction deviation, if you haven't already.

The current linear advance isn't optimized to work with S-curves (yet #10812 ), but it's still better than nothing.

[warbunnies]

Hmm okay, s-curve is more useful with printers that cannot handle high accelerations.

I tried turning on junction deviation with its default settings and the movements became really jerky with a lot of vibrations. Are the standard settings too high or something?

[ejtagle]

There has been some problems with deltas lately... We are investigating those issues.

[warbunnies]

I'll let you know how the testing goes.

[warbunnies]

I can now confirm that junction deviation is not something that works with deltas right now. It goes really slow and has a very very strange vibration while printing.

[ejtagle]

The main problem with deltas is the kinematics. Marlin is handling all limits and jerk and scurves per motor, not per cartesian axis...

[warbunnies]

Ya i imagine it would take a lot of testing to figure out the ideal way to organize movements for a delta.

[p3p]

The main problem with deltas is the kinematics. Marlin is handling all limits and jerk and scurves per motor, not per cartesian axis...

Isn't that correct even for deltas, it's the motors that have the mechanical limitation the values compensate for, the end-effector (inertia etc) just can't be grouped into the same calculation for non-cartesian machines.

[ejtagle]

@p3p: it is correct to handle limitations (maximum jerk, acceleration and feedrate) per motor, but there are also maximum jerk, acceleration and feedrate limitations for the end-effector/extruder... And right now those are completely ignored.
The movements of the end effector are the result of a non-linear composition of the movements of the motors (I agree those movements can be considered to be linearly dependant if the movement is small enough, that is the idea that Marlin uses).
But, if you consider the whole motion, and not each small part the movement was split into, the speed variation exists. The extruder motor must feed filament in a non linear way because each segment has differing speeds ..

[Sebastianv650]

@warbunnies regarding s curve acceleration, I'm also seeing (or hearing) no difference in my test prints so you are not alone. As I'm using it on an AVR board, it might have something todo with the necessary "simplification" that is used there so the AVR is able to caculate it in real time.

A speed over time plot would be intresting, that's on my list but I found no time up to now to do it.

[warbunnies]

@Sebastianv650 I'm using an ARM board. Is there a way to prevent the simplification or is that done automatically when you specify the board?

[alexyu132]

@ejtagle Junction deviation also seems to be acting up on my CoreXY machine with acceleration 4000 and junction deviation 0.03 (tested down to 0.005, still the same issues). On tight curves the printer seems to corner much too fast leading to a loud grinding noise throughout the curve. Normal corners and back-and-forth infill work fine, though the movement seems more similar to jerk 20 instead of the default 10.

[Sebastianv650]

@warbunnies the differences between AVR and other boards are selected automatically.

[ejtagle]

@alexyu132 : As you have probably seen, the grinding noise should be fixed in the latest bugfix...

[warbunnies]

@ejtagle Did they fix it for deltas? Also where do you see these updates?

[ejtagle]

Rattling on Deltas should be fixed. And it is already merged for both bugfix branches

[alexyu132]

@ejtagle the junction deviation code definitely seems better than before, though it still seems to take certain corners much more roughly - during line infill it sometimes makes a light thumping noise when taking a 90 degree corner.

[thinkyhead]

@alexyu132 — Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see where it stands.

[alexyu132]

@thinkyhead I've been using normal jerk for now without any roughness or skipping - I'll test junction deviation later today to see if the issues are resolved.

[alexyu132]

@thinkyhead unfortunately it looks like junction deviation is still broken on the latest 2.0.x. It seems to instantly snap to speed during honeycomb infill producing a very loud continuous grinding and layer shifting.

[warbunnies]

Finally had time to update firmware & test wiring. Could not get the regular pins to work for the external sd card but the 2nd extruder pins work just fine. So I'm just gonna stick with those.

Junction deviation seems to be working fine for me. I can only see one area were it may have issues. While it was creating the skirt/brim, it made some really jerky movements but is really smooth everywhere else. Based on what alexyu said + my experience, it is possible that really really small moves could be messing it up & shouldnt use junction deviation.

Also tried the firmware retraction and i gotta say this is amazing. 70mm/s retracts and an entire 1.5mm less retraction distance than i use to use. Plus it doesnt sound like im murdering my extruder when i retract any more.

[github-actions[bot]]

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.