Z Probing... Backwards?

Alright, I may be losing my mind. For weeks I’ve used grbl panel’s Z-probe to happily help zero my zaxis against my work (along with the clips on the probe headers, obviously).

Suddenly this morning, probing goes backwards. The Z axis travels up. Nothing has changed in my setup. Sometimes, after manually zeroing Z and running a job, Z probing will start going in the right direction again. The behavior can be repeated by sending the manual zeroing command to grbl directly as well.

Any brilliant ideas on what I’m missing here?

Same thing happened to me.

I am trying to remember the cause.

Check the current z value when you start. I think it is negative.

Jog the Z axis to the top and zero it out. Then try the z probe again.

If that is not it let me know and I will rack my brains some more.

Possibilities include:

  • bad wiring — check for a loose / intermittent connection
  • software defaults changed — check to see what $23=0 (homing dir invert mask:00000000) and $3=6 (dir port invert mask:00000110) are set to — I think some control programs can reverse directions as well
  • something wrong with the electronics — let us know at support@carbide3d.com if none of the above helps and we’ll try to help you sort it out.

Some interesting results this morning… I used CM to restore back to “default” XXL config, home’d it. Then if I pull up MDI and send /G38.2 Z.-5 F1 it runs homing backwards. If I send it G38.2 Z.-5 F1 (presumably flowing through CM’s magic now, lacking the /) it works as I’d expect it to and probes downward.

Looking at the logs, when I drop the preceeding slash, it actually sends “G38.2Z-29.225” to GRBL and entering this command WITH a / results in the correct behavior.

My conclusion here is that 1: I’m not quite smart enough, and 2: this must have to do with work offsets. Anybody think they can shed some light on the why here?

1 Like

Actually, now within the same machine session, the behavior of sending those commands through CM has changed. both now send the machine backwards. I may give up on probing all together. oy.

Odd remark here but have you tried the whole power down, disconnect, reconnect, power up fix?

Mine will do everything jacked up if I pull the USB while its powered up and then replug in the USB without powering down and reconnecting.


I use Universal GCode Sender. and I had the exact same thing start happening yesterday. I probed several times using my macro in UGS using this command - G38.2 Z- .5 F1 and it worked fine. Then all the sudden I started getting a GRBL Probe alarm when trying to probe… And I noticed it was probing up instead of down. I tried power cycling the controller, restarting UGS, etc. But what fixed it for me was to add a G20 G90 in front so my probe command is now G20 G90 G38.2 Z- .5 F1. Now I am probing in the correct downward direction again. I am using the UGS 2.0 Stable build. So you might try adding a G90 in front, which sets it to absolute position mode.

1 Like

Thanks for writing this up, Dustin! G20 and G90 are setting Inch and Absolute Distance mode… interesting that that fixes it. Also interesting that those commands are included at the top of all CM generated gcode, as well as the stock PP for vectric. I’ll give that a crack for sure!!

I started having the same issue with the probe going up, not down to meet the touch plate. Nothing has changed in my setup that I’m aware.

I have tried running commands directly, which sometimes works, but when I run a second command through MDI, I get an error in Carbide Motion (latest version).

I tried some of the suggestions here:
Leave out the ‘/’, add the ‘/’,
Precede code with G21 G90 (G21 = mm)

Did anybody have any luck with this?

On a Nomad or Shapeoko?

If the machine was working properly and an axis begins behaving oddly under commands which you know should result in a particular movement, there are two likely candidates:

  • software defaults changed/corrupted — resend/reset — http://docs.carbide3d.com/support/carbideupdater/#updating-your-controller
  • bad wiring connection — stepper motors may be reversed in a number of ways, and a faulty connection may cause a motor to only run in one direction — note that a loss of connection can actually damage a stepper driver, so careful in testing

The other possibility is the Probe command is interacting oddly with the current work coordinate system.