Raspberry Pi

[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.

[irving2008]

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.

No, but with 1 step = 0.05mm, a few steps out is problematic. I'm running at 10KHz interrupts now but there are reports of others handling 100KHz interrupts, using the PRE_EMPT flags in the kernel compile (another reason to re-compile). The only speed limit I have right now is the fact that the interrupt handler runs in user space so context switching is a significant part of the interrupt latency (about 50uS measured).

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.

Thats essentially the way I am doing it. I have a buffer of 1024 'moves' but if I have to fill it with 1 step moves its going to need to be much bigger or the steppers are going to run out of work to do... Or did you convert the whole of the G-code into steps before putting it in the buffer? How big is your buffer?

How fast is your interrupt and do you change the rate? It occured to me that one way to control feed rate would be to have a programmable interrupt timer using the Pi's PWM generator - but that wastes a GPIO output pin as I don't think you can programme it to interrupt if its not allocated to an output pin (and possibly needs to be fed back to an input).

[Robin Hewitt]

I have a buffer of straight lines. Lines currently are 24 bits long max. With the acceleration/deceleration/directions included I can define a straight line, XYZ, in 12 bytes.

I pinched the idea, I won't say where from. It also makes jogging easy but the buffer needs canny attention after you hit pause because unexpected braking has to become unexpected acceleration when you unpause.

I put a tidemark at 800 lines, if the buffer drops below that it gets another 10 lines. Drip feeding from the host may not be the way you want to go.

I use 2 interrupts, one for the stepping, one for the comms.

I have one bug at the mo', if the host misses a byte from the status report it waits forever for it to arrive. I need to add a timeout/retry. I haven't lost any data going the other way, yet, touch wood.

Edit: You step at .05mm? Is that a typo? I step at .005mm.

[irving2008]

yes it was a typo...

I now have a working 3D modified/optimised Bresenham run-length algorithm. I interpret the G-Code file (or will do soon) and write the run length data to a file. When you press 'go' it just reads the file and fills the buffer, then keeps it topped up. With over 3Gb of storage available on the SD card I dont need to worry about running out of memory! I added a second 'playback' buffer so once the interrupt handler outputs the steps to the stepper it puts what it just did in the playback buffer. This is then used by the visualisation routines which run at a low priority...

Still got to work on acceleration and deceleration approaches...

[Robin Hewitt]

Still got to work on acceleration and deceleration approaches...

I've been up to my ears in the ARM Coretex Tech Ref manual for the last few days and I think I have the hang...

The snag with accel decel is terminal velocity on a movement which very much depends on it's intersection angle with the next movement.

You don't want to be forever slowing to zero.

You don't want to work that sucker out inside the interrupt.

You have to be able to brake and recover when you hit the PAUSE button.

Looking at it I have a notion that I save the movements with a target max velocity and a desired terminal velocity, I can figure out accelerations and decelerations starting from current speed on the fly using a look-up table. If I bung in a Gig or two of Micro SD card memory I should be able to store the entire cut and simply exchange status data with the host computer while cutting. I think the USB connection becomes a weak link when the motors start turning. Also it would be nice simply to unplug the lap top and take it with me if I wanted to cut "lights out".

I am starting with TIM2 set as a down counter with interrupt on update and a big fat delay in the reload register. That way I can figure out what the delay should be, see how far the timer has got and write the counter register directly with what remains.

The interrupt looks at a status byte and decides what to do. That way my base program can simply tinker with the status byte and everything happens automatically.

Two interrupts per step, one of variable length to control the speed, one of set length, just enough to trigger the step after the DIR and STEP lines have had a chance to settle.

[Fivetide]

This is awesome; sorry I started the other thread I have 2 RPI’s I want to make an integrated O2 headphone amp and personal music player for my brothers 50^th birthday with one. Was hoping to make a nice milled alloy or brass case for it.

[TrickyCNC]

I've been thinking of getting me a slice of Pi .... I need to have a better read through this thread though, as it seems other options were suggested ?Anyone going ahead with the Pi or did you decide on arm ?

[Robin Hewitt]

I think Pi is ARM based. Haven't got one myself, I'm using the STM32F103V development board because it's cheap and comes with a dinky full colour touch screen I want to play with.

I'm wondering if ST is a new funky name for what was Signetics Thompson? Perhaps I've been around too long

[TrickyCNC]

ooh ... now you got me thinking ... Atari ST , or Amiga 1000 :) ... I wonder ...