Rigid tapping issue

[spumco]

So I've got my mill to the point where I can start making chips; thanks for the help over the past months.

Running in to a problem with my first attempts at rigid tapping.

Drilled a simple hole and attempted to run a G33.1 rigid tap cycle. Fortunately, I was just cutting in air a couple inches above my stock when I noticed that on the spindle reverse of the canned cycle, the Z-axis did not retract.

Instead, it kept moving down. Obviously, had I been tapping for real it would have broken the tap or wiped out the hole.

I've just tried running this about 10 times and the same thing happens:
- Cycle starts
- spindle spins up to 500rpm
- Z-axis rapids to 1.000"
- Z-axis moves down at what appears to be the correct feed to the correct depth (for tapping a 1/4-20 hole)
- Spindle stops (briefly) and the Z-axis stops (briefly)
- Spindle reverses and the Z-axis keeps moving down, but the DRO reports it moving up.
- Cycle ends at the reported (but incorrect) Z-axis start height.

Here's the G-code, with comments omitted:
G17
G90
G54 ( Work Offset )
M06
S500 M03
Z1
G0 X0 Y0
G33.1 Z-0.5 K0.2
M05

It sounds (from a slight 'thump') that the Z-axis is trying to reverse at the bottom of the hole but cant and then continues down. Once the tapping cycle appears complete, it rapids up to the (now incorrect) start height.

It's losing steps as the machine zero winds up being 0.250" below where it should be. I've tried turning the axis acceleration down to 10ipm2, but that didn't fix anything. I've checked twice and each time I run the cycle it loses .250" (give or take a couple thou).

Other air cuts running various G-code files with Z-axis motion haven't resulted in incorrect motion or lost steps. I have not cut anything yet, but I've run a few programs with slow and fast Z-motion and this is the first time I've seen anything like it.

Any idea why it's continuing down and losing steps?

[cncdrive]

Could you please post your .pro settings file here, so we could test your code here using your settings.

[cncdrive]

We've just tested your g-code with a UC400ETH using some random settings, because we do not have your settings file yet and it works fine here, the spindle changes direction and the Z-axis also changes direction and keeps the syncron without problems.
So, please upload your settings file to let us test with those settings also.

And some things for you to verify is if your Z-axis direction pin is set correctly?
And check if the spindle really changes the direction? Or if it only slows down and spins up to the same direction. (not correct direction pin setup)

[spumco]

Yes, the spindle is changing directions. At 500rpm I can see it reverse at the bottom of the 'hole' before it continues down.

Pro file attached. I'm running off to work right now, but I'll check the z-pin later today. I would imagine if it were reversed everything would be reversed - the tap cycle would go up and then down, not down and then down.

Thanks,
Spumco

[cncdrive]

Thanks for the profile file.
We've tested with it and it works fine here, the Z-axis keeps the syncron and it also changes direction with the spindle.

So, I think what's remaining is to check if the Z-axis direction setting is OK at you, I mean to check if your Z-axis gets the direction signal.
First I would check the direction signal virtual LED of the Z-axis on the diagnostics screen if the Z-axis dir pin is changing state when the spindle changing direction in the rigid tapping.
And also check if you can jog the Z-axis up and down to see if the Z axis drive receives the direction signal.

If the above are all working OK then I would check if the encoder counting properly with a simple rigid tapping code, like the one you copied in,
but do not turn the spindle motor on, but turn the spindle with the encoder with hands.
When the g-code execution will reach the G33.1 and if you not turning the spindle on then the UCCNC will just wait, so then start rotating the spindle manually in the CW direction and check if the Z moving down in syncron and then try to reverse rotate the spindle to CCW and check if the Z changes direction and starts moving upwards.
In other words test if the syncron is OK between them in both directions, if not then something is probably not OK with the encoder signals, but lets first check this and then go on from there when you see the results.

[spumco]

So I just ran your test, in addition to slowing things way down. Here are the results:

1. Jogging the Z-axis up and down resulted in the Zpos changing appropriately
2. The spindle direction LEDs are indicating CW and CCW correctly when it reverses.
3. Slowing the spindle down to 100rpm resulted in normal (correct) Z-axis movement.
4. Slowing the spindle down to 250rpm resulted in normal movement
5. Removing the M03 command and turning the spindle by hand resulted in the Z-axis following the spindle down, and when I reversed the spindle the Z-axis followed the spindle back up.
6. Running the spindle at 500rpm resulted in the same missed steps as last night. Watching the diagnostics tab, the Z-axis appears to change direction when the spindle reverses.
7. Running the spindle at 500rpm a few more times resulted in 2 instances of the Z continuing down incorrectly, and two instances of it moving up correctly.

Let me know what you think.

Thanks,
Spumco

[cncdrive]

So, you saying that with lower RPM the rigid tapping works OK with the Z-axis moving down and backs up at the bottom of the drill when the spindle changes direction, like it has to?
But when you running the spindle at higher speed, e.g. 500PRM then is when the issue happens?

And I'm not sure I understand the issue clearly, we talked about the Z axis always moving down and not changing direction at all and you've mentioned lost steps earlier too, but what does lost steps exactly means?
I mean how do you determinate that there were lost steps, how did you exactly observe that?

The UCCNC should not have any problems with the 500RPM, I mean you have the encoder resolution set to value 200 in your profile and that gives only 1666Hz encoder count frequency, so that part should not be a problem.

What could be a problem in my opinion:

1.) If you run the spindle at 500RPM and you program a K0.2 pitch that will result a 100 units/min feedrate on the Z-axis. Your Z-axis is set to exactly 100 units/min, so if the spindle will go faster than that then the Z-axis can't follow, because the limit is 100 units/min and the motion controller will not make the Z-axis go faster.
However that should not cause lost steps, just wrong pitch, so you should set the Z velocity higher if you want to safely do taps with this 500RPM spindle speed and K0.2 pitch.

2.) Lost steps: Isn't it possible that your motor is loosing steps, because it can't run that fast, does not have enough torque at this speed and it jumps out of syncron? If you using steppermotor then this is possible.
But again it would be great if you can describe how do you observe the lost steps?

3.) How fast your spindle spins up? Isn't it possible that your stepper motor loosing steps on the high RPM when it does not have enough torque to accelerate up as fast as the spindle accelerates or the same with the decceleration? Can you try to adjust your spindle? I mean if you controlling it with a VFD then you could probably change the acceleration/decceleration parameter for a test.

And we will also run some more tests tomorrow, using the 500RPM spindle speed with your profile, because today we only ran it slowly for better observation as this information that the issue is only on high speed was not clear until now, so we did not know that we should run the test on high RPM.

[spumco]

I'm observing lost steps because when the Z-axis continues down after it is supposed to reverse direction (withdrawing the tap), the DRO reports that the axis is actually rising. Every single time I've run this cycle the DRO has reported an accurate final position, regardless of what actually happened.

If the DRO is rising, and the diagnostic LED's are reporting it rising, but the axis is actually lowering, those appear to me to be lost steps. That, or the software is commanding Z-down motion but reporting a Z-up motion. This seems unlikely.

Another interesting thing just happened as I was testing it out again: It just wound up higher than it should have. Exactly the opposite of the earlier tests, and at only 250rpm this time.

I changed the max Z-axis speed to 150 to see if what you had mentioned about the threading feed rate would influence this.
Homed the Z, jogged down a few inches, and then set G54 offset to 1.0" and started the cycle. Threading depth was changed to Z-1.5" to give me a bit more time to observe what was going on; all else was the same as with the code I posted earlier.

- spindle started [corrrect]
- Z moved down at the commanded feed rate (10ipm) to Z-0.5" [correct]
- Z moved down at the threading rate to (about) Z-0.75", then stopped moving but the DRO kept moving down [incorrect] to Z-1.5"
- spindle reversed direction [correct]
- Z moved up at the threading rate 1.5" [correct]
- Because it stopped moving down at Z-0.75", the true final point is now 1.75" higher than the start point.

This is strange. I wonder if this is some EMI/RFI-related issue.

It's quite possible that my Z-axis stepper motor doesn't have enough torque to reverse direction quickly enough, but I would have thought that would result in no motion at the bottom of the cycle, not it continuing downward. I have replace the spindle motor with a significantly heavier one than was originally installed, but the head isn't back-driving the ball screws (drooping) when the power is off. Two gas springs are installed to help keep the head up.

Here's what I'm going to try:
1. I will change the VFD settings and increase the spindle accel/decel time to see if that changes anything. It is currently set at 1 second, which is pretty quick ramp up/down, but I have a big braking resistor and the VFD appears happy with the setting. I'll try a 1.5 or 2 second ramp, which, as you suggested, should reduce the Z-axis acceleration during direction changes.
2. I will try a different thread pitch (finer) to see if that changes anything.
3. I will write a Gcode file that simply moves the Z-axis up and down a bunch of times at rapid rate, but without any spindle activity. If the axis motor is losing steps due to inadequate torque, this will appear as the mill head being physically lower than when the cycle started. I will set up a dial indicator and indicate the true starting point, and then see if there's any difference after the cycle stops.
4. I will run the same up-down Gcode file, but with the spindle turning. If the first run doesn't show any missed steps, but the second one does, this may indicate EMI/RFI problems. If there are still no lost steps (i.e. the head actual finish position is the same as the start point) then this is a threading problem, and unlikely to be an EMI/RFI or stepper torque issue.

I'll report back when finished. If you have any other suggestions I'm all ears.

-Spumco

[spumco]

Third round of testing complete.

I am not losing steps during normal (non-tapping) Z-motion.

1. I wrote some code that would rapid the Z up and down aggressively with many direction changes, and a dial indicator showed that the head was within .001" - .002" of the starting point when finished. My indicator stand isn't terribly rigid so that could explain a thou or two.

2. Same thing, only with the spindle turning at 1500rpm. No change, no difference between start point and finish point, and the DRO was indicating properly.

3. Same thing, only I set the max feed rate to 250ipm and the acceleration to 50ipm2. This was more than double during the failed tapping test, and still no odd motion or lost steps.

4. Changed the VFD accel/decel from 1 second to 2 seconds and ran the tapping test again with the axis max speeds still set at 250/50. This resulted in the Z-axis being higher than it should by almost 2" at the end of the cycle even though the DRO reported being at the correct height. The cycle started, the spindle spun up, the Z-axis lowered about 0.5" (should have gone to Z-1.5"), and then it changed direction and moved up.

5. Changed the tapping cycle from G33.1 to G33.2 and M03 to M04 to see if it was doing it in both directions. First run the head moved down 1.5" and back up correctly at what appeared to be the right thread pitch. Second run resulted in the same as earlier, with the down motion being way to slow (although the DRO is reporting movement being correct) and the up motion being correct. Second run actual final height was also about 2" higher than it should be.

6. A simple G73 peck drilling cycle did not result in any lost steps or inaccurate motion, despite setting the peck depth and retract very short to ensure aggressive Z-axis direction changes.

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

I watched it very closely, and it appears that during tapping cycles the downward motion and the upward motion are at different feed rates. The downward motion looks like it is feeding at 1/4 the rate it moves back up. Imagine threading a fine pitch tap in, but withdrawing a very coarse one.

It appears that the Z-axis motor is not receiving the correct number of steps in the downward motion, despite UCCNC thinking it is working properly according to the DRO. This is only happening during the G33.1/2 cycles.

And, in addition to the tapping problem, the jogging function seems to stop working in step mode. If I start UCCNC the jog panel works fine until I run a Gcode cycle. After that cycle is finished, if I change from 'continuous' to 'step' mode there is no response from either keyboard on on-screen buttons and the DRO doesn't change. This persists until I restart the software, and I've triple-checked that I don't have a cursor in a text field somewhere waiting for me to press the 'enter' key.

Sorry this is getting long, but I'm at a loss at this point. It feels like there's something wrong with the software and not any of the mill hardware. I'm actually shocked at how smooth it's running at the higher Z-axis speeds.

Thanks again,
Spumco

[spumco]

One other thing...

My spindle encoder is on my motor and not directly on the spindle. I'm running a 1.5:1 pulley ratio, and have that set up in the configuration. You may recall our conversation(s) over the past couple of weeks getting the encoder to play well with UCCNC and my VFD over in the Hardware forum.

The user manual states that the software compensates for the Sact speed, but is this possibly my problem? Is the tapping cycle malfunctioning because even though the software can do the math on the A/B signals, the index signal is happening 1.5 times slower per revolution than the software expects?

If this were the case, I'd expect the Z-axis motion problem to be the same every time. This is not what's happening however, as I've seen the Z-axis wind up both lower and higher than it should - but I'm trying not to overlook anything.