MakerCAM - Issues with Circles (Google Chrome, Mac)

an open source, web based CAM package that works!
TonyB
Posts: 105
Joined: Mon Apr 29, 2013 3:34 am
Location: Norwalk, Ia

MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by TonyB » Mon Apr 29, 2013 4:04 am

Everything seems to be working well, except this one issue.

For whatever reason, when it's drawing a circle the X and Y axis are not moving at the same time. The X axis moves, then the Y axis moves, then the X axis moves, then the Y axis moves, and so on. This makes the circle look like a 'stair-stepping' sort of line. I assume it can only be one of two things: 1. A bug in the MakerCAM program (I realize it's a beta) or possibly the numbers I'm inputting for the profile operation.

I'm sure it's beneficial to mention I'm on Google Chrome on a Mac (and if I remember correctly, I'm on the developer version); I guess maybe I'll try another browser tomorrow.

Here's some more information.
This is what I'm trying to cut; though in this example I changed the target depth (and step down) to draw it with a pin.
Image

This is what I had used to draw:
Image

This is what I had used to cut, when I originally found the issue:
Image

This is what the drawing looked like:
Image

I originally created everything in Inkscape and opened it into MakerCam; whenever I had circles coming in they were completely out of alignment with everything else. I tried playing around with some ideas and figured out that if I swapped them out with squares they worked fine (pertaining to alignment). So I left the squares and then drew the circles in MakerCAM and lined the circles up in the middle of the squares, thinking that this would solve the entire issue.

Image

But... the issue continued.

So, doing some research I found this:
Image
Ignore all the horrible mistakes I made; my X axis hit once or twice... but the circles drew perfectly fine! So somewhere between drawing the circle and creating the g-code I'm either doing something wrong or there's some sort of bug in this workflow.

Any suggestions on what to do?

Thanks!
Tony

Here's another good example of being able to draw curves with no issues:
Image
MegaSquirted 62mm 7m @ 20psi on 91 octane
410whp/411ftlbs

Build Thread
Image

WillAdams
Posts: 8514
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15
Contact:

Re: MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by WillAdams » Mon Apr 29, 2013 11:27 am

What does the G-Code look like in a previewer?

The solution is to join everything into a single outline in Inkscape, bringing in only one object:

- Send the largest to the back
- Select it and a smaller object on top
- Path | Difference
- Repeat
Shapeoko 3XL #0006 w/Makita RT0701 Router w/0.125″ and ¼″ Elaire precision collets
Nomad 883 Pro #596 (bamboo)

TonyB
Posts: 105
Joined: Mon Apr 29, 2013 3:34 am
Location: Norwalk, Ia

Re: MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by TonyB » Mon Apr 29, 2013 1:41 pm

WillAdams wrote:What does the G-Code look like in a previewer?
Here's the gview for reference.

Image

This is exactly what it looks like when I visualize the 'nc' file in UniverstalGcodeSencer-v1.0.6. When I press 'send' to start running the file, the tool path on the screen makes the same motion as in the drawing I provided (stair-stepped).
WillAdams wrote:The solution is to join everything into a single outline in Inkscape, bringing in only one object:

- Send the largest to the back
- Select it and a smaller object on top
- Path | Difference
- Repeat
Awesome, I'll give this a shot tonight!

Thanks,
Tony
Last edited by TonyB on Mon Apr 29, 2013 4:31 pm, edited 1 time in total.
MegaSquirted 62mm 7m @ 20psi on 91 octane
410whp/411ftlbs

Build Thread
Image

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by cvoinescu » Mon Apr 29, 2013 2:25 pm

We've seen the circle/stairstep problem before, and it turned out to be very long lines, longer than GRBL could handle, so it ignored important parts of them. If you could post your actual G-code, it could be helpful.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

TonyB
Posts: 105
Joined: Mon Apr 29, 2013 3:34 am
Location: Norwalk, Ia

Re: MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by TonyB » Mon Apr 29, 2013 2:49 pm

cvoinescu wrote:We've seen the circle/stairstep problem before, and it turned out to be very long lines, longer than GRBL could handle, so it ignored important parts of them. If you could post your actual G-code, it could be helpful.
Hopefully this file attaches correctly; if not I'll find somewhere to host it and than attach a link.
Attachments
drawEndPlate.nc
Stair-step circle issue
(9.24 KiB) Downloaded 183 times
MegaSquirted 62mm 7m @ 20psi on 91 octane
410whp/411ftlbs

Build Thread
Image

pagercam
Posts: 12
Joined: Sun Dec 30, 2012 8:42 am

Re: MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by pagercam » Mon Apr 29, 2013 6:15 pm

TonyB wrote:
cvoinescu wrote:We've seen the circle/stairstep problem before, and it turned out to be very long lines, longer than GRBL could handle, so it ignored important parts of them. If you could post your actual G-code, it could be helpful.
Hopefully this file attaches correctly; if not I'll find somewhere to host it and than attach a link.
From the wiki line lengths (number of characters/line) maxes out at 50 in old versions 70 in newer but this file has lines as long as 87 characters majority of line are beyond 70. The positions are calculated out to 14 decimal places which is higher accuracy than the size of an atom, usually 3 decimal places is sufficient and as good as a CNC can achieve if everything is perfect. Check to see if you can reduce the resolution to something smaller or write a parser to do it for you. I believe that there was some talk about having GRBL or the sender throw an error for excessively long lines, are you using the latest version???

TonyB
Posts: 105
Joined: Mon Apr 29, 2013 3:34 am
Location: Norwalk, Ia

Re: MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by TonyB » Mon Apr 29, 2013 7:55 pm

pagercam wrote:From the wiki line lengths (number of characters/line) maxes out at 50 in old versions 70 in newer but this file has lines as long as 87 characters majority of line are beyond 70. The positions are calculated out to 14 decimal places which is higher accuracy than the size of an atom, usually 3 decimal places is sufficient and as good as a CNC can achieve if everything is perfect.
Gotcha. I think I see what you're saying.

When comparing my file ("drawEndPlate.nc") to the calibration file ("ShapeOko_Calibration_Pattern_01b.ngc"), I notice some major differences:
A line from my file:
X14.604060913705583 Y44.931472081218274 I43.20558375634518 J-8.241116751269036 F300
A line from the calibration file:
X35.4642 Y187.1220

Couple of questions:
1. So I assume based off calibration file I should round or truncate the X, Y, and Z numbers to four decimal places as a rule of thumb?

2. It seems like gcode is relatively easy to read. I assume this code is compiled once it's transferred to the Arduino?

3. In "ShapeOko_Calibration_Pattern_01b.ngc" it looks like there's mainly X, Y, and Z variables. But in "drawEndPlate.nc" there's X, Y, Z, I, and J variables? What are I and J?
pagercam wrote:Check to see if you can reduce the resolution to something smaller or write a parser to do it for you.
Couple more questions:
1. Would adjusting the resolution be a setting in Inkscape or MakerCAM? I would assume Inkscape?

2. I could pretty easily write a program to round or truncate part of the decimal, is that what you mean by writing a parser to handle the resolution?
pagercam wrote:I believe that there was some talk about having GRBL or the sender throw an error for excessively long lines, are you using the latest version???
This is definitely part of the problem. When I flashed my Arduino, I used the link on the wiki:
http://www.shapeoko.com/wiki/images/5/5 ... _basic.txt
Which was on:
http://www.shapeoko.com/wiki/index.php/Assembly_step_15



I'll plan on adjusting my gcode to eliminate the line number issue, then do a test run. If that works well then I will re-flash my Arduino with the latest grbl code from git. Then potentially update the wiki to help eliminate this issue in the future, if it seems necessary.

I eventually want to do my drawings in AutoCAD, but after doing a little bit of research it looks like the "AutoCAD to gcode" programs are all Windows based? If it's as easy to read an AutoCAD file as it is to read a gcode file, I may be obligated to write a program to convert AutoCAD to gcode.

Anyhow, thanks for the help so far! It's been a ton of fun playing around with this stuff and I'm feeling even more optimistic as I learn more about each "piece of the puzzle".
MegaSquirted 62mm 7m @ 20psi on 91 octane
410whp/411ftlbs

Build Thread
Image

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by cvoinescu » Mon Apr 29, 2013 9:27 pm

X, Y, Z, I, J and K are coordinates. They're in millimeters, and it makes no sense to preserve precision beyond one micron. Three decimals are plenty, but if you want four, so be it, as long as your lines are less than 50/70 characters long.

G-code is relatively easy to read. It consists of commands (which start with G, and some with M) followed by parameters. G0 moves as fast as the machine can go and is called "traverse", G1 moves at the speed given by the F parameter and is called "feed", G2 and G3 draw arcs, clockwise and counterclockwise. The expectation is that milling occurs during G1, G2 and G3, but not G0, which is why there's no speed ("feed rate") control for G0. Of the parameters, X, Y and Z are the coordinates to move to (usually absolute, but there's a relative mode too), and, for arcs, I, J and K are the coordinates of the center (usually relative, and K is for modes that are rarely used). If a coordinate does not change during a move, it can be omitted (which is why you see almost no Z parameters). With some commands (G0 to G3 included), you don't need to repeat the command on a new line if it's the same as before: you can supply just the new set of parameters (coordinates, and maybe feed rate), which is why most of your lines are just X, Y, I, J and F. Linear moves would be just X and Y (and/or Z if moving vertically too, and/or F if speed has to change).

G-code is not compiled; the Arduino runs an interpreter which receives it line by line and executes it. It doesn't move right away, then read another line. In order to avoid starting and stopping for each little move, it processes several commands ahead and feeds them into a movement planner, which schedules the moves as fast as it can while making sure that (a) it doesn't exceed the pre-programmed speed, acceleration (and/or jerk) limits of the machine, (b) it doesn't exceed the given feed rates, (c) it keeps the movements coordinated, that is, if several axes move simultaneously, they accelerate and decelerate together so that the resultant movement is a straight line (or an arc), and (d) it can stop at the end of the last command processed so far, while still obeying the same limits. It's fairly tricky to do this, and even trickier to do it on the Arduino Uno, which has only limited processing power. The Uno also generates pulses for every single microstep each motor has to move, each perfectly timed, while also doing what I described above. Be suitably impressed!

You can tell most CAM programs how many decimals to generate. Sometimes that's part of a post-processing step for the G-code. Some G-code senders can do that for you too. Failing that, just read the file and round any number after a letter X, Y, Z, I, J or K to 3-5 decimals (3 should be plenty for mm, 4 should be good for inch coordinates too).

The "AutoCAD to G-code" is what "CAM" is about. You design the part (essentially a shape) in CAD, and then design the manufacturing process for it in CAM. It's not as easy as converting, say, JPG to PNG, which any dumb computer can do. While there are programs that attempt to guess, and maybe even do a good job for simple parts, in most cases you have to tell the CAM program what to do and how to do it for each feature of your part (type of operation, choice of tool, other parameters). The CAM program helps a lot: once you've told it how you'd like it to mill a certain feature, it'll calculate what could be a very complex toolpath for you (the G-code), taking into account the geometry of the part, the geometry of the tool, and the practical limits of your manufacturing process (e.g. you can't mill more than this much material with every pass, you can't plunge more than this much at a time, you have to do a roughing pass stopping slightly short of the final shape followed by a finishing pass with a different tool, and so on). The CAM program will help you visualize the planned movement of the tool and the resulting object. It'll keep track of features and help you optimize the order of operations, and do all sorts of other things to make the process easier. But, ultimately, it's still a blend of design and engineering, with a human involved.

Check out the Wiki, which lists several CAM programs. Some run on systems other than Windows.
Last edited by cvoinescu on Mon Apr 29, 2013 9:50 pm, edited 1 time in total.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

TonyB
Posts: 105
Joined: Mon Apr 29, 2013 3:34 am
Location: Norwalk, Ia

Re: MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by TonyB » Mon Apr 29, 2013 9:45 pm

cvoinescu wrote:X, Y, Z, I, J and K are coordinates. They're in millimeters, and it makes no sense to preserve precision beyond one micron. Three decimals are plenty, but if you want four, so be it, as long as your lines are less than 50/70 characters long.

G-code is relatively easy to read. It consists of commands (which start with G, and some with M) followed by parameters. G0 moves as fast as the machine can go and it's called "traverse", G1 moves at the speed given by the F parameter and it's called "feed", G2 and G3 draw arcs, clockwise and counterclockwise. The expectation is that milling occurs during G1, G2 and G3, but not G0, which is why there's no speed ("feed rate") control for G0. Of the parameters, X, Y and Z are the coordinates to move to (usually absolute, but there's a relative mode too), and, for arcs, I, J and K are the coordinates of the center (usually relative, and K is for modes that are rarely used). If a coordinate does not change during a move, it can be omitted (which is why you see almost no Z parameters). With some commands (G0 to G3 included), you don't need to repeat the command on a new line if it's the same as before: you can supply just the new set of parameters (coordinates, and maybe feed rate), which is why most of your lines are just X, Y, I, J and F. Linear moves would be just X and Y (and/or Z if moving vertically too, and/or F if speed has to change).

G-code is not compiled; the Arduino runs an interpreter which receives it line by line and executes it. It doesn't move right away, then read another line. In order to avoid starting and stopping for each little move, it processes several commands ahead and feeds them into a movement planner, which schedules the moves as fast as it can while making sure that (a) it doesn't exceed the pre-programmed speed, acceleration (and/or jerk) limits of the machine, (b) it doesn't exceed the given feed rates, (c) it keeps the movements coordinated, that is, if several axes move simultaneously, they accelerate and decelerate together so that the resultant movement is a straight line (or an arc), and (d) it can stop at the end of the last command processed so far, while still obeying the same limits. It's fairly tricky to do this, and even trickier to do it on the Arduino Uno, which has only limited processing power. The Uno also generates pulses for every single microstep each motor has to move, each perfectly timed, while also doing what I described above. Be suitably impressed!

You can tell most CAM programs how many decimals to generate. Sometimes that's part of a post-processing step for the G-code. Some G-code senders can do that for you too. Failing that, just read the file and round any number after a letter X, Y, Z, I, J or K to 3-5 decimals (3 should be plenty for mm, 4 should be good for inch coordinates too).

The "AutoCAD to G-code" is what "CAM" is about. You design the part (essentially a shape) in CAD, and then design the manufacturing process for it in CAM. It's not as easy as converting, say, JPG to PNG, which any dumb computer can do. While there are programs that attempt to guess, and maybe even do a good job for simple parts, in most cases you have to tell the CAM program what to do and how to do it for each feature of your part (type of operation, choice of tool, other parameters). The CAM program helps a lot: once you've told it how you'd like it to mill a certain feature, it'll calculate what could be a very complex toolpath for you (the G-code), taking into account the geometry of the part, the geometry of the tool, and the practical limits of your manufacturing process (e.g. you can't mill more than this much material with every pass, you can't plunge more than this much at a time, you have to do a roughing pass stopping slightly short of the final shape followed by a finishing pass with a different tool, and so on). The CAMP program will help you visualize the planned movement of the tool and the resulting object. It'll keep track of features and help you optimize the order of operations, and do all sorts of other things to make the process easier. But, ultimately, it's still a blend of design and engineering, with a human involved.

Check out the Wiki, which lists several CAM programs. Some run on systems other than Windows.
Wow, that was quite the explanation. I'll have to re-read that a time or two to really comprehend what you wrote.

I'll probably reply with more questions later on, once it really sinks in.

I'll definitely be adjusting the decimal places as soon as I get home. I wasn't dead set on 4 places after the decimal, I just threw that out because that's what I saw in the example that drew a circle relatively well. Having 4 places after the decimal has a better chances of running into row length issues; so I'll more than likely go with 3 places after the decimal since you suggested it.

Thanks again!
Tony
MegaSquirted 62mm 7m @ 20psi on 91 octane
410whp/411ftlbs

Build Thread
Image

WillAdams
Posts: 8514
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15
Contact:

Re: MakerCAM - Issues with Circles (Google Chrome, Mac)

Post by WillAdams » Mon Apr 29, 2013 10:27 pm

The solution I posted is for circles not being aligned --- the too-long line matter is documented in the wiki.
Shapeoko 3XL #0006 w/Makita RT0701 Router w/0.125″ and ¼″ Elaire precision collets
Nomad 883 Pro #596 (bamboo)

Post Reply