Rigid tapping issue

[cncdrive]

It's late night here, so I will reply to the things I've noticed for first read:

If the index signal is behind a gearing is a problem, not because the index happening slower or better to say less frequent,
but because the index will happen at different absolute angles of the spindle at the different rounds of the rotation and the motion controller syncronises to the index,
so this explains why the final position is not OK.
If the A/B is behind a gearing is not a problem, but the index must happen once per turn always at the same angle, otherwise the tapping can't work properly which I think I've mentioned a few times in a few threads on this forum.

And one more thing I've noticed was this:

7. Adjusting the encoder PPR from 208 (my 'tweak') to 200 (dataplate) and reversing the A/B pins did not result in any improvement.

If you reverse the A/B pins of the encoder direction in the software (is the same as exchanging the A with B) then the rigid tapping should not even start,
because the motion controller will know that your encoder is not counting to the proper direction and will wait for you to reverse the count direction,
so it should start working only if you reverse the encoder back with the pins or with the direction setting or if you change the spindle rotation direction.
If the rigid tapping starts with both direction settings then something is wrong with the encoder, then it does not count properly for sure.

[spumco]

Now that I think about it, I did change the encoder count but I may have planned to try switching the encoder pin checkbox but didn't because I had a number of other things going on while I was testing. In any case, the tapping cycle has always started even if the results were incorrect.

Sounds like I need to try it out with the pulley setting at 1:1. I will ignore the actual spindle speed, but if this is the fundamental issue then the Z-axis motion should be identical each time with no change in distance traveled.

If so, then I suppose I'll either need to change to a 1:1 pulley and live with the reduced spindle speed, or get an encoder for the spindle and send that signal to the BOB for UCCNC and let the motor encoder just provide closed-loop to the VFD.

[cncdrive]

I have dicussed this issue with my collegue and one more possible problem we see is that your Compensation acceleration setting is very high compared to your normal acceleration. (Comp.accel parameter of the axis.)
The Comp.acceleration parameter is used when rigid tapping, thread cutting and backlash compensation and it must have a higher value than the normal acceleration and that is because of the nature how these function work, I don't want to go into details of this now, as it is irrelevant, the only important for you to know now is that this parameter is used for the acceleration when rigid tapping.

What we think that probably your stepper motor can't handle the high Comp.acceleration and trying to accelerate too fast and loosing steps.
What you should do is test your Z-axis with normal movements (e.g. jogs or G0/G1s) and see what is the max. acceleration which your axis can handle and go a bit lower than that.
Now try to set the normal acceleration of the axis to about half of that and set the Comp.acceleration to the max. value you studied that it is still working OK.
So, your Comp.acceleration will be 2 times your normal acceleration.
And please try the rigid tapping cycle.
We are very suspicious about that the high comp.acceleration parameter will be the cause for the lost steps you described.

And ofcourse finally you will have to also change the Index channel of the encoder, I mean you will have to put that without gearing, but for this test the index behind the gearing should still work to some level,
I mean the tapping will still work, only more than one taps can't be syncronised together with the index behind the gearing.

Please let me know if this resolved the issue...

[cncdrive]

And one more thing is that your tapping code works fine at us also with high spindle speed (just tested that), so it is sure now that the high spindle RPM is not the cause for the problem.
However as said you should really set the velocity a bit higher for the Z as mentioned proviously if you want to safely make the taps with this pitch and this spindle RPM.

[spumco]

I'll adjust the compensation acceleration when I get home later today and see how it goes.

Assuming that Z-axis motion is resolved after adjusting the compAccel, I still have the index issue remaining.

Instead of changing to a 1:1 pulley permanently, or adding a second complete encoder to the spindle (in addition to the motor), will installing just an index signal on the spindle work with the existing motor encoder signals?

By that I mean disconnect the existing index signal wire from the motor encoder to my BOB, and attach a hall effect sensor directly to the spindle. If UCCNC can still do the math between the motor speed to spindle speed ratio, that would permit me to have the higher spindle speed I want and still be able to do rigid tapping.

Or, if UCCNC can't reconcile the spindle index with the motor encoder at the 1:5 ratio, would setting the PPR in the software to about 134PPR (for a 200PPR encoder) to compensate for the 1:1.5 pulley ratio effectively 'trick' the software?

[cncdrive]

Yes, you can get the index signal from a different source, e.g. from a hall sensor sensing e.g. a rotating half disk or something like that.
And no, you can't trick the one index per turn requirement to have a fully working G33.1/2, because the issue is that with a ratio the index will happen on different angles,
so then you will be limited to do single pass taps only. You will be unable to make multi pass taps, because the controller can't resyncronise to the same absolute angles on the second and next passes.
But ofcourse everything depends on what you want to do, if you only want to do single pass taps then the index behind the gearing is not a problem.

[spumco]

Next round of testing:

Turning the compensation acceleration down to 50 solved the erratic motion completely. The Z-axis now moves up and down and stops at the top or bottom within .001" of intended position each time - even when I sped the spindle up to 750rpm.
Obviously I left it at the default setting because the user manual stated that it was used for backlash (didn't mention tapping) which I don't have turned on. I'm guessing the default of 240/units is for metric machines.

Now that it's moving up and down without losing or gaining height, the next related problem is that the Z-axis isn't gearing correctly to the spindle.

Since you've told me that the index has to be 1:1 with the spindle, I set up an index signal directly on the spindle using an inductive sensor and flag trigger. Changed the index pin/port in UCCNC and verified that the index LED was being triggered appropriately once per spindle revolution.

Using the thread pitch K0.2 value in the code I posted earlier, I started the cycle with the spindle turned off. Rotating it by hand caused it to move down as expected, but the Z-axis moved down 0.272" (both on the DRO and with a dial indicator) per revolution instead of 0.200."

I double-checked the axis steps per inch and re-calibrated. This resulted in the Z moving down 0.266" (vs. 0.200") when the index LED indicated exactly one revolution.

I reverted back to using the motor encoder index signal to see what would happen. Running the same cycle, the Z-axis moved exactly 0.400" down between index signals.

This was almost exactly 1.5 times the earlier 0.266" travel when using the spindle index sensor. Makes sense, as my pulley ratio is 1:1.5.

Changing back and forth between the two index signals (motor and spindle), and changing the encoder PPR makes no difference in the ratio of actual vs. commanded advance per revolution. Changing the pulley ratio between 1:1.5 and 1:1 makes no difference - not that it should have as you've mentioned before that the encoder can be behind gearing and still function.

So the question now is why is the Z-axis moving 1.33x farther per rev than commanded when geared to the spindle? The Z-axis is moving precisely to the indicated (DRO) position, either spinning the spindle by hand or under power, but the amount of advance per rev does not match the commanded value.

I've attached my profile again as I've made a number of changes - based on your advice and testing - from the last one I sent.

Regards,
Spumco

[cncdrive]

Using the index on the motor behind the gearing or the index on the spindle must make no difference of the tap pitch,
because the tapping is syncronise to start at the index signal, but after the index happened the syncron is kept to the encoder counts and not to the index.
So, changing the source of index can only change when the tapping starts, at which angle, ofcourse it will also change the movement between the index signals occurance,
because the index signal will occur more or less frequent (longer/shorter angles per index) depending on the gearing if the index is behind the gearing, but that will make no pitch change.

If your pitch is not correct, not what you programmed with the K parameter then there are only 2 possibilities:

1.) The Z axis steps per units are not correct.
2.) The set encoder resolution is not what the real resolution is.

Since there are no other possibilities for this problem only this 2 you should check and verify these settings.

[spumco]

Thank you, I just didn't know if there was some other setting I'd overlooked.

Since the Z-axis steps per inch have been calibrated and it's moving within a few tenths of commanded location, then the encoder resolution must be off.

Do you have any suggestions on how to verify the actual PPR other than rotating it by hand and counting the LED flashes? It's a 100PPR model so it shouldn't be miserable, but this just seems to be a fairly imprecise method.

[Derek]

When I fist set up tapping on my machine I did the spindle off, turn by hand test. I zero'd the Z axis DRO. I wrote a code for a 20 tpi thread and turned the spindle 20 times and the Z axis was at -1.0.
There may be a better way but that's how I did it.

Derek