Acceleration calculation in CNC

Advert

New Replies

Report Bug

Help/FAQs

Acceleration calculation in CNC

This topic has 13 replies, 6 voices, and was last updated 4 June 2020 at 21:52 by Iain Downs.

Viewing 14 posts - 1 through 14 (of 14 total)

Author

Posts
2 June 2020 at 20:19 #477080
Iain Downs
Participant
@iaindowns78295
Hi, all.

So I'm making a motor drive for my mill with a stepper and intend to drive it with my own code in arduino.

So far, I've ignored acceleration (in my first bodged CNC controller for a micromill and the current code for the drive), but with a table + vice + work weighting in at 50kG +, I suspect I can't go from zero to a lot without considering acceleration.

It's been decades since I did mechanics (the mathematical sort) in anger, so I want someone to check my logic.

Motor : about 3N

Mass of table: about 60kg (I'm assuming on earth Mass = Weight)

f=ma so max acceleration for the motor (a =-f/m) = 3/60 = 0.05 m/s^2 (^2 = squared )

also, from distance (s) = 1/2 acceleration (a) x time (t) ^2 we get

t = sqrt(2s/a)

assuming each motor step moves 0.01mm, I've created a table in excel showing the elapsed time to get that distance with the specified acceleration. From that we can get the time between steps which is how we set the stepper timing up.

The image below is the first few rows of the calculation

So the the first pulse (dt-4th column) should be 0.008284 seconds, the second 0.006357 and so reducing as the drive speeds up. The spreadsheet ends up getting to 0.05 m/s (5 centimetres per second( in one second which is what you would expect, so it's probably right.

Mind you that's 2500 pulses later.

Obviously microstepping will use shorter pulses.

So my plan is to generate the acceleration table when I get the velocity input and follow that for the step period until I reach the required speed and then follow a fixed time period until I reach the correct distance (or I encounter a gate) and then just stop. Deceleration is for wimps.

Mind you, I've just realised that my arduino doesn't have the room to fit that table in so I will have to generate it in another way. Hmmm. That's just software, though!

I hope this makes sense and that there's someone who can confirm the maths and approach!

Any suggestions for algorithm are also welcome!

Iain
Advert

2 June 2020 at 20:19 #15280
Iain Downs
Participant
@iaindowns78295
Some nasty maths
2 June 2020 at 20:36 #477088
John Haine
Participant
@johnhaine32865
This is I believe a much-studied problem with a number of algorithms. A very quick Google lead me to this but I have seen other papers on the topic.
2 June 2020 at 21:24 #477094
Iain Downs
Participant
@iaindowns78295
phew!

You are a better googler than I am. The stuff I found that was vaguely relevant was even more technical than this!

I will need to read this properly, but the essence of it seems to be an iterative process subtracting the root of the previous from the current step. Which actually is the essence of what I describe above.

s is increasing by the same amount each time so to get the time time to get to the current I calculate t = sqrt(2s/a) which is proportional to sqrt(n) and thus the step time is basically sqrt(n+1) – sqrt(n).

Who new I was clever?

Then it gets proper complicated and not for tonight. However, that looks very useful and I sort of get it.

It looks like the sqrt time on the arduino is around 50 microseconds so my brute force approach would work for speeds of up to 20kHz if I can't get to understand the maths here.

Many thanks, John!

Iain
3 June 2020 at 10:22 #477156
John Haine
Participant
@johnhaine32865
Hello Iain, well, I've been googling for technical papers in maths and engineering since Google first existed so I've gotten quite good at constructing search terms. I think the main insight in that paper is that there's a simple approximation for the difference of the square roots of two successive numbers, so you don't have to use the internal function at all. So you may be able to make your own algo by using just the approximation.

I'm interested in what you're doing as I'm in the process of building the Arduino-based electronics for my own table X-feed. At the moment I am testing it with a Ward division controller which isn't ideal (though I'm sure it could be reprogrammed). I'm using an Arduino but decided to use grbl rather than roll my own software, though being a 4-axis full CNC controller it's drastic overkill – but hey, it's free and takes care of things like acceleration so why not? Grbl just fits a standard UNO.

I'm slightly puzzled by your motor being 3N and not Nm, and the assumption that the torque 3 N(m?) produces an acceleration of 3/60 m/s/s. I haven't been through the sums but is that correct?
3 June 2020 at 11:39 #477185
Robin
Participant
@robin
Back in the day I yearned for a Roland CAMM-3 desktop mill, but with a young family it was unaffordable.

Now it way out of date and completely affordable, so I bought one, upgraded the screws and motor, hacked the processor and completely reprogrammed it. They come with full circuit diagrams and PCB lay out. Bliss.

I rewrote the code to drive 3 axes, control panel and blinky LED display all from one 4MHz Z80 processor. When I found the stepper driver part in their disassembled code it was so delightful I have never used anything else.

It involved breaking the whole tool path in to straight lines on the host PC then passing them over as required.

Each line included the number of accelerating steps, a number of constant speed steps and a number of decellerating steps. Axes either stepped on every interrupt or used a magic number. You added the number in to a 16 bit tally and if it carried you stepped. The acceleration table was a list of numbers to be put in the timer interrupt.

It was gentle on the processor when it reached the end of a line and began another, had to be really because it was stepping on teh NMI.. Things got a teeny bit exciting when the PAUSE button got pressed but that was more long winded than difficult.

Happy days. It is waiting for me to add the new tiny V belts to the spindle, I have cut three speed pulleys. I tried toothed belt but it was too noisy.
3 June 2020 at 11:54 #477191
Brian Oldford
Participant
@brianoldford70365
Have you looked at this? **LINK**
3 June 2020 at 20:22 #477292
Iain Downs
Participant
@iaindowns78295
John – thanks again for that link. I do get that it's taking an iterative approach and will try and reproduce in my spreadsheet when I've a moment so I properly understand it and then translate it into arduino speak.

I thought about GRBL, but actually it doesn't have the operations I want – I don't think. For example, I intend to put a switch on so I can set limits arbitrarily and have the table move there at one speed and back at another (for example).

I intend to make a console for it on an android table I've got knocking around, so I can do things like have a jogging slider (touch the screen and move to the right and the table follows – the further across, the higher the speed).

I feel much more comfortable writing my code than trying to follow someone elses!

So the architecture is an android table to decide what to do. An arduino to run some simple commands and the stepper and electronics to do the work. I've a build log started in another thread in this area. Happy to share the code when done.

Robin – my early microprocessor experience was the 6502 on the Apple II – only low level stuff was machine code to test various hardware interfaces I'd built (not very complicated machine code at that).

Thanks, Brian. THe comments above apply. I'd rather toll my own that take on someone else's (better) version. Well at home anway – in the day job I have less latitude…

Iain
3 June 2020 at 20:23 #477293
Iain Downs
Participant
@iaindowns78295
And, yes, John, you're right, it's 3Nm so the actual force available is higher, I think.

Iain
4 June 2020 at 10:38 #477400
SillyOldDuffer
Moderator
@sillyoldduffer
I've been distracted up this interesting byway, and am confused by the maths. John's paper compares ideal delays compared with those produced by Equation 13.

For 15 steps, my implementation produces the ramp:

0.60, 0.47, 0.39, 0.35, 0.32, 0.29, 0.27, 0.25, 0.24, 0.23, 0.22, 0.21, 0.20, 0.19, 0.19, 0.18, 0.18, 0.17, 0.17, 0.16, End

The ramp looks reasonable in that gap between steps gets progressively shorter as wanted for acceleration, but apart from starting at 0.60, my values don't follow the table. Nor do I understand how the numbers in the table correspond to an acceleration. I must be missing something again!

The complete Arduino program is:

My main goal is comparing the performance of Fixed Point maths versus Arduino floats, because the latter, while easy to use, are slow because most Arduinos don't have a hardware floating point accelerator. But I haven't got that far because I'm not sure my code is producing the right answers. Can anyone see if I've miscoded Equation 13, or any other blunders, or – if I've got the sums right – explain why the table is different?

I'm fairly sure the issue is me. I'm reasonably confident of my nextDelay() function, fairly confident the code for my interpretation of Equation 13 is OK, and very much less confident I've interpreted the equation properly. I sort of follow the paper, but my understanding is foggy. For instance, I've guessed the ramp's start value is 1.0 for no good reason.

Actual code driving a stepper motor needs a bit more thought. For example, in my code there's nothing to stop Equation 13 recommending inter-step delays too fast for a real motor to cope with. A practical driver would likely need to enforce a minimum inter-step delay to avoid losing steps. Though nothing else occurs to me, possibly other considerations. As when I try to use Q-format Fixed Point arithmetic, where the user has to keep a close eye on their range and accuracy limitations.

Dave
4 June 2020 at 11:58 #477421
John Haine
Participant
@johnhaine32865
On using grbl. I think really you can do whatever you want by sending it g-code commands from the MMI. So you could imagine setting it up so its calibrated, have it homed to some zero point, and rather than setting a switch to where you want your limit you could have a scale on the table and say for example

G01 X300 F100
G00 X0

Obviously you'd want to wrap those commands into a macro. I've found a neat thing called MIT App Inventor which seems to be a "Scratch" – like way to build Android apps. But I can't see much difficulty in principle in translating some simple MMI into streams of G code commands.
4 June 2020 at 12:00 #477424
duncan webster 1
Participant
@duncanwebster1
My milling machine table is driven by a stepper motor, controlled by Arduino, but not CNC. It has a speed control pot, start/stop/fast buttons and end of travel microswitches. I took a different approach to acceleration. The Arduino has a command 'tone', which outputs a square wave onto the selected pin at the selected frequency, so the code starts with the output frequency set to a slow value, every 5 ms it reads the speed pot, if the demand setting is higher than the output it adds a fixed value to output. Vice versa for slowing down from fast traverse, but at the moment if the stop is pressed it stops dead. All I can say is it works.

As I'm nervous of relying on a processor to stop it, there is a bit of relay logic involved, when the relay is de-energised (stop button pressed) it resets the output to slow and disconnects the processor output from the stepper controller. When start is pressed it immediately starts at 'slow'. Now working on tying in the DRO so it can have software end of travel switch rather than having to physically move a microswitch
4 June 2020 at 12:25 #477429
duncan webster 1
Participant
@duncanwebster1
I ought to have mentioned that when the relay is de-energised (and the Arduino disconnected from the stepper controller), the speed pot slider is grounded, so the Arduino thinks demand is zero and it ramps down the output
4 June 2020 at 21:52 #477553
Iain Downs
Participant
@iaindowns78295
Hi, Dave. I'm getting somewhere with this, but it's a bit of a struggle.

As I understand it, when the motor is accelerating each pulse will happen a little quicker than the last one.

The bulk of the paper is about the ratio between this pulse and the last one.

if we know the delay for a given pulse (Cn), the the next pulse time will be approximately Cn – (2*Cn)/(4*n +1), where n is the step number. Actually, I'm oversimplifying this. as this is the relative time. We still need to multiple by a factor for the actual acceleration, Hmm. Needs more thought

So basically you calculate the time for the next pulse based on the last one and this calculation.

Having said all that, I'm halfway through getting my head round this practically and it's now about time to close down for the night.

I'll try and put this into my sketch tomorrow.

Iain
Author

Posts