Is it me, or is it Z?

Created a simple silverware drawer liner to test my setup. Square corners, a couple of pockets, and straight lines.
DrawerLineIn.nc (82.4 KB)

When I try to cut, the bit goes to the first pocket, raises above the surface and then starts to plunge, but never goes below zero. X and Y move appropriately for the cut which seems to hover just above the surface the whole time. (Manually telling the Z axis to plunge from Ground Control works as expected.)

I thought maybe it was due to the file being set to imperial units. So, I regenerated in metric.
DrawerLiner.nc (81.7 KB)

Unfortunately, the same issue persisted. I’ve verified that both files have -Z offsets in the GCode so they should plunge into the surface. Per the suggestion here:

I tried adding a hard coded F command to line 20 (the first G3 command) even though there was an F in the G1 command on the line above.

So, have I missed something? Does Ground Control not support the flavor of G Code that I’m generating? Are the Z steps too small for the motor to execute?

The code has a mix of cuts in the sheet and parts that are above.
What CAD-CAM workflow did you use?

1 Like

Built in Fusion 360:
https://a360.co/2w4tHcF

Laid out on a plane, stock was supposed to be .197 inches deep.
https://www.lowes.com/pd/RevolutionPly-5mm-Poplar-Plywood-Application-as-4-x-8/50121135

When I saw the cuts hovering I set the “Bottom” to -0.5 inches so that the bit would plunge into my spoilboard just to make sure it wasn’t an something simple like me setting it to .197 mm instead of .197 inches.

I don’t have F360 but it looks like it could be something with where the origin is set.
Hope you can find something usefull here Fusion 360 confusion untill the F360 gurus come in.
Also what post processor did you use for the .nc?

Used the same process / origin for Fusion 360 that I did for my first cut over here:

Only this time I used a more reasonable 0.015 inch tolerance rather than the .0004 mm tolerance that slowed down my first project.

I was hoping more G Code knowledge from 3d printing would transfer over to CAM. Unfortunately, it looks like I still have some learning ahead of me.

2 Likes

I’ll try to take a look at your Fusion 360 file and see if I see anything out of wack on the CAM side…

In the mean time; if you haven’t seen it; this is a pretty cool tutorial on using the CAM side for F360 to Maslow.

I haven’t used F360 CAM for Maslow a lot, but when I have this is my go to tutorial/method.

2 Likes

What’s your Z-axis setup? If it is using the router base as a sleeve for the motor housing (stock z-axis), you may need bungies to give the housing a little push.

2 Likes

Thanks, I had not seen that video before. The info 6 minutes in with the side visualization of heights was useful. I think for future operations I’ll make sure that Bottom is to reference “From: Stock bottom” as a safety. Just in case I’ve been selecting top contours.

I installed bungies on my Z before my first cut as I had been lurking in the forums while waiting on my Maslow to arrive. When running the G Code, I can actually watch, after the Z is raised to .6 inches then dropped back to the surface, the Z motor doesn’t turn at all, even when the display in Ground Control indicates that it should G3 to Z of - .697 inches.

2 Likes

Perhaps something wrong with the connection? Several times I have started files where nothing happens because I forgot to plug the Z-motor in after doing a bit change or router maintenance. Perhaps there is a loose wire in the plug?

1 Like

It looks like it wasn’t any issue with the hardware or cables. In the end, I ultimately managed to get the part to cut, but I had to switch to a straight plunge instead of a helical plunge.

The non-working G code used a lot of small arcs to descend:
G3 X10.6714 Y14.0676 Z0.1038 I-0.0149 J0.0575
X10.6793 Y14.0708 Z0.1 I-0.0182 J0.0565
X10.7037 Y14.1552 Z0.0965 I-0.0262 J0.0533
X10.6175 Y14.1716 Z0.0931 I-0.0506 J-0.031

The working version used just dropped the Z and then began moving:
G1 Z-0.2345
G1 X10.7082 Y14.1336 Z-0.2389
G1 X10.7095 Y14.1323 Z-0.2433

I’ll probably be setting up a test run at some point where I try generating a series of pockets using different plunge types to see if I can isolate and reproduce the issue. On the up side, I learned a lot more about using Fusion 360 to generate G Code in the process and I learned how to use CAMotics to perform sanity checks on the results.

2 Likes

Looks like helical plunge in Fusion might generically be an issue:

1 Like

There was a recent post about setting the F360 origin on top of the workpiece and making sure that negative Z moved into the work.