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." 

It slightly increases the print time but saves a lot of hassle especially on moving bed downwards on filament change.

Posted by: @hf1

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. 

Posted by: @hyiger

 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.

Posted by: @mnentwig

No. Logical, yes, as a simple safeguard against running into the nozzle.

Why would the load cell be disabled?

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 :-)

Posted by: @hf1

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".

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.  

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!

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.

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."