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 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?
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
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