Once a year I attempt to get my boat anchor (a/k/a Nomad 883 Pro) to work. I’m definitely getting closer. I bought mine to cut and engrave metal and I’m starting with 360 brass first. I think I have acceptable feeds & speeds for the 1/8" and 1/16" endmills and now I’m trying to find acceptable settings for a 30 degree v-bit.
The settings I currently use do work…however, for a 1" x 0.5" area that is 0.1" deep it takes about 4 hours. Ideally, I would like to cut that time in half.
If you haven’t read any of my previous posts…I’m a complete newbie to CNCing. I’m using both Carbide Create and Carbide Motion.
Here are the current settings that I am using for the 30 degree V-bit:
Retract Height - 4mm
Diameter - 0.25"
Flutes - 2
Flute Length - 0.5"
Angle - 30
Feed - 50 ipm
DOC - 0.003"
RPM - 10,000
Stepover - 0.008
Plunge - 10
Does anyone have any suggestions and to which parameters I should change and what it should be changed to in order to significantly increase the speed to get the job done?
your retract height is very very high… 1mm is more likely a better answer.
in vcarving retract height becomes dominating at times…
Thanks for that tip Arjan…it cut the time from 4 hours down to 3 1/2 hours.
Can I simply double my Feed Rate to 100? If I do that do I need to adjust any of the other settings? Or should I double to DOC to 0.006 instead? Or should I double both the Feed Rate and the DOC?
The theory is like so:
- for a given RPM, feedrate and number of flutes, you end up cutting chips of a given thickness. The math is chipload = feedrate / (RPM x nb of flutes). And chipload basically represents how aggressive you are in taking bites from the material. If you have a set of feeds and speeds that works for you, and you want to “just” move faster, then you can increase the feedrate AND increase the RPM in the same proportion, and you will end up with the same chipload, so the cut will pretty much be guaranteed to still go fine (actually, higher RPM will decrease cutting forces so if anything it should be an even easier cut)
- DOC is a different, unrelated parameter. The deeper you cut, the largest the forces on the endmill (because for a given chip thickness, the deeper you cut the longer the chip, and cutting “longer” chips takes more effort). If you double DOC, all other things being equal, you pretty much double the efforts on the endmill/machine. How deep a DOC you can achieve depends on the material, endmill diameter, machine rigidity, and stepper motor torque.
In your case, you initial post mentions using 10.000RPM, 50ipm and a 2 flute endmill. That’s a 0.0025" chipload. That works fine because you are taking such a shallow cut (0.003").
If you double the feedrate, and SINCE your RPM is already maxed out at the Nomad’s 10.000RPM limit and you won’t be able to increase it, you will effectively double the load. Would it still work ? Hard to tell without experimenting, the easiest would be for you to test incrementally higher feedrate values, using the feedrate override during a cut. If you push the feedrate and it stills sounds and looks fine, then you know. And it feels much more comfortable to start from a know good value, and dynamically bump the feedrate by e.g. 10%, see if it still works, rinse and repeat.
If you double the DOC, you will double the load. Again, would it work ? Maybe, maybe not, at some point the machine will give up (in the case of a Nomad, it’s likely to show up as the spindle stalling, or getting excessive chatter)
This is my super-long-winded way to say…just try incrementally higher feedrate and DOC values, and when you find the limits, dial that down by 10% and you will have found the maximum usable setting for that particular material and endmill combination. Sometimes it’s possible to theoretically predict the highest feedrate and deepest DOC that should be achievable, but vbits are just weird (e.g. their tip has a rotation speed of zero…) so experimentation is key.
So I went into CC and doubled both the Feed Rate and the DOC (separately and together)…and the estimated time to complete was exactly the same. Any idea what I am doing wrong now?
It’s probably a bug/toolpath refresh issue.
For the sake of testing, if you recreate a new toolpath from scratch with the same selection and cutting parameters, is the time properly reduced then ?
If this turns out to be a glitch in CC, you can double-check your old and new generated G-code files themselves in one of the online G-code viewers that provide a runtime estimate.
For example this one, if you copy/paste the content of your G-code file in there, it will tell you the total estimated duration.
I thought that could have been the issue, so I had closed out CC and reopened and tried again…but with no change. I did notice that the estimated time in CC was significantly longer than the estimated time in CM…but the reality was that CM was just completely wrong and in the end, the estimated time in CC was very close to reality.
Thanks again Julien!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.