Z-Min for Park Position

Could someone please explain the effect of the Z-Min value for the Park Position in printer settings. The online documentation doesn't seem to say anything about it either.

I've set it to a couple of different values but when I press the Park button in Manual Control it only seems to affect the X & Y positions.

Edited 1 time(s). Last edit at 01/25/2013 05:44AM by buildrob.

For some printer the z axis can be quite dangerous, therefore special caution is taken when it comes to that axis.

If you go to park position, z-min is the minimum height you want to have when the job is finished. So it only goes to z-min if:

a) you homed the z-axis (z coordinates are shown black)
b) your print was lower then z-min
c) you z-min is lower the z-max for your printer.

If any of these conditions is violated, the z-change is ignored.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Thanks for the reply Marcus. Ok I see the problem. So my printer's build area height is 200mm.

I was initially guessing that Z-min had some effect like that.... so I set Z-min to 200 and hit the Park button. My expectation (which I think is reasonable) is that it would raise the printer all the way up. But it did nothing (hence posting this request for info).

If I set the Zmin to 199 (after reading this) it did work as I expected.

Can I suggest you change the last condition (c) in the Zmin logic to "your z-min is lower than or equal to the print area height".

Three other suggestions:

- "Stop motors" is a misleadingly named button. When I pressed the "Stop motors" button in Manual Control when it had queued movement commands to the printer I expected that it would stop the printer movement, e.g., like a non-emergency stop. So I was surprised when it did not actually have any effect on the movement of the motors (i.e., it didn't stop the motors when it had queued movement commands)). I was going to report it as a bug until I looked up up the actual effect of M84 command. I think "Turn off motors" would be a much clearer label (as the button has nothing to do with "stopping" movement as you initially think).

- It might also be a good idea that the XYZ positions should also go red after pressing the "Stop Motors" button (i.e., they should be rehomed). Most common reason to stop the motors would be to move them manually - in which case the firmware gets confused about its position.

- I noticed after homing the Z-axis if I repeatedly pressed the Z+ button (I was trying to get the Z axis to the maximum limit) then it actually exceeded the maximum build height. The z position went red after 200mm but kept incrementing. The printer luckily hit a firmware Zmax limit before hitting the top of the frame (but then the entire printer had to be reset). Interestingly if I only incremented the printer in (say) 5 x 10mm steps at the time then it enforced the build height limit at 200mm. It only ignored the build height limit if I overflowed some queued command limits (e.g., by pressing the Z+ 10mm button lots of times in a row).

Did you want me to raise a github issue for any of the above issues?

Edited 2 time(s). Last edit at 01/26/2013 12:27AM by buildrob.

buildrob Wrote:
-------------------------------------------------------
> Thanks for the reply Marcus. Ok I see the problem.
> So my printer's build area height is 200mm.
>
> I was initially guessing that Z-min had some
> effect like that.... so I set Z-min to 200 and hit
> the Park button. My expectation (which I think is
> reasonable) is that it would raise the printer all
> the way up. But it did nothing (hence posting this
> request for info).
>
> If I set the Zmin to 199 (after reading this) it
> did work as I expected.
>
> Can I suggest you change the last condition (c) in
> the Zmin logic to "your z-min is lower than or
> equal to the print area height".
>
Yes, fixed for next release.

> Three other suggestions:
>
> - "Stop motors" is a misleadingly named button.
> When I pressed the "Stop motors" button in Manual
> Control when it had queued movement commands to
> the printer I expected that it would stop the
> printer movement, e.g., like a non-emergency stop.
> So I was surprised when it did not actually have
> any effect on the movement of the motors (i.e., it
> didn't stop the motors when it had queued movement
> commands)). I was going to report it as a bug
> until I looked up up the actual effect of M84
> command. I think "Turn off motors" would be a much
> clearer label (as the button has nothing to do
> with "stopping" movement as you initially think).
>
I see what you mean. What you wanted was the pause button in the toolbar. Renamed it for the next release for less confusion.

>
> - It might also be a good idea that the XYZ
> positions should also go red after pressing the
> "Stop Motors" button (i.e., they should be
> rehomed). Most common reason to stop the motors
> would be to move them manually - in which case the
> firmware gets confused about its position.

That is useless. It is one example where you move the head manually, so you know it is invalid. The most obvious reason to turn motors off is silence. Depending on the position I can hear the motors. In addition most firmwares have enabled a deleyed motor stop which is also unknown to the host. So I prefer to assume the printer doesn't move only because the motors are off. You should home any axis before a new print anyway. I put this in my start code along with pre heat and refill off extruder.


>
> - I noticed after homing the Z-axis if I
> repeatedly pressed the Z+ button (I was trying to
> get the Z axis to the maximum limit) then it
> actually exceeded the maximum build height. The z
> position went red after 200mm but kept
> incrementing. The printer luckily hit a firmware
> Zmax limit before hitting the top of the frame
> (but then the entire printer had to be reset).
> Interestingly if I only incremented the printer in
> (say) 5 x 10mm steps at the time then it enforced
> the build height limit at 200mm. It only ignored
> the build height limit if I overflowed some queued
> command limits (e.g., by pressing the Z+ 10mm
> button lots of times in a row).
>

I know what you mean but the problem is not solvable at the moment. Moves are limited depending on current position or to be more precisely the last position send to the printer. The host does not know anything about queued commands and the possible displacement resulting of it. It gets even worser if you knew that there are 2 queues. One for the running job and one for manual commands where the manual commands have priority. In such cases you never know for sure which job commands get executed before your manual command.

> Did you want me to raise a github issue for any of
> the above issues?

No, fixed everything I would fix.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

No worries. Thanks for explaining the situation. Great work.

One response ...

repetier Wrote:
> I see what you mean. What you wanted was the pause
> button in the toolbar. Renamed it for the next
> release for less confusion.

I don't feel that you need an extra "Pause Button" - just that the "Stop motors" button didn't do what its name suggested (to me). Renaming it should be fine.