Weird Behavior After Completed Job

To clarify and address your questions:

1) It was a typo in my original description of step six; the homing is done with the usual command G28.2, not G20.2 as I had originally typed.

2) I do indeed have a limit switch at the top of Z travel, which is triggered normally when homing the Z axis. The machine is, indeed, a three-axis gantry type machine, with X+ moving away from the operator, Y+ moving to the left, and Z+ moving upward. (A conventional “right-handed” coordinate system.)

3) When jogging in step 3, I do move the Z-axis downward to a negative absolute coordinate location. When I then use G92, it sets offsets to make the new location (with the tool now located relative to the blank) 0/0/0 in the working coordinate system. (I believed that this was normal practice.)

To clarify the problem – in step six, when I go to home the machine after completion of a job with G28.2, the Z-axis travelling upward, bumping the switch, and the retracting is normal (not a problem) for homing. The odd behavior is that the X-axis, which then *starts* to move toward its home position, stops moving before it actually contacts the switch, and then the Y-axis (which would typically home last, after X) doesn’t move at all.

No error shows up when X stops moving. Re-issuing the G28.2 command after this “incomplete homing” then results in normal behavior; the Z-axis moves/bumps/retracts, followed by X, then followed by Y.

It’s like something is stopping the normal homing routine, but only in this specific condition, and the absence of an error code is baffling.

I will follow up on your questions A, B, and C tonight if I can get out to the shop.

Regarding your statement that having a Z-max switch and homing to Z-max is unusual – I guess I am just surprised by this. I suppose that most users must therefore home to Z-min. I never thought about this too much (I have switches on both Z-min and Z-max), and I home to Z-max because then I never have to worry about crashing a long tool into the table while homing, and it gets the spindle up out of the way for attaching/removing a workpiece.

Another theory (which I will test) from a co-worker is that the M30 command at the end of my G-code file is “getting stuck”, and that the machine is actually pausing at the end of the file rather than completing. I can imagine that running a G28.2 in this condition (which the machine regards as the “paused middle” of an incomplete G-code file) might cause screwy behavior. I will test this more thoroughly.

Thanks for all of your input so far – as problems go, this isn’t too bad, as I am still able to run and complete jobs – but as an engineer, I hate unsolved mysteries and ghosts in the machine.

Cheers!

Everything you just said makes perfect sense to me. I think we might have been “talking past each other” with how we were describing Z-min and Z-max and the correct homing routine, but I am 100% aligned with “home Z to zero, all Z motion downward is negative”.

I’m becoming increasingly convinced that the error might be that my G-code, which executes all of the moves (finishes cutting the part successfully), is actually getting stuck in the final couple lines at or around the M30 command, and this is what’s causing the quirks.

I will update this post after bug-checking so that other users may reference this if they encounter the same thing. Thanks again for all of your help!