Gallery, Projects and General > Project Logs
Electronic Leadscrew for the New Lathe
RussellT:
The sensors are not expensive so you could have more than one along the radius of your encoder, and you could also have an encoder disc on motor or on flywheel which would give you a much greater range of input pulses.
I imagine something like a row of sensors from spindle to motor and a disc that would slip onto the end of the shaft of either facing the row of sensors. Depending on dimensions the same sensors could be used for either disc position.
Going for electronic division would make it difficult to cut special threads, you never know the metric system might make it to the USA soon.
However you could take care of that if you went for microprocessor/Arduino division. I would say that you have to stick to integer maths for accuracy. If you use the Arduino you need to use an interrupt for the input pulses.
I wouldn't want to use dip switches like that. I think they're fiddly and difficult to see. I'd go for a row of toggle switch - or if you have visitors to impress some huge steam punk style knife switches.
Russell
vtsteam:
Sparky that teensy board is really neat!!
Andrew total agreement, that's what I'd use.
Pekka, commercial encoder per Andrew.
Russell special threads no problem, just depends how you implement the switch processing.
A lookup table for division count per thread switch setting could give any results you care to set up in the table. 6 bits of input would give 64 threads.
It also relieves the processor from doing division. it can be very fast as an algorithm.
Agorithm:
1.) Poll switch setting byte value,
2.) use that as an index to do a lookup in a table, and store the table value found
3.) Increment a count on receiving encoder pulse (interrupt or polling, whatever suits the board)
4.) Compare the count to the stored value
5.) if the count is equal to the stored value, send step pulse, reset count, loop
6.) else loop
Accuracy:
Example:
With a 3 to 1 stepper to leadscrew ratio, and a 10 tpi leadscrew and a 200 step motor, the movement fineness is 6000 steps per inch of carriage movement. That should be plenty.
With a oommon Ebay 600 line encoder at 5 to 1 spindle ratio the fineness of control is 3000 divisions per revolution. The worst rounding error would be in the higher pitches that weren't factors. Let's say 39 tpi was desired for some reason (40 is a factor). The error would be about 0.1% of pitch. Some odball fractional pitch around this fineness of thread could be as bad as 0.7% off. That's theoretical worst case. And coarser threads are better. Oddball fractional pitches around 20 tpi would have a max error of half that. And many common thread pitches are factors.
You could use a finer encoder if this error level was a bother, or you could step up the encoder ratio further -- I don't think it will matter to me on my lathe with its overall tolerances in general. However increasing the pulses per spindle rev increases the noise and calculation speed requirements. I'm not sure that it's worth going further on my lathe.
Another possibility for dealing with rounding errors would be to round down, but accumulate errors in the algorithm, add them, and increment the encoder pulse count when they exceed 1.
I did think about toggle switches for input, and maybe I'd do that later after first going with a dip switch to get things moving. Plus I like the idea I could hide a dip switch more easily.
Ideally a rotary switch with a big metal knob would be a great "old school" solution to fit a traditional looking lathe, I think. You'd have to make one with a PC board and wipers, but it could be done as a later project in itself!
Thank you all for your replies! :beer: :beer: :beer: :beer: :beer:
DMIOM:
Steve,
Even if you don't buy any of their products, I'd recommend having a look at the US Digital website - they're one of the leading manufacturers, and I've used their products for quite a few applications over the year.
I can't see it on their website at present, but they even used to make a tiny device called an "eDivide" which had a bank of DIP-switches to set the ratio. I've used those for prototyping and then produced small-runs using PIC controllers.
You mentioned using the likes of an Arduino - I'm not sure if one would keep up reliably, but a PIC programmed in C should certainly cope. I've made a couple of slip-detectors using encoders & PICs - one had sensors either side of a clutch on a shaft running at just over 5,000 rpm; the other was similar but across a whole transmission, so as well as the two encoders, there were also a number of pins used to signal the gear in use to the PIC, so the dividing ratio could be set appropriately. One of the tricks was to use the hardware counters built into the micro, minimising the arithmetic overhead.
Dave
Edit: here's a very simple diagram, using their own stepper driver - just add the variable divider betwixt the encoder & driver....
RussellT:
It sounds as though you're going to end up doing the programming you were trying to avoid.
I suggest amending your outline as follows.
5.) if the count is equal or greater than the stored value, send step pulse, deduct stored value from count
6.)loop
You might be able to improve accuracy by multiplying the count by 10 or 100 - that way you could get a couple more significant digits on your stored value and by using the subtraction method I've just suggested the extra pulses would be added in whenever they were needed. That still allows you to use integer maths which avoids the extra processor load and any possible inaccuracy from rounding errors. It wouldn't be as good as increasing the input count.
Russell
vtsteam:
Thanks Dave, that's a very useful site! :beer: And that diagram with divider you mention is what I was thinking of. I do have a different stepper driver, but similar.
re. PIC: I don't know C. :( Too bad there isn't a board for FORTH, I know that! :lol:
Russell, yes to getting away from programming, but seems necessary -- the error from the disc encoder bands method seems too great. I don't think the programming is too big an issue. As long as I avoid feature creep!
Yes, sounds like a good suggestion re. reducing error. :beer:
Here's my spreadsheet for others to play around with. You can see the effects of changing reduction ratios, leadscrew TPI, encoder gratings, etc. and it will give error rates, disk band size, thread TPI etc.
edit:
I've removed the spreadsheet attachment here because it needed revision -- the latest version (v1.2) is on page 4 of this thread.....
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version