Brain wobble: z 0 adjustment



  • I am rather embarrassed to admit this but I am drawing a blank on a very very basic issue. I replaced a thermal break and as a result my nozzle is a bit lower than it was before. No problem I say, I just adjust my probe offset in config.g.
    The command I changed was this:
    G31 P25 X-12 Y-28 Z1.0
    I adjusted the Z value.
    For reasons unknown to me, there seems to be no change in the nozzle position for Z0. I also tried Z-1.0 and there seems to be no change.
    In either case, I need to babystep the head up by 1 mm to be at the proper Z level for my first layer.
    I am obviously forgetting something rather basic or am adjusting the wrong offset or what have you. In any case - help ... please ....



  • Replying to my own post, I found this line in config-overwrite.g:

    G31 K0 P25 X-12.0 Y-28.0 Z4.50

    So, it seems like the G31 in config.g is just an initial setup and is adjusted again on config-overwrite.g.
    I don't understand why I would have that line in two places but such be life.
    I will now go and tweak again to see if I can adjust things in config-overwrite.g (and to beat myself up for not finding this before posting my question)



  • Yup, that was the problem 😞



  • @jens55 said in Brain wobble: z 0 adjustment:

    Yup, that was the problem 😞

    I'm one of those folks who don't like using config-override.g

    Whenever I do something that may have updated the info in that file I move it into config.g

    And I don't have M501 in config.g.

    I am also not aware of anything that would have put G31 into config-override.g

    Frederick



  • Yeah, I have no idea what possessed me to put G31 and G10 commands in there. I now have great big flags in config.g pointing this out for any future occasion.
    I don't know how many months it's been since I last changed the z offset but it must be getting onto a year now.

    This is also why I don't particularly like how some other things are handled. Maybe things have changed but there should really be fixed parameters such as speed and acceleration so that when a parameter is overwritten in a macro, let's say for probing, you can go and undo the changes at the end of your macro. This of course avoids unintended consequences of changes in one place that are then carried into other places.
    Again it's been a while since I mucked around with that and maybe it is now possible to undo temporary changes.



  • @jens55 Like @fcwilt , that's why I don't use config_override.g either. Having settings in more than one place will always bite one in the ar*e sooner or later. And as you say, changing settings in macros can also lead to problems unless one is very careful to always restore whatever was changed back to the config.g value at the end of said macro.

    Another pet hate of mine (although other people love it) is allowing slicers to change things like acceleration and jerk settings. The problem being that, at the end of a print, those values will be whatever the slicer last set them to be, rather than what one might have in one's configuration file. Therefore, if one allows the slicer to override the acceleration values, then one must always print gcode files which have slicer generated acceleration settings embedded in them and never rely on what is in config.g. Otherwise one will end up with settings in two different places. Personally I prefer to only use config.g for all such settings.



  • @deckingman said in Brain wobble: z 0 adjustment:

    Another pet hate of mine (although other people love it) is allowing slicers to change things like acceleration and jerk settings.

    I'm with you on that one - 100,000% - if that's even possible. 😉

    Frederick



  • @deckingman said in Brain wobble: z 0 adjustment:

    Another pet hate of mine (although other people love it) is allowing slicers to change things like acceleration and jerk settings. The problem being that, at the end of a print, those values will be whatever the slicer last set them to be, rather than what one might have in one's configuration file. Therefore, if one allows the slicer to override the acceleration values, then one must always print gcode files which have slicer generated acceleration settings embedded in them and never rely on what is in config.g. Otherwise one will end up with settings in two different places. Personally I prefer to only use config.g for all such settings.

    I never even considered that .... I always print via Cura so it (I hope) eliminates that as a problem.

    So talking about setting speed acceleration and jerk - I just looked at my probing macros and the way I handle things is I set new values, and then, when I restore the old values, I set the actual value of what is in config.g. The problem with that is that if I change config.g, all of theses other files will restore values to the wrong parameters (what USED to be in config.g and not what IS in config.g).
    This was set up before variables was a thing and I don't know what the status is of that at the moment.
    If someone has an example of how they handle this issue it would be a good time to fix this rather than wait for the next time I wonder why the heck the parameters are different from what config.g is setting them.



  • @jens55 said in Brain wobble: z 0 adjustment:

    If someone has an example of how they handle this issue it would be a good time to fix this rather than wait for the next time I wonder why the heck the parameters are different from what config.g is setting them.

    I have created numerous .g files in the sys directory that I call as needed.

    So, just as a simple example, you could have a couple of files called

    • stepper_settings_default.g
    • stepper_settings_special.g

    So from config.g and anywhere else you can call stepper_settings_default.g.

    And when you need the other settings you can call stepper_settings_special.g.

    Frederick



  • @fcwilt , that is an excellent idea! Thanks !



  • @jens55 I call a macro in my slicer's start gcode to set G31 & M207.

    PLAOffset macro, for example:
    M291 P"PLA Offset" S0 T5 ; make sure the right on is called
    G31 P500 X0 Y-60 Z3 ; set threshold and offsets - z offset is last one - increase to get closer to the bed
    M207 S1.5 F6000 R0 Z0.03 ; firmware retraction



  • @fcwilt said in Brain wobble: z 0 adjustment:

    @jens55 said in Brain wobble: z 0 adjustment:

    If someone has an example of how they handle this issue it would be a good time to fix this rather than wait for the next time I wonder why the heck the parameters are different from what config.g is setting them.

    I have created numerous .g files in the sys directory that I call as needed.

    So, just as a simple example, you could have a couple of files called

    • stepper_settings_default.g
    • stepper_settings_special.g

    So from config.g and anywhere else you can call stepper_settings_default.g.

    And when you need the other settings you can call stepper_settings_special.g.

    Frederick

    That's a great idea!


  • Moderator

    @deckingman said in Brain wobble: z 0 adjustment:

    Another pet hate of mine (although other people love it) is allowing slicers to change things like acceleration and jerk settings.

    I make use of those slicer jerk and accel settings to great effect. If the firmware allowed for separate values on a per move basis I wouldn't need to, but only the slicer is really aware of what type of print move is happening. I consider it just another application of on the fly gcode configuration.


  • Moderator

    @jens55 said in Brain wobble: z 0 adjustment:

    Replying to my own post, I found this line in config-overwrite.g:
    G31 K0 P25 X-12.0 Y-28.0 Z4.50

    At some point you would have had to have sent M500 P31 to save a measured trigger height.

    https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M500_Store_parameters



  • @Phaedrux said in Brain wobble: z 0 adjustment:

    @deckingman said in Brain wobble: z 0 adjustment:

    Another pet hate of mine (although other people love it) is allowing slicers to change things like acceleration and jerk settings.

    I make use of those slicer jerk and accel settings to great effect. If the firmware allowed for separate values on a per move basis I wouldn't need to, but only the slicer is really aware of what type of print move is happening. I consider it just another application of on the fly gcode configuration.

    I know you do (let the slicer set the acceleration settings). But you either didn't read the entire paragraph, or you chose to ignore the rest of it and take one sentence out of context. Please don't do that.

    The full context of what I said (if you read the entire paragraph) is that one should either exclusively use the slicer to change acceleration settings, or exclusively use the configuration file and not allow the slicer to change those settings. Otherwise, one will have accelerations settings in two different places and changing the wrong one will have adverse consequences.


  • Moderator

    @deckingman I did not intend to take you out of context.


Log in to reply