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.
Last night, I implemented angular moves by looking for the biggest difference between current and desired positions, and then scaling my maximum speed down according the the ratio of each other axis difference to the big one.
ReplyDeleteTonight I'm tidying my new code, and hopefully starting to implement a coordinate array that can be stepped through as each point is reached by the required axis.
If a manager were to look at the tasks I've been setting myself, they would be mystified at the way I'm going about it. Drivers first ! then, gradually implement the other steps, until finally you get to the user interface.
Hi,
ReplyDeleteI have similar project but on much lower grade hardware. I created a stepper motor driver based on the ATTINY2313 and l298, thinking I could just leave the l297 out and control l298 directly trough PWM on the input pins to achieve microstepping. Sadly this is not the case, the problem could be with the software and/or with the hardware, or with the way I'm generating the steps. What I did achieve is full torque half stepping and that will do for my project.
The controller works fine, I just wanted to reduce resonance trough microstepping, and some better precision.
I was wondering, what is your take on microstepping? I did achieve some degree of microstepping but the steps are very uneven so it is pretty useless.
If you are interested in my project take a look here: http://letsmakerobots.com/node/9006