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
Comments
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. |
Tried it, did not work. |
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. |
Is it known when version 4.1 will be released? |
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 |
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. |
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) 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 ? |
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! |
Thanks for teh quick ! I launch download ! |
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 |
Reading your Git, I understand you work on algorithms only. It's about the UI... |
Reading your Git, I understantd you work on algorithms only. It is about UI. |
Yes, I don't work on the UI, just the slicer itself. |
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. |
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. |
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 :
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 ! |
The same is valid on the cr10s and even more the cr10. |
I've made these the defaults. Let's hope that the changes make it work better for everyone! Thanks for testing. |
@Ghostkeeper , I have a question... in the json definition file for the Tornado, there is an override :
It has no effect You added :
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.
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 ! |
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.
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.)
Well, if more people agree we can copy some values over from the current CR10 profile. |
Thanks, I understand. And the machine_xxx settings are found in the "Printer Settings" plugin. In the printer definition file, I put these lines :
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). |
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. |
These settings are preventing layer shifts on the Tevo Tornado according to our users at #5694.
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.
The text was updated successfully, but these errors were encountered: