G92 function change

[newydave]

In RC3 (and all earlier versions) issuing a G92 would set my machine's absolute position. I've just tried RC6, and even after homing, if I send a positive G92 for the Z axis I can't move below the initial homing point.

EG
G28 Z0 (Home Z)
G92 Z20 (Set Z height to 20)
G1 Z10 (move Z=10, 10mm lower)

The last command G1 results in no movement, even though M114 suggests that Z=20.

If this is by design due to the improved Z homing, can we have an alternate G code for setting absolute position. Alternatively if I revert the RC3 G92 code (without using auto bed levelling) can I expect some bad breakage?

[Blue-Marlin]

You want to find a z-probe-offset?
That's due to a fixed bug in the software endstops. Formerly the software endstops have not be corrected for a G92 - now they are. To get below the zero, measured by G28, you now have to deactivate the software endstops.
A bit off-toppic:
Doing something with the position directly behind a G28 is not a good idea. For a special system the end position is always the same, but if you use an real endstop or a probe, or an other probe can make a difference in the end position for G28. Doing a absolute move before G92 makes this consistent. Homing finds the zero-point. That's not the same as moving to zero. Especially not if a probe is involved.

@thinkyhead
Would be a good idea to make the software endsops switchable on/off by by g-code. Maybe M120/M121 with 'S'- parameter. 'H' for hardware-endstops could be the default.

[thinkyhead]

I'll see about extending M120/M121. Currently there's no way to disable software endstops (the ENDSTOPS_ONLY_FOR_HOMING setting is fixed).

Also worth mentioning, no extra tricks are now needed with G92 to work around whatever it is you're trying to work around. So maybe you don't need G92 for what you're doing…?

If you want to routinely move below Z=0, set your Z movement limit to a negative value, and then use a MANUAL Z home position of zero.

[Blue-Marlin]

ENDSTOPS_ONLY_FOR_HOMING is working for hardware endstops only.

A common tutorial for finding the Z_PROBE_OFFSET_FROM_EXTRUDER has been (as far as i remember):

*Set Z_PROBE_OFFSET_FROM_EXTRUDER to 0 and flash.

• G28
• G0 Z0 // you can't go lower because of the softwareendstop
• G92 Z20 // tell the machine to be at z=20. Due to the error in software endstops you now could move the nozzle 20mm deeper.
• Make the paper test.
• Read the display or send M114 to find the actual z.
• Subtract the found value from 20 to find Z_PROBE_OFFSET_FROM_EXTRUDER
• Put that into the config and flash again (or use one of the other methods to change the nozzle-probe-z-offset)

That does not work anymore. The tutorial was not a good one because it relied on the G92 glitch but worked for at least a year (https://www.youtube.com/watch?v=EcGFLwj0pnA 9:00++and others).

Better than fooling about the z-height with G92 is, to simply do the obvious. For going beyond the endstop position - switch off all kinds of endstops.

[newydave]

@Blue-Marlin @thinkyhead Thanks
Does this mean that the firmware carries two sets of positions. One, absolute, set via G28, and a relative one accounting for offsets and bed levelling?

Until my IR Z probe arrives I've been manually setting Z height using a piece of paper between the hotend and bed and gradually lowering. Then I was setting the height to zero with G92 Z0. I can usually get around 10 prints before having to rehome Z manually. I wrote a few menu items for the LCD controller to make this less tedious.

I'll try disabling software endstops tomorrow but having it available via M120/M121 would be a bonus

[thinkyhead]

@Blue-Marlin Correct. The G92 command can no longer be used to overcome the software endstops.

If you are at Z=0 after homing with G28 and you issue the G92 Z20 command, this tells the machine that the current position is now Z=20 (no longer Z=0), and the software endstop for Z gets 20 added to it so that you still cannot move any lower.

If you want to move lower than the Z home position, you must change your physical limit settings, which determine where the software endstops are set. Change Z_MIN_POS to something below zero (-2 for example). But still set your Z_HOME_POS (and/or MANUAL_Z_HOME_POS) to zero. Then when you home you will be at Z=0, but your machine will now allow you to move to -2mm.

[gddeen]

I had this same problem. My power dropped and I wanted to resume a print. Can I take it to within 2mm of the high end software/or hardware z stop and then it will say 'Ahh I know where Z=0 is...'
I had no trouble reprinting when I used 'G92 Z131.076'... It is actually very nice it won't go below
that Z plane....

[fabtopia]

I had the same problem. Changing the Z_MIN-POS to a negative value -5 (the same as Z_RAISE_BETWEEN_PROBINGS but negative, makes sense for me).

@thinkyhead and @Blue-Marlin: Better mention this in the release notes, because many users depends on this bug/"undocumented feature"

[gddeen]

I wouldn't care if I had an LCD entry that said 'LOWER THE DANG NOZZLE 0.025mm I'M STANDING RIGHT HERE AND YOU ARE WRONG, EVEN THOUGH 5 seconds ago I DID A G29 S2!"

I'm Clueless when 'BED Z' entry is used... Do I set it + to get it lower? - to get it lower? It only
takes effect after G29 S1, G29 S2, G29 S2..., G29 S4 Z0.210, G28.

Probably all that is needed is an explanation of how to level the bed with MBL via the LCD,
and via a terminal.

[thinkyhead]

@gddeen Sorry, I don't see what you are commenting on.

How does this topic, which concerns change to G92 (set the current position) relate to G29 with S parameter (assume you are referring to Mesh Bed Leveling)?

[gddeen]

G92 Z0.2 says the nozzle is at 0.2 height. But, it won't lower because it thought it was at 0. (Because it
doesn't remember the Z value across power outages.)
The command no longer can be used to lower the probe below a believed 0. (fine.)

Then how about adding an entry (not a G92) into the LCD where the operator can override.
They are standing there and see the height is wrong.

Only a G28 or a G29 S1 can be used to overcome this Z plane limit which is now incorrect.
But in some cases those commands can destroy a print.

Is that slightly more understandable? (I dunno really.)

[epatel]

@gddeen Here is what I wrote about those two methods of levelling with MBL, see last part of this https://github.com/epatel/Marlin/blob/75f9fb50c4002f6d4ba0345f5594cbac1fab1fa6/Documentation/MeshBedLeveling.md

[gddeen]

Yes Sir, I read that before. I have studied the code.

I change marlin_main.cpp G29...

    // For each G29 S2...
    if (probe_point == 0) {
      // For the intial G29 S2 make Z a positive value (e.g., 4.0)
      current_position[Z_AXIS] = MESH_HOME_SLEW_Z; // GDD MESH_HOME_SEARCH_Z;
      sync_plan_position();

It moved over the bed as if it was using the Zprobe... So this value I set to 4.
MESH_HOME_SEARCH_Z is set to 13.5... the distance needed to clear the bed for the Z probe.
...
The Bed Z works great... But it always starts up at 0 after a reboot. I don't really have a clue when
it is used. (Actually I do, but it i very confusing to those that don't read code.)

I would LOVE to rewrite your document to describe what I believe your code does. You assume a
lot from those that have no understanding of the probe, configuration.h, mesh bed leveling, the
commands (G28, G29, M420, M421, M428, G92).

MBL get resets when a G28 is issued (and automatically added in cure start.code.)

Essentially, someone wants to 'install the hardware', 'perform a mesh bed level' and reboot
their printer. When a nozzle is changed, when the bed leveling is adjusted, when the optional
Z Probe angle is adjusted, they need to know what to do. (Not how it is doing it.)

When they find that after a G29 that it is printing too high, HOW do they fix it?

What are the values in configuration.h?

What the heck is ABL? What is different from MBL (I know in gory detail!)

I THANK you and love MBL. ABL destroyed my printbed, my Z couplers, my MIN_Z_Endstops, etc ...
The code itself was fine, but it never worked and I didn't know why. (I do now.)

[epatel]

@gddeen I am sorry if MBL is confusing or destroyed something for you. I tried to make it as straight forward and separate from ABL I could, also thinking of some safety measures not to destroy a printer. Actually, I first tried to understand ABL and see if I could piggyback on that but I could not wrap my head around it fast enough, so I gave up and made MBL separate from it and solving my own use case, see #1619
Later I did my own minimal AMBL http://www.thingiverse.com/thing:1120142 and I have seen one piggyback on that and being happy with it.

You point out a number of good educational points. Marlin could actually be worth writing a book about from a user perspective. Not sure if there is a single person that has tested all parts and can describe all the ins and out from Delta printers to CoreXY etc. Personally I can only help with MBL and rationals for it, and not much else because I am like you on other areas (have to dig in the code to figure stuff out).

What if someone could organise a Kickstarter campaign to gather all/some Marlin developers + setup for common printers, for say a week somewhere. Good to know the people, the machines, the features. Maybe possible to make steer groups and a roadmap. I wouldn't mind seeing i.e. @foosel or you taking the lead on this

[epatel]

@gddeen maybe https://twitter.com/toms3dp has a lot of experience with Marlin?

[gddeen]

I think Tom did one on ABL... I opted for MBL instead of ABL. It produced MUCH nicer prints.
Yes, 3d printing is a rag tag team of all different printer types.

I used your pull from Marlin for MBL (around RC2)... Then, I moved back to RCBugFix. (from RC6) Yikes. Everything broke. But, no worries. It was fun.

I've only been doing this for 6 months... Do you mean the Marlin, smoothie, etc DON'T get together
at the 3d major conferences, like the one in Germany a few months ago? Wow. I am startled.
There should be standards, a standards committee, advisory groups, flavors and versions and direction.
(I assumed you were it since MBL is a significant addition in Marlin.) Maybe RepRap does all that...

[foosel]

@epatel I already have my hands completely full with OctoPrint and also the last time I tried to improve anything on Marlin that went beyond just bug fixing I was greeted with hostility. I'd rather not repeat that, especially when it would mean that OctoPrint suffers.

[epatel]

@foosel Happy to hear you are busy and I see you are getting the Patreon thing going too, nice. :) ...well, it was just a crazy idea.

[thinkyhead]

@gddeen maybe https://twitter.com/toms3dp has a lot of experience with Marlin?

Which reminds me… I was thinking, we should really do videos on the finer points in Marlin. But, who has all the time, equipment, and expertise? Wouldn't it be cool if we could get Tom some extra Patreon patrons and politely ask if he would be open to making videos on the main topics and features of Marlin. He really does good production too.

@jbrazio @Roxy-3DPrintBoard

[thinkyhead]

that went beyond just bug fixing I was greeted with hostility

@foosel You have my sincere apologies if I have been hostile to your best intentions. I am making a sincere effort to involve host developers in all relevant discussions, not merely to atone for first impressions, but because a productive partnership will always make things better. I think there was a lot of "bad taste" left behind in the mouths of many who tried in the past 18 months to sort out misunderstandings and cross-purposes through these forums as Marlin has been going through major evolutionary throes.

Somehow, through this haphazard process, I have faith that we all eventually come to a better point. The detours do suck, I agree. And I know I am not always as aware as I should be of the limits of my understanding.

For my part, I had to flee the whole Marlin scene for a while and recoup from the intensity of it all. A lot has been learned here (pointing to my chest and head), and there is more still being learned about balancing needs and desires. Marlin and I seem to be inextricably linked, so I must continue to evolve along with the whole phenomenon. Your straightforward and well-thought-out feedback is always appreciated.

[thinkyhead]

Only a G28 or a G29 S1 can be used to overcome this Z plane limit which is now incorrect. But in some cases those commands can destroy a print.

@gddeen The "supported way" to overcome the Z plane limit is to make the Z_MIN_POS lower, which moves the (fixed) Z software endstop lower. You then have to set a MANUAL_Z_HOME_POS of zero so that the home position is known to be zero, and not (the default) Z_MIN_POS.

With that setup, you no longer have a Z software endstop at zero. (And maybe that's something to be re-thunk…?)

With the update to G92 this all definitely needs to be stated and explained in the documentation for these options, and for G92, and in the configurations. ( @jbrazio ) I hope we'll have it all up-to-date around the same time as the final 1.1.0.

[jbrazio]

Wouldn't it be cool if we could get Tom some extra Patreon patrons and politely ask if he would be open to making videos on the main topics and features of Marlin

This is a great idea !
But I don't know if he would be willing to "support" one firmware.

With the update to G92 this definitely needs to be stated and explained in the documentation and configurations.

Noted.

[gddeen]

[off track]
I got yelled at a time or two, but if you stand up and take it people get tired of yelling. Then
everyone forgets and then you get cool answers (see above... I'll go try that.)

Tom has bought some awesome video equipment and he's good at writing and the documentaries.
I wonder what he was like as a 7 year old... (I would guess the same, but turned up a few notches.)

[thinkyhead]

@jbrazio Well perhaps if focusing on Marlin exclusively is too narrow, Tom might be more open to covering how to configure "bed leveling" on more than one firmware, so Marlin could be just one part of that topic, for example.

[jbrazio]

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.