Raspberry Pi

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