Gallery, Projects and General > Project Logs

Electronic Leadscrew for the New Lathe

<< < (30/32) > >>

vtsteam:
Just thinking about the possibility of doing metric threads with this thing, too.

Assuming my 3000 steps per inch, that's 118.11 steps/mm. Close enough approximation would probably be 118

If 118 was used, the cumulative error over my lathe's normal bed capacity (~ a 12" or 30 cm thread) would be ~0.25 mm).
Frankly, I wonder whether most home shop lathe leadscrews will drive their carriages to .25mm precision after 12" travel.

But for even closer precision, I could just increment one step every cm (a step is only .0085 mm).

vtsteam:
Well, that's just imagining a metric 1mm pitch thread. Actually the way to program this for all metric threads is to generalize the increment correction method I mentioned at the end, above.

Basically increment (carry) a step, as you are threading, whenever you've accumulated a remainder (error) greater than half a step. Just like rounding numbers.

vtsteam:
I've been quiet on this subject for awhile, but actually the ELS project has progressed to near completion (I hope!). The last week or two I have been trying to understand how to program interrupts in the Arduino UNO using FORTH.

Interrupts have been a real Babel of online tech jargon for me to try to weed through to eventually get to a relatively simple set of requirements. I've read through examples for different control chips, read the Atmel datasheet, etc. tested and tested and tested trying to get them working, and finally, yesterday, did finally have success.

While programming for interrupts is a well documented and straight forward process in the official Arduino programming language, that language is too slow for what I want to do, even using interrupts. FORTH is far more compact, and considerably faster. It's also a language I enjoy using again. But the version I'm using: FlashForth has little documentation for using interrupts on an Arduino UNO. What there is is aimed at PCI interrupts on a different board, not EI interrupts, which was what I needed.

Anyway, I'm now at a full understanding of EI's, and the applicable Atmel registers on the UNO, and successful at using the UNO's pins #2 and #3 for A and B signals from the ELS encoder. Actually, I only need one interrupt for the A line. The B status can just be read during the A interrupt routine to determine spindle direction.

I've got a workng FORTH program now as far as reading the encoder goes, but a new fly in the ointment is that my 600 line encoder doesn't seem to work. I don't know whether its open collector outputs got damaged or not -- something the supplier warns about. I'm going to try another test before calling it dead, but that's a big disappointment. I've sent for another, since this one is way too old to inquire about a return. And maybe it got damaged in several years storage -- maybe it was a static problem.

While I'm waiting for the new encoder to arrive, I may open this one up and see if anything can be done to replace the output transistors. I'd need some advice about that from you guys if I do. Not sure what would be suitable in the box of spares.

vtsteam:
 :doh: :doh: :doh: :doh:
Problem wasn't the encoder but the breadboard. I have two of them. Apparently not quite the same, though they look the same.

The one I've used before has two sets of power busses running down the sides. The newer one interrupts both busses half way down the sides. I was using that one, thinking the busses ran all the way.

Turns out that an encoder just won't work if not connected to power! Took me an entire day to figure that out...  :wack:

Reminds me of the old IT troubleshooting litany: "Did you check to see if it's plugged in?"

vtsteam:
By this evening I have code working to sense direction and then step an old junkbox stepper motor in response to the 600 line encoder via interrupts.

I also have the routine working to divide by a pitch value.  I can twiddle the encoder back and forth as fast as I can manage and whatever pitch rate I set the motor follows proportionately. It still remains to be seen if the whole will be fast enough when running on a lathe. It's going to be a pretty high data rate for the encoder/Arduino program -- 3000 lines per single spindle rotation. At 100 rpm that's 30,000lines /min, or 500 hz, But, fingers crossed....

The remaining stuff to do is:
1.)Add a code routine to subtract the current pulse count from the pitch setting whenever the direction changes.
2.) Add 6 switches ( a dip switch to start with) to set the pitch rate, and add the routine to read that.
3.) Decide whether the pitch value will be calculated from the switch byte, or looked up in a table. I think the latter would be more flexible, and allow future expansion to odd and metric pitches. But the calc method would probably be faster.
4.) try it on the lathe probably with a sharpie in the toolholder.

Navigation

[0] Message Index

[#] Next page

[*] Previous page