What is the problem?
Previously I had a “pause” script that simply homed the X and Y axes without moving Z at all.
However when I just tried to use it it moved the z by my “min clearance” and then when it resumed printing obviously printed 4mm high.
What did you already try to solve it?
I looked through the Gcode documentation to make sure I had the right code and I do. Here it is:
G28 X Y; Home X and Y
M84; Disable motors
Additional information about your setup
Firmware: Marlin
I'm still a newbie but correct me if I'm wrong (still learning) but, shouldn't that be:
G1 X0 Y0; xy goto home
Seen this and wanted to follow since I'm still learning.
No, and for a few reasons, but one major one.
My printer, and many others, do not home at 0. Sending it there would move it to the centre of the bed.
So yes, I could modify the code to send it to the same coordinates as home, but I haven’t had to do that previously and I am more concerned about the change in behaviour than I am about how to get around the issue!
Another issue is the repeatability. I like to have it hit the endstops and register it as homed and “zeroed” and then on restarting I home it again. This means that any skips or issues that may (but never have) occur on the long travels are accounted for and any jostling of the head while swapping the filament is accounted for.
I’m glad you’re willing to learn, that’s an excellent mindset to have and I hope this helped 
Ahhh. Thanks for the education. I was under the assumption that i.e. G1 X0 Y0 wasn't sending the axis home but to a specified coordinate. I appreciate you respecting my "Newbism" 
and not shunning me.
Hope you get the problem fixed....following.
One question along: Why do you disable the motors during the pause? There is a great risk to change their positions and the further on print fails...
Maybe you should give us more of your pause script
So as you already know - why do you ask then???
Have you actually read what the issue is? Or have I failed to explain what should be a simple concept.
A command (G28) which previously I used to home X and Y without Z moving at all on many occasion as, now moves Z by my “min clearance”, behaviour that is unexpected and disruptive.
I don’t know what you think I’m asking but I don’t think you think I’m asking what I’m actually asking.
So I suppose to reword it:
As I do believe that not having the option to home without including min clearance is actually very limiting.
G28 commands and probably something in its config changed that has it now do the additional Z movement.And please dial down a notch on the attitude. Thanks.
Also (yes, irrelevant to your original question, but still):
Homing switches aren't necessarily 100% repeatable, meaning you'll get minor shifts on each home. Not an issue if the same homing position is kept throughout a print, but a problem if you repeatedly rehome during a print. Which is why I'd actually recommend against disabling the steppers, but whatever floats your boat.
Thanks, I’ll do so, though I haven’t changed any settings in my firmware in a long time.
Also, sorry. It’s been a bad week and I’ve let that stress eke out. I’ll try to contain my negativity better.
Nothing is 100% repeatable really, but endstops are certainly more accurate than nothing at all. You’ve got a point about not turning off the motors though.
On an unrelated note, this is your discourse, right? I’m finding it very hard to use, sadly (partly why my negativity eked out). I tried logging in via google and it claimed to have done so then left me with the same “login” button. I tried logging in via LinkedIn which worked better at first but then it asked me to enter a password when there wasn’t a password box.
Needed up making an account but I find the cookies notification jumps around and is hard to cancel, taking up 1/3 of my mobile screen and the type-box is a bit pesky to use too. I need to hide my keyboard to scroll above it and then when I try and select it again it can be a pain to reselect and start entering text again.
I'm almost tempted to tell you it is irrelevant to the topic on hand
It's "mine" as in, I have admin rights. It's a hosted instance however and managed by the folks at discourse, so I can't do that much about any software quirks.
I don't have Linkedin setup as login method? 
What mobile browser is that? Have never seen it do that. I also wish I could get around needing this stupid box in the first place, but sadly my hands our bound in that regard since I don't want to be sued into bankruptcy by cease-and-desist-lawyers.
Stuff like this would be better suited for the #site-feedback category however.
It is irrelevant, and don't worry, the irony isn't lost on me! 
Yeah, I kinda figured as much halfway through typing my reply but then discovered selecting the text to delete it was going to be a challenge in and of itself.
Oops, sorry! GitHub, not LinkedIn, I'm quite the frazzled mess today...
I'm running Safari on iOS (now safari on Mac now I'm back home, which seems fine because of the layout) but I think it could be optimisation for phone issues. Mind you as I'm typing my text is vanishing beneath my computer's cookies notification and not automatically scrolling above it, so that's annoying. I'll see about bringing it up on Site Feedback or as it is developer-related, taking it straight to Discourse Feedback.
To get back on topic for a moment, I remembered I have a simple file that pauses with G28 and I believe I printed it without a problem quite recently. I'll give that another go and see what happens when it's running G28 from a script and not from OctoPi. Will post results when I have them or when I've looked into the firmware again.
Thanks for your patient responses and thanks for OctoPrint, we've had our rough patches, it and I, but I'm extremely grateful to have it and to use it
Hi again.
Printed that file, checked the code too. It actually does G28X and then G28Y as separate moves. That file printed perfectly fine.
I then noted that my “cancel” script on OctoPrint has them separate too, which makes sense given the physical arrangement of my bed clips. So I tried a cancel and it crashed the system. The head stopped where it was without homing and the server dropped out. Reloaded the page but it still had the status Panel on the left frozen so I couldn’t restart the print.
Anyway, reloaded OctoPrint, changed the “pause” script to home X and Y separately and tried the file again but paused it manually via the OctoPrint script. It included the min clearance again. Cancelling, however, worked flawlessly this time.