Problems with Z axis

[Wubster]

I’m having trouble with the automatic Z axis.

Setup:
Ridgid R2911 router
Ring mount
Adjusted router depth clamp tension so wobble is minimized but z axis motor can freely move z axis.
Added bungee to keep router retracted.
Mounted a ruler on router so I can measure actual z axis displacement.

Ground Control v1.26
Arduino Firmware v1.26

Troubleshooting automatic z axis:

The calibration routine only sets the zero point for the z axis. It does not calibrate the pitch or direction of rotation of the z axis screw. Seems like the calibration routine would be more useful if it did.

Z-Axis Pitch (mm per rotation) is set to -3.17mm.
Z-Axis Safe Travel Height set to 2mm.

I set bit to touch the work surface.
In Z axis window I change distance to 0.000000000 and press raise. Z axis motor hums but does not move.
I press Define Zero. The router retracts 1mm above work surface. GC reports Z=-1.64. Why did it move? Yesterday Define Zero often caused movement, but this is the only occurrence today.
In Z axis window I change distance to 20mm and press raise.
Z axis motor turns very close to 8 turns. The router raised 25.5mm to a point 26.5mm above work surface. GC reports -27.08mm. 25.5mm per 8 rotations equals 3.1875 mm/rotation. I will leave Z-axis pitch at -3.17mm until I can measure rotation more precisely. Why did it raise 25.5mm instead of 20mm?

I press Go to Zero and the bit raises up to the mechanical stop. I press the stop button to prevent damage. Why did it go up not down? It would be nice if there were a limit switch.

I set bit to touch the work surface. GC reports Z=-0.52 In Z axis window I change distance to 10.0 and press Define Zero. Z axis motor hums quietly but does not move. GC reports Z=0.00. Repeatedly clicking Define Zero has same result. No movement.

I press Save and Raise to Traverse. Bit raises 4mm. GC reports Z=-4.01. I’m not sure what to expect this button to do as I find no documentation for it. GCODE looks like it is supposed to raise the bit to the Safe Travel Height of 2mm.

I press Go to Zero. Bit raises 6mm to a point 10.3mm above work surface. GC reports Z=-10.31. (up 6.3) Why does it raise and not lower to zero?

I set bit to touch the work surface. GC reports Z=0.40 In Z axis window I change distance to 0.10 and press Define Zero. Z axis motor makes no noise and does not move. GC reports Z=0.00. Repeatedly clicking Define Zero has same result. No movement.

I press Go to Zero. Motor hums but does not move! Repeatedly clicking Go to Zero has same result. No movement. Changed distance to 10. Still no movement with Go to Zero.

Changed distance to 2 and press Raise. Bit raised 3.9mm to a point 3.9mm above work surface. GC reports -4.07. (down 4.07)

I press Go to Zero and the bit raises 6.1mm to a point 10mm above the work surface. GC reports -10.53. (up 6.46)

Changed distance to 10 and press Lower. Bit lowered 13.6mm to a point 3.6mm into work surface. GC reports Z=5.07. (down 15.6)

Changed distance to 5 and press Raise. Bit raised 5.6mm to a point 2mm above work surface. GC reports -2.76. (up 7.83)

I press Go to Zero and the bit raises 5mm to a point 7mm above the work surface. GC reports -7.69. (up 4.93)

Changed distance to 1 and press Lower. Bit lowered 2.8mm to a point 4.2mm above work surface. GC reports Z=-4.57. (down 3.12)

Press Lower. (still 1mm) Bit lowered 2.8mm to a point 1.4mm above work surface. GC reports Z=-1.43. (down 3.14)

Changed distance to 0.1 and press Lower. Bit lowered 2.1mm to a point 0.7mm into work surface. GC reports Z=0.49. (down 1.92)

Changed distance to 0.01 and press Raise. Bit raised 1.7mm to a point 1mm above work surface. GC reports -1.13. (up 1.62)

I click Actions, Advanced, Run Triangular Test Cut Pattern, Cut Test Pattern. Raises the bit to the mechanical limit. I hold in the mechanical thread release button on the router to prevent damage. Z axis keeps running up until I press Stop Cut about a minute into the test.

GC reports of bit location are approximately correct but the distances moved are not equal to the commanded distances and the Go to Zero does not work. Suggestions?

[Keith]

Hi @Wubster, welcome to the forums. Sorry you are having trouble and that it looks like you’ve been waiting a while for a response. It was a holiday weekend in the US, and I think in general a lot of us are less diligent at checking the forums on weekends. But anyway… Let me see if I can help…

@Wubster

I set bit to touch the work surface. GC reports Z=-0.52 In Z axis window I change distance to 10.0 and press Define Zero. Z axis motor hums quietly but does not move. GC reports Z=0.00. Repeatedly clicking Define Zero has same result. No movement.
I press Go to Zero. Motor hums but does not move! Repeatedly clicking Go to Zero has same result. No movement. Changed distance to 10. Still no movement with Go to Zero.

When you hit “Define Zero” you are telling GC that this is the location of the z-axis that it should consider zero. The axis should not move as a result of hitting “Define Zero” but the hum of the motor is likely the PID routine sorting out that it doesn’t actually need to move the axis. GC should report z=0.00 at this point. Pressing “Go to Zero” will not make the axis move at this point because you just told GC that the axis was at zero by hitting “Define Zero”

@Wubster

I press Save and Raise to Traverse. Bit raises 4mm. GC reports Z=-4.01. I’m not sure what to expect this button to do as I find no documentation for it. GCODE looks like it is supposed to raise the bit to the Safe Travel Height of 2mm.

I press Go to Zero. Bit raises 6mm to a point 10.3mm above work surface. GC reports Z=-10.31. (up 6.3) Why does it raise and not lower to zero?

This is sounding a bit like an encoder problem in the z-axis motor. I’m not the best one to help you troubleshoot if that’s the case, but I imagine you’ve been waiting to hear from someone on this.
Who did you purchase your kit from?

@Wubster

Changed distance to 2 and press Raise. Bit raised 3.9mm to a point 3.9mm above work surface. GC reports -4.07. (down 4.07)

I press Go to Zero and the bit raises 6.1mm to a point 10mm above the work surface. GC reports -10.53. (up 6.46)

Changed distance to 10 and press Lower. Bit lowered 13.6mm to a point 3.6mm into work surface. GC reports Z=5.07. (down 15.6)

Changed distance to 5 and press Raise. Bit raised 5.6mm to a point 2mm above work surface. GC reports -2.76. (up 7.83)

I press Go to Zero and the bit raises 5mm to a point 7mm above the work surface. GC reports -7.69. (up 4.93)

It looks like there’s a lot going on here. A couple questions for clarification…
–when you are saying that the bit is going into the work surface, are you running the router and actually drilling a hole?
–I am getting confused by the up and down in parentheses that you are putting at the end of your sentences [i.e.: "GC reports -10.53. (up 6.46)]. What are you trying to say there? My interpretation is that you are saying that GC is reporting the bit lowering, but it is actually going up by 6.46 mm.

So, my first troubleshooting suggestion is that you check all your cable connections for the z-axis to make sure they aren’t loose.
My next suggestion is that you do a systematic raising of the axis by 10mm at a time starting from the bit touching the work surface and pressing “Define Zero”. If the axis raises consistently using the raise button, check to see if the distance is always the same. It kind of sounds like your distance per revolution of the axis might be off, so trying this might help to figure that out. If it always raises the same, or nearly the same (as measured by you) then adjusting the distance per revolution might help.

As for GC reporting negative axis locations when actually raising the router, that is baffling. Please don’t take offense at this, but are you certain you are working only in metric (GC didn’t somehow switch to imperial somewhere in there)?

I’m not sure if you are able to post images yet (if not, reading a bunch more posts in the forum should get you over that), but if you can, pictures of your whole setup, your sled and z-axis setup, and if possible a video of the axis and what GC is reporting when you are trying to move the axis.
To give you an idea of the kind of video I am thinking of, here’s one I posted

Hopefully we can get this solved for you soon

[Wubster]

Keith,
Thanks for the reply. I’m in the USA, jut using metric because it’s the default.

@Keith

When you hit “Define Zero” you are telling GC that this is the location of the z-axis that it should consider zero. The axis should not move as a result of hitting “Define Zero”

I understand that the z-axis should not move with “Define Zero”, but there have been several times in troubleshooting this that it causes some movement. Not sure why.

@Keith

Pressing “Go to Zero” will not make the axis move at this point because you just told GC that the axis was at zero by hitting “Define Zero”

Correct. The only time that “Go to Zero” seems to work is when it is already at zero.

@Keith

Who did you purchase your kit from?

Maker Made. I’ve emailed them and not heard back yet.

@Keith

This is sounding a bit like an encoder problem in the z-axis motor.

That’s what I’m thinking, too. Is there a simple Arduino sketch I could use to test just this motor/encoder?

@Keith

when you are saying that the bit is going into the work surface, are you running the router and actually drilling a hole?

No. Router motor is off, but the z-axis motor pushes the bit down below the bottom of the sled. It would drill a hole if I turned the motor on.

@Keith

I am getting confused by the up and down in parentheses that you are putting at the end of your sentences [i.e.: "GC reports -10.53. (up 6.46)]. What are you trying to say there? My interpretation is that you are saying that GC is reporting the bit lowering, but it is actually going up by 6.46 mm.

The numbers in parentheses indicate the difference in Z as reported by GC. So GC says Z=-4.07, then I click Go to Zero and after the move GC reports Z=-10.53, which is 6.46 higher than it was before the command (up 6.46). (I meant to write up 4.07, not down 4.07 in my original post. Sorry. It’s confusing enough without that.) The distances that the router bit actually travels are pretty close to the differences in Z that GC reports, but the distances traveled don’t match what it was commanded to travel. Makes me think the encoder is working fine but the commands get messed with somewhere between the gcode that GC outputs and the motor.

@Keith

my first troubleshooting suggestion is that you check all your cable connections for the z-axis to make sure they aren’t loose

Done.

@Keith

My next suggestion is that you do a systematic raising of the axis by 10mm at a time starting from the bit touching the work surface and pressing “Define Zero”.

I’ll try this next.

@Keith

It kind of sounds like your distance per revolution of the axis might be off

I think it’s fine based on 8 turns to raise 25.5mm, but I’ll look more closely at this.

@Keith

As for GC reporting negative axis locations when actually raising the router, that is baffling.

I figured that was a consequence of a negative value for Z-Axis Pitch.

@Keith

Please don’t take offense at this

No offense taken. I’m happy for your help!

[Keith]

@Wubster

I figured that was a consequence of a negative value for Z-Axis Pitch.

That should not make a difference as the negative pitch only accounts for the direction the motor turns to ensure that when you ask it to raise it raises and vice versa. GC then knows which way to turn to motor to achieve what you want, and should report the actual position, not an inverse of the actual position.

@Wubster

That’s what I’m thinking, too. Is there a simple Arduino sketch I could use to test just this motor/encoder?

I am sure it could be done. I don’t have a ready solution for you, though.

@Wubster

Maker Made. I’ve emailed them and not heard back yet.

I am adding @MakerMadeCNC @makermade to see if that helps you get any exposure

@Wubster

the z-axis motor pushes the bit down below the bottom of the sled

I doubt it’s an issue, but that would be putting extra strain on the motor. Can you pull the sled and do your z-axis tests on a bench?

Another, perhaps less appealing suggestion, is that you wipe the EEPROM and reinstall the firmware on the arduino. You’ll have to restart your calibration, but some have found that starting from a blank slate helps eliminate weird gremlins.

Keep us posted.

[MakerMadeCNC]

Sorry nobody has responded to your email. @Wubster Can you email me directly at chris@makermadecnc.com and we can set up some time to have a skype call to get you fixed?

-Chris

[Wubster]

I still haven’t received a reply to the emails I sent to @MakerMadeCNC or to Chris. I made a video showing some of the problems with the z axis.

Demonstration of Maslow Z-Axis Problems

A summary of the problems:

1. Z axis position reported by GC is negative but approximately matches the actual position of the router
2. The distance moved does not match the commands.
3. Define Zero sometimes causes the router to move a few mm.
4. Stop button does not immediately stop the motor. Not sure how long that is supposed to take.
5. (Not shown in video) Go to Zero causes the router to move a random distance and direction. It does not go to zero.

@Keith

wipe the EEPROM and reinstall the firmware on the arduino

Not exactly sure what you mean by that. I’ve tried re-uploading the arduino sketch to the board. Do you mean something more?

[Gero]

This does look like a bug. Under Settings -> Advanced -> Wipe EEPROM you can brainwash you arduino.
I had at least one occasion were the GC wipe did not work. I downloaded a ‘wipe sketch’ from the arduino forum that worked.
I am inconclusive if uploading a new sketch wipes the eprom, it should according to most of the info i found on the net.
The series of ‘insanity’ of the arduino i had could not be traced down to a solution. I found that some settings changed in GC can cause this ‘illness’ if you don’t quit GC and unplug the arduino after.

Wipe eeprom and rename groundcontrol.ini would be the next escalation. New calibration is required but can be shortened if the chains are marked and the previous settings copied to the new .ini.

[Wubster]

@Gero

Settings → Advanced → Wipe EEPROM

I tried this, then re-uploaded the arduino sketch to the board. Still no difference.

@Gero

rename groundcontrol.ini

I don’t find this file. The only .ini file I find is GroundControl-Windows.Portable.v1.26\GroundControl-Windows.Portable.v1.26\GroundControl\old.ini.

[Gero]

It should be in your user folder -> C:/users/{your-username}
Have you tired swapping the wire for Z?

[Wubster]

Found it. Thanks.

@Gero

Wipe eeprom and rename groundcontrol.ini would be the next escalation

Didn’t help.
I don’t have an extra z wire, but it checks ok with an ohmmeter between the solder connections on the motor driver board and the motor connector.
Thanks for your replies.

[Gero]

Am wondering if switched wires in the cable could cause this, but expect the error to be more consistent. Noise (interference) is another possible cause. Ferrite on both sides of the motor cables and USB cables is a chance.
Also check the noise in the power grid.
Am out of ideas.

[Keith]

Wow, ok… First, thanks for the video, that was extremely helpful in understanding what is going on.

In watching that, I am starting to lean more toward a GC problem. The fact that GC is reporting a move that is approximate to opposite what is actually happening is really odd. I know that you realize that, and it’s not helpful to reiterate, but it helps my process

That said, could you try one other thing… Go and get an earlier version of GC and Firmware and install that on your computer and arduino. I am not up on which versions were most stable, so I can’t really say which one to go to. I am still using v1.06 (I think), so a lot of the improvements and potential bugs are things I haven’t had experience with. I am not sure it will make a difference how far you go back, as long as we can determine if your GC install is the problem.

I am concerned by both the negative (or opposite) reporting of depth and the extra distance moved. if you wanted to play with it, you could try changing the axis pitch to -1 and see what happens. I would be interested to see how far GC thinks it moves in that case. I am not sure how helpful that test would be, though. With any luck, changing versions of GC will give some insight. And at least multiple versions can coexist on your computer (assuming you only try to open one at a time), and reprogramming the arduino isn’t that hard.

I heard a second voice on the video. You are lucky you have someone to help you with this. Hopefully we can get you up and running soon so you can start making fun stuff rather than celebrating troubleshooting victories.

[Keith]

@Gero

Am wondering if switched wires in the cable could cause this, but expect the error to be more consistent. Noise (interference) is another possible cause. Ferrite on both sides of the motor cables and USB cables is a chance.
Also check the noise in the power grid.

These are all good suggestions, but they don’t seem to account for what’s happening. GC is sending a message that is apparently inconsistent with the GUI. The pitch is appropriately negative to effect the proper motor rotation to raise and lower, but GC is reporting doing the opposite of what is being asked of it. Take out the physical side of things (the actual motor and axis) and GC is not performing as expected. If @Wubster had not yet built the axis but just wanted to see the motor turn, then I’d have not gotten hung up on anything but the fact that GC isn’t doing what is asked of it, namely, when told to raise 3 mm, it turns around and lowers 10+ mm, and tells you as much.
When taken in that light, wiring, encoders, noise… none of that accounts for the discrepancy. It is totally inside of GC that things seem to be going awry.

@Wubster, can you remind me… are you on a Windows machine?

Also, on a different topic, you may want to start making plans to replace the router with a c-channel or similar axis, and a spindle. I haven’t replaced my router yet, but switching from the router base to a c-channel axis made for much less frustration with the z-axis movement. Of course, that is predicated on getting it working in the first place!

[WoodCutter4]

@Keith

GC is sending a message that is apparently inconsistent with the GUI.

Either GC or the firmware (I admit that I haven’t taken the time to understand those parts yet). I have seen these issues with z-axis, and main motors, but I feel like it has only been during calibration. The thing is, these issues are hard to articulate, document and repeat (seems inconsistent), and are fairly easy to “work through” and move on. I feel like the functionality has been good enough that the GC and FW programmers haven’t needed to look at it and have focused precious time on other, larger, or more obvious fixes/improvements. The thing about this open source project is, if you see a problem you can fix it, however; this project has gotten rather large and is daunting for most to dive into the software programming, which requires knowledge of how GitHub works, python and arduino environments etc.

[Wubster]

Thank you for taking the time to help with this.

@Keith

you could try changing the axis pitch to -1 and see what happens

I tried this. Pretty much as before except the router moves about 3x as far as GC reports. This is what I would expect.

Working on installing older versions…I’ll report back soon.

@Keith

You are lucky you have someone to help you with this.

My son. He’s 12. It’s his machine and he’s done almost all the work on it. I’m just helping him troubleshoot it.

@Keith

are you on a Windows machine?

Yes. Windows 7.

[Keith]

Fair statement, but I am not sure how that helps @Wubster. It appears that he is able to repeat it consistently, so something is fundamentally wrong for him. I am not saying the problem is in the work that’s been done, I am simply trying to help him troubleshoot so that he can move forward. I greatly appreciate all the time and effort that people have donated to the Maslow community. For those of us without the time or expertise to dive into the code, we have to find our solutions within what already works. Again, though I feel indebted to everyone who has contributed, even though I have not had time to utilize the work that’s been done since I installed v1.06 There are exciting improvements I would like to utilize, but don’t have time to implement as yet. Even without those improvements, I love what my Maslow can do, and I am hoping to get Wubster to at least the same level of functionality as me.

As it stands right now, it appears that he can’t “work through” it and move on yet. Hopefully with some back tracking we can figure out where the issue lies, and if it is a community wide problem, alert the community to a potential bug. If the problem lies in his particular set up, then we can fix that with him so he can move on.

[Keith]

@Wubster

My son. He’s 12. It’s his machine and he’s done almost all the work on it. I’m just helping him troubleshoot it.

Nice! My son is 7 and I am hoping he gets the making bug. I can see a glimmer of interest, but so far big projects like this have a hard time of keeping his interest long enough to bear fruit. Great job to your son!

I hope the earlier version gets you running, then we can try to figure out what’s going on with using 1.26

[WoodCutter4]

You are right, not a helpful comment but more a lament, I apologize.

Learning how to be proficient/dangerous with GC and FW programming is on my list of things to do (I hope to start working on that very soon, actually).

Regarding what to do right now, I think documentation via a repeatable process is the best we can do to communicate to those with the knowledge of the inner workings of GC and FW. I can facilitate tagging those people to help us further isolate/confirm the source, then we can try to figure out what the solution is and create a PR.

As far as “working through it” goes, while waiting for a fix, for me, I’ve not worried about these issues when I have seen them during calibration. It seems that once you get the machine running it behaves as expected, at least for pluge depths anyway (I haven’t measured raises).

@Keith

start making plans to replace the router with a c-channel or similar axis, and a spindle

EDIT: plus one for that. Take a look at @Metalmaslow 's stuff, specifically their sled/c-beam z-axis/linkage upgrade kit. I am SUPER excited about this (price is VERY good).

[Wubster]

I tried GC versions 1.25 and 1.06 with matching firmware versions. No change. I’m thinking it’s a problem with the motor shield or arduino. I ordered an upgraded shield v.1.4 from East Bay Source. I’ll see if that makes a difference.

[WoodCutter4]

Another “not helpful”, “grumpy grampa-like” comment for context…the original kits from Bar and Hannah didn’t have an automated z-axis…(“back in my day”)…GC would stop and tell you to raise/lower the router and you would confirm that was done and the maslow would move on. The current “stock” z-axis kit is a cheap solution for automating that process and isn’t perfect. Yes, it has problems and, yes there is mechanical slop in the router parts, which has been discussed ad nauseam on this forum (here is a good example). Also, the original intent of Maslow is to be accessible to the most people (cheap and simple) but as time has gone on, additional expensive features have been suggested and wanted. You can make whatever upgrades you want!

To summarize: if you aren’t satisfied with the “stock” z-axis, there are plenty of options for upgrading; take a look around the forum and the garden. fwiw, I’m not happy with the stock z and am upgrading to the metal maslow kit I linked to above, for more reasons than the z-axis.