Raspberry Pi

[irving2008]

Oops, forgot the cutarc() subroutine

Let me know what else I forgot

Robin

Thanks.

Been playing around with interpolation routines but run into a snag... so need to go back and rethink the code I've written. Issue is this... in 2D to make it easy... want to move from 0,0 to 1000,1300 say (steps, not mm). Lets assume that the feed rate requires this to take 1 second... then the x rate is 1000steps/sec and the y rate is 1300 steps/sec. But I have a base rate of 5000 steps sec (10khz interrupt/2). so X is every 5th interrupt and y is every 3.85 interrupts.. but you cant do 3.85.. so i need a much higher interrupt rate and some interpolation... in this case 50000 and divisors of 38,38,39,38,38,39,38,38,38,39 per 5000 gives 1301 with a max error of 2 steps... So i need to get that kernel level interrupt working... in the meantime, i'll have to run it all at 1/10 speed :(

[bobc]

Thanks.

Been playing around with interpolation routines but run into a snag... so need to go back and rethink the code I've written. Issue is this... in 2D to make it easy... want to move from 0,0 to 1000,1300 say (steps, not mm). Lets assume that the feed rate requires this to take 1 second... then the x rate is 1000steps/sec and the y rate is 1300 steps/sec. But I have a base rate of 5000 steps sec (10khz interrupt/2). so X is every 5th interrupt and y is every 3.85 interrupts.. but you cant do 3.85.. so i need a much higher interrupt rate and some interpolation... in this case 50000 and divisors of 38,38,39,38,38,39,38,38,38,39 per 5000 gives 1301 with a max error of 2 steps... So i need to get that kernel level interrupt working... in the meantime, i'll have to run it all at 1/10 speed :(

You could try the Bresenham line algorithm, it extends to n dimensions.

[irving2008]

You could try the Bresenham line algorithm, it extends to n dimensions.

I'm already using a modified form of that. The issue isn't one however of where the line goes, but how fast it goes in each axis. If the pulse rate is derived from a fixed clock, then the granularity of the pulse rate is limited.

[bobc]

I'm already using a modified form of that. The issue isn't one however of where the line goes, but how fast it goes in each axis. If the pulse rate is derived from a fixed clock, then the granularity of the pulse rate is limited.

Well sure. It's a question of what level of accuracy you are aiming for, sub-atomic ? :)

Apparently on the Pi there is a USB interrupt at 8Khz which takes around 20% of the CPU, so getting a 50kHz interrupt might be a challenge.

[Robin Hewitt]

It is fun isn't it, the hours I spent making it work. Everytime I thought I had it figured I found the next little snag

I find the major axis which steps on every interrupt, and slave everything else to that. I reload the timer after every step from the acceleration table, stretching the delay by 1.5 (approx root 2) if both X and Y go together.

I can give you the working code that drives my mills but it may not help being written in Z80 assembler. It runs from a pre-digested buffer of straight lines without any multiplies or divides. On a slow CPU, 8MHz, the interrupt steps anyone set to step on entry then reconfigures the step and direction lines at exit.

I'm a bit of a dinosaur.