Hangs on G33/G76 command

Linuxcnc's spindle synchronized motion basically gears the tool motion to the spindle for the duration of the cut, however having only a single reference point for tracking spindle speed is very far from optimum. Without adding filtering, even a 1% spindle speed variation would require the Z axis to make a large instantaneous step once per turn. It is possible to filter this but a much better solution is to have a real encoder on the spindle (even 20 notches would be a big improvement) This does require 2 inputs instead of one (one for A and one for Index)

Heres a video that shows the gearing in action:



(this cannot work without a decent encoder)

mtngun wrote: I did notice some unstable Z axis speeds during the threading pass at low (150 - 300 rpm) spindle speeds

You might try chaining the accel settings, I think I had a similar problem several years ago, and I think that was the fix.
Do you have any idea how near to the actual maximum your setting is?

PCW, I've added an encoder to my to-do list, but for now I'll try to soldier on with the single spindle sensor. :whistle:

AndyPugh, I normally run conservative speed and acceleration settings on my stepper driven equipment, but temporarily crank up the speed and acceleration for threading, particularly on the Z axis. Currently the Z is set at 25 ipm max velocity and 0.4 acceleration (inch units). The velocity is maxed out for my hardware, but I may be able to crank up the acceleration a little more, if only temporarily for the occasional threading job.

BTW, I conducted an experiment on an air pass to see whether EMC was tuning the Z speed in mid-pass. After beginning a long threading pass, I turned off the spindle. EMC stopped the Z axis. When I turned the spindle back on, the Z axis resumed motion, so apparently EMC does continue to monitor the RPM and tune the Z speed in mid-pass (unlike TurboCNC).

mtngun wrote: so apparently EMC does continue to monitor the RPM and tune the Z speed in mid-pass (unlike TurboCNC).

You could have just asked

During a spindle-synchronised move the Z position is slaved in a fixed ratio to the value seen on the motion.spindle-revs pin.

It might be interesting to halscope that pin and see how "glitchy" the value is.

More slots would be better.

I did some more air-testing of threading, with my Z accel cranked up to 0.5 and the spindle speed turned down to 68.7 rpm, which was as low as the display would read. It can spin a bit slower but EMC seems to require at least 60 rpm or so before the speed will display. I was air-cutting 5" long threads with various pitches.

Sometimes it behaved OK.

Other times the Z speed "hunted."

Other times the Z speed maxxed out for no apparent reason -- the speed was not proportonal to the pitch. Once it got into its max speed mode, sometimes it took quite a while for it to calm down and return to the appropriate speed. Sometimes several inches, sometimes several passes. So it was not just a matter of normal deceleration -- it was more like the accelerator pedal was stuck. :woohoo:

I tried monitoring the "spindle phase a" on the Hal meter and it was always solid when I was watching it. The displayed RPM rarely varied more than +/- 0.1 rpm. Once in a great while there would be a blip in the displayed RPM -- which would be followed by a blip in the Z axis speed, but that didn't happen often. The Z hunting incidents occurred more frequently than the blips in the display speed, so I wondered if the threading code was using a different signal than the displayed speed ?
image missing http://i487.photobucket.com/albums/rr235/mountainmolds/spindle-phase-a_zpsfcbf7be6.png

Next time I will monitor the "motion.spindle-revs" pin instead.

More air-testing.

I was using G33 Z_ K.05, threading back and forth between Z2 and Z7, and sometimes varying K. VFD set at 68.7 rpm.

Several times the Z speed "hunted" in mid-thread even though the displayed RPM and the Hal scope "motion.spindle-revs" were solid at the time.

Here is a pic of the "motion.spindle-revs" scope taken while the Z speed was "hunting" in mid-thread. As you can see, there was no problem with the "motion.spindle-revs" signal.
image missing http://i487.photobucket.com/albums/rr235/mountainmolds/thread3_zps61565351.png

I gradually increased K on each pass like this:

G33 Z2 K.05
G33 Z7 K.06
G33 Z2 K.07
..... and so on up to ....
G33 Z7 K.15

At that point it was running the max Z speed of 25 ipm for the entire 5" length of the thread, even though the "correct" speed should have been approximately 15 ipm.

Then I gradually decreased K on each pass:
G33 Z2 K.14
G33 Z7 K.13
G33 Z2 K.12
.... and so on.

Here is a pic snapped in mid-thread, K=.12, and it is running at the max Z speed of 25 ipm even though the "correct" speed would have been closer to 10 ipm.
image missing http://i487.photobucket.com/albums/rr235/mountainmolds/thread2_zpsc63d8b0d.png
It finally slowed to the correct speed with less than an inch left to thread.

As other EMC users have noted, low RPMs seem to produce more threading errors than high RPMs, even though you would think the opposite would be true, so I was deliberately torture-testing EMC by threading at the lowest possible RPM. Most of these problems seem to go away if you crank up the spindle speed to 500 rpm or so.

Still, it sure seems like there is a problem with the PID tuning or whatever is used to sync the Z axis with the spindle.

Does the PID tuning "adapt," and if so, does it "remember" the PID settings for the next threading pass? If so, that could explain why the maxxed out Z speed required several passes to return to normal. :huh: