Thanks, but I worked around it by sending an M600 E0 L0.
Printable View
If it positions correctly after the G28 & G29 pair... Does it really matter if G28 is goofed up? The reason I'm asking is two fold. First, if you have Auto Bed Leveling working, why would you not want to use it? And the second reason is this: The way G28 and G29 probe points is different. I suspect the G28 is going to evolve and share common code with the G29. If this is true, this annoyance will go away when that happens.
I wanted to get it solved as a backup for the G29. Sometimes I print something tall, tall enough that when the G28 at the start of the next print is moving the Z axis down to home, the X and Y steppers time out, if I forget to rehome all axes before starting the next print. When this happens the G29 does not run. If the G28 gets the nozzle back to the bed as it should, the print may not have to be aborted in these cases.
Can you explain what you mean by the X & Y steppers time out? Does this only happen when the nozzle has to move a long way down after a really tall print? There may be a simple fix for this.
You have:
#define Z_MAX_POS 170
If your Z Print Envelope is bigger than this, bumping this number up will help. The HOMEAXIS(Z_AXIS) routine tells the nozzle to move down:
destination[axis] = 1.5 * max_length(axis) * axis_home_dir;
in it's attempt to find the end stop.
So... If your Z axis is bigger than 255mm (170mm * 1.5), this may be the issue. (Plus the Z axis raises before homing... So you lose that much of the 255mm of travel downward.)
And... I don't think you should be 'forgetting to rehome all the axis before restarting.' It really does make sense to have a G28 and G29 pair in your slicer's startup GCode.
I don't remember now where I saw this, but I read something about G29 will not run if a G28 hasn't been run first, or if the steppers deactivate. I'm still searching for this info so I can show a source. Yes, I only notice this happening when Z homing takes a long time after a tall print, and the X and Y steppers deactivate.
edit: Oh, DUH... it's part of Configuration.h, in the Safe Homing section:
// - Allow Z homing only after X and Y homing AND stepper drivers still enabled
// - If stepper drivers timeout, it will need X and Y homing again before Z homing
Somehow it also affects G29 after the steppers time out. I think because if the steppers turn off, their position is lost, so Marlin doesn't know that they've been homed.
I've upped that to 195. I have an 8 inch i3v, and that's as close as I dare go to the edge. It's probably too close as is, with the 12mm Z-raise.Quote:
You have:
#define Z_MAX_POS 170
I do have G28 and G29 n4 in my Slic3r start code. It's this G28 after a previous tall print that times out the X and Y steppers before the Z homes, and keeps the G29 from running.Quote:
It really does make sense to have a G28 and G29 pair in your slicer's startup GCode.
OK... Understood! The code in the G29 command that keeps the command from running if the X or Y axis isn't homed is this:
// Prevent user from running a G29 without first homing in X and Y
if (! (axis_known_position[X_AXIS] && axis_known_position[Y_AXIS]) )
{
LCD_MESSAGEPGM(MSG_POSITION_UNKNOWN);
SERIAL_ECHO_START;
SERIAL_ECHOLNPGM(MSG_POSITION_UNKNOWN);
break; // abort G29, since we don't know where we are
}
The axis_known_position[] matrix only gets set false a couple of places.
Here is one of the set that is biting you:
#define disable_x() do { WRITE(X_ENABLE_PIN,!X_ENABLE_ON); WRITE(X2_ENABLE_PIN,!X_ENABLE_ON); axis_known_position[X_AXIS] = false; } while (0)
This happens in the manage_inactivity() function.
void manage_inactivity()
{
if(buflen < (BUFSIZE-1))
get_command();
if( (millis() - previous_millis_cmd) > max_inactive_time )
if(max_inactive_time)
kill();
if(stepper_inactive_time) {
if( (millis() - previous_millis_cmd) > stepper_inactive_time )
{
if(blocks_queued() == false) {
disable_x();
disable_y();
disable_z();
disable_e0();
disable_e1();
disable_e2();
}
}
}
The stepper_inactive_time variable is set by default to:
static unsigned long stepper_inactive_time = DEFAULT_STEPPER_DEACTIVE_TIME*1000l;
It can also be over ridden with a M84 command.
Technically, your not inactive, but if it takes too long for the Z Homing to happen, it will look like the steppers have been inactive for a while. You can change that by bumping this number in Configuration_adv.h up. Maybe to 120 ????
#define DEFAULT_STEPPER_DEACTIVE_TIME 60
Testing the time now, just ran Z up to 185, now going to G28 and see how long it takes.
It'll have to be 130, more likely 150, as the switch hit the first time just before 2 minutes.
Well... At least the problem is understood! You can get it to do what you need....
It maybe you can just kick up your Z-Axis feed rate. You must have it set super low.
Well, that problem is understood. The other is still a mystery.