Z-axis behavior

Troubleshooting
1

I manage a Makerspace (Fox.Build in St. Charles, IL) where we have a Maslow V1 we built after a member saw it demonstrated at a Maker Faire. It has been a good machine for us, but we recently shortened it and moved it. I’m bringing it back online after the move (everything worked fine prior to the move).

I calibrated the XY chains, and that seemed to go ok. The problem I’m having is with the Z axis. If I use the Z-axis menu in WebControl to move it up 0.1", then down 0.1" everything seems fine. However, if I inject a custom g-code such as:

G01 Z0.1
G01 Z0

It moves up what appears to be 1/10th of an inch, but it does not move back down very much at all. If I try to run a g-code file the Z-axis just keeps getting higher and higher off the surface. I replaced the bungie thing that pulls the router back down, but no change (I didn’t expect a change, since the Z-axis control from WebControl seems to work fine).

I suspect I am overlooking something, but I can’t think of what it might be.

Thanks!

Doug

2

This sounds like an issue with the G90 vs G91 command. In G91 mode or relative mode every time you send G01 Z0.1 it will move up by 0.1 and the command G01 Z0 won’t do anything because that is telling the machine to move a distance of 0. In G90 or absolute mode it will move to the location Z=0 from wherever it is now. You can switch from one to the other by sending either G90 or G91

3

I just retried it with the following “custom G-code” from within WebControl:

g90
g0 z.1

It moved up what appears to be 1/10"

I followed that by:

g90
g z0

The motor hummed, but did not appear to move.

I also checked the g-code file I had originally tried to cut and the 2nd line is a G90.
The code in the Z-axis dialog of WebControl still moves both directions.

4

So the problem was one of the hall effect sensors broke off the Z-axis motor. The cover got knocked off long ago, exposing the circuit board. Apparently someone banged into it again and broke off the sensor. It seems odd that with no Z-axis encoder there was no error reporting.

The result was every move acted like a relative move because Z was always reported as being at 0.0.

1 Like
5

Ahhh that makes sense. Good catch!