Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ender-3 Layer Shifting Issues #5694

Closed
saper253 opened this issue May 4, 2019 · 23 comments
Closed

Ender-3 Layer Shifting Issues #5694

saper253 opened this issue May 4, 2019 · 23 comments
Labels
Type: Improvement Improvement to existing functionality.

Comments

@saper253
Copy link

saper253 commented May 4, 2019

When using Cura with Ender-3, the slicer, writes the G-code with issues which leads to layer shift in the middle of the print.
The issue is present in Cura 3.5 and 4.0. At least these two versions that I tried.

How to Fix:
When in Cura, instead of selecting your printer template as Ender-3, select CR-10. Because CR-10 bed is bigger, what you need to do after is to reduce the built plate from 305mm X 305mm to 235mm X 235mm. Done!
Alternatively, you can use another slicer application.
If anyone has the same issue, I hope this fixes it for you.
If not, you can try tightening the belts and make sure the motor holding screws are tight.
If the problem is still there, try cooling your motherboard as it might be overheating and therefore, making a motor skip.

@smartavionics
Copy link
Contributor

Just a suggestion. With the Ender-3, try disabling acceleration and jerk in the profile and see if it still has a layer shift problem.

@baxi69
Copy link

baxi69 commented May 5, 2019

Tried it, did not work.

@Ghostkeeper
Copy link
Collaborator

We've had an update to the Ender 3 definition that could resolve this issue: f03e5c2

It's due to be released with Cura 4.1.

@baxi69
Copy link

baxi69 commented May 6, 2019

Is it known when version 4.1 will be released?

@smartavionics
Copy link
Contributor

You could try one of my releases that will include f03e5c2. They can be found at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

@Ghostkeeper
Copy link
Collaborator

Planning for 4.1 is not set in stone yet, so don't pin me down on this, but we're making a release towards the system testing team of Ultimaker tomorrow. If all is fine there we can make a beta release next week and a stable release several weeks later. We're aiming for a new release of Cura about every 2 months.

@yet-another-average-joe
Copy link

yet-another-average-joe commented May 8, 2019

We've had an update to the Ender 3 definition that could resolve this issue: f03e5c2

It's due to be released with Cura 4.1.

Hello !

IMHO a jerk value of 20 m/s is far too much ! Acceleration is fine (500). I don't own an Ender 3, but a Tornado (similar design), and had lots of shifting issues until I reduced accel. to 500 mm/s² and jerk to 10 mm/s (I use 8 mm/s).

It seems that this jerk at 20 mm/s is for historical reasons, as explained by Thinkyhead in this issue on Marlin Git : MarlinFirmware/Marlin#3002, and should be reduced to 10 because of changes in the algorithms. But he did'nt... As explained, values are fine for Ultimaker printers, but not for Repraps, and chinese printers with a moving bed (pendulums on more or less preloaded springs, with a varying mass and height ; on my side shifting appeared because of the nozzle hitting the printed part, because of uncontrolled movements of the bed)

@saper253 :

If accel. / jerk is disabled in Cura, the firmware will control them (as I understand this ???). Therefore, the printer firmware will also calculate using 20 mm/s (default jerk value in vanila firmware and in Ender-3 firmware). No need to recompile Marlin. G-Code commands can be used in a terminal (with a M500 inorder to save values) or in the Cura start G-Code.

This is my 2 cents.

A question for @smartavionics : I hesitate... Should we install your fork, or wait for 4.1 beta ?

@smartavionics
Copy link
Contributor

A question for @smartavionics : I hesitate... Should we install your fork, or wait for 4.1 beta ?

As you say, one could disable the A/J in Cura and then just add the desired A/J setting gcode to the print start code and then you don't need the new release.

Of course, there's lots of other good reasons for trying my fork too!

@yet-another-average-joe
Copy link

Thanks for teh quick ! I launch download !

@yet-another-average-joe
Copy link

Where should I search about issues and report them if needed ? (I see one - minor - right now)

@smartavionics
Copy link
Contributor

Where should I search about issues and report them if needed ? (I see one - minor - right now)

If you are talking about issues specific to my builds, please raise them at https://github.com/smartavionics/Cura/issues

@yet-another-average-joe
Copy link

Reading your Git, I understand you work on algorithms only.

It's about the UI...

@yet-another-average-joe
Copy link

Reading your Git, I understantd you work on algorithms only.

It is about UI.

@smartavionics
Copy link
Contributor

Yes, I don't work on the UI, just the slicer itself.

@Ghostkeeper
Copy link
Collaborator

If you've tested that a jerk of 10 works better on the Ender 3 we'll change the defaults in Cura and it should work out of the box from then on. Or you could make a PR yourself to change it. I just need you to test it first since I don't have that printer.

@gudnimg
Copy link
Contributor

gudnimg commented May 9, 2019

Ender 3 user here.... jerk of 10 is the maximum for anyone using default marlin 1.1.9 configuration (though you can change it in configuration.h yourself pretty easily). I've not seen any reason to change that on my end. If Cura has a jerk of 20, the printer will still use 10 since that is the max used by the firmware. Higher jerk than firmware makes Cura's time estimate more off.

You can see the jerk settings at line 645 https://github.com/MarlinFirmware/Marlin/blob/1.1.x/Marlin/example_configurations/Creality/Ender-3/Configuration.h

Also the default travel acceleration in Cura 4.0 is 5000, but in Marlin it is 500 for Ender 3, not sure if its a max value though. I saw no noticeable difference when I changed it in Cura to 500.

@yet-another-average-joe
Copy link

yet-another-average-joe commented May 9, 2019

If acceleration and jerk control are enabled in Cura, Cura puts M204 and M205 commands in gcode. These values are not saved in EEPROM by a M500, but they are used until the next print resets them, or until a reboot.

Some code generated by Cura, accel and jerk being enabled :

G1 F2400 E-3
;LAYER_COUNT:60
;LAYER:0
M107
M204 S500
M205 X20 Y20
G0 F3600 X117.053 Y105.081 Z0.1
M205 X8 Y8
;TYPE:SKIRT

Enable accel and jerk control in Cura, set accel and jerk to whatever you like, and then start printing. While the printer is printing, access the Control menu, and have a look to Control/Motion/Acceleration and Control/Motion/Jerk menu items in Marlin : they have been changed according to the G-Code. The G-Code overwrites the values in RAM (but not in EEPROM until a M500)

[EDIT] I clicked on the thumb up by error ! Github allows people to like they own posts !!! :)))))))))) Crazy !

@Liger0
Copy link

Liger0 commented May 18, 2019

If you've tested that a jerk of 10 works better on the Ender 3 we'll change the defaults in Cura and it should work out of the box from then on. Or you could make a PR yourself to change it. I just need you to test it first since I don't have that printer.

The same is valid on the cr10s and even more the cr10.
A jerk of 20 is crazy, the jerk for those machines should be 7-8, which is the standard in the optimized marlin firmwares.

@Ghostkeeper
Copy link
Collaborator

I've made these the defaults. Let's hope that the changes make it work better for everyone! Thanks for testing.

@Ghostkeeper Ghostkeeper added Category: Settings Type: Improvement Improvement to existing functionality. labels May 20, 2019
@yet-another-average-joe
Copy link

yet-another-average-joe commented Jun 12, 2019

@Ghostkeeper , I have a question...

in the json definition file for the Tornado, there is an override :

        "machine_max_jerk_xy": { 
            "default_value": 6 

It has no effect

You added :

		"jerk_print": {
			"default_value":10
		},

And it works !

What is this "machine_max_jerk_xy" ? I've been playing with it and no success. This page did'nt help much : http://files.fieldofview.com/cura/Replacement_Patterns.html

About the jerk and acceleration parameters, the Creality CR10 json file has even more conservative parameters : 500 for all accelerations, 8 for all jerks. (The Tornado is a copy of the CR10). I just discovered this comparing the json files....

This is maybe the reason why people have been recently complaining about Cura on some printers ; before the Tornado json definition file was added, everybody was using the CR10 definition. And this json template profile worked perfectly. And when the Tornado profile came out, some switched to. (I did), whith the useless "machine_max_jerk_xy" override.

I think that the CR10 profile is still the profile to use for the Tornado.

Maybe some json profiles were created using non optimal firmware values, without taking into account the optimizations that came later from the dedicated forums.


{
    "name": "Creality CR-10",
    "version": 2,
    "inherits": "fdmprinter",
    "metadata": {
        "visible": true,
        "author": "Michael Wildermuth",
        "manufacturer": "Creality3D",
        "file_formats": "text/x-gcode",
        "preferred_quality_type": "draft",
        "machine_extruder_trains":
        {
            "0": "creality_cr10_extruder_0"
        }
    },
    "overrides": {
        "machine_width": {
            "default_value": 300
        },
        "machine_height": {
            "default_value": 400
        },
        "machine_depth": {
            "default_value": 300
        },
        "machine_head_polygon": {
            "default_value": [
                [-30, 34],
                [-30, -32],
                [30, -32],
                [30, 34]
            ]
        },
        "layer_height_0": {
            "default_value": 0.2
        },
        "top_bottom_thickness": {
            "default_value": 0.6
        },
        "top_bottom_pattern_0": {
            "default_value": "concentric"
        },
        "infill_pattern": {
            "value": "'triangles'"
        },
        "retraction_enable": {
            "default_value": true
        },
        "retraction_amount": {
            "default_value": 5
        },
        "retraction_speed": {
            "default_value": 40
        },
        "cool_min_layer_time": {
            "default_value": 10
        },
        "adhesion_type": {
            "default_value": "skirt"
        },
        "skirt_line_count": {
            "default_value": 4
        },
        "skirt_gap": {
            "default_value": 5
        },
        "machine_end_gcode": {
            "default_value": "G91\nG1 F1800 E-3\nG1 F3000 Z10\nG90\nG28 X0 Y0 ; home x and y axis\nM106 S0 ; turn off cooling fan\nM104 S0 ; turn off extruder\nM140 S0 ; turn off bed\nM84 ; disable motors"
        },
        "machine_heated_bed": {
            "default_value": true
        },
        "gantry_height": {
            "value": "30"
        },
        "acceleration_enabled": {
            "default_value": true
        },
        "acceleration_print": {
            "default_value": 500
        },
        "acceleration_travel": {
            "default_value": 500
        },
        "jerk_enabled": {
            "default_value": true
        },
        "jerk_print": {
            "default_value": 8
        },
        "jerk_travel": {
            "default_value": 8
        }
    }
}

Also, some overrides sound weird. For example, why the hell is the adhesion type defined on a printer basis ? It is model dependant !

This thread was very instructive. I did'nt understand why my parameters were always reset when switching from one printer to another. (I defined as many printers as I have heads - the poor man's tool changer).

Now I understand, and I can create my own json files ! Great ! And many thanks !

@Ghostkeeper
Copy link
Collaborator

What is this "machine_max_jerk_xy" ? I've been playing with it and no success.

It's what Cura understands to be the maximum jerk setting in the firmware. At the end of the print, Cura will set the jerk back to this value. Cura will also use it to produce more accurate time estimates if Jerk control is disabled.

For example, why the hell is the adhesion type defined on a printer basis ? It is model dependant !

Not entirely. With some build plates you'd really need at least a brim in order to get it to stick to the build plate. I'd say that adhesion type depends most on your material but secondly on the type of build plate your printer has (heated, non-heated, glass, aluminium, etc.)

I think that the CR10 profile is still the profile to use for the Tornado.

Well, if more people agree we can copy some values over from the current CR10 profile.

@yet-another-average-joe
Copy link

yet-another-average-joe commented Jun 13, 2019

Thanks, I understand. And the machine_xxx settings are found in the "Printer Settings" plugin.

In the printer definition file, I put these lines :

        "acceleration_enabled": { "default_value": true },
        "acceleration_print": { "default_value": 500 },
        "acceleration_travel": { "value": 500 },
        "acceleration_travel_layer_0": { "value": 500 },
		
        "jerk_enabled": { "default_value": true },
	"jerk_print": { "default_value": 8 },
        "jerk_travel": { "value": 8 },
        "jerk_travel_layer_0": { "value": 8 },

They preset acceleration and jerk exactly how I ususally tune the slicer, and how many users do for such printers. With these parameters, I never had shifting issues. Note that I removed the shitty Tornado buidtak and replaced it with 2.5mm mirrors and blue tape (I now print mainly PETG).

@Ghostkeeper
Copy link
Collaborator

The buildtak vs. tape thing shouldn't have a lot of influence on the acceleration and jerk settings (maaaaybe if faster movement would pull the print off I guess) so I'll just put those in the defaults for Tevo Tornado.

Ghostkeeper added a commit that referenced this issue Jun 14, 2019
These settings are preventing layer shifts on the Tevo Tornado according to our users at #5694.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Improvement Improvement to existing functionality.
Projects
None yet
Development

No branches or pull requests

7 participants