1. Got a question or need help troubleshooting? Post to the troubleshooting forum or Search the forums!

<<Revamped M565 Z Offset. Set it and forget it!>>

Discussion in 'Mods and Upgrades' started by Austin, Mar 5, 2015.

?

Interested in an offset that is stored in the printer instead of declared in the gcode?

  1. YES!

    40 vote(s)
    88.9%
  2. nahh lame

    5 vote(s)
    11.1%
  1. Mike Kelly

    Mike Kelly Volunteer

    Joined:
    Mar 11, 2013
    Messages:
    6,967
    Likes Received:
    2,275
    I always define my Z offset in Firmware. You can tell what it is on the LCD based off the Z position after homing.
     
  2. Austin

    Austin Team ROBO 3D
    Staff Member

    Joined:
    Aug 8, 2013
    Messages:
    20
    Likes Received:
    7
    @Ziggy I went through and found every instance of the two variables and modified them slightly.

    Im going to upload a detailed changelog tomorrow so you could see exactly what I changed and get a better picture.

    I can't take it to Marlin's GITHUB because it's tailored to the R1 (or any 3D printer with auto level). So here I am.

    @Mike Kelly so what happens when your offset needs adjusting? Do you have to reflash the firmware to change that value?
     
  3. Mike Kelly

    Mike Kelly Volunteer

    Joined:
    Mar 11, 2013
    Messages:
    6,967
    Likes Received:
    2,275
    Correct, but it's not much more difficult to change it in firmware than in the slicer or gcode.

    The plus side is that any time I slice a print it just works.
     
  4. Ziggy

    Ziggy Moderator
    Staff Member

    Joined:
    Feb 20, 2013
    Messages:
    707
    Likes Received:
    530
    Robo firmware is GITHUB Marlin just configured for the Robo. Only addition to Marlin is M565 code handling (which is now in the Marlin development version anyway). So there is no reason not to take your proposed mod to GITHUB
     
  5. Ziggy

    Ziggy Moderator
    Staff Member

    Joined:
    Feb 20, 2013
    Messages:
    707
    Likes Received:
    530
    Mike

    I presume you are changing

    Z_PROBE_OFFSET_FROM_EXTRUDER;

    in configuration.h. If so, that is the zprobe_offset value which can be read, changed and stored via the LCD.
     
  6. Mike Kelly

    Mike Kelly Volunteer

    Joined:
    Mar 11, 2013
    Messages:
    6,967
    Likes Received:
    2,275
    Correct and good to know. Granted I currently have it set to a 50 micron offset. I'll look a little more closely for it.
     
  7. Austin

    Austin Team ROBO 3D
    Staff Member

    Joined:
    Aug 8, 2013
    Messages:
    20
    Likes Received:
    7
    Actually with the R1 stock configuration it can't. The value on the LCD can only range from 0.5 to 50. The zprobe_zoffset value has to be negative. A neggative value can't be achieved with the screens current settings. My firmware fixes this ;)

    @Ziggy @Mike Kelly

    Here is a detailed log of where and why code was changed. If you see any issues please bring them to attention. I'm not trying to be a know-it-all by any means. I make lots of mistakes haha let me know what you think
     

    Attached Files:

    Shigemal likes this.
  8. Mike Kelly

    Mike Kelly Volunteer

    Joined:
    Mar 11, 2013
    Messages:
    6,967
    Likes Received:
    2,275
    Me and Ziggy both use retractable probes for auto leveling so we don't need to worry about any negatives :)
     
    Shigemal likes this.
  9. Ziggy

    Ziggy Moderator
    Staff Member

    Joined:
    Feb 20, 2013
    Messages:
    707
    Likes Received:
    530
    It seems you haven't actually tested this in the Robo firmware. The LCD Z offset value is assumed to be negative in the firmware. The current development version of Marlin makes the same assumption but checks the value as well.

    The limits on the LCD offset menu range is also configurable in the firmware.

    MENU_ITEM_EDIT(float32, MSG_ZPROBE_ZOFFSET, &zprobe_zoffset, 0.5, 50);
     
  10. Austin

    Austin Team ROBO 3D
    Staff Member

    Joined:
    Aug 8, 2013
    Messages:
    20
    Likes Received:
    7
    Ummm yea I tested this. I just tested it right now too. I used my LCD to set my offset. I set it to 6mm. I trusted you were telling the truth and that my nozzle would raise up to 6mm above the probes. My print started. Probed nicely. Then my nozzle ran into the bed and my coupler nuts popped out of place and ripped my endstop wires out as they spun. I can take a video if you don't believe me.

    Have you tested this? @Ziggy Where in the firmware does it assume "zprobe_zoffset" negative. I can't find any absolute value statements in the R1 stock firmware.

    I'll just send my fix to ROBO 3D customer service. I'm sure they'll be nice enough to look it over.
     
  11. Ziggy

    Ziggy Moderator
    Staff Member

    Joined:
    Feb 20, 2013
    Messages:
    707
    Likes Received:
    530
    Austin,

    I use this z probe offset function via the LCD or M565 or firmware configuration.h all the time - it works in the standard Robo firmware.

    If you have made extensive mods to Z offsets handling in the firmware, then the behaviour will be totally different (and possibly wrong).

    When I said it the offset is assumed to be negative, you are required to define the Z Offset configuration.h parameter as negative (for a probe). However this is simply reversed to a positive zprobe_zoffset value when used in Z position calculations.

    To better understand what the developers have done with the Z Probe offset search for

    Z_PROBE_OFFSET_FROM_EXTRUDER and zprobe_zoffset

    in the Robo Marlin code. It is fairly complex and not that easy to see why they have done things the way they have in all cases. Changing the code in one place can have unintended consequences elsewhere.

    And the developers have also changed some of the handling in the latest firmware.
     
  12. Austin

    Austin Team ROBO 3D
    Staff Member

    Joined:
    Aug 8, 2013
    Messages:
    20
    Likes Received:
    7
    I thought you and @Mike Kelly had retractable probes?

    Actually I used a Robo that never had my fixed firmware uploaded to it. Not even once. I downloaded the auto level firmware straight from ROBO 3D's website and flashed it. The only modification I made was to my Z steps because the printer has lead screws. This wouldn't affect anything though.

    Here's a youtube video demonstrating the screen lcd offset not working.

    Excuse the bloody paintjob on this R1

    What more proof do I need to provide? Please tell me honestly.

    [EDIT]
    Just went through Marlin. Z_PROBE_OFFSET_FROM_EXTRUDER is only brought up twice. It only defines the value that "zprobe_zoffset" resets to when a M502 command is seen. I've already checked every instance of the value "zprobe_zoffset" there is nothing else for me to see. When was the last time you took a look at the code? Did you even look at my changelog?
     
    #32 Austin, Mar 11, 2015
    Last edited: Mar 11, 2015
  13. Ziggy

    Ziggy Moderator
    Staff Member

    Joined:
    Feb 20, 2013
    Messages:
    707
    Likes Received:
    530
    No more proof at all. Works as designed.

    You set the LCD Z Offset to 6.65mm. This means the Robo thinks the correct position for the extruder tip is 6.65mm BELOW where the probing tells it the Z home is. And that is what the Robo tried to do when it started printing - it tried to move the extruder tip down.

    And yes, the Marlin developers coded the firmware for auto leveling expecting the Z probe offset parameter in configuration.h and on the LCD to be negative.

    The M565 gcode added by the Robo guys can have positive or negative values for Z offset. Which is one of the reasons I have suggested using M565 Z??.? to set the Z Offset and M500 to store it more permanently in the printer EEPROM.


    Re your edit above

    I'm sure you must have noticed that at the Arduino reset the LCD Z offset value is restored to match the Z_PROBE_OFFSET_FROM_EXTRUDER parameter defined in configuratio.h. This does not need a M502 to be received.

    Suggest you look at what this statement in Marlin_main.cpp setup() does - and it is different depending on whether EEPROM is defined or not.

    // loads data from EEPROM if available else uses defaults (and resets step acceleration rate)
    Config_RetrieveSettings();
     
    #33 Ziggy, Mar 11, 2015
    Last edited: Mar 11, 2015
  14. Austin

    Austin Team ROBO 3D
    Staff Member

    Joined:
    Aug 8, 2013
    Messages:
    20
    Likes Received:
    7
    You were still wrong about the screen. I can't use it for setting my z offset on a stock Robo because my platform will never be BELOW the probing points.

    My firmware fixes this.


    Oh okay let me rephrase that then: ZPROBE_OFFSET_FROM_EXTRUDER only defines what value the 'zprobe_zoffset' resets to when a M502 command is seen or the Config_RetrieveSettings() function is seen when EEPROM_SETTINGS is not defined.

    EEPROM_SETTINGS is defined in my firmware.

    [EDIT]

    EEPROM_SETTINGS isn't defined in the stock firmware. That's why issuing an M565 Z-??.?? then M500 won't store a value in the EEPROM on a stock R1.

    I rest my case.
     
    #34 Austin, Mar 11, 2015
    Last edited: Mar 12, 2015
  15. Ziggy

    Ziggy Moderator
    Staff Member

    Joined:
    Feb 20, 2013
    Messages:
    707
    Likes Received:
    530
    Well we will have to agree to disagree.

    There is no need for your firmware code changes at all. And the coding to remove zprobe_offset removes a very useful function which conflicts totally with what the Marlin developers are doing in future releases and the G code specs. I would certainly not recommend anyone implement your coding changes as they are.

    There is a configuration parameter #define EEPROM which does what you needed to do - set the Z probe offset using M565 and store it using M500. That's what configuration parameters are for. Anyone (well most anyway) can change simple configuration parameters. I guess the Robo guys did not set #define EEPROM because most R1 users will include M565 Z??.? in their start up code and just don't need it

    Alternatively you could have used the standard M206 function to set the Home Offset (and M500 to store it.)

    http://airtripper.com/1799/marlin-firmware-home-offset-guide-using-g-code-m206/


    The LCD Screen Z Offset could also be used as it is when the home is above the bed if you used the Z Home Offset (set by M206) as it was intended to be used.

    Nevertheless, a useful mod would be to allow the LCD Offset value to be set to allow for a Z Home ABOVE the bed as well as below the bed without defining a Z Home Offset. Why not have a go at doing that?
     
    #35 Ziggy, Mar 12, 2015
    Last edited: Mar 12, 2015
  16. Austin

    Austin Team ROBO 3D
    Staff Member

    Joined:
    Aug 8, 2013
    Messages:
    20
    Likes Received:
    7
    But I'm not removing any functionality of the zprobe_zoffset.

    This is what i'm fixing.
    *Z OFFSET is instantly stored on change
    *Z OFFSET can now be changed through the EEPROM window in Repetier or MC
    *Z OFFSET can be positive or negative without affecting outcome
    *Z OFFSET can now be set through screen
    *Z OFFSET will not be reset when there is a “revert to factory settings”
    *Eliminates confusion caused by having multiple z offset values

    If you go through my changelog you'll notice there isn't any loss of functionality when it comes to the 'zprobe_zoffset' value. The only function your losing is the old "add_homeing[2]" variable which isn't necessary at all. I always have this variable set to 0 anyway. If you can prove that my code is actually removing necessary functionality of anything please do so.

    And I can implement this same fix on future versions of Marlin. It's unfair to claim that a future unreleased version of Marlin is conflicting with my code change. Do you have a crystal ball on your desk?

    This code change wasn't made for future versions of Marlin (although its possible that it would work just fine with new releases of Marlin) it was made for the current R1 stock firmware. Not that difficult of a concept to grasp.

    If a new version of R1's firmware is released i'm sure I could implement the same fixes (if they haven't already) but that's a bridge we'll have to cross when we get there.
     
  17. Ziggy

    Ziggy Moderator
    Staff Member

    Joined:
    Feb 20, 2013
    Messages:
    707
    Likes Received:
    530
    Austin,

    Please take your proposed change to the GITHUB Marlin developers. Maybe they will see some value where I don't see any. Maybe they will agree to scrap the gcode M206 functionality as well.

    And I certainly don't need any crystal ball to see what future versions of Marlin will look like. Please download the Marlin development versions for yourself and you can see what they are doing. For example, they have an early version of a function to test the repeatability of the Z Probe bed measurement. They are adding a custom gcode to set the zprobe_offset and putting limits on the max and min value of the zprobe_offset. The developers have also added/modified a "clamp_to_software_endstops" function which uses both Z Home offset and Z probe offset. These are the main reasons why I see conflict with future releases.

    It obvious you have done a fair amount of work on this and you are passionate about it. It works for you and that's what matters. I have also made many mods (and some hacks) for my own use - but I would not recommend others do them all.
     
  18. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    21,421
    Likes Received:
    7,049
    Don't hold your breath.

    You should be working this through the marlin dev group since Robo will consume any way.
    Edit: what Ziggy said ☺
     
  19. Austin

    Austin Team ROBO 3D
    Staff Member

    Joined:
    Aug 8, 2013
    Messages:
    20
    Likes Received:
    7
    Oh I see. I take back my silly "crystal ball" comment haha.

    I'll work on my code and make another version with "slimmer" code changes.

    I'll definitely report the LCD issue to the Marlin's GITHUB but I don't think my other fixes will apply to the standardized Marlin (due to the elimination of "add_homeing[2]" functionality).

    Thanks for your input and constructive criticism @Ziggy . I like bouncing ideas off knowledgeable folk. I'm gonna stick with this fix though! Not the last time you'll be hearing about this ;)
     
  20. Ziggy

    Ziggy Moderator
    Staff Member

    Joined:
    Feb 20, 2013
    Messages:
    707
    Likes Received:
    530
    Austin,

    Do you want to have a go at modding the LCD to allow +/- Z Offset values?

    IMO this would be a very useful mod for Robo owners with either Z probes or Z nut auto leveling. This mod is also very likely to be accepted by the Marlin developers.
     
    mark tomlinson likes this.

Share This Page