Auto_Bed_Leveling: Enhanced G29 command

[Roxy]

Does anyone have any idea why my Y axis moves a small distance during the "Z lift before homing"? Is the firmware trying to ensure that the Z probe is over the bed instead of in the air? This has been offsetting my Y axis by 10-15 mm each time, making it more likely a large print would go off the other side.

It would be helpful for you to post your Configuration.h file. It might have something to do with the Z_SAFE_HOMING stuff:

//If you have enabled the Bed Auto Leveling and are using the same Z Probe for Z Homing,
//it is highly recommended you let this Z_SAFE_HOMING enabled!!!

#define Z_SAFE_HOMING // This feature is meant to avoid Z homing with probe outside the bed area.
// When defined, it will:
// - 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
// - Position the probe in a defined XY point before Z Homing when homing all axis (G28)
// - Block Z homing only when the probe is outside bed area.

#ifdef Z_SAFE_HOMING

#define Z_SAFE_HOMING_X_POINT (X_MAX_LENGTH/2) // X point for Z homing when homing all axis (G28)
#define Z_SAFE_HOMING_Y_POINT (Y_MAX_LENGTH/2) // Y point for Z homing when homing all axis (G28)

#endif

[AbuMaia]

Here you go. I have safe homing turned off. Maybe part of it is still active? Edit: I connected to Pronterface, homed all axes and watched as the Y axis moves while Z axis lifts before extending the probe. Once homing had completed, I manually moved the Y axis (via Pronterface) to see just how far it had moved. Since the Y move during Z lift didn't change the Y axis position (it was still considered at "home", position 0), the Y endstop switch didn't register when in negative coordinates, so I counted until I heard the click. It was 10mm. Interestingly enough, the RRD SmartController LCD doesn't do negative numbers, it went through symbols instead.

[Roxy]

Everything looks pretty reasonable in the Configuration.h file. Can you try doing an M502 followed by a M500 to insure we are using the Configuration.h settings. And see if it still does the same thing. Are you running the Enahnced G29 code at the start of this thread?

[AbuMaia]

If you scroll down a bit, you'll see I have the EEPROM turned off as well, but I'll put in those M codes when the current print is finished. Yes, I've added the Enhanced code to the firmware already. Edit: I just did the M502 followed by M500, then homed all axes. Y axis still moves during Z lift. I feel I should note the Y axis doesn't move with every Z movement, only during the "Z lift before homing".

[Roxy]

Yes, I saw the EEPROM chit chat was turned off. But I want to make sure the EEPROM actually matches the current configuration.h just in case the wrong EEPROM image is loaded.

What is your schedule like? Is there a 4 or 5 hour block of time you can be at your machine and printer so we can do this without a day in between each response?

You are still failing to answer the question: Are you running the 'Enhanced G20 Bed Leveling Code' ?

[AbuMaia]

I did already answer your question, before the edit. Yes, I'm running the enhanced code. I'll be available tomorrow after 12 noon mountain time.

[brucehvn]

I did already answer your question, before the edit. Yes, I'm running the enhanced code. I'll be available tomorrow after 12 noon mountain time.

What I don't think I saw in the conversation was whether you were using the auto bed leveling code before adding Roxy's enhancements and if so, did the problem exist then?

[AbuMaia]

Yes, I was using auto bed levelling before I added the enhanced code. No, the Y axis movement is not a bug of the enhancement code.

[Roxy]

I did already answer your question, before the edit. Yes, I'm running the enhanced code. I'll be available tomorrow after 12 noon mountain time.

OK. Is it possible to do a quick video of the behavior? That would be helpful, but I understand if you can't make that happen. How about you post your Marlin_main.cpp file also. At worst case, I can build your firmware and see if I can duplicate the behavior.

One way or the other, we will skin this cat. Hopefully, it goes quickly.

[AbuMaia]

OK. Is it possible to do a quick video of the behavior?

Video is uploading. It will be at http://youtu.be/H1fGJysek4M when it's done.

Here is my Marlin_main.cpp.