Increasing the Max Feedrate?

Technical Details
1

In my tests and trials on the Maslow, I have been trying to optimize the feeds and speeds.

I am a CNC programmer for a large cabinet manufacturer in my area, so I have some experience doing this on production machines. There are two types of bits we use most, 1/4" downshear and 3/8" compression. The 1/4" downshear bits spin at 18000rpm, 6000 mm/min, 10mm in one pass. The 3/8" compression bits spin at 18000rpm, 16000 mm/min, 19+ mm in one pass. Now, I know that trying to run the Maslow at the same sort of speeds isn’t going to work, since it’s not nearly as powerful as these gantry-style production machines.

I used this speed calculator I came up with at work to help do the optimization of the Maslow:

image
image990×425 28.1 KB

The lowest RPM available to me on my router in 10K, so I lowered the spindle speed on the calculator and came up with an optimal feed of 2500 mm/min. I made up a couple of test programs, and was surprised to see the machine wasn’t actually running at that speed. Okay, I didn’t measure the actual speed, but it certainly looked like it was slower than it should be. Also, the bit was squealing. It was ear-piercingly loud, which usually means that something’s off.

I did a little digging. I remembered seeing somewhere a mention of a maximum feedrate hardcoded into the machine. When I opened up the firmware, I found the value under CNC_Functions:

image

In the spirit of experimentation, I tried increasing the value to 3000 just to see what would happen. I will admit, I was a little nervous I was going to overheat and fry the motor controller. However, in running a couple of test cuts, the machine hadn’t let the smoke out yet. I ran two tests. First, I tried cutting 4 straight, horizontal lines, each at different speeds. The sound did improve when it got to the 2500mm/min line. Also, I ran my calibration test, and circle within a square. I definitely didn’t expect the results:

IMG_20171021_114019
IMG_20171021_1140192448×3264 1.47 MB

The straight line test is at the bottom, cut into one of my original square calibration tests. I’m not entirely sure what caused it, but the lines deviated quite a bit from what I programmed. The circle in the square test above that is even further off. Some of that may have been the sled drifting, but I saw the motors trying to adjust their position as the sled made it back to the correct location. It almost looks like one of the encoders wasn’t keeping up with the other. Or maybe the interval of the PID tuning is too long? The only programming I know is G-Code and a little scripting so I’m not entirely sure how to fix this issue. If anyone has any ideas, I’d like to try them out.

I’m also going to see if making some tooling changes solves my problem for now. I ordered some 1 flute upshear bits from the Maslow store. According to my calculations, the idea feedrate for that bit is 1000mm/min (see the above feedrate table, the bit in question is 2 rows down from the highlighted one), so it should work pretty well at the Maslow’s top speed of 900. I will also try plunging my 2 flute bit deeper into the plywood and see if that helps.

I made the switch over to a pantograph sled just after I ran these tests, so I first have to get the machine dialed back in :stuck_out_tongue:

7 Likes
2

The machine was designed for a max speed of 48 ipm to go faster than that you need either faster motors or larger sprockets. I picked up a set of 25 tooth sprockets which should give me a max speed of 110-120 ipm

The other problem you will run into is that we do not do any acceleration planning yet, so at higher speeds you will run into problems at corners, especially when cutting in the bottom corners.

3

Huh, so when I told the firmware it could go faster, it tried and the motors just couldn’t keep up? Interesting.

I like the bigger sprockets solution myself. I’ll have to give it a try at some point. I’m guessing there’s a quite a few settings that would need to be changed to get that to work.

That’s a good point. I know the SCM group routers we have at work have acceleration planning, and it really helps with their faster speeds.

5

no, just one setting that sets the sprocket size, and that should be changed
from a diameter to a tooth count (and calculate the diameter from there)

6

Would bigger sprockets result in lower resolution?

Yes, but not enough to notice, currently we have 8148 pulses/rev, with under
2"/rev, so cutting this resolution in half won’t affect accuracy.

Looking at the motor drivers, the chip used has a wide range of operating
voltages and there are a wide range of motor voltages. What would be the
effect of driving the motors at 24v with the same gearing? (With suitable
adjustments to the shield, of course).

the current 12v motors would burn out.

Then there¢s the mechanical considerations with moving a mass at a higher
speed - the oscillation and ¡swing¢ from changing direction at higher speed
will be greater.

From my experience of desktop CNC, you get great returns from acceleration
planning over basic grbl (TinyG/Smoothieware, for example).

basic grbl inclues acceleration planning.

I¢m as impatient as the next bloke when it comes to watching something be
cut… and I have some pretty powerful spindles to play with… I¢ll be
watching this space with interest.

It’s not just a matter of being impatient, as the top post in this thread talks
about, the proper feedrate for the bit size, edge count, and rpm is needed to
keep from burning out bits. Currently, we are moving slowly enough with high
enough rpms that this is a real problem

7

The setting is gear teeth, but the diameter isn’t calculated in the current firmware.

9

I’d be more concerned about the current limiting drivers, although whether or not brushed motors respond to higher voltages like steppers (as in compensating for inductance with faster acceleration) is an interesting question

10

Ahem

See the above, perhaps Dr. Google already has the answer to acceleration vs induction for higher voltages on DC motors

11

Would those happen to be something like these sprockets? I checked the specs on the motors and it seems that they have a 8mm output shaft. The part linked above has a bore of 3/8", not sure if that would be close enough. Otherwise, I’ll have to buy a 1/4" bore sprocket in a machinable alloy and turn a bigger hole on it with a lathe. Or course, this will require me to either borrow someone else’s lathe or buy one myself.

Precisely. Honestly, if the required feedrate is 10 ipm I wouldn’t care in the slightest and we wouldn’t be having this discussion.

On the note of wearing out bits, I would just like to ask if anyone else has noticed how loud their machine is because of the low feedrate.

Do you have a supplier for these motors? We have enough trouble trying to source worm-gear 12v motors for people who want to build their machines without a kit. I’d rather fix the issue through some code changes and parts that can easily be found on McMaster or another hardware supplier. Also there’s the issue of providing that voltage for the motors without letting the smoke out of the driver board, as @mooselake mentioned.

FIFY. Please be civil on this forum.

12

I purchased something like these

I would get metric sprockets, not try for ‘close enough’ and boring them out is
a lot of effort for very little benefit compared to just buying something.

13

Some forums and other online venues invite and encourage flaming and insults (a certain lead Linux developer comes to mind). We’ve taken a more respectful approach here.

A poster at the old Bell Labs comes to mind. “Tact is the art of telling somebody to go to Hell, and have them smile as they leave on their journey”

4 Likes
14

Linus generally attacks ideas not people, a significant difference lost on a lot
of people who aren’t involved there.

He accuses them of being careless or sloppy sometimes, but very much avoids
attacking them as a person.

15

The way those lines sag reminds me of the way earlier versions of the firmware rendered G00 movements. Were the lines made with G00 commands using firmware v0.91 or earlier (before, say Oct.5)? More recent firmware keeps the motors coordinated during G00 moves, so I think those cuts would be straight now.

1 Like
16

That might have something to do with it. I think I ran those tests before I updated my machine to v0.94, so they could have been run on v0.87. Those cuts should have all been G01 commands, however. Maybe because I was trying to run the motors at their max RPM the behavior is similar to the rapid commands, which I’m assuming also are the high end of the RPM range. But you also said that you were able to patch that with the newer firmware, so maybe I’m grasping at straws here. I’ll have to give it another test with more modern firmware when I’m at the machine next.

I got the single flute bits from the Maslow store yesterday. Now all I need is a little time in the shop to give 'em a go, along with everything else I’d like to test. One day I’ll have time…

1 Like
19

Apologies. I overreacted. I used to mod on an old gaming forum and a comment like that usually started a flame war. Good to know we’re all fairly level headed around here.

The motor you linked is very similar to the one in the kit. The encoders seam a bit cheaper, but as you mentioned you could simply use better encoders. The bolt pattern is even the same, so you could easily swap them out without needing to change brackets. I think the 24v @ 470rpm would be a good one to test. Please let us know the results of your tests, it would be great to see which solution to the problem works best :wink:

20

Maslow doesn’t use a stepper for the Z, it could, but that would be a software
and hardware change to drive it. We use an encoder+brushed DC motor just like
the other axis

for the encoder, you want something with 1000-4000 steps/rev for the two main
motors, the Z axis needs much less, there a couple hundred steps/rev is good
enough.

David Lang

21

Actually, the motor in the kit is 11 P/R as well, 11P/R *4 steps/P *291 gear
ratio = 8148 steps/rev

24

Pulses/revolution, aka PPR pulses per revolution. That’s 11 pulses per turn of the motor, or 8148 per turn of the sprocket.

26

pulses per revolution in the encoder. I thought you had used that earlier.

28

Every field invents it’s own jargon to keep out the uninitiated (says the cynical moose…). At least it’s not 3D printering where level isn’t level, resolution isn’t resolution, etc.