That does not make sense for an overflow problem. Is the get count function synced to the speed too? Or is it clock based? Or perhaps a bit of both?
-
Scam Alert. Members are reminded to NOT send money to buy anything. Don't buy things remote and have it shipped - go get it yourself, pay in person, and take your equipment with you. Scammers have burned people on this forum. Urgency, secrecy, excuses, selling for friend, newish members, FUD, are RED FLAGS. A video conference call is not adequate assurance. Face to face interactions are required. Please report suspicions to the forum admins. Stay Safe - anyone can get scammed.
What's Paul up to?
- Thread starter PaulL
- Start date
That does not make sense for an overflow problem. Is the get count function synced to the speed too? Or is it clock based? Or perhaps a bit of both?
Ok, dug through the manual and the source somewhat more - the code sets QPOSMAX to 0x00ffffff - 24 bits of counter. That's 16M or so pulses per overflow, so that's not what's going on with my system. The hardware itself can go up to 31 bits. It looks like the choice of 24 is to match with floating point precision - more than that and you'd lose precision in the conversion to a 32 bit floating point number (23 bits of mantissa, plus the implied leading 1 bit).
So I'm on the slippage hypothesis. Breakfast is done, I just have to brave the ice storm for the trudge out 50' to the workshop.
So I'm on the slippage hypothesis. Breakfast is done, I just have to brave the ice storm for the trudge out 50' to the workshop.
Is it always high or always low. If high, consider noise. If low, consider lost counts.
Is it out by a ratio or by a more or less constant amount? If ratio, consider a correction factor. If constant, then a subroutine or preload or formula or interrupt error might be interfering. If it's a solid error, consider adding a correction formula.
You eat breakfast every day?
Last edited:
Do you have a counter you can use to test that with instead?
I'm pretty sure it's a 32 bit counter and the variables are 32 bit. And it's sampling the count at 2Hz or every 500mS. However you have to factor in the large pulley diameter to small pulley diameter so the actual number of counts per spindle revolution is much larger than 2400.
If you have taken that into account you might be out by the number of teeth you carved on the little pulley relative to the number of ribs on the back of the belt. I think guessing slippage is headed in the wrong direction.
It's a 32 bit counter with a programmable overflow, set to 24 bits. The control code is all floating point, so the 24 bit limit makes sense.
I can still slip the wheel over the belt, even with the teeth. The nylon isn't providing much friction and my holder isn't letting me apply enough force to keep it from bouncing.
Heading out to the shop now.
Ok, new holder in place, wheel carefully aligned. Set the ratio at 468 RPM, and I'm off by 25% at the low end, (48 on mine vs 60 on the lathe). But now I *really* don't trust the lathe read-out. I can vary the pot to get single-RPM changes on my display, while the lathe doesn't update. It would appear to be a very poor approximator of the RPM, given that it has a hall effect sensor counting 4 times per revolution.
I'm going to mount the sensor John gave me now so I can have an index and count reality.
I'm going to mount the sensor John gave me now so I can have an index and count reality.
Generally, I find Hall effect transducers to be very reliable. The wave form is especially immune to noise and miscounts. Is the gap too wide?
It is very slow to respond, and ramps oddly - I suspect it has a really shoddy software filter to generate the output. This is increasing my incentive to mount the new display and electronics directly in the lathe enclosure.
The wave form on a hall effect is not like most other sensors. It has a very steep edge on one side (which is why it works so well), and almost a hysteresis type curve on the other. But you raise a good point, you could try reversing the wires on the sensor. If it is backwards, a trigger designed for the steep edge might go to hell in a handbasket on the other side!
The hall effect bits are all stick to the lathe. I haven't excavated the control board to read what chips are on it, but I'm guessing it's the cheapest counter-and-lookup table they could find 15 years ago. The RPM readout is good enough for setting cutting speed, but not accurate.
Question about your quadrature setup in the software. You said you had 600 lines for 2400 edges per rev. What's the diameter of the driven disk and what's the diameter of the driving pulley? Do you not also have to put that information into the software. At least as a scale factor?
Like if it's 4:1 so you put down for the encoder 9600 edges per rev?
Or do you guess at the RPM and enter some sort of value?
Edit: Oh and can you put the scope on the hall sensor feeding the lathe electronics?
Like if it's 4:1 so you put down for the encoder 9600 edges per rev?
Or do you guess at the RPM and enter some sort of value?
Edit: Oh and can you put the scope on the hall sensor feeding the lathe electronics?
Yes, I'd like to see this too.
I used my logic analyzer to count how many rising edges I have on the A signal in one revolution of the spindle, so that embeds the two radii. Multiplying that figure by 4 gives the number of edges the software is expecting.
Just wiring up that opto-sensor now, which I'll be able to hold in my toolpost easily enough. Then my scope should be able to get some RPM figures out for me.
I dug into my plastic bin marked DRO and Stepper Driver. The source code for the PIC is dated 2008. I thought maybe the US Digital Encoder had an index output. The part number is only S1-400-B so it's a ball bearing based unit but no Index. I confirmed that with the scope. The index pin is the same as the A output. Back in 2008 I must have paid $57US for it.
To me the diameter of the large pulley looks to be bigger than just over 2x the smaller one. So 600 lines on the encoder to get 1675 is 2.79. I suppose if the small pulley is 2" the big one could be 5.58". Hard to tell from the photo.
Optical illusion perhaps.
John
Ok, the whole "calibration jig" is a touch Rube Goldberg, but it's working, and I trust my speed output.
I have an Allen key chucked, with the optical interruption sensor held in a quick-change tool holder, which made alignment really easy. That snare of (too short and messy) wires go to the breadboard where there's a couple of resistors thanks to which I fried neither the sensor nor my logic analyzer. It also has a bypass cap to reduce noise on the sensor. The logic analyzer hooks to the breadboard, as well as power and ground coming from my controler, in case I wanted to get my encoder pulses at the same time as the index pulse.
Logic analyzer snapshots show the thing repeatable and the displayed time is correct as far as the logic probe is concerned.
Thanks @jcdammeyer and @Susquatch for the support.
Biggest hurdle to overcome to make this work? The brown and black wires on the sensor are reversed from the random diagram I pulled off the internet - black wanted +, brown to ground.
On to making some test threads!
I have an Allen key chucked, with the optical interruption sensor held in a quick-change tool holder, which made alignment really easy. That snare of (too short and messy) wires go to the breadboard where there's a couple of resistors thanks to which I fried neither the sensor nor my logic analyzer. It also has a bypass cap to reduce noise on the sensor. The logic analyzer hooks to the breadboard, as well as power and ground coming from my controler, in case I wanted to get my encoder pulses at the same time as the index pulse.
Logic analyzer snapshots show the thing repeatable and the displayed time is correct as far as the logic probe is concerned.
Thanks @jcdammeyer and @Susquatch for the support.
Biggest hurdle to overcome to make this work? The brown and black wires on the sensor are reversed from the random diagram I pulled off the internet - black wanted +, brown to ground.
On to making some test threads!
Yes, I should be able to do that.
There's a little 8-bit Holtek HT48R30A hiding behind the panel. 10MHz job. Lots of empty, clean space behind there, so I'm pretty sure this is where my electronics will go.
Seeing if I can find the right Molex connector to adapt some leads onto the sensor wiring.
You realize of course that the nut you used isn't really 1/2"-13 but actually 2mm pitch.Yes, I should be able to do that.
There's a little 8-bit Holtek HT48R30A hiding behind the panel. 10MHz job. Lots of empty, clean space behind there, so I'm pretty sure this is where my electronics will go.
Seeing if I can find the right Molex connector to adapt some leads onto the sensor wiring.
