Page 1 of 1


Posted: Wed Oct 31, 2018 2:25 pm
by Mitch2312
I am very new to the world of CNC but learning my way so please accept my apologies if I do not use the correct terminology but I will try my best to explain my problem
I am having an issue in MAKERCAM (from Inkscape) when try to pocket the number 0 as in 2018.
What happens is instead of pocketing between the 2 lines that make the inner and outer guides of the number 0 it wants to hollow out the whole thing leaving me with a round hole not a neat 0
I have tried:
Using different fonts
Opening in Chrome not IE
Set the tool diameter to 1mm
Checked that they are all on the same layer
Increased the size of the number
I have tried highlighting the whole 2018
I have tried clicking on the inner line first then the outer line of the 0 and vice versa

I am really at a loss now so would value any help and assistance in this.
Many thanks



Posted: Wed Oct 31, 2018 2:56 pm
by WillAdams
Usually this is caused by a font with incorrect winding --- try converting to paths (might have to create the file in Inkscape, then load as an SVG).


Posted: Wed Oct 31, 2018 6:20 pm
by Mitch2312
Many thanks for your reply.
I am sorry but I have no idea what you are talking about.
Please tell me what I have to do and how to do it if you could.
Thanking you in advance
Best ever


Posted: Thu Nov 01, 2018 9:30 pm
by Mitch2312
Is ther nobody out there who can help a novice with a quick fix to this issue with the number 0?



Posted: Sat Nov 03, 2018 2:10 pm
by WillAdams
Set the type in Inkscape, convert the type to paths using Path | Object to Path and if need be, correct the direction (outermost path should be counterclockwise, inner path clockwise --- fill should always be to the left of the path.

Then, import the file and select the geometry which you need for the pocket.


Posted: Tue Apr 02, 2019 3:18 pm
by Xaracen
Actually I have been having this same issue with makercam, and it is especially problematic with arc segments. It seems to have a lot to do with how wide an angle the arc segment bends between nodes. When I export a simple circle from my drawing app (Xara Photo & Graphic Designer), it creates the circle as four arcs each of 90 degrees, each arc has a node point at both ends, each node joining two arcs together. Makercam's own 'insert circle' creates a circle with just two 180 degree arc segments. In my Game Counter project (see Members Project section) the helipad symbol gave me and makercam a lot of grief, because while the Pocket CAM operation correctly hatched the gap between the inner and outer ring, as well as the H in the middle, when it came to calculating the paths makercam would ignore the inner ring and pocket the entire disc, wiping out the H, and often also pocket several cut widths outside the outer ring too, just for good measure!

I got round this by manually inserting three additional nodes on each 90 degree arc on both circles, so no arc bent more than 22.5 degrees. Makercam was entirely happy with these.
See the pic below. The helipads (yes, I know!) are 5.6mm across, and the toolpath used a 0.5mm cutting bit.
Hekipads comparison.png
Hekipads comparison.png (32.34 KiB) Viewed 4387 times
This issue has never affected me before, and I wasn't happy, and several other things had been bothering me enough that I resolved to see what I can do with makercam to improve it. The pocket bug is not going to be easily resolved, I expect, but this simple workaround worked pretty well, for me at least. And the other things I have managed to fix, especially loading alternate default CAM toolpath settings.

Edit: I forgot to mention that reversing one of the paths never worked for me, and other than the Helipads, I never had a problem. And in the case of the Helipads, I could select the whole helipad and pocket it in one operation, makercam would correctly identify and hatch the required areas automatically, which most of the other free CAM don't really do well.

Edit: update, To create a ring I normally create two concentric discs, and subtract the inner disc from the larger one. These fail to pocket in makercam. But if I first rotate the inner disc by 22.5°before subtracting it then its nodes are no longer in line with the nodes of the larger disc. Makercam pockets these perfectly. In makercam you can achieve a similar result by moving one of the circular paths slightly out of perfect alignment from the other. These will also now pocket correctly!


Posted: Wed Apr 10, 2019 3:39 pm
by GurneyHalleck
Looks like we need to start a list of MakerCAM issues!

At least I can easily reproduce the pocketing error. That’s a start:
pocketissueSS1.png (221.03 KiB) Viewed 4320 times
More to follow.


Posted: Tue Apr 30, 2019 3:15 pm
by Xaracen
OK, we can cross off the circle hatchfill glitch, just fixed it. I think it was only ever a cosmetic problem, but it looked a little unsettling, and it might have contributed to the Pocket Bug, but it seems essentially irrelevant to that.

Makercam's circle is formed from two 180° arc segments. Each arc joins the same two coordinates, both curve from A at one side of the circle to B at the other side of the circle. To be a proper closed shape, however, the final coordinate of the second arc should return to the initial coordinate of the 1st arc, so all I did was swap the two coordinates of the 2nd arc over, in the function that creates it, so now the 1st arc goes from A to B, and the 2nd from B back to A.

The Pocket Bug is definitely odd. If you have two concentric circles and pocket the gap between them (call this a ring) you can avoid the bug if you nudge one of them vertically off-centre, even by a single pixel. A horizontal nudge doesn't do it. You can also rotate one of the circles instead of nudging it, and that can work, but not necessarily for all angles. The safest way, until the bug is fixed, is to nudge one circle up and left by a tiny amount, and that immunises the ring for all rotations, as far as I can tell from testing.

A horizontal alignment of the circles' centres, and with one or more of the points the arcs pass through, seems to be the defining criterion. But not always, sometimes the bug doesn't happen when you think it should, so testing will continue.

Edit: I've been calling my own fork of makercam FlatCam, but I've since discovered that name is already taken for a PCB-CNC utility, so for now I will be calling my fork XaraCam until I come up with something better. Anyway, the Pocket Bug is my current focus, and makercam's other issues will have to wait until that is solved, unless a fix for something else becomes apparent while I'm trawling through makercam's code, as happened with the circle hatching glitch.


Posted: Fri May 31, 2019 8:52 pm
by Xaracen
Update: Makercam's Pocket Bug is actually at least two bugs, and probably three. The one that is triggered with two concentric circles has now been properly fixed, and tweaking of drawings isn't needed anymore.This was due to a couple of missing 'corner cases' in the nesting routines that should have had checks but didn't. They do now, and they work properly. The issue wasn't specific to circles but to any set of paths in which the starting points of the paths shared a common y coordinate value, that is they were horizontally aligned.

The other main bug is to do with how the offset curves are calculated using the toolbit diameter along with roughingclearance if set. If the diameter is too large for the width of the gap being pocketed, no cutting paths can be calculated, so when the calculations finish and remove the pocket hatch fill, there are no cuts to display in its stead, so you just see your drawn shapes with no fill. This isn't actually a bug, but it could be handled better with a 'your bit is too big!' message. If the bit is an easy fit for the gap, the calculations go just fine.

But if the bit is just a little smaller than the gap, makercam can get confused about how to fit the cutting paths, and the cutting paths end up obliterating the drawn shapes. That's Pocket Bug number 2!

It also turns out that some specific bit diameter/roughingclearance/stepover combinations can trigger something visually identical to the other bugs, with cuts rampaging where they shouldn't. A good example of that happened to me yesterday:

Two concentric circles (again, they are good test shapes) inner 10mm diameter, outer 14.2mm, so the gap between them is 2.1mm. Pocketing with a 2mm bit calculates OK. So does a 2.069mm bit. But a 2.07mm bit triggers the cutting path stampede. When we get to 2.137mm the stampeding cuts cease and we reach the 'your bit is too big' situation, ie, no hatch and no cuts.

But my default bit setting is 0.5mm, and one time I forgot to change this for the test circles above, and I got the cut stampedes. So I changed it to 0.51mm, and recalculated without any other changes, and it calculated just fine. Same with 0.49mm. But 0.5mm? Nope! And absolutely no question about having enough room. This wasn't the first time I'd seen this happen, but this time I was mentally tooled up from all the workouts on the other issues. :D

Keeping the 0.5mm and instead changing the stepover from the default 40% to 39% worked. So did 41%. Putting it back to 40%? Nope. So this is Pocket Bug number 3.

So these two bugs are now next on my priority list! I'm hoping the two are related and that fixing one will also fix the other, or at least that fixing one will leave me much better informed about the other.