Page 1 of 3

acceleration

Posted: Wed Oct 07, 2015 2:15 am
by FargoPhil
I am new to cnc in general and am learning how to work my shapeoko 3. I've got an led laser that I added on and am having trouble with getting things to come out right. I believe that part of my trouble is that I don't understand how grbl deals with the acceleration setting. For a test, I wrote a little gcode to move the spindle from x0 y0 to x40 y0. I made two scripts that I would expect should be equivalent in their execution. In one, I incrementally change x by .1, in the other it's a direct x40 y0.

With the default acceleration the first code executes noticeably more quickly. When I increase the acceleration, they appear to run the same. But of course with the higher acceleration the machine jerks all over the place when cornering. So that doesn't seem like a proper solution.

Code: Select all

G21
F3000
M05
G01 X0.00 Y0.00
X40 Y0 M3 S0
M05
G01 X0.00 Y0.00

Code: Select all

G21
F3000
M05
G01 X0.00 Y0.00
X0 Y0 
X0.1 Y0 
X0.2 Y0 
X0.3 Y0 
X0.4 Y0 
...
X39.7 Y0 
X39.8 Y0 
X39.9 Y0 
X40 Y0 
M05
G01 X0.00 Y0.00
What's bothering me is that I'd expect that they both should be the same since the spindle is moving the same direction the whole time in both cases. No need to accelerate between commands. Any insights would be appreciated.

Thanks!
Phil

Re: acceleration

Posted: Wed Oct 07, 2015 1:25 pm
by cvoinescu
GRBL has a very short planner buffer: 17 moves, if I recall correctly. Each G-code command generates one move (or a bunch of smaller ones, if it's an arc). By necessity, because it doesn't know what follows after the last move in the buffer, the planner has to assume the machine comes to a rest at the end of that last move. As moves are executed and removed from the planner buffer and new moves added at the end, this assumption is revisited: but it always needs to be able stop at the end of the then-current end of the buffer. So it goes as fast as possible under the constraint that it must be able to stop using the available acceleration at the end of the 17th move. In your case, you give it, at best, 1.7 mm to stop -- so it can only go as fast as a braking distance of 1.7 mm would allow.

With the 40 mm as a single move, the planner knows it can accelerate for 20 mm and brake for 20 mm, so it can reach a much higher speed. It's also clear why increasing acceleration has such an effect on the 400 x 0.1 mm code.

Unfortunately, there's not enough RAM on the AtMega328p for a larger buffer (it even had to decrease from 18 moves to 17 when the serial buffer was increased from 50 to 70 characters). If at least 200 moves fit into the planner buffer, the two sequences would be nearly equivalent under any acceleration.

Re: acceleration

Posted: Wed Oct 07, 2015 1:43 pm
by FargoPhil
Interesting. That clears things up. I didn't realize the buffer was only 17 moves.
Is there a flag I can set to change the assumption that the spindle should stop when the buffer is empty? So instead of assuming after 17 moves we're going to stop, assume that after 17 moves we're going to be going the same direction/speed.)

What I'm thinking is to generate gcode like above for the actual image, then overshoot the border by a bit for the velocity change. Really what I think I want is for the laser head to be moving at a constant speed (should match the feed rate) while over the target area. It shouldn't be hard to set a buffer area around the outside of the target area to perform non-constant velocity operations (stop, increment y, accelerate in opposite direction.)

We'd wind up with gcode like this

Code: Select all

    G21
    F3000
    M05
    G01 X0.00 Y0.00
    X0 Y0
    X0.1 Y0
    X0.2 Y0
    X0.3 Y0
    X0.4 Y0
    ...
    X39.7 Y0
    X39.8 Y0
    X39.9 Y0
    X40 Y0
    M05
    X50 Y0
    G01 X0.00 Y0.00
The extra 10mm (or whatever) would allow the planner time to decelerate and turn around before going back to 0,0.

Re: acceleration

Posted: Wed Oct 07, 2015 2:25 pm
by chamnit
@cvoinescu is absolutely correct with Grbl's planner buffer assessment.

There are additional factors that must be considered. First, the AVR 328p has enough processing power to parse, plan, and execute one g-code block every 4ms guaranteed, based on tests. It can do it faster for smaller blocks and certain cases. In your program though, you are moving at 3000mm/min and each block is 0.1mm. This translates to 2ms per block. What might be happening is that your program might be needing to stream faster than Grbl can process this. You can help this problem by doing what you said, by adding a 1mm motion to have things catch up, increase the serial baud rate to 250000 to help increase throughput, and/or use an Arduino Mega2560. The planner buffer increases to 30 or so, I think, but the CPU is not any faster. An increased buffer can create some ideal conditions in the planner so it doesn't have to do as much work (hard to explain, but trust me on this).

Second, along with the stepper motor acceleration settings, there is another acceleration setting that Grbl uses called junction deviation. This sets how much acceleration that Grbl will move through a corner. Typically this value is something like 0.02mm or 0.01mm and tuned for milling machines. I would decrease this value to 0.005mm or less for a laser cutter (or 3d printer) and this should help eliminate any jerking problem through corners.

Re: acceleration

Posted: Wed Oct 07, 2015 2:40 pm
by FargoPhil
I'll look at the junction deviation this evening.

I've got a shapeoko 3. I'm not sure off hand what arduino the carbide motion board is equivalent to.

What I'd *like* to do is use the same machine for both lasering and routering, ideally without messing with the tools. I've currently got the laser attached onto the stock spindle mount. There's enough clearance to leave it on there and have the router installed. So the mass of the laser head is going to be relatively high compared to a strict laser cutter.

What it sounds like I need to do is run some tests to find the top acceleration I can run without issue and set the feedrate based on that. From there it will be a matter of adjusting the power to get the desired result.

Thanks!
Phil

Re: acceleration

Posted: Wed Oct 07, 2015 2:48 pm
by chamnit
Ah. The SO3 electronics has a 328p, so you're stuck there. To be honest though, a SO3 is superb for milling but isn't quite the ideal machine for laser cutting. You need a machine that is low-mass and high-acceleration. Stiffness doesn't really matter, since there aren't any lateral loads other than when changing direction. An SO2 or 3d printer machine would do a better job. That said, an SO3 will work fine, just as long as you understand it's not purpose built for it.

But, yes, I would increase the accelerations as much as possible for laser mode on your SO3. This helps the planner having to plan less per block (has some smart code in there to re-compute motions that change). And then limit the feed rate based on your testing.

You can also increase the block lengths in your laser g-code too. 0.1mm is quite fine resolution and the program you posted is redundant. Instead of moving X 0.1mm incrementally, you can do a complete line motion for the entire length, as you would in milling programs. Grbl will treat that long line motion as one planner block out of the 17, rather than individual ones for each g-code block.

Re: acceleration

Posted: Wed Oct 07, 2015 3:03 pm
by FargoPhil
I've been coming to the same conclusion (get a purpose-built laser machine), in the mean time I'd like to try and get the so3 to do the job. Actually, given that "the job" is to be a toy I can learn on, it's doing a bang up job. :)

The actual gcode coming out of the engraving software includes spindle changes to control the power of the laser. I removed the SXXXX portion since I was seeing the acceleration issue with or without it. In practice, each of those incremental moves has a different spindle speed.

Thanks
Phil

Re: acceleration

Posted: Wed Oct 07, 2015 3:44 pm
by Gadgetman!
Please note that the 115200bps speed is about 10K characters, which means that it can only transfer about 10characters/mS if operating at full capacity. Unfortunately, though, there's handshaking going on, the controller telling the sender when it can or can't receive more data.
So for every 4mS slot, it can at best transfer 40characters, in reality, it may be as low as half that.

One way of speeding up the transfer is to get rid of the 'fluff' in your files.
A G0 or G1 only needs the X/Y/Z that changes.
If there are comments, keep those at the beginning if possible.
Blank lines, spaces... Get rid of them.
Stay away from CAM packages that uses Inches internally if you design in Metric...

As for a flag to 'stop it from decellerating'... Yeah, and then there's an awkward bit of code in the queue.... Such as a heap of 0.1mm moves, then a 180degree change of direction...

Re: acceleration

Posted: Wed Oct 07, 2015 4:00 pm
by FargoPhil
That's a really good point re; the transfer speed. By the sound of things the target for each line of gcode is < 20 bytes. I'll keep that in mind. I've been digging around in the Universal GCode Sender source, and could probably implement a pre-processor feature to cut out X/Y/Z/S if the previous row had the same value. Sounds like there would be some benefit here for that.

I have the impression there is no flag to change the planner's assumptions about what's beyond the buffer. So that idea was a dead end.

Thanks
Phil

Re: acceleration

Posted: Wed Oct 07, 2015 4:13 pm
by cvoinescu
I agree with most of what Gadgetman! said, except the bit about handshaking. There is no in-band signalling from the host to GRBL, and the signalling from GRBL to the host does not eat into the bandwidth of the other direction. In practice, UARTs often work with no overhead at all, at the theoretical speed (115,200 bps in this case). With 8 bit encoding, no parity, and 1 stop bit, that's 10 bit periods per character, or 11,520 cps, or 46 characters per 4 ms interval. That's enough to keep GRBL's buffer full.
FargoPhil wrote:I have the impression there is no flag to change the planner's assumptions about what's beyond the buffer. So that idea was a dead end.
There can't be one. The planner can not make any assumptions about what's beyond the end of the buffer: the only safe behavior is to plan to stop at the end.

If there was such a flag, what would happen at the end of your code? Execute last G-code command in your file assuming machine will continue to move full-speed, then no command comes. What now?

Even if you don't use the assumption unless the buffer is full, you still have a problem. You have 18 moves left. You're at X = 38.2 mm moving full speed east. You need to stop at X = 40 mm. How do you do that? Same problem if the 18th move (the one not yet in the planner buffer) is a sharp corner that can't be taken at full speed, or even after 1.7 mm worth of braking.