Carbide Motion maxes out at 200mm per minute?

CNC Machines Nomad
1

I have access to a Carbide Nomad at a local Maker Space.

I have an issue/question about feedrates.

I am using a program called PyCAM to generate GCode. I am machining acrylic so I set the feed at 1118mm per minute. Looking at the actual GCode shows F1118.00000.

PyCAM estimates the part will require the tool to travel 38906.63mm and estimates it will take about 35 minutes. I have read these estimates should be taken with a grain of salt so I didn’t really know what to expect.

As the machine is working I see the changing X Y and Z numbers in Carbide Motion. I also notice Velocity seems to always be 200mm. Hmmm. Every once in a while it jumps to like 1000mm. I think that may have been fast moves, but did not think to pay attention at the time.

Three hours later I have my part. Success! I was happy until I started analyzing the numbers.

38906mm / 1118 mm per minute = 35 minutes
38906mm / 200mm per minute = 3 hours 15 minutes

The actual time the machine took was 2 hours and 53 minutes indicating an average feed rate of 225mm per minute.

The part is simple, an extruded trapezoid, 75mm x 30mm x 12mm. Everything is flat with sharp corners, nothing round. It actually came out really nice.

Am I understanding what Carbide Motion means by Velocity? If so, why am I restricted to 200mm? Why is Carbide Motion ignoring the feed rate I specified in the GCode? What am I missing?

What do you guys need to know to help? Since I don’t own the machine I don’t know all of the details. I will do my best to provide any information will help figure this out.

Thanks, and sorry this got so long.

2

  1. The GRBL settings from the machine. Send $$ through the MDI and it will report back a bunch of settings.

  2. The gcode. If it is generated with a lot of tiny segments, the machine will try to accelerate and decelerate every segment, never reaching top speed.

1 Like
3

Thanks for the reply.

  1. I will not be able to get the GRBL settings right away. Hopefully I will have time tomorrow to go over and play with the machine.

  2. I understand what you mean in theory. I do not understand the code well enough to tell just by looking at it. If that were the case I would think that Motion would reflect the changing velocity. I am 99% positive it never got above 200mm/min while it was cutting. I did notice a couple of times where it dropped into the 190s, but they were few and far between. My first pass was a roughing pass where I was removing 3 inch slices. I would think that should be enough distance to get above 200mm/min, but I am newb so I probably shouldn’t assume.

Hopefully I attached the GCode correctly.

.side1-14mm.nc (78.7 KB)

4

option 3: what version of CM? If CM4, has the feed rate setting been changed?

5

I don’t personally own a Nomad, but the Nomad spec sheet here:
https://carbide3d.com/nomad/specs/
Would indicate 100 inches per minute x/y and 50 inches per minute in z. I don’t know if that is working speed or during rapids though.

Dan

1 Like
6

The Nomad can only move so fast, since it’s using Acme threaded rod — best thing to do is to analyze the part geometry and toolpaths and see if possibly having a tool change or some other change to the CAM settings can reduce the machining time.

If you still have the file, please check it against the time estimate in CAMotics.

1 Like
7

You need to look at settings:

$110=500.000 X Max rate, mm/min
$111=500.000 Y Max rate, mm/min
$112=500.000 Z Max rate, mm/min
$120=10.000 X Acceleration, mm/sec^2
$121=10.000 Y Acceleration, mm/sec^2
$122=10.000 Z Acceleration, mm/sec^2

They’re kind of obvious, but you need to keep in mind that acceleration and max rate need to generally be adjusted together. ie. if you set a high max rate, but leave the acceleration low, you’ll never get up to the high rate. However, depending on how much torque you actually have available, you may not be able to set the acceleration very high before it starts skipping steps (you’ll know, it’s pretty dramatic - doesn’t hurt anything, just…obvious) . Get things dialed in before trying to run a job, it can take some experimentation. You may not be able to go higher than 200ipm, depends on the machine, how tight it is, all sorts of things.

(reference here: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration)

1 Like
8

Gcode looks fine, other than having some inefficient moves. I think you should see the machine moving at your feedrate (or the max feed set for the machine…just realized this was the Nomad category).

It would be nice if it was this easy, but even if your code was a single straight line, one pass, that method won’t work because of the acceleration.

Ran on a sim (faster than a Nomad can go apparently), and I was seeing your feedrate.
sim_Feedrate

1 Like
9

So much food for thought. Thanks for all the replies.

I did test with CAMotics, just didn’t think to mention it. It shows the same estimates as PyCAM.

I don’t feel like I am trying to push the envelope. I set my feeds and speeds based on what Carbide 3D says is appropriate for machining acrylic on the Nomad. I realize the time computations I posted are overly simplistic. The difference between the “perfect case” estimates and the actual time just indicates something isn’t right to me.

I went and played with the machine today. The version of Carbide Motion is 3.0.366, build date 2016-11-01. GRBL version is 0.9g.

I played around with watching Carbide Motion while homing and cutting air. The tool definitely is capable of moving faster than it cuts for me. I was able to observe the velocity jump during rapid homing movements as well as during fast moves while cutting. When it is cutting though, the velocity goes no higher than 200.

Here is the result of $$. It looks like all factory default to me. $110, $111 and $112 would indicate that I should be able to cut faster than 200mm/min. I really expected to find them set at 200.

Test Waiting…

<Idle,MPos:-5.000,-5.000,-5.000,WPos:-5.000,-5.000,-5.000,Buf:0,RX:0,Ln:0,F:0.>

gc_not_motion

___________$$ ___________

$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=1 (dir port invert mask:00000001)
$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=200.000 (x, step/mm)
$101=200.000 (y, step/mm)
$102=200.000 (z, step/mm)
$110=2600.000 (x max rate, mm/min)
$111=2600.000 (y max rate, mm/min)
$112=1270.000 (z max rate, mm/min)
$120=270.000 (x accel, mm/sec^2)
$121=270.000 (y accel, mm/sec^2)
$122=270.000 (z accel, mm/sec^2)
$130=250.000 (x max travel, mm)
$131=250.000 (y max travel, mm)
$132=100.000 (z max travel, mm)
ok
gc_dwell
___________N0 G4P0.05 ___________
gc_get_offsets
___________$# ___________
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:553.000,883.000,-112.195]
[G59:-123.420,-107.380,-127.000]
[G28:0.000,0.000,0.000]
[G30:-2.500,-5.000,-5.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:-2.500,-107.380,-75.255:1]
ok
gc_parser_state
___________$G ___________
<Idle,MPos:-5.000,-5.000,-5.000,WPos:-5.000,-5.000,-5.000,Buf:0,RX:0,Ln:0,F:0.>
[G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 F0. S0.]
ok
<Idle,MPos:-5.000,-5.000,-5.000,WPos:-5.000,-5.000,-5.000,Buf:0,RX:0,Ln:0,F:0.>

10

Maybe that version of CM doesn’t report correctly? The little GIF above was made running your file with no modifications. Feed will reach 1118mm/min.

Try another sender.

11

I played with the Nomad some more today.

Good idea/bad idea…I don’t know, but it worked. I modified the GRBL settings for $110 and $111 and set the max feed to 1118 mm/min, the recommended feed rate for acrylic. I then replaced all G1 in my code with G0. The Nomad flew! I had my part in about an hour as opposed to three! The velocity in Carbide Motion pegged out at 1118 and would at times drop down depending on the move.

I also played around a with UGS 1.09 Classic. I was running short on time, but I was able to figure out how to get UGS to connect to the Nomad and cut air. I am not familiar enough with UGS yet. I could not find any place where it showed the current velocity of the tool like Motion did. I ran my code through the first roughing pass and it took a bit over 6 minutes. The is close to the time it took me to run my first roughing pass using all G0 fast moves.

Carbide Motion will not go over 200mm/min on the library’s Mac. It will not go over 200mm/min using Carbide Motion on my personal laptop. If I run UGS from my laptop initial tests show that UGS will follow the feed rate in my code.

I guess I will probably go forward using UGS, but I don’t like that I can’t figure out what is wrong with Carbide Motion. It doesn’t make sense. Surely I can’t be the only one using 3.0.366 that would have noticed this kind of problem.

12

Try CNCjs

13

Replacing G0 with G1 is really not the way to go about this. Just regenerate the gcode with the feed rate set the way you want it. If you’ve reset the machine max, the G1 commands will go as fast as you set them, but no faster than the max. Using G0 turns off all the fancy speed management and optimization between commands in the GRBL software.

Just like “Be Kind, Rewind” - be sure to put the machine back to it’s original settings so you don’t mess up the next guy…

1 Like
14

Nope.

That is the problem.

Before I changed it the max for X and Y were set at 2600 mm/min but the Nomad would max out and go no faster than 200 mm/min for linear movements.

My code sets the feed rate at 1118mm/min but Carbide Motion seems to ignore that even when the max is set to 2600.

15

Gotta say that is weird. Wonder if you were to reflash to controller if it would sort that out. Have you contacted support@carbide3d.com?

16

Then there is something else going on here, worth figuring out. Everyone else seems to be able to do this.

17

I did some more testing today.

I used UGS and cut air. The time it took to do my roughing passes show the tool is moving at an average speed of 1113mm/min. A toolpath following the contour of my part moves at 1115mm/min. I know the math is overly simplistic and I am not cutting material but my part is done in 45 minutes as opposed to 3 hours!

To test further I used MeshCAM to generate the tool patch. I did not bother to tweak too much, just rough the part and finish it with 1118mm/min as the feed rate. When I loaded the code into Carbide Motion the velocity of the linear movements was always at or around 1118mm/min when you would expect it to be. It also does lots of other weird movements that confuse me, but that is beside the point.

At this point I think Carbide Motion does not like my PyCAM generated code. I looked at the MeshCAM code and notice that the feed rate is set 374 times. Hmm. Just for fun I may try adding lots of F1118.0 into my PyCAM code and see what happens in Carbide Motion.

18

That is… weird.

I went back through the code you posted at the beginning and I still don’t see anything in particular. One thing I do see when I look at the G-code on a decent editor is that each line ends with multiple ctrl-M (return) characters. and most movement blocks have a space at the line start. If this came from the toolpath generator (and isn’t an artifact of file conversion when you uploaded it or some other irrelevant issue), maybe that is an issue. It shouldn’t be, but you never know.

19

Can you send $G and report back what you see? Not expecting anything unusual, but this all seems odd.
Can you try a different version of CM?
Does CM send any startup lines?

20

I have looked at the code with Notepad and Notepad++. I looked at what I have on disk as well as downloading what I uploaded to look at it. I see the beginning space you mention but no ctrl-M. I may not have all the settings right to see such things though. Can you recommend a free editor that I could try?

I’ll try the $G next time I am over there.

Currently I don’t think I can try a different version of CM. The only versions available for download are 3.0.366(Mac), 3.0.368(PC) and 4. I have tried 366 on their Mac and 368 on my laptop with the exact same results. 4 is not an option for me as it would require flashing GRBL. I have spoken with the guy in charge at the library and it would require their IT department to get involved.

I have emailed support but have not heard anything back yet.