Close



Results 1 to 6 of 6

Threaded View

  1. #4
    Super Moderator Roxy's Avatar
    Join Date
    Apr 2014
    Location
    Lone Star State
    Posts
    2,182
    Quote Originally Posted by Geoff View Post
    Auto level is on, Sorry, I should have included the G29 in my list , yes I run the G29 after the G28, however the G29 on the kossel simply does an autolevel check and retract, so its good for calibrating the Z probe retract but other than that it doesnt give me settings I can use for the actual Z height.

    @MK-X I did yes, but I will double check. There is a couple of spots I notice the autoprobe drags on the bed a little, so I think that might be it, I will double check again.
    As it turns out... BrainScan went through a similar hair pulling debug session starting about here:

    http://3dprintboard.com/showthread.p...ll=1#post19007

    I don't know if this is what is causing your problems, but the big problem is the M503 command fails to report everything that is happening after reset on the Arduino.

    Do you have the EEPROM turn on? Because if you do, you could have a bad value for the Z-PROBE-OFFSET stored in the EEPROM and you won't know it. It won't matter what you change the Configuration.h setting to, it will use the value out of EEPROM. Probably, the simplest suggestion is turn off the EEPROM chit chat until you get everything else running. But if you need it, you can do a M502 and a M500 to restore default (Configuration.h) settings and store them. The problem with doing this, is now the Configuration.h settings will be ignored unless you do the M502 & M500 pair. With that said... That might be what you are fighting right now. If somehow a bad number for the Z-PROBE-OFFSET got stored, it doesn't matter what you set things to in the Configuration.h file. You will need to do a M502 & M500 to load the compiled default values and store them.

    At post #58 in the thread we finally get confirmation that was what was keeping him from setting his Z-PROBE-OFFSET in Configuration.h (See the previous post for the analysis)

    http://3dprintboard.com/showthread.p...ll=1#post19319

    And that is why there is an EEPROM Invalidate command provided in Post # 75:

    http://3dprintboard.com/showthread.p...ll=1#post20943
    Last edited by Roxy; 08-27-2014 at 08:37 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •