Possible bug: ZigZagRamp entry leaves small shoulder on circular profile (depth not reached at end of ramp)

MillMage version:

  • MillMage [insert exact version, e.g. 0.8.01-RC-3] on macOS

  • Controller: GRBL (X‑Carve 1000 mm)

  • Tool: 1/4" spiral downcut


Summary

When using Entry Type = ZigZagRamp on a Profile operation around a circular part, the ramp does not reach the full programmed depth by the time it transitions onto the circular contour. This leaves a small “shoulder” or step at the entry point on the finished wall, even though Final Depth and Depth Per Pass are set cleanly.

On circular geometry (no straight segments), I would expect the zigzag to complete its Z‑drop to the current pass depth before the cutter begins following the circle. Instead, it appears to blend onto the circle early, leaving a visible ledge.


Expected behavior (per docs)

The Profile Operation docs state:millmagesoftware

  • Zig Zag Ramp:

    • “The router plunges straight down to begin the pass, then performs the zig zag motion, lowering along Z as it goes.”

    • “For ZigZag and Plunge entries, the router lowers to the Depth Per Pass as it begins carving each pass.”

My understanding of this is:

  • For a pass with Depth Per Pass = D, the zigzag entry should end at Z = −D.

  • When the tool transitions from the zigzag onto the main profile, it should already be at that pass depth, so the wall is continuous with no shoulder at the start point.


Actual behavior

On a round part:

  • The zigzag starts at the entry point and begins ramping down.

  • Before the Z‑axis reaches the full Depth Per Pass, the toolpath transitions onto the circular contour.

  • The remainder of the ramp “depth” seems to finish as the bit is already following the circle, resulting in a tiny radial step/shoulder where the ramp began.

The attached photo shows:

  • A clean, continuous wall for most of the circumference.

  • One localized spot where a small ledge is visible; this aligns with the zigzag entry point in Preview.

This appears in Preview as well as on the physical cut, so it doesn’t look like lost Z‑steps or mechanics—it seems to be how the toolpath itself is being generated.


Minimal repro steps

Here is a simple way I can reproduce it:

  1. Create a new MillMage project.

  2. Draw a single circle (e.g. 3" diameter).

  3. Create a Profile operation:

    • Tool: 1/4" downcut

    • Side: Outside

    • Start Depth: 0

    • Final Depth: 0.250"

    • Depth Per Pass: 0.250" (single pass; also happens with multiple passes such as 0.3125" to 0.625")

    • Entry Type: ZigZagRamp

    • Ramp Angle: e.g. 20–25°

I see the artifact on parts in hardwood with these settings.


Additional context

  • The part geometry is purely circular (no straight sections), so there is nowhere “obvious” for the ramp to truncate.

  • Depth values are clean multiples, so rounding shouldn’t be causing a partial pass.


Questions for the devs

  1. Is this a known issue with ZigZagRamp on closed circular profiles?

  2. Is there a recommended workaround besides switching the final pass to Plunge/Spiral or adding a tiny separate cleanup pass just to remove that shoulder?

  3. Should ZigZagRamp enforce that the ramp fully reaches Depth Per Pass before transitioning onto the profile, even when the geometry is a complete circle?

I’m happy to provide the .mage project file and additional screenshots or test variations if that helps track it down.

Thanks for taking a look—MillMage has been great overall, and I’d love to help tighten up this edge case if it is indeed a bug.

The ramp move should be at full depth when the 2nd leg of the ramp completes. If that’s not the case, it’s a bug. I’ll investigate.

Oz,

After more testing, I think the small shoulder left on the rabbet of my round box is strongly influenced by MillMage’s default ramp parameters.

For context:

Tool: ¼" 2‑flute downcut.

Operation: circular profile and rabbet cut, using ZigZagRamp entry.

Defaults copied from the tool dialog:
Ramp angle: 22.5°

Ramp feed: ~10 in/min for a ¼" tool, ~5 in/min for the ⅛" tool (≈ 10–15% of main feed).

Plunge rates were also low compared to feed.

Observed behavior:

On circular rabbet profiles, there is a small radial shoulder at the ramp entry region. The rest of the circle is at the correct rabbet depth; the ramp entry region is slightly shallow.

This happens even though Depth per Pass and final depth are set correctly, and the tool is otherwise cutting cleanly.

Why I think the defaults contribute:

A 22.5° ramp angle is very steep for wood router work; most CNC router guidance suggests 2–5° for a gentle entry. At 22.5°, the ramp is very short in XY, so the tool has little distance to reach full depth before transitioning to the circular path.

At the same time, the ramp feed is extremely low relative to the main feed (≈ 10–15%), which makes the ramp segment a tiny, slow “hook” at entry instead of a long, controlled lead‑in.

The combination of a very steep angle + very low ramp feed seems to make it easy for ZigZagRamp to blend into the circle before the depth actually equals the programmed DOC, leaving the observed shoulder.

Suggestions:

Revisit the default ramp angle and ramp feed values for new tools. A more typical router default might be 3–5° with ramp feed around 50–75% of main feed, and plunge around 33–50% of main feed.

In ZigZagRamp on circular profiles, ensure the ramped segment always reaches the full programmed depth before blending into the circular pass, regardless of angle, to avoid the shallow shoulder band I’m seeing.

Right now, every new tool inherits the same ramp angle (22.5°) and very conservative ramp feed, regardless of diameter or flute count. Since the tool definition already includes diameter and flutes (and could later include material), MillMage could calculate much better defaults automatically.

For example, from the tool profile you can:

Set DOC ≈ 0.5–1.0×D based on wood type.

Set stepover ≈ 40–50% of D for roughing.

Set plunge ≈ ⅓–½ of main feed.

Set ramp feed ≈ 50–75% of main feed.

Set ramp angle in the 3–5° range for wood, rather than 22.5°.

Using router‑appropriate heuristics like these would give new users far safer and more realistic starting points, and likely avoid the kind of rabbet shoulder artifact I ran into with the current defaults.

Can you attach the file you’re seeing this on, just in case there’s a stray option or a math issue somewhere?

I’m not seeing this, either in the preview, or in the generated gcode.

To test, I made a 100mm circle, set a profile to run along the line, and gave it an 8mm ramp. The small red dot on the right is just me marking the start point:

This is the gcode it generates:

; T{tool}
M3 S10000
G0 X150Y100Z10                 ; Starting position of the shape - 150x 100y
G0 Z0.2                        ; rapid to a little above the surface
G1 Z0F127.2                    ; Plunge to Z = 0
G1 X149.984Y98.709Z-0.535F510
G1 X149.935Y97.427Z-1.066
G1 X149.854Y96.153Z-1.595
G1 X149.742Y94.888Z-2.121
G1 X149.598Y93.632Z-2.645
G1 X149.424Y92.385Z-3.166
G1 X149.219Y91.149Z-3.685
G1 X149.076Y90.402Z-4          ; Halfway point of the ramp, Z = 4mm

G1 X149.219Y91.149Z-4.315
G1 X149.424Y92.385Z-4.834
G1 X149.598Y93.632Z-5.355
G1 X149.742Y94.888Z-5.879
G1 X149.854Y96.153Z-6.405
G1 X149.935Y97.427Z-6.934
G1 X149.984Y98.709Z-7.465
G1 X150Y100Z-8                  ; Finished the ramp - Z = 8mm

Notice the coordinate for the end of the ramp is exactly the coordinate for the start of the shape, and the Z is the full 8mm depth I requested.

Have you checked the generated gcode on your end? It should be a simple thing to verify this.

I see no indication in the preview either - It would be easily visible from the side in the wireframe if the last part of the zigzag was at a different height than the actual path:

It’s possible that since you’re using a downcut bit, that initial ramp is pushing the material down with enough force to flex the bed a little, but by the time you get back to the beginning of the profile, that’s no longer the case and the material has raised back up again.

I can make the ramp defaults less aggressive, but they’re always going to vary based on what kind of bits you use and the material. An upcut bit will handle steeper ramps.

A typical suggestion for zig-zag ramps is to use a distance of 1/2x to 1x the bit diameter. 1x the diameter would be a 45 degree ramp. 2 to 5 degrees would be quite conservative and would . Any endmill capable of plunge moves is in theory capable of using any ramp angle. For side flute or downcut bits, you want a shallow ramp.

Making the default ramping angle 2 degrees would make many cuts run much longer. In my simple example here, the cutting distance with a 22.5 degree ramp is 363mm, and with my 50mm/sec feed rate, it takes about 10 seconds to run. Dropping the ramp angle to 2 degrees increases the cutting length to 571mm of travel, taking 15 seconds, or a 50% increase in time. I would do that for aluminum, or using a downcut bit in hardwood, but that would be overkill for most of the bits I use.

3 inch box bottom.gc (499.9 KB)

The original file was adjusted to address the artifact with an additional clean up pass. Attached is a file containing the same operations. It could be the downcut bit, or some other machine related issue. I will run a couple of tests with both a down and up cut bit and report my findings.

There´s also something going on here:

I meant attach the project file. The generated GCode doesn’t help much if I don’t know what the project looks like, and the gcode is too dense to be able to see much on its own.

3 inch round box bottom.mage (36.4 KB)

sorry, my mistake see attached.

I run a simulation in another program as to eliminate errors from MillMage algorithm / control and the paths are aligned well.

.
.
Do you have an ATC or change the cutters manually?
Maybe you can run only the affected path / shape on another piece of wood just to verify…

I apologize to all (and especially you Oz). I purchased a new 1/4” upcut bit and tested. The artifact is no longer present. Oz you were correct, the downcut bit and my aging Xcarve must have caused the issue. As you described, the downcut bit must have been causing my Z axis to remain elevated just that tiny amount until the zig finally zagged so that the bit could finally reach its full DOC.

I am so very sorry to have wasted your time. In the future, I will try and perform more accurate triage on the potential of a physical anomaly before jumping to the virtual possibilities.

2 Likes

It’s ok - At least now I know it’s correct. :slight_smile:

1 Like

I learn something from this. Thank’s

2 Likes