Tracking algorithms and speed change.

Hi,
I've been pretty quiet, occupied elsewhere for a while, but I'm back, and keen to get going again. For those who don't know, I decided at the beginning of this 2009 year to design up a new machine using an ST Microelectronics ARM 100 pin 72MHz microcontroller. I got 15 boards built, and they are useable after a few jumper placements to correct a bad edit I made designing the board.

The topic question,
At the moment, I've got an interrupt running 5 channels PWM, 5 channels servo motor or brushless ESC, and 4 on-board bipolar stepper motor drivers. (L298 with some feedback)
At the moment, I've got the steppers running as fast as possible without speed ramping, and with decent drive waveforms. I can (theoretically) bump the speed up to 16 x faster, but that wouldn't work without some speed ramping and other finessing. However, it promises some room for granularity in acceleration.

I haven't done any g-code parsing code yet, but I was thinking to convert each G-code as it comes, into a start to finish coordinate array in 4 axis. This processor has 20k RAM. I could be non economical and allow 4 bytes per axis per point stamp (16 bytes), but if I have a long, detailed move, then this translates to... say 256mm x 1/256mm accuracy, = 2^16 x 4 bytes x 4 axis. Nasty !

So, I think I'll have to calculate mostly on the fly, with a short lookahead buffer for speed profiling. That way, I can do coordinate calculations and acceleration, deceleration calcs in the main loop, with results available in the buffer, for the interrupt.

To complicate this, I'm still a relative C novice

Acceleration and Deceleration can be pre-calculated, assuming that the mechanical power and inertia at each axis is OK.

Have I got anything here really wrong ?

Any other things I've missed ?

Edited 1 time(s). Last edit at 11/05/2009 01:34AM by grael.

---

My CNC/extruder creation: [grael-minifactory.blogspot.com]

Hi grael,

in old-style CNC-controllers most ramping and accel/deccel was made with speed profiles drawn from a table with sinus-values - so you mustn't calculate on the fly, but it consumes memory ...

Viktor

Hi Viktor,
The microcontroller has 128k Flash, so table memory is easy. It's also pretty fast on maths, so I'm thinking that calculating on the fly will work fine. Anything too complex, I can precalculate at the compile level, or as part of the boot process. At the moment, I'm using 4 different values for pwm phase states in motion and at rest(per motor), but here, I'm looking at the step inclusion rate per axis for that axis speed.

I will have to try to picture the process mentally I think

I'm trying to work on the motion control logically to break it down into processes, with the G-Code parsing being one of the last things to tackle

Simple linear ramping algorithms take up very little run time or RAM.

Non-linear algorithms can be simple or evolve into raging beasts comsuming the entire scheduler period, depending on what is required.

if you need more ram, just add a 62256 or similar - remember, it doesn't need to be as fast as your processor, only as fast as your stepper!

I wouldn't bother though, trapezoidal envelopes are trivial to calculate in real time and should work fine. [machinedesign.com] has some diagrams and a heap of equations if you really want to get stuck into acceleration profile stuff, and google knows of plenty more

... i remember a tricky/funny way of outputting high complex binary patterns for CNC-machines without any CPU - simply attach a binary counter/latch to an EPROM where the dir-/step- or coil-activation-patterns are stored in ascending order.

This could be simple accelerating data or even complex paths ... depending of the memeory-size ...

Viktor

I think it's a few steps closer to coming together. Literally ! I have my X and Y axis end limit detectors installed today.

More progress in due course on one of the build threads, or my build blog.

---

My CNC/extruder creation: [grael-minifactory.blogspot.com]