Gnome sweet Ohm

This is the back view of my contraption:

This morning, I spent a couple of hours unsuccessfully trying to get my piezo running from within the main interrupt at varying frequencies, and not getting anything. Finally, I traced it down to my having used the "=" operator instead of the "==" equality tester. In the B.A.C.I.C. variants, "=" is multi purpose, and I'd forgotten about that significant difference in C!

Following from that, I wrote some code to beep at a different frequency when each limit was reached, during which I found I had two sensor wires swapped on my Z axis, which was still unattached.

Next, I added in some simple code to zero my "actual" values for each axis on encountering the end stop.

Here's where I found another little thing that had to be done: If you are already interrupting a beam, then you don't know how far the vane has penetrated the slot... so I had to write some backing off code for each axis.. trivial. Problem was, my code to zero the "actual" value counters was working, so I had to write some override code to make the interrupt checks ignore the beam interruption during the backing off period.

Next, I wanted to have the x and y axis the same as you would draw on graph paper, i.e. values increasing from left to right, and front to back. However, although I have bidirectional end vanes on x and y axis, my y axis, in the max frontal extension position, knocks my keyboard from it's parking perch where I program from. Since many builds will be small ones, I decided to change perspective, and have the y zero point at the back, as if viewed from the circuitboard side.

It might not sound like a lot of progress, but it's all these small steps that contribute to a final working CNC router, printer, or automated gizmo.

Dr Frankenstein is pleased with his mutant creation

It's taken me almost 4 hours, but I've attached my EEEBox XP PC, monitor and PSU to my build assembly. No end of axis sensors wired or fitted yet, that can be another day. I have some reasonably heavy MDF attached, and it seems to be moving freely on the M6 and M8 threads. The Y axis still needs to be connected, it's the only floating one. X and Z are fixed motors, and have fixed wiring looms. Z is not yet used.

I have the stepper axis calculations back running on alternate interrupts, as I think excessively high frequency resetting of the PWM was preventing cycle completions from occuring.

It occurred to me today that I could run a "lawn mowing" operation with a router bit and some X & Y stepper excercises, and clean myself a perfectly flat platform if required.

Guy Fawkes

Today is the day, that in my youth, we could let off sky rockets, bangers, etc. Now, for my kids, it's only the etc. First rockets were banned, then bangers.
Anyway, before I go and play pyromeister with the kids, this is where I'm up to:

96 servo increments, representing approx 55 degrees movement. (improved resolution)
Each main interrupt, the interrupt:
- Updates the 5 x servos.
- Updates the 5 x PWM channels, 0% to 99.75%
- Checks the steppers: only one is step-updated in any interrupt, 31 interrupts are then serviced before the next motor is checked and so on.

This will be my next target for change, I want to use the granularity of the missed cycles to allow for smooth acceleration and deceleration. Ideally, this needs to be mass adjusted for each axis seperately, and possibly with an allowance for increased weight of additive build, decreased weight of subtractive build, during progress, if full optimisation is needed.

During a long g-code move, it's expected that there will be no acceleration or deceleration for the midsection of the move, here's where I'm going to have to look at some different algorithms. Stopping is achieved by an axis current position equaling a set target location, but I will need to decide somehow, what granularity to use, in creating intermediate locations between start and finish. If the next position is too close to the current one then I would expect slow stepper movement, and if it's far, then I would expect fast movement. I need to try to avoid pixelation type granularity as much as possible, while doing an accurate line, curve etc.