Very slow feed - gcode from dmap2gcode

CNC Machines Shapeoko
1

Hi Guys

I’m not sure if this is an issue with Grbl, Carbide Motion, dmap2gcode, or user error, so bear with me. Knowing me, this is something simple that my typical overthinking has caused me to be blind to. I am using a newly built Shapeoko XXL.

I used dmap2gcode to generate two milling operations: a roughing pass and a finish pass. The roughing pass worked beautifully with a 1/4" end mill running feed at 50mm/min and plunge at 25mm/min. It wasn’t nearly aggressive enough for a rough pass, but it worked overall, so I didn’t kill it.

Now, when I went to run the finish pass, the feed rate was incredibly slow. It didn’t matter what I entered for the feed or plunge in dmap2gcode, the XXL would move at the exact same rate. If I exported new code with different values like a lower Z-Safe, that is respected, but it would still crawl for all moves. The exception is rapids, which it has no problem with. I’ve cranked the feed up to a ridiculous 4000mm/min with no change, and I’ve checked the max feed in Grbl which is set to 5000mm/min.

Can anyone shed some light on this? Here are links to the two nc files, as well as my Grbl settings:

Rough: https://drive.google.com/open?id=0B4QPvDHcUA-daHQwU1g4cjlEajA
Finish: https://drive.google.com/open?id=0B4QPvDHcUA-dODUtRVprNTdvbU0

$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=6 (dir port invert mask:00000110)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=255 (status report mask:11111111)
$11=0.020 (junction deviation, mm)
$12=0.010 (arc tolerance, mm)
$13=0 (report inches, bool)
$14=1 (auto start, bool)
$20=0 (soft limits, bool)
$21=1 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=0 (homing dir invert mask:00000000)
$24=100.000 (homing feed, mm/min)
$25=1000.000 (homing seek, mm/min)
$26=25 (homing debounce, msec)
$27=5.000 (homing pull-off, mm)
$100=40.000 (x, step/mm)
$101=40.000 (y, step/mm)
$102=40.000 (z, step/mm)
$110=5000.000 (x max rate, mm/min)
$111=5000.000 (y max rate, mm/min)
$112=5000.000 (z max rate, mm/min)
$120=400.000 (x accel, mm/sec^2)
$121=400.000 (y accel, mm/sec^2)
$122=400.000 (z accel, mm/sec^2)
$130=425.000 (x max travel, mm)
$131=465.000 (y max travel, mm)
$132=80.000 (z max travel, mm)
ok

EDIT: I’ll also mention that I never see the velocity in Carbide Motion exceed 100mm except during rapids. Don’t know if that’s related…

Thanks!

2

It’s not GRBL, Carbide Motion, The problem: crappy software, and lack of knowledge (user). Take a look at the attached, the feed is 65mm/min (should be more like 200mm/min. This is very east to fix. (A) Use better software if it won’t let you program at a higher feed rate, or (B) open the program in a text editor (OR GCode editor) and do a FIND and REPLACE to change the F65.000 to F(WHAT EVER YOU WANT)

1 Like
3

This won’t affect your speed, but if you have an XXL you need to change you max travel settings to take advantage of the entire work surface.
Your settings:
$130=425.000 (x max travel, mm)
$131=465.000 (y max travel, mm)

Both $130 and $131 should be set to closer to 838mm (33 inches).

1 Like
4

Thanks for the replies, guys.

@RichCournoyer - I understand how it might seem like a lack of knowledge, but I’m not completely knew to CNC and gcode. The software was picked only so I could get some quick ‘n’ dirty code from depth maps. I have Fusion 360, but haven’t looked into how I might leverage the depth maps I have for cutting reliefs.

As for the F65 feed, that’s from the roughing pass file, which worked fine for me. It’s the second file, the finish pass, that has a feed being ignored. Even with the same F65 as the rough pass, the router crawls. I tried F125, F220, F400, F800, and on up, all with no effect.

@dtilton71 - Thanks, Dustin. Just haven’t gotten around to changing the max X & Y. I’ve been doing small test cuts as I ramp up, so I haven’t needed the full cutting area quite yet.

5

@RichCournoyer - I’m sorry, I see now why you said that. I forgot that I linked to one of the earlier nc files, version 02, where I hadn’t yet upped the feed. I was trying to show a side-by-side of the two files. One, the rough pass, where the feed seemed like an acceptable speed at F65, and the finish pass, where F65 did not seem to have the same movement. Later versions of the finish pass nc file have higher feeds like I mentioned in my last message with no change in speed.

6

Sorry, I am a doubting Thomas. The Shapeoko is as smart as a parrot, and will travel as fast as YOU set the feed rate (up to 5000mm/min).

I looked at your program and see different feed rates (They can me Plunge, Ramp Feed, etc), if you are not setting the correct feed (F) the feed won’t change. Clear?

You can continue to use dmap2gcode, you just need to increase your knowledge of GCode I think.

When I program (Either Carbide Create OR Fusion 360) I (a) set the feed very aggressively, and call the program Something Rev A.nc and if I see things are not working well, I will open text editor and change the appropriate feed (Plunge, Ramp Feed, etc) and then (b) rename the program something Rev B.nc, etc

Hint: in Fusion, when setting up my tool, I make sure that every feed rate (Plunge, Ramp Feed, etc) is different (example 22, 6, 5, 4 inches/min) so that I can pick and choose EACH feed rate when doing a Find and Replace during the editing.

IF you don’t believe me…

  1. Click on MDI
  2. Type G1 X (something) F100
  3. Type G1 X (something) F200
  4. Type G1 X (something) F400

and you will see that the Shapeoko responds nicely and accurately to each given feed rate GCode

1 Like
7

Thanks, Rich. Definitely part of what’s frustrating about this problem is I did essentially what you suggest before I posted here. i.e. different values to keep the feed and plunge rates segregated, opening the files to do a find and replace, etc. The big difference being that I started with a slow feed and moved toward aggressive rather than the other way around.

The only other difference in the code generation, afaik, is roughing was calculated for a 1/4" end mill and the finish was calculated for a 1/8" ball.

I hear what you’re saying, and I’ll certainly try and do some manual tests with MDI when I get home after work. There must be something dumb I’m missing, so maybe a day away from the machine will provide the needed clarity.

8

In the past, difficulties like this have been encountered when the G-code file had many short moves, and the comm / control program only sent 1 line at a time, which I’d thought was a solved problem — I’d suggest submitting the file to Carbide 3D and the Grbl support page on Github and see what they can puzzle out.

Have you tried it in a previewer/simulator? http://www.shapeoko.com/wiki/index.php/Previewing_G-Code

Alternately, try sending it using a different program, Universal G-code Sender (Java) or bCNC (Python) — if the file works at a reasonable speed then, we can narrow it down to Carbide Motion.

2 Likes
9

Thanks, Will. Those are good suggestions. I haven’t had an opportunity to sim it or send it with anything other than CM, so I’ll try that tonight (or maybe at lunch in a few minutes…)

I had heard something about short moves being an issue. I think the finish pass file is chock-full of short moves since the Z is constantly changing for 3D cuts, right?

10

Do you have a preferred sim program? (I’m using Windows)

11

If you’re using Windows, you owe it to yourself to try GrblGru which is flat out amazing.

I use NC Plot (an old free version, 1.1 — wish I could find a copy of 1.2)

1 Like
12

OK, preliminary results:

Thanks for the tip on GrblGru. That was a great test and it revealed that, not only should the feeds be working as expected, but I’m not crazy. I can make the simulated cutter fly over the piece. I also spoke with Apollo this afternoon and he went over some possible issues, such as the overall resolution of the model I’m trying to cut. I think that might be the “pixel” setting in dmap2gcode.

As you suggested, Will, Apollo also mentioned trying another gcode sender other than CM. Sure enough, it looks like that might be the bottleneck. I now have the finish pass running at the correct speed using Universal Gcode Sender.

More testing after work, but it’s looking like there’s something about Carbide Motion that doesn’t like the number of lines necessary to cut such fine detail? Related to acceleration? TBD

Thanks everyone who chimed in!

13

Yep, just final confirmation. The job is nearly done using Universal Gcode Sender. I’ll send an email to Carbide support at some point so that they can at least look into it further in regards to Carbide Motion.