Born of this thread: https://discourse.octoprint.org/t/changing-the-g-codes-for-the-buttons-in-the-control-tab/4534/7 Seems some printer firmware "engineers" are messing with how homing works... again... GG.
@Arun_Baby If you want to give this a go https://github.com/ntoff/OctoPrint-CustomZhoming and see if you can use it to customise the command given when you press the Z homing button. You can enter ONE command for it to send, so you can try your G28 X00 Y200 Z0 thing if you want, but I stand by my original statement that it's up to you to make sure your nozzle is in place before homing Z, if you're manually homing your axes. Judging by how rogue firmware developers are when it comes to this stuff, I'm not entirely sure G28 X100 Y200 Z0 will even fix your issue (unless you've tried that command and know it will work). Half the time firmwares just ignore any and all values for X, Y, and Z. Entering G28 Z9999999999999999999999999999999999999999999999999999999999999 is exactly the same as G28 Z half the damn time.
@Ewald_Ikemann I'm not really sure this'll help you much, from the page you linked to, it doesn't seem Prusa has a way to home the axes individually at all? It's either all or nothing? (probably safety oriented so you can't crash the nozzle?) Would adding X and Y support benefit you at all? What did you end up doing?
2 Likes
@PythonAteMyPerl
I never had a nozzle crash into the bed. Except the z sensor failed or was misaligned.
But I give it a try. Sure!
But I don't know why Prusa cut down the homing command that much.
Either you can home Z or all three. X and Y alone would be necessary.
And: Thanks a lot for your efforts!
@Ewald_Ikemann I don't think the plugin will really help you all that much in its current form, especially if there really is no way to separate the axis homing between x, y, and z. I don't own a prusa printer so can't really test anything either. But that's the part I don't know, IS their homing just "all or nothing" like that other page suggests? Or can you do some sort of like G28 W X or something to just home x?
But I don't know why Prusa cut down the homing command that much.
Either you can home Z or all three.
Well, I could add an option to change what the home x/y button sends too, same as the z button. So you could make it send G28 W or whatever.
ALso of note, this will change even gcode that gets sent from a file, not just the buttons. I'm unsure of how that'll affect anything (my guess is it shouldn't if it doesn't see x y and z or just z).
I guess I sort of forgot that octoprint doesn't actually have separate x, and y homing buttons anyway, I added those to my own setup through an unreleased (and unfinished) plugin.
@PythonAteMyPerl,
it actually supports only these ones:
-----8<---Snippet---------8<---Snippet---------8<---Snippet---------8<---Snippet----
G28
Home axis
Examples:
G28 W Home x, y and z axes.
G28 Home x, y and z axes and then runs mesh bed levelling (G80).
-----8<---Snippet---------8<---Snippet---------8<---Snippet---------8<---Snippet----
It's like all or more...
So it obviously cannot even home Z alone. But I'll investigate more after my current print...
Ok then, probably not a whole lot you can do then (or that a plugin can do) if they've stripped it down to pretty much just having "home all" or "home all and level".
I guess theoretically, as long as the printer hasn't lost position, you could set the home button to just be an absolute position like G1 X0 Y0
Yepp. When I opened this thread I was more optimistic in finding alternatives.
Maybe I'll have a look at the firmware...
As a workaround I used the G1 command, but this expects a homed machine.
When you move head or bed, this does not work correct.
But I can try something that came just up my mind: I'll try G1 with relative distances and a moderate speed in hope the end sensors will trigger correctly.
This relative movement work neither.
The printer uses the stored X/Y zero position for end stopping...
Depending on what the printer defaults to, you might need to tell it you're giving it measurements in absolute or relative moves. I think most printers default to absolute, so something like G1 X0 would send it to X0. To use relative moves like G1 X10 to move it 10mm away from where it currently is, you'd need to tell it the move is in relative units (G91) first, then your G1 X10.
Prusa just shot out a new firmware. Let's see if there are changes.
Great! They reactivated the old G28 commands again. So I can do G28 X, G28 Y, G28 Z.
G28 W runs homing in X, Y and Z.
G28 runs homing in X, Y and Z and and bed levelling.
cool cool. Not sure how much further I'll go with the plugin then, firmwares not being consistent & all. Some firmware doesn't care about numbers, so something like G28 X0 is the same as G28 X50000, so in order to actually be useful I think the plugin would need to have script support to run multiple lines like on homing Z you'd first run command X to position the bed, or command Y to enable a probe.
I feel like those are things the operator should be doing so they know the actions have been performed, but then again I'm not much of one for automatic probing of stuff, I much prefer my manual setup printer. So I doubt this plugin (in its current form) will be of any use to anyone, but it does at least fullfil arun's request to be able to run that specific command for homing
1 Like