[BUG] Core One L Z-travel limited to 21mm
There's a bug in the 6.5.2+12579 C1L firmware which occasionally results in the machine's entire Z-travel being limited to just 21 mm. I just powered-up my C1L this morning, with the bed at the lowest point in its travel. Unfortunately, the machine now recognizes that position as "+21 mm" on Z, so the bed can now only be raised 21 mm off the machine's floor, to a position that it recognizes as "0 mm" -- but which should actually be "+309 mm". This obviously renders the machine useless.
I ran the Z-calibration and Z-test routines yesterday, which might be related.
In the attached image, one can observe the bed's position, and that the machine believes that position to be "0 mm".
- Machine: Core One L
- Firmware Revision: 6.5.2+12579
- Modifications: none
RE: [BUG] Core One L Z-travel limited to 21mm
Rebooting the machine has no effect on the situation. Running the Z calibration routine does fix it, at least temporarily.
RE: [BUG] Core One L Z-travel limited to 21mm
Did you run an auto‑home after powering up the beast?
RE: [BUG] Core One L Z-travel limited to 21mm
Did you run an auto‑home after powering up the beast?
No.
RE:
To elaborate on @kachidoki's post: "Z calibration" is a process you need to run rarely. It drives all Z motors down into the mechanical end stop. The goal is to make sure that the bed is leveled; but it does not define the Z position.
"Auto homing" (which includes homing in X, Y, Z) is a step you need to to every time after powering up the printer. It drives the axes into their "zero position" end stops, which for Z is all the way up where it touches the nozzle. This defines the XYZ positions, which the printer does not store when powered off.
Apologies in case this was all clear and the problem lies elsewhere.
RE: [BUG] Core One L Z-travel limited to 21mm
Thx Jürgen, that's exactly what I meant. 😅 Just a small addition: auto‑homing isn’t strictly mandatory. It is done automatically at the start of every print. You only need it when you want to manually move the axes.
RE: [BUG] Core One L Z-travel limited to 21mm
"Auto homing" (which includes homing in X, Y, Z) is a step you need to to every time after powering up the printer.
Not according to Prusa. The notorious banging around that the machine does before each print is for the purpose of determining its home, and the user only needs to run the manual homing procedure in the event that a homing error is reported.
RE: [BUG] Core One L Z-travel limited to 21mm
"Auto homing" (which includes homing in X, Y, Z) is a step you need to to every time after powering up the printer.
Not according to Prusa. The notorious banging around that the machine does before each print is for the purpose of determining its home, and the user only needs to run the manual homing procedure in the event that a homing error is reported.
Yes, ok -- have you read @kachidoki's clarification in the following post? The homing needs to happen after every power cycle: Either it happens automatically before you start a print. Or you need to trigger it manually if you don't want to run a print (right away), but want to move the printer axes around manually. In either case, the axes don't know where they are, and hence cannot move to defined positions, before the homing has happened.
So maybe this was a situation where, other than you typically do, you did not start a print right away but wanted to move the axes manually? If so, you need to trigger the "auto homing" before.
RE: [BUG] Core One L Z-travel limited to 21mm
Again, not according to Prusa -- with whom I spoke this morning about this issue.
And the machine is clearly able to remember defined positions, since until I ran the Z-calibration earlier today, it was able to remember -- even across a power-cycle -- that the bottom of the Z-travel was "+21mm".
So, with respect, it appears that you may be referring to other machines and/or obsolete information that conflicts with Prusa's current products and instructions.
Regardless of all of that, I was not asking for suggested workarounds to the problem. I had already discovered that running the Z-calibration routine fixes the problem. The point of the post was to report the bug that caused the machine to invent the idea that the bottom of the Z-travel was +21 mm, and not +33x mm as it should be, and as it had been for the preceding several months. From what Prusa Support told me earlier today -- after I posted here -- this bug might already be fixed in the forthcoming firmware release. There have apparently been reports of similar behavior, which are allegedly fixed in the new release. Those fixes might address this bug, as well.
RE: [BUG] Core One L Z-travel limited to 21mm
If you say so... In my experience, every time you power on the printer it assumes all its axes are at "zero", and it only lets you move Z down, to larger coordinates, from there.
Hence, if you power it off at what it currently considers "Z=0" and then back on again, it will again assume to be at Z=0. If that happens to be 21 mm above the base plate, it lets you move down there and calls that Z=21, but does not let you move further up than where it started at power-on.
Anyway, if things are working as expected again for you, that's fine. If you want to report what you consider a bug, it's best to do that on Github; that's where the developers see it. Take Prusa support's "it might be fixed in the next firmware release" with a grain of salt; that may just be their way of saying "and now let's end this call please."
RE: [BUG] Core One L Z-travel limited to 21mm
I cannot say more than @Jürgen. I would have been happy to check this behavior on my One L but it is currently doing a multi-days print. However, neither my One+, XL, MK4S do that, they all three share the same codebase for the firmware, as the One L (the link given by Jürgen just above). I just checked on the One+ to be sure and Z=0 after a reboot as expected. X=252 and Y=-19 after a reboot in my case even when I moved the printhead to the center of the machine. AFAIK it wasn't the case on my MK3S and MK2S neither, but that's not the same firmware nor the same generation.
The only detail I am not sure is that you mentioned this to happen "occasionally". Then it might be a bug hidden or addressed by the auto-homing. I'll try to keep an eye on it during future power-ups. Anyway, this forum is a community place. For technical reports like bugs or feature requests, you must open an issue on Github.
Cheers.
RE: [BUG] Core One L Z-travel limited to 21mm
To @hf1
hat you are describing is not a mistake! And my predecessors did warn you about this fact, according to the truth, but you stubbornly keep yours! The printer does not save the position of the print head anywhere, I repeat nowhere, before turning it off! Try this: After turning on the printer, note down the X,Y,Z positions on paper. Then send the print head to the home position using the "Auto home" command on the display. And then send the print head to any X,Y,Z position. Note this position again. Then turn the printer off and on again. And look at the X,Y,Z data again. And you will find that the data is the same as after the first power-on, but the mechanical position of the print head has not changed and is in the position before power-off! That is why there is the Auto home command, when the print head checks the mechanical limits of the machine and adjusts the X,Y,Z values!
RE:
Sorry, need to back up my colleagues here. This information is wrong. When the power is off the motors are disengaged. You are free to manually move the print head and bed to any position you want. So if even if the printer stored the last X,Y,Z coordinates in the eeprom before power down, those coordinates would be meaningless anyway since the printer doesn't know where the bed and print head are on power up. How could it? There are no encoders to keep track of position when the motors are not locked. The only way to know for sure is to do an auto-home and lock the motors. Then determine positions by step counts.
As @Jürgen pointed out, until you home the printer, the only "safe" direction is down (along the Z axis) until it bottoms out.
RE: [BUG] Core One L Z-travel limited to 21mm
Yes, you need to auto-home before manual controls allow Z-travel up. Intuitive? No. Logical, yes, as a simple safeguard against running into the nozzle.
Isn't it even in the same menu? I use it a lot but it's stored in muscle memory, too lazy now to watch myself twiddling buttons 🙂
RE: [BUG] Core One L Z-travel limited to 21mm
No. Logical, yes, as a simple safeguard against running into the nozzle.
Why would the load cell be disabled?
RE: [BUG] Core One L Z-travel limited to 21mm
Sorry, need to back up my colleagues here. This information is wrong. When the power is off the motors are disengaged. You are free to manually move the print head and bed to any position you want. So if even if the printer stored the last X,Y,Z coordinates in the eeprom before power down, those coordinates would be meaningless anyway since the printer doesn't know where the bed and print head are on power up. How could it? There are no encoders to keep track of position when the motors are not locked. The only way to know for sure is to do an auto-home and lock the motors. Then determine positions by step counts.
I don't know who you are referring to as your colleagues, but I am relating what Prusa Support told me regarding the issue. If that "information is wrong", apparently Prusa has a communication issue along with a potential firmware bug.
With respect to your question, it appears that you are making the assumption that the firmware always endeavors to identify the actual location of the mechanical parts. I'm unsure that that assumption is valid, since there are definitely scenarios where the firmware stores and uses the last "known" position -- which may or may not still be the actual location. If you get right down to it, the firmware can never be absolutely certain of the actual location of the mechanical parts, so again, I question your assumption here.
I understand that you, and several others here, are explaining how the system should work, and even how it is designed to work. The point of reporting a bug is to observe when the implementation differs from design and/or intention, and that is what I have observed with my machine. Again, per my conversation with Prusa Support, my understanding of how the machine is supposed to function in this respect comports with theirs, but it does not operate in that manner. If they are wrong, that is not anything which I can correct.
RE:
I understand that you, and several others here, are explaining how the system should work, and even how it is designed to work. The point of reporting a bug is to observe when the implementation differs from design and/or intention, and that is what I have observed with my machine. Again, per my conversation with Prusa Support, my understanding of how the machine is supposed to function in this respect comports with theirs, but it does not operate in that manner. If they are wrong, that is not anything which I can correct.
This is not a bug. It's correct behavior. Just go up one menu level, run Auto Home. Then you can move the Z axis where ever you wish. The entire point of auto homing is so that the firmware can determine the position of the printhead relative to the bed.
RE: [BUG] Core One L Z-travel limited to 21mm
You can add auto home gcode to the start gcode section of the print in the PrusaSlicer. Just add G28 just before any print moves.
It slightly increases the print time but saves a lot of hassle especially on moving bed downwards on filament change.
See my GitHub and printables.com for some 3d stuff that you may like.
RE:
The point of reporting a bug is to observe when the implementation differs from design and/or intention, and that is what I have observed with my machine.
What you have observed is an implementation which differs from your expectation.
You seem unwilling to adjust the latter, despite a handful of people having tried to explain to you how the printer behaves, and why. Hence I am inclined to take Prusa support's approach: "It may change with the next firmware release. Please let's end the dialog now."