@madgrizzle Yes, stock Z-Axis and the Z-Axis is enabled in the settings. The Z-Depth raises to a safe height, but never returns to the defined zero point. Something with the EEPROM maybe?
Try this… go to the Z-axis control and lower the bit to be at “zero” and hit “define zero”. Then, raise the bit by 0.5 inches and then lower it by 0.5 inches. If it doesn’t return back to “zero”, that could help lead us to figuring out the issue.
Also, do you have a bungie cord or something over the top of the router?
- Z-Axis Installed: On
- Z-Axis Pitch: 3.17
- Z-Axis Safe Travel Height in mm: 5
- One bungee cord over the top.
I’m not in front of the Maslow now, but I can test after 6pm EST.
When I was testing the Z movement on the router due to a previous problem I had with the Ridgid base, I was moving the Z-Depth up and down by 1" and it returned to the zero point every time.
I’m also creating a basic 3" circle toolpath to test something small.
Well, seems like you have everything correct. Life has gotten in the way of me doing much with my maslow lately and am not in a position to do any testing, but perhaps something with 1.13 is causing issues. @bar said he would look into it.
The .nc file sure looks proper. Have you checked mechanical things like the set screws?
If yours is a Ridgid router, check the orange ‘goodie’ - I had a spate of mysteriouis z-axis trouble after running mine into the stops a while back, which damaged that part, see the discussion here. It is a cheap ($1) part, but often slow to ship. I bought several to be prepared for the next time.
After the binding issues described, it wouild not surprise me at all to find that the thread-follower part of the ‘orange goodie’ has been worn down or deformed to the point that it doesn’t engage fully. If the traveller ran into the stops at the top of the travel, or the router body jammed while the screw was trying to drive it down, the plastic part would be chewed by the screw rod and lose grip for future movements.
I was able to do some hand carving on my damaged one to partially restore the shape and ‘get by’ while I waited for the replacements to arrive.
Agreeing with @blurfl that the .nc looks fine.
If all mechanical thing are ruled out, like no movement on the z connector with the help of zip ties, it’s perhaps worth a try to wipe the eeprom. Also unzip to a empty folder, if you had previous versions of the firmware. Overwriting did not work clean for me in the past.
Ok, so I reset the settings to default in GroundControl (this crashed the app but on restart it appeared successful). Cleared the EEPROM, no notification that this was successful. Then I proceeded to go through the calibration process again. Everything worked fine till I got to the test calibration cut.
For the Z-Depth I went through the typical process, lower the bit to just above the surface of the wood and Define Zero. Pressed done on the modal and selected Define Zero button to move on to the test calibration.
When I start the test calibration, the first thing the Z-Depth does is move up to a safe height. The sled moves over to the top corner cut, and the Z-Depth lowers, but not to the Zero point I previously defined. The rest of the cuts appear in the air.
So from my perspective, the problem occurs outside of the sled cut, and in the calibration process as well. I’d also assume that if the Zero point is defined in the EEPROM, the EEPROM didn’t get wiped by selecting the option in Advanced Settings. Is this something I can do manually with a simple Arduino sketch?
I’m pretty familiar with the z-axis control portions of the software, and willing to write a sketch. What would the sketch need to do?
Could I suggest marking the z-axis coupling and the threaded shaft with slivers of tape, then using the z-axis window to run up and then down 1.25" (10 full turns each way) to check that the software and encoders are moving the motor the proper number of turns? If you do this, make sure the traveler is placed so as not to hit the stops … The ten turns should be very nearly exact - within a few degrees after ten turns in my experience. This would prove three segments of the mechanism simultaneously - software, motor coupler and shaft coupler. Finally, I f this doesn’t reveal a fault, then measure the distance the traveler moves during each ten turn transit. If that is asymmetrical, you’ve narrowed the issue to the parts in the traveler or the threaded shaft.
Once you press “Define Zero” to move on to the test calibration page, the z-axis raises to 0.25 inches, correct? This happens before you press the button to start the test cut… correct?
And just to make sure. After you press “define zero” in the modal, you immediately then press “done” and don’t manually raise the bit to a safe height or anything, correct?
@madgrizzle Back at it today. In the Z-Axis Configuration after I define Zero and select Done, the Z-Axis does not move. When I load a script and press Play, the Z-Axis raises, moves, and starts to cut at the raised position. It then starts to lower from the raised position, but this is still above the wood and no cuts are made. Pressing Home after this point selects this new raised Z point as the new Zero. I’ve gone into settings to change the Z-Axis Safe Travel Height in MM to 0, just to make sure that isn’t the issue and I still experience the same problem.
@blurfl If I raise and lower the Z-Axis 10 times using a distance of 1.25" the distance of the collet to the wood is fairly consistent (just eyeballing the distance). I’m assuming zeroing out the EEPROM is done by traversing all of the address blocks and nulling all the data, correct?
in the z-axis controls, when you press “lower” does it move the router bit closer to the wood?
if not, try changing this value to -3.17
Lower does bring the bit closer to the wood. Changing the Pitch to -3.17 inverts the movement, When I start a cut it brings the bit closer to the wood, but the cut itself raises the bit away from the wood.
Just thinking out loud here, what if I define Zero as being lower than the depth of the first cut? When the script starts, it will raise the bit, and then lower it to the correct point? It’s a hackish way of doing it, but I would at least be able to cut something.
Can you make a quick video of what’s happening, and share the g-code that’s
being used (it can be a very simple cut, a simple rectangle or line)
If I’m understanding what its doing and all settings are set properly, and I were in your shoes… I would try it lol. but first, I would get out the calipers and double check the pitch measurement to be accurate. only (.1) of variation made a noticeable difference in depth when I was messing with mine. I don’t have the rigid router so measurement is different but its worth double checking. remember, “measure twice, cut once”
This is how I understand the code…
During the calibration process, you are asked to define zero on the z-axis. In the modal, you set the height of the router bit to zero and press “Define Zero”. This issues a "G10 Z0 " gcode that sets the current position of the zaxis as the zero point in the controller. Once you press “Done”, the modal closes and you come back to the calibration step that let’s you set Z-axis to zero. You then press “Define Zero” on that page to move to the next step. However, when you press “Define Zero”, the code issues another “G10 Z0” followed by a "G00 Z.25 " (assuming you are in inches). The first line sends gcode to the controller to set the current position (basically, it gets set twice for some reason) and the second line tells the controller to raise the zaxis 0.25 inches. This puts the zaxis to a safe height. This happens before you press any buttons on the next page. Does the z-axis raise to 0.25 inches when you do this step?
I know nothing. I don’t have my Maslow yet. I know nothing of arduino.
Are you putting a minus sign in front of your cut depth?
Nothing personal, nothing condescending, just something I would forget to do
One other thing to check is your CAM program and where the zero is defined on that. If your zero is defined in the CAM program as the bottom of the stock, and the actual stock is thinner than the CAM thinks it is, then you could end up with air cuts. The issue with the CAM thinking that zero is at the bottom of the stock is that all the cuts will be in the positive Z-axis area, whereas with the Maslow having the zero at the top of the stock, all of the cuts happen in the negative z-axis area.
So, what is sounds like to me is that you are defining zero properly, then running a g-code program that was set up with the zero being the bottom of the stock.
Hopefully it’s that simple
Edit: I just looked at the g-code, and that does not appear to be the issue, unfortunately. The g-code clearly shows negative z movement. I am still stumped.