I have been using the Advanced V Carve quite a bit lately. I noticed that on some sections the speed slows down alot. For example, I have a bit that I set to go 50 IPM and in some sections it slows down to 8 IPM. I was curious if it did it on purpose on small detailed sections. I threw that theory out when I have duplicate sections because on the identical section sometimes it was the original 50IPM and on others 8IPM.
Is this normal?
Here is the one I have in the machine as we speak. As we speak the bit is at 8IPM around the ax.
Braves-Final.nc (2.7 MB) Braves-Final.c2d (355.5 KB)
Also worth noting that the estimated time in Carbide Create and Carbide Motion doesnt equal the same time.
The v-carve toolpath has the plunge rate set at 8ipm and the feedrate at 50ipm,
so what you are seeing is effectively that in some parts of the cuts, there are many plunge moves, especially on that axe area, see all vertical red lines in the toolpath preview:
CC tends to not fully optimize the number of times it plunges/retracts in V-carve toolpaths, it is what it is. What you could probably do is increase that plunge rate though (what material is it ? you can probably double or triple those 8ipm safely)
And yes the time estimation is sometimes a bit off in CC. You can double-check/compare with time estimates from other online or offline G-code viewers if this is a concern for you.
Appreciate the feedback. Will look at making edits.
Here is another example I had. On some of the hands in the attached files it cut at 8IPM and some at 50IPM. They are all the same shape, curious why the difference?Schroering.nc (865.9 KB) Schroering.c2d (51.2 KB)
Also for the Braves sign, I found a spot that is of concern also. While your comment makes sense Im still concerned. Note the section in the image. This area i noticed slows down to 8IPM, much like other portions of the text carving.
Here is a link to a video. You can see it go from 8 to 50. Not trying to prove you wrong by any means just trying to make sure everything is good. Thanks for the help!
Did you mean to include a video ? I see a jpeg still image
I’ll try and check the g-code for that specific portion of the text carving
Mmmh, interesting. If I zoom in on the outer curves of the v-carve, the trajectory is all noice and smooth:
but if I zoom in very closely on the tight areas, for example on that portion of the cut you mentioned, I see these strange hiccups in the trajectory:
I wonder if it’s a display artefact, or a g-code generation side effect, I’ll dig further.
If it’s there in the G-code, then I wonder if acceleration/deceleration along these micro movements might cause the overall movement to crawl to a slower average feedrate
EDIT: better illustration, with the associated G-code line:
Sorry…
Thanks, so that video confirms that the slowdown occurs in an area with the squiggly trajectory lines, while the fast move is in an area with smooth trajectory.
I wonder if it’s an artefact introduced by CC due to rounding errors or something, considering the very small stepover (0.008) and small size of those vcarved areas. Later I’ll try and regenerate that same V-carve toolpath in Vectric’s VCarve to see how it behaves in that area.
@Rdevine Can you share the original image? The one you imported to Create. I’d guess the issue originates there.
(the vector in the c2d file looks clean though)
Hmmm…I also assumed that those zigs and zags were the Z going up and down (which would explain the slow feed), but they are XY moves with no feedrate change. I’m changing my bet…now I’m guessing it’s a buffering or serial communication issue with all of those tiny (.001") moves.
That’s a really good bet. I never bothered to look into how GRBL manages consecutive segments at a constant feedrate, and how accels play a role in that or not at all, can you enlighten me ?
Regardless, it will be interesting to figure out why those microscopic moves are generated in some areas of the toolpaths, and not in others (larger outside curves). I feel there might be something related to rounding errors at small scales, lack of smoothing, something like that. What I noticed also is that these small deviations are not visible in CC preview, but there are there in the G-code as visualized in another viewer.
Ok so the G-code generated by VCarve from the same vector at the same stepover is clean:
I went back to CC, created a new file, draw some random text, and created an advanced v-carve toolpath, exported the G-code, zoomed in in that other viewer, and saw the steps along the path:
I guess it’s time to call @robgrz to the rescue to notify him, maybe he knows about this, and if he doesn’t that could go in the CC improvements bucket list.
I’ll try and run some sample files on my machine to see if I see the same slowdown effect as @Rdevine or not.
Let me know if there is anything else you need. Do you still need the original SVG file?
Well actually yes, just in the name of science (because my test in Vectric VCarve was from a re-exported SVG from CC, which may have altered things, so I’m 99.999% sure it didn’t
