Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
I recently added a second z-axis stepper and leadscrew to my Ender 3 Pro, and I also replaced the motherboard with a Bigtree-tech SKR Mini E3 V2.0.
When I try to print now, models sliced with Prusaslicer 2.5 hardly move up at all during the print. The display on the printer shows that the layer height is being increased as requested, but the z-axis hardly moves. Eventually the extruder starts skipping because it has not moved up enough to have room to push filament out. If I control the z-axis manually from the menu, the z-axis moves up correctly, so I know that I don't have issues with binding, wiring, voltage/current, or steps/mm. I have tried setting the G-code flavor to both Marlin 2 and Marlin (legacy) with the same results.
I sliced the same model using Cura 4.10 and it prints perfectly.
SPECS:
- Ender 3 Pro
- Bigtree-tech SKR Mini E3 V2.0
- Latest firmware from Bigtree-tech from github
- Marlin 2.0.8.2.x
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
Have you tried changing your z axis acceleration in the PS machine settings ? If your lcd commands work, and the lcd layers display correctly when printing a file from PS (so its being commanded to move the correct distance from the gcode) then that pretty much leaves the machine not doing the commanded action for some reason.
If you tell it to move too fast and it cant then it will think its higher than the motors managed to move it. That would be my fist thing to check.
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
Just had another thought, your installed firmware on the BigTree does support the sending of numbers without the leading zeroes doesnt it ? PS was updated to trim them so it now sends E.8 rather than E0.8, same for all the axis. At the start of a print the numbers for X/Y and generally E are all big numbers so all have something proceeding the decimal. Except Z of course which will be Z.28 or whatever for your layer height.
Not sending the 0 is valid g-code but I recall that there was several issues raised on github when the change happened as some firmware dont work without them. They should though as its valid.
You could do some hand edited gcode that does your start routine and then raises up to say G1 Z10 and then extrudes G1 E10, then Moves to Z20 and extrudes E.99. That way you can test if the firmware supports the missing leading zeroes as it should go to Z10, extrude 10mm of filament, then go to Z20 and extrude just under 1mm. If it doesnt extrude at Z20 then you will know.
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
Have you tried changing your z axis acceleration in the PS machine settings ? If your lcd commands work, and the lcd layers display correctly when printing a file from PS (so its being commanded to move the correct distance from the gcode) then that pretty much leaves the machine not doing the commanded action for some reason.
If you tell it to move too fast and it cant then it will think its higher than the motors managed to move it. That would be my fist thing to check.
My accelerations are actually set to about 1/2 of the machine limits right now.
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
Just had another thought, your installed firmware on the BigTree does support the sending of numbers without the leading zeroes doesnt it ? PS was updated to trim them so it now sends E.8 rather than E0.8, same for all the axis. At the start of a print the numbers for X/Y and generally E are all big numbers so all have something proceeding the decimal. Except Z of course which will be Z.28 or whatever for your layer height.
Not sending the 0 is valid g-code but I recall that there was several issues raised on github when the change happened as some firmware dont work without them. They should though as its valid.
You could do some hand edited gcode that does your start routine and then raises up to say G1 Z10 and then extrudes G1 E10, then Moves to Z20 and extrudes E.99. That way you can test if the firmware supports the missing leading zeroes as it should go to Z10, extrude 10mm of filament, then go to Z20 and extrude just under 1mm. If it doesnt extrude at Z20 then you will know.
IDK the answer to this, but it is something I could try.
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
Could you post the startup code:
wbr,
Karl
Statt zu klagen, dass wir nicht alles haben, was wir wollen, sollten wir lieber dankbar sein, dass wir nicht alles bekommen, was wir verdienen.
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
Just had another thought, your installed firmware on the BigTree does support the sending of numbers without the leading zeroes doesnt it ? PS was updated to trim them so it now sends E.8 rather than E0.8, same for all the axis. At the start of a print the numbers for X/Y and generally E are all big numbers so all have something proceeding the decimal. Except Z of course which will be Z.28 or whatever for your layer height.
Not sending the 0 is valid g-code but I recall that there was several issues raised on github when the change happened as some firmware dont work without them. They should though as its valid.
You could do some hand edited gcode that does your start routine and then raises up to say G1 Z10 and then extrudes G1 E10, then Moves to Z20 and extrudes E.99. That way you can test if the firmware supports the missing leading zeroes as it should go to Z10, extrude 10mm of filament, then go to Z20 and extrude just under 1mm. If it doesnt extrude at Z20 then you will know.
I thought you might be on to something, but now I'm not sure.
First, I printed a 25 mm cube (hollow with no top) sliced by PS v2.5 without changing the g-code for the z moves (default conditions). This one ended up being 16.86 mm instead of 25.04 mm. Again, the walls were thicker than they should have been and the part was mashed outwards. I find this very interesting because one would think that if the issue lies solely with the dropped initial 0 on the z moves that at the worst the cube would only be about 1mm short, as every move after 0.84 mm comes with a preceding non-zero digit.
Next, I had noticed that Cura uses G0 commands for z-axis moves instead of G1. Based on that, I took that default file and replaced all of the z-axis G1 moves with Go. This did nothing to help. My 25mm cube ended up 5.19mm when measured, despite the display showing it ended at 25.04mm. The walls were much thicker than they should have been and the part was mashed outwards due to the repeated layers being laid down with almost no changes in z height.
I then changed the g-code for the first 4 layers (z=0.24, 0.44, 0.64, and 0.84) so that they had initial zeroes (i.e. the default G1 z.24 became G1 z0.24). The first time I printed this version it seemed to make a huge difference. It ended up being 24.82 mm tall. However, I printed it again and the second time it was only 15.00 mm tall.
On all of the above, I often heard the extruder skipping. I was only going 30 mm/s max printing speed, 0.20 layer height and a 0.6mm nozzle, so this should not have been happening. It has to be because the layers were barely changing height so the filament had no room to extrude.
I also sliced the same model in Cura, still using an initial layer height of 0.24 and subsequent layers of 0.20. This came out at 24.91 mm tall, and at no point did the extruder skip.
These tests don't appear to pinpoint the problem to a lack of initial zeroes on the z-axis moves, although the one result that was 24.62 mm tall might indicate that the missing zeroes are partially to blame.
RE:
Could you post the startup code:
wbr,
Karl
As requested. Highlighted text is what is in my start G-code. The rest is generated by PS.
If you click on the picture a little more code will be displayed than the preview shows.
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
If you attach a zipped up project file (3mf) then it will contain EVERY setting that people can then examine as needed.
I wouldn't worry about the skipping extruder at the moment. I think you are right if the z isn't raising up then there wont be enough gap to properly extrude filament so skipping is not surprising.
What I would like to see besides a zipped project file from slicer is the actual gcode file from Cura that prints successfully for comparison. With the project we can generate the PS gcode anyway.
RE:
If you attach a zipped up project file (3mf) then it will contain EVERY setting that people can then examine as needed.
I wouldn't worry about the skipping extruder at the moment. I think you are right if the z isn't raising up then there wont be enough gap to properly extrude filament so skipping is not surprising.
What I would like to see besides a zipped project file from slicer is the actual gcode file from Cura that prints successfully for comparison. With the project we can generate the PS gcode anyway.
As requested.
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
Thanks for the files mkoic.
One thing that I immediately noticed between the gcode output of Cura and PS that is probably VERY relevant to your problem is the Z axis feedrates. Every single layer height change in Cura is basically the following
G0 F300 X129.663 Y129.663 Z11.24 - this is basically a non printing move with the feedrate set at 300 mm a minute. The X/Y coordinates dont change from the previous line so only the Z is actually moving.
Compare that to the code from PS
G1 Z11.24 F6000 - ignoring the G0/G1 difference as PS doesnt use G0 the feedrate is 6000 mm per minute. Theres a fair bit of difference between 300 and 6000 lol. 20x as fast. I believe that may the the root cause of your problem. Your z axis literally cant go at the speeds you have set in PS.
What Im not sure of yet is why its using F6000 as the Z feedrate is set to 12 mm per second which should then equate to 720 mm per minute. I suspect its using the normal travel feedrate defined in the Print Profile. That is set at 100mm/s which is 6000 mm per minute. The thing is the settings sent at the start of the gcode to the printer using the M203 command should be limiting it to Z12 regardless of what the rest of the gcode contains. Unless the firmware on your new board is ignoring those. Prusa has a habit of relying on the firmware to act as a global brake once they are set and doesnt actually check the ones it generates are lower than the machine limits. Unfortunately that means they are relying on whoever has implemented the firmware for a machine actually doing a good job and complying with all the spec. They should, so technically its not a PS problem but that doesn't help you.
In your print settings profile under Speed>Speed for non Print Moves>Z travel set that to 12 (or lower). That will then force the Z moves to have a feedrate of 720 for those height changes. I would have thought your machine could cope with that. If not then 5 would give you the 300 to match Cura. You might have to experiment a little.
Anyway give that a try and report back.
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
Thanks for the files mkoic.
One thing that I immediately noticed between the gcode output of Cura and PS that is probably VERY relevant to your problem is the Z axis feedrates. Every single layer height change in Cura is basically the following
G0 F300 X129.663 Y129.663 Z11.24 - this is basically a non printing move with the feedrate set at 300 mm a minute. The X/Y coordinates dont change from the previous line so only the Z is actually moving.Compare that to the code from PS
G1 Z11.24 F6000 - ignoring the G0/G1 difference as PS doesnt use G0 the feedrate is 6000 mm per minute. Theres a fair bit of difference between 300 and 6000 lol. 20x as fast. I believe that may the the root cause of your problem. Your z axis literally cant go at the speeds you have set in PS.What Im not sure of yet is why its using F6000 as the Z feedrate is set to 12 mm per second which should then equate to 720 mm per minute. I suspect its using the normal travel feedrate defined in the Print Profile. That is set at 100mm/s which is 6000 mm per minute. The thing is the settings sent at the start of the gcode to the printer using the M203 command should be limiting it to Z12 regardless of what the rest of the gcode contains. Unless the firmware on your new board is ignoring those. Prusa has a habit of relying on the firmware to act as a global brake once they are set and doesnt actually check the ones it generates are lower than the machine limits. Unfortunately that means they are relying on whoever has implemented the firmware for a machine actually doing a good job and complying with all the spec. They should, so technically its not a PS problem but that doesn't help you.
In your print settings profile under Speed>Speed for non Print Moves>Z travel set that to 12 (or lower). That will then force the Z moves to have a feedrate of 720 for those height changes. I would have thought your machine could cope with that. If not then 5 would give you the 300 to match Cura. You might have to experiment a little.
Anyway give that a try and report back.
Thanks, Neophyl. I'm at work now so I'll check later this evening. One thing to note is that when I upgraded to V2.5 I did not change any of my machine limit settings, so I'm assuming that they are the same as they used to be before the upgrade. Regardless, I'll try what you suggest and report back. Thanks for taking the time to work through this with me.
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
If your original boards firmware was using the M203 X500 Y500 Z12 E120 ; sets maximum feedrates, mm / sec line from the gcode properly then even if the later gcode used a feedrate of F6000 or even F1000000 then the firmware itself would have capped it to F720. That would all be handled by the board itself.
If your new board isn't doing that capping and just accepting the F6000 rate then yeah it would have worked before and have problems now. The contents of the gcode wouldn't be different.
Prusa really should start actually using those machine limit values to check the ones inserted into the generated code as it would be an extra layer of protection. They don't and have never done so. I think because not all of the gcode flavours actually use those machine settings over rides. They arent really integrated into the slicing, they are more appended at the start for machine use if the option is selected.
Anyway even though its not my machine I'm really really hoping that this sorts out your problem.
Dont you hate it when work gets in the way of a good hobby 🙂
RE: Z-axis not working correctly Prusa 2.5 with Ender 3 Pro
If your original boards firmware was using the M203 X500 Y500 Z12 E120 ; sets maximum feedrates, mm / sec line from the gcode properly then even if the later gcode used a feedrate of F6000 or even F1000000 then the firmware itself would have capped it to F720. That would all be handled by the board itself.
If your new board isn't doing that capping and just accepting the F6000 rate then yeah it would have worked before and have problems now. The contents of the gcode wouldn't be different.
Prusa really should start actually using those machine limit values to check the ones inserted into the generated code as it would be an extra layer of protection. They don't and have never done so. I think because not all of the gcode flavours actually use those machine settings over rides. They arent really integrated into the slicing, they are more appended at the start for machine use if the option is selected.
Anyway even though its not my machine I'm really really hoping that this sorts out your problem.
Dont you hate it when work gets in the way of a good hobby 🙂
Looks like success this evening!
z travel = 12 mm/s was still too much, but 5 mm/s was the charm. I printed two cubes and both were 24.92 mm tall, then I printed another small part and that came out perfectly.
So what I think I’ve learned is:
1. Trying to move too fast results in moves not happening at all, or at least with much smaller than expected results.
2. The firmware for my board/printer combo does not ensure that max speed limits are adhered to.
3. PS doesn’t babysit the firmware. It expects the firmware to do its job.
4. At least for my setup, the dropped initial zeroes on move commands don’t have a negative effect.
Thanks for the help and recommendations for troubleshooting this issue. It was a frustrating problem to run into, but I learned something and in the end it was all fairly painless.