Is it just me or does Carbide Create plunge at a really fast rate when doing tabs? Doesnt seem like changing plunge speed has an effect on this. When deep slotting aluminum it gets a little scary and you can see evidence of tool deflection in the walls.
I love using create for simple stuff but this is my one big issue. Also who do I pay so we can have ramping?
Thanks for any help 
Yeah…pretty sure it’s not going to happen…
Fusion360.
I already use Fusion but still much faster to use Create on some 2d prototype stuff.
Doesnt hurt to ask right
Yea. I just came here to figure this out too. I have come to the conclusion that the plungerate for tabs stays at the same as the feedrate. Why doesn’t it use the plungerate?
If I’m correct in this observation, this can’t be too big of a change for Carbide3D. A ramp would be sweet, but it would be a simple change to get it to honor the plungerate parameter we already specify.
It would make a huge improvement (and eliminate a major frustration) for users that use tabs. I’ve been doing aluminum sheet engraving lately. The engraving is great, but the cutting fails on tabs about 50% of the time.
Since I’m calling this a bug, not a feature request, that should be prioritized, right? Where do we submit bugs?
I would repost this on the Carbide Create Pro what do you want to see thread. @robgrz runs the project and checks this thread. BTW, it is not that ramping was not asked for before but you probably have more influence than the rest of us have.
Thanks for that tip. I did post it.
I don’t know the complete business model for Carbide3D and how this Pro fits into it. But if the base software is what is included with machines, it should be fixed in that software.
This one problem has been my biggest frustration since getting this Nomad. When you have to restart a program (several times) and skip the first couple operations because it stalled on a tab plunge, that is a major pain.
Today, I learned how to edit this out of my G-Code manually. It was super tedious. But all the cutting I did was perfect. No more stalled spindle and faulting out because of it.
So, Carbide3D, if you want to improve the joy of your new users, please fix this bug.
Have you looked at the gcode and confirmed that it’s not changing the rate for the plunge on a tab? Given that meshcam does this properly, it would be very surprising if it was wrong in carbide create (same guy, same post)
Yes. I looked at the G-Code, compared it to a normal plunge. As I already stated, I edited the a bunch of G-Code manually to test this out.
I’m no expert at this stuff, but it is pretty simple, hopefully my explanations make sense.
Here is an excerpt of a tab in the middle of a x-y cut, as generated by Carbide Create. the bold text is mine for description purposes, not part of the code.
For reference, I had these settings:
G1Z-0.914F6.3 plunge before x-y cutting at 6.3 mm/min
G1Y16.431F203.2 first move of x-y plane cutting at 203.2 mm/min
X34.904Y16.253
removed a few x-y moves for brevity
X36.482Y14.843
X54.563
Z-0.518 raise tool for beginning of tab
X59.738 x-y move to end of tab
Z-0.914 plunge at end of tab - no speed change, still at 203.2 mm/min
X149.812 resume x-y cutting
I manually fixed about 30 tabs yesterday with this method. The speed changes I added are in BOLD.
X54.563
Z-0.518
X59.738
G1Z-0.914F6.3
G1X149.812F203.2
The tabs I fixed, ran perfectly.
So, I guess you were right.
Fusion360 is probably in my future.
I would strongly recommend then that you contact support@carbide3d.com . Rob is pretty good about this stuff.
I was curious, so I did some poking at this…and got carried away with myself. I hope Rob doesn’t mind too much.
CC doesn’t have a separate directory for posts like meshcam, so no easy path there.
I dumped the strings from the executable, and found this.
DESCRIPTION = “Carbide3D-MM(*.nc)”
It implies it’s using the same post that MeshCam uses for Nomad. Rob is likely to have reused as much as he could from earlier projects…he wrote meshcam…probably uses the same toolpath engine…probably uses the same posts…I have meshcam…what does that post look like in meshcam?
So I read the MeshCam manual and looked at the carbide3d-mm post.
This is how it plunges:
PLUNGE_RATE_MOVE = “G0[SZ]”
PLUNGE_RATE_MOVE = “G1[Z] [FP]”
[FP] Plunge feedrate
[SZ] Safe Z height
It uses the “rapid” rate (G0) until it reaches the safe Z height (ie. where it expects there to never be any material) then slows and uses the plunge feed rate (G1…FP).
That’s clearly not what you’re getting though. So I kept poking, because now I was much more curious. I know the meshcam post for nomad works this way, I’ve used it many times.
I looked at the Shapeoko post in meshcam. It has no plunge statement. That’s interesting because it’s an optional statement in the post according to the manual. If it’s not there, it just uses the “FEED_RATE_MODE” statements. Which for Shapeoko post are:
FIRST_FEED_RATE_MOVE = “G1[X][Y][Z][F]”
FEED_RATE_MOVE = “[X][Y][Z]”
So I looked at the dumped strings again, and sure enough, you can see the strings for FIRST_FEED_RATE_MOVE, it’s values, they match up with both posts, but no PLUNGE_RATE_MOVE string. It looks like CC is actually using the “shapeoko” version of the post, not the “nomad” version of the post (both of which emit tool changes, by the way)
You’ll see exactly the behavior you describe - at the first move there will be a feedrate, and until the feed changes, the feed won’t be output again just like you describe. That also means you won’t get the rapid rate to the safe Z height, which can really slow down the whole cut.
On a lark, I tried setting CC to Nomad, to see if it made some adjustment to the post, and the output what still broken. It looks like it always uses the same post without changes which is what I expected, but means you can’t work around this by changing the machine type.
Because the posts aren’t separate in CC, you’ll have to ask @robgrz to fix it - looks like it just needs to use the Nomad post instead of the Shapeoko post. Maybe @WillAdams or @Luke can put in a good word to help it along 