Encoder seems to skip or add pulses

[digiexchris]

hi Maxim, wondering if you have some troubleshooting suggestions for me with my H2. My lathe has a 4:1 reduction through several gears inside the head stock that causes the change gear output gear to turn 1 turn for every 4 spindle turns. I've solved this by using a 4 times smaller gear on the encoder, so the encoder turns 1:1 with the spindle. The whole system has some back lash of course, because of the gears involved.

I have noticed when threading, occasionally the thread will not follow the previous thread. I've investigated with an oscilloscope, and it seems that the encoder pulse width changes a bit, but also I suspect that vibtration may also cause the encoder to count extra steps due to the extra gear backlash involved, but I'm not sure. If I run the spindle very slow, it happens less. The thread tracks perfectly, except when it doesn't. It's then shifted onto tracking the new thread track that it just made.

Using the angle display, I see that the revolutions do not always add up to 360, there's some loss there. I've checked the 2k pullup resistors, and the oscilloscope is showing fairly nice square edges on the pulses. I have used a dial indicator to check that there is no loss in the stepper movement, using a simple arduino sketch that just issues steps in one direction, and then back to the start. It's a closed loop stepper too that works well.

On the tacho view, I can see the rpm vary by between 4 and 7 at about 600 rpm, but if I hold the encoder input shaft in the lathe chuck, there is no variation at all. That's my clue that there's something funny with maybe extra pulses due to gear train backlash.

I also tried belt drive to the encoder, in case vibration was a concern. I may have to make a belt pulley for the spindle, but there is VERY little room. I might do an arbor inside the bore just to test this out.

I wonder what happens in the firmware if there are two pulses from one encoder channel before the other encoder channel gets a pulse, would that cause the firmware to think it's reversed a bit of position? I think it would eventually make up for it with double pulses on the other channel though once it hits the other side of the backlash again. I feel like I saw some code that prevented it from reversing unless the spindle had come to a stop, does this affect the position tracking too? I wonder if that anti-reverse should only apply to stepper commands. It's a gear head lathe, so it's definitely possible for an interrupted cut to cause bouncing between gear teeth on a lightly loaded shaft like what is driving the encoder.

I've also tried 1000uf capacitor across VIN, along with a 0.1nf ceramic to filter the power better, there was some noise there. That didn't change the behaviour of the encoder pulses at all, didn't even change the shape on the scope. Seems the filtering on the Arduino Nano is good enough.

Do you have any suggestions on troubleshooting this? electrically, it seems that all is well.

Also I'm using an imperial lathe, so I wouldn't mind if you could double check my math for some of the settings.

I'm using a 600 ppr encoder, 1:1 with the spindle through the gear train I have set up. my leadscrew is 7 TPI (0.1428571428571429 inches of tool advance per leadscrew revolution), and I have a 2:1 reduction from my stepper to the leadscrew (the stepper has a 40t gear, the leadscrew has an 80t gear), effectively making it 0.0714285714285714 inches per rev. In metric this would be 1.814285714285714mm, and in deci-microms its 18142.85714285714

[kachurovskiy]

Hi Chris, your math checks out. I wonder if setting

nanoels/h2/h2.ino

Line 51 in 1f3148e

#define DIR_CHANGE_DIFF_MICROS (int) (5000 * ENCODER_STEPS / 600)

to 0 changes anything for you? Please post your code at gist.github.com and share the link here for completeness. Thanks!

[digiexchris]

Thanks, that did it! Perfect thread. I used a 10tpi because it's coarse enough for double tracking to be obvious. Can you comment on exactly how you thread? This is the way I'm doing it:

set both stops, set the pitch, turn it on. Turn the spindle on, the tool moves to the left stop. I retract the cross slide a bit, hold down the right button, the tool moves to the right stop. I have to keep holding the right button down, or it'll start moving to the left again. Then with my other hand, I set my cross slide back to zero, and enter a little bit of cut with my compound, and release the right button.

Is there a way to get it to go to the right stop and stay there, until I hit the left button again to start the next cut? I'd like to have both my hands available but it takes a long time to stop the spindle so I'd like to keep it running. It seems to track the thread perfectly though.

[kachurovskiy]

Thanks, that did it! Perfect thread.

Sweet! The original logic was there to prevent stepper direction changes at significant stepper speeds which usually results in parts being scrapped so watch out for that. It's hard for me to imagine how your encoder can be changing direction when spindle is running though, perhaps if you post some photos of it it would help.

Is there a way to get it to go to the right stop and stay there, until I hit the left button again to start the next cut?

Keep if OFF until everything is setup for the cut (tool moved in, spindle running, stops set, etc.) and then press ON?

[digiexchris]

Keep if OFF until everything is setup for the cut (tool moved in, spindle running, stops set, etc.) and then press ON?
That's how I start the first pass. Then I need to go back to the beginning of the next thread, for the next pass. So I leave the half-nuts engaged, retract the tool, hold the right button, and it moves to the right stop. As soon as I release the right button, the tool moves back to the left stop. If I push the on/off button at that point, it loses sync (as expected).

So I'd prefer if I could let go of the right button and have it remain at the right stop until I've made the adjustments for the next pass (feeding in 0.05mm or so with the compound).

It's very possible I'm using it wrong!

I can record a video if that's unclear.

[kachurovskiy]

I see. You could try increasing the delay on line https://github.com/kachurovskiy/nanoels/blob/main/h2/h2.ino#L1004 to e.g. 4000 and see if it gives you enough time before the tool starts moving after reaching a limit? Thank you.