I’ll give it a-go. Thank you @TimS for the troubleshooting ideas.
A few questions for ya on carbide: What ‘machine’ setting do you use in carbide create? Or the post processor code (GRBL or ‘Basic G-Code’) to be using?
Anybody else having success with V pockets or carves generally?
Set it to GRBL
Welp, @TimS we got similar results. I tried a different file and used carbide. Though i do think Carbide did a better job with lettering once it was moving and in the ‘channel’ but both Krabz and Carbide seem to produce the same effect when they do their initial ‘pecks’. I think the pecks are perhaps closer with Carbide…maybe?
In each it “ramps down from the side” and this is where it shows the extra pecks or incomplete paths.
And the outcome is …
I messed with the depths and Z zero to see if it would clean it up a bit but no luck.
Maybe @mkrabset has the right theory and it’s related to the Maslow4 itself and its relation between the Z and the XY?
Anyone interested in trying this file with a 30 Degree bit?
30Deg.Blue.Carbide1mmDPTH.TST3.2.nc (16.8 KB)
MARK.TEST.SVG.Carbide.c2d (108.1 KB)
Some notes:
Does this mean that the machine starts moving sideways before it finishes the Z-axis move?
@bar it is hard to say. But i don’t think so. A summary from what we know…
From the pictures above i see two issues:
The outline of the ‘name tag’ does not complete nor the “R” in “Mark”. This happens whenever there is an entry or exit point (I think entry, particularly).
The ramp down shows extra pecks. It ramps down from the outside of the mail line of the cut. (see the tiny peck just below the arrow in the picture and compare to the route path).
From previous discussions and testing, the behavior above does not seem to occur when I am doing an inside profile of the same SVG, only when I am doing a V Pocket (Carbide OR Krabz --tested).
This is very curious because @mkrabset tested on a non-maslow machine and issues 1&2 did not appear.
I would possibly expect something like this to occur if my Z zero was not properly set because the pecks with a V-bit reliant on depths of the bit to make the proper cut widths on the surface appear as they should.
Suffice to say i’m at a loss and am curious how those ramp downs may go for someone else’s Maslow4.
As always thank you everyone for troubleshooting with me! What a great community. I know these things are ‘pecky’ 
and appreciate everyone so much.
Looking at your simulated cut path and the actual cut. The pecks look to be in the right spots.
Thought 1: I think the reason they look out of place is that they aren’t connecting to the rest of the letter. I believe that this is due to the small depth of the cut and changing z axis during the v pocket isn’t deep enough to notice.
I would try a deeper cut with wider letter for more area to v pocket. (However, I think the effect that you really want might be achieved by a contour cut with a v-bit)
Thought 2: The z axis movement is not in line with x/y movement. If the z axis lifts up to fast before the x/y begins to move it will peck instead of have a gradual ramp in or out. This would probably be software related, but you could try to lower your z axis speed to see if that changes anything.
Try each separately to test each variable at a time. I’m curious if @mkrabset made his cut as a v-pocket, looks more like a contour
@TimS I made the cut with a 30deg vbit using the nc-file shared by @HobbyBody earlier.
The black color is acrylic paint, just to improve contrast.
@TimS These are good suggestions.
Thought#1 was my first thought. I tried a dozen different methods/ depths separately:
Thought#2- This is a good idea. I’ve varied the z axis speed only slightly on two cuts as a test of timing (i’m wasn’t sure if Maslow4 responds to z axis speed commands or if there was a range.)
I’ll give this last one a-go and report back. I’ll try two cuts with fast z and slower z movements.
If thought #2 is an accurate description of the problem as evidenced by @mkrabset test vs my test, then the issue would maybe in the software or decoding being done on the Maslow4…maybe?
It’s possible that its in the software decoding of the gcode, but the Maslow control system is built on top of FluidNC which has been around for years and is pretty widely used, and that’s built on GRBL which is almost ubiquitous so it’s more likely to be an issue somewhere on the Maslow side with hardware or something else
If we think movements are going to fast maybe try enabling G61 for a test. It will likely slow the whole program down for exact stopping but in theory the Maslow will go to every point programmed.
Hey @Dano - Forgive my stupidity. What is G61
It is a cnc g code command that forces the cnc to go to every point before moving to the next point physically.
I think it would have to be manually added to your file unless it’s a setting in the cam software to turn on.
it does not look like fluidnc implements g61
http://wiki.fluidnc.com/en/features/supported_gcodes
David Lang
Oops I couldn’t find that page before responding. I was looking at the grbp support page that had it listed
