Z Axis direction issue

Making some test cuts today with a newly assembled maslow. Calibration went swimmingly and all has looked very good.

Before starting another test cut I was resetting the zero on the z axis and somehow it got into a state where both the raise and lower buttons caused the z axis to raise.

Event sequence:

  1. Open zaxis panel
  2. hit the lower the button a few times with it set to inches - lowered as expected
  3. changed it to mm
  4. set the value to 5
  5. hit the lower button - bit raised
  6. hit the lower button several more times (before realizing what was happening) - bit raised
  7. cycled power to the board
  8. hit the lower button - raised
  9. restarted ground control
  10. hit the lower button - lowered as expected

It would also be great if there was a STOP button on the z-axis panel just in case

has anyone seen anything like this yet?


Very interesting! I bet the issue has to do with the switch from inches to mm, somewhere in the math there I bet something is not being converted right. I will see if I can make it happen consistently, then track down what’s going on. Thanks for finding this!


When ground control issues a z-axis down from this popup, does it also automatically issue a gcode for what units to use? I looked at the code for z-axis down and all I see is:

self.data.gcode_queue.put("G91 G00 Z" + str(-1*float(self.distBtn.text)) + " G90 ") 

When you switch from inches to mm, it looks like all it does is change data.units to “mm” and divides the existing measurement by 25 (probably should be more like 25.4) I haven’t found where it tells the controller that the measurement has changed from inch to mm or vice versa. Does the queue processor detect if data.units has changed and issue the associated g-code or just always issues the appropriate g-code everytime you press z-axis down?


Great point! I think we need to issue a G20 or a G21 command to the machine at that point! It’s possible that changing data.units sends the command automatically…it’s been so long since I touched that part of the code I can’t remember. This sounds like a very promising hypothesis on what’s going on.


I’m looking at serialPortThread.py (I think that’s the write spot) and it looks like it does it once (on setup) but never again. I assume that getmessage is run once and remains running unless it loses usb connectivity.

Could it be an overflow problem? If it’s set to 5 and the machine is actually in inches and not mm, then maybe that would overflow the value and result in a negative number?

And am I correct in thinking that the keydown_popup routine in the ZAxisPopupContent routine prevents a negative number from being entered into the text field?

1 Like

The z-axis is slow to respond. Could this be commands stacked in the queue waiting to be executed?

Darn, I just checked and it looks to me like the G20 and G21 commands are getting sent to the machine when the units switch happens.

It’s good news that it seems to send the right commands, but that torpedos my theory :upside_down_face:

I added this as an issue to fix in GC.

Not sure why the other issues are happening.


I’m trying to learn the code so I can help troubleshoot or even improve it. Can you point me to where in the code that those particular g-codes get sent?

1 Like

I’ll have to check in the morning when I have a computer again. My guess is that I did something clever and used Kivy’s event system to bind a function to be called any time the data.units variable is changed. At least that’s the way I hope I did it :grinning:

The first places I will look are in the files frontpage.py and gcodecanvas.py

The function will be bound to the variable with a .bind when everything is initialized

I can track it down precisely in the morning :relaxed:

Seems I was typing this when you were responding… thanks for confirming!

It’s line 78 of frontPage.py that is sending it…

self.data.bind(units = self.onUnitsSwitch)

1 Like