Hangs on G33/G76 command
26 Dec 2013 05:28 - 26 Dec 2013 06:45 #42009
by mtngun
Hangs on G33/G76 command was created by mtngun
I attempted threading for the first time today on my lathe. However, when it gets to the G76 line (or G33, alternatively), nothing happens, nor is there any error given.
The program seems to "hang" and will remain "hung" until I hit the e-stop.
I do have a spindle tach, and EMC is reading it, and displaying the correct spindle speed, as I recently posted in another thread.
I note that the G76 documentation states that the pin "motion.spindle-at-speed" must be set up in HAL before G76 will work, and I don't see a "spindle-at-speed" line in my HAL. Do I need to add something to HAL?
linuxcnc.org/docs/html/gcode/gcode.html#...G76-Threading-Canned
Update: Hal-meter's "spindle-at-speed" is "false" when the spindle is turning and "true" when the spindle is not turning. Isn't that backwards of how it should be? How would I fix it?
![:huh: :huh:](/media/kunena/emoticons/wassat.png)
I do have a spindle tach, and EMC is reading it, and displaying the correct spindle speed, as I recently posted in another thread.
I note that the G76 documentation states that the pin "motion.spindle-at-speed" must be set up in HAL before G76 will work, and I don't see a "spindle-at-speed" line in my HAL. Do I need to add something to HAL?
linuxcnc.org/docs/html/gcode/gcode.html#...G76-Threading-Canned
Update: Hal-meter's "spindle-at-speed" is "false" when the spindle is turning and "true" when the spindle is not turning. Isn't that backwards of how it should be? How would I fix it?
Last edit: 26 Dec 2013 06:45 by mtngun.
Please Log in or Create an account to join the conversation.
26 Dec 2013 08:55 - 26 Dec 2013 08:56 #42012
by PCW
Replied by PCW on topic Hangs on G33/G76 command
Pretty sure motion.spindle-at-speed defaults to true so thats not a problem.
What _is_ missing is index (the encoder index pin is not connected)
Both G33 and G76 wait for the index pulse before starting spindle synchronized motion:
linuxcnc.org/docs/html/examples/spindle....d_spindle_feedback_a
If you only have a single sensor (and it has one count per turn) you should be able to do this:
net spindle-phase-a <= parport.0.pin-13-in-not
net spindle-index <= parport.0.pin-13-in-not
If the index polarity is wrong the correct statement would be:
net spindle-index <= parport.0.pin-13-in
What _is_ missing is index (the encoder index pin is not connected)
Both G33 and G76 wait for the index pulse before starting spindle synchronized motion:
linuxcnc.org/docs/html/examples/spindle....d_spindle_feedback_a
If you only have a single sensor (and it has one count per turn) you should be able to do this:
net spindle-phase-a <= parport.0.pin-13-in-not
net spindle-index <= parport.0.pin-13-in-not
If the index polarity is wrong the correct statement would be:
net spindle-index <= parport.0.pin-13-in
Last edit: 26 Dec 2013 08:56 by PCW.
The following user(s) said Thank You: mtngun
Please Log in or Create an account to join the conversation.
26 Dec 2013 10:07 #42013
by mtngun
Replied by mtngun on topic Hangs on G33/G76 command
The first line was already in my hal. I tried adding the 2nd line but then EMC gave me a boot error: Pin 'partport.0.pin-13-in-not' was already linked to spindle-phase-a'If you only have a single sensor (and it has one count per turn) you should be able to do this:
net spindle-phase-a <= parport.0.pin-13-in-not
net spindle-index <= parport.0.pin-13-in-not
Please Log in or Create an account to join the conversation.
26 Dec 2013 10:27 #42014
by PCW
Replied by PCW on topic Hangs on G33/G76 command
Hmm... maybe this will work better
net spindle-phase-a encoder.0.phase-A
net spindle-phase-b encoder.0.phase-B
net spindle-phase-a encoder.0.phase-Z
net spindle-phase-a encoder.0.phase-A
net spindle-phase-b encoder.0.phase-B
net spindle-phase-a encoder.0.phase-Z
Please Log in or Create an account to join the conversation.
26 Dec 2013 10:31 #42015
by mtngun
Replied by mtngun on topic Hangs on G33/G76 command
Using my original Hal here are some quick and dirty Hal meter checks with the spindle turning:
spindle index ~ false
spindle index enable ~ false
spindle phase-a ~ toggles as spindle rotates
spindle phase-b ~ false
spindle position ~ gives a number
spindle velocity ~ gives a number
encoder.0.index-enable ~ false
motion.spindle-at-speed ~ true
motion.spindle-index-enable ~ false
It does appear that the spindle index is not doing its thing.
As discussed in another thread I had to set the spindle sensor up as phase A rather than as the spindle index, in order to make the axis spindle speed display work.
I am too much of an EMC newbie to understand how to make the Hal file happy with the index and the phase A at the same time.
spindle index ~ false
spindle index enable ~ false
spindle phase-a ~ toggles as spindle rotates
spindle phase-b ~ false
spindle position ~ gives a number
spindle velocity ~ gives a number
encoder.0.index-enable ~ false
motion.spindle-at-speed ~ true
motion.spindle-index-enable ~ false
It does appear that the spindle index is not doing its thing.
As discussed in another thread I had to set the spindle sensor up as phase A rather than as the spindle index, in order to make the axis spindle speed display work.
I am too much of an EMC newbie to understand how to make the Hal file happy with the index and the phase A at the same time.
![:laugh: :laugh:](/media/kunena/emoticons/laughing.png)
Please Log in or Create an account to join the conversation.
26 Dec 2013 11:02 #42017
by mtngun
As you suggested, changing the one line from: "net spindle-index encoder.0.phase-Z" to "net spindle-phase-a encoder.0.phase-Z" seems to fix my problems with no other changes.![:woohoo: :woohoo:](/media/kunena/emoticons/w00t.png)
Now G33 and G76 work, and the spindle speed display still works.![B) B)](/media/kunena/emoticons/cool.png)
I did notice some unstable Z axis speeds during the threading pass at low (150 - 300 rpm) spindle speeds. This was discussed by another poster in another thread. He fixed his problem by adding "net spindle-position encoder.0.position-interpolated => motion.spindle-revs" but my Hal already had the "interpolated" feature and yet the Z speed was still "hunting" intermittently.
Increasing the RPMs to 500+ seems to make Z speed stabilize. Apparently it is a PID tuning problem in the software, and may be influenced by hardware as well?
Ironically, the reason I converted from TurboCNC to EMC was because TurboCNC also failed to maintain a consistent Z speed during low RPM threading. The only solution I found with TurboCNC was to crank up the RPM. Sigh.![:S :S](/media/kunena/emoticons/dizzy.png)
I was told that TurboCNC only reads the RPM at the beginning of a threading pass, and then assumes a constant RPM for the duration of the pass, so I never understood why the Z speed needed to "hunt" in mid-thread. Why not just lock in a constant Z speed?
I dunno whether EMC reads the RPM only at the beginning of the thread, or whether it continues to read the RPM and continues to tune the Z speed in the middle of a threading pass? If it continues to tune the Z speed, that could explain the "hunting," especially with steppers that are not capable of changing speed quickly. Though once again, it seems to me it would be simpler for the software to lock in the Z speed for the duration of the pass? I mean, do you really expect the RPM to vary significantly over the course of a threading pass?
I pulled up my spindle index signal in the Hal scope and it looked clean and consistent, so the spindle index signal does not seem to be the problem. The indicated RPM bounces around maybe +/- 1 rpm, which is pretty good to my way of thinking and certainly no cause to adjust the Z speed in mid thread.
Replied by mtngun on topic Hangs on G33/G76 command
Hmm... maybe this will work better
net spindle-phase-a encoder.0.phase-A
net spindle-phase-b encoder.0.phase-B
net spindle-phase-a encoder.0.phase-Z
As you suggested, changing the one line from: "net spindle-index encoder.0.phase-Z" to "net spindle-phase-a encoder.0.phase-Z" seems to fix my problems with no other changes.
![:woohoo: :woohoo:](/media/kunena/emoticons/w00t.png)
Now G33 and G76 work, and the spindle speed display still works.
![B) B)](/media/kunena/emoticons/cool.png)
I did notice some unstable Z axis speeds during the threading pass at low (150 - 300 rpm) spindle speeds. This was discussed by another poster in another thread. He fixed his problem by adding "net spindle-position encoder.0.position-interpolated => motion.spindle-revs" but my Hal already had the "interpolated" feature and yet the Z speed was still "hunting" intermittently.
Increasing the RPMs to 500+ seems to make Z speed stabilize. Apparently it is a PID tuning problem in the software, and may be influenced by hardware as well?
Ironically, the reason I converted from TurboCNC to EMC was because TurboCNC also failed to maintain a consistent Z speed during low RPM threading. The only solution I found with TurboCNC was to crank up the RPM. Sigh.
![:S :S](/media/kunena/emoticons/dizzy.png)
I was told that TurboCNC only reads the RPM at the beginning of a threading pass, and then assumes a constant RPM for the duration of the pass, so I never understood why the Z speed needed to "hunt" in mid-thread. Why not just lock in a constant Z speed?
I dunno whether EMC reads the RPM only at the beginning of the thread, or whether it continues to read the RPM and continues to tune the Z speed in the middle of a threading pass? If it continues to tune the Z speed, that could explain the "hunting," especially with steppers that are not capable of changing speed quickly. Though once again, it seems to me it would be simpler for the software to lock in the Z speed for the duration of the pass? I mean, do you really expect the RPM to vary significantly over the course of a threading pass?
I pulled up my spindle index signal in the Hal scope and it looked clean and consistent, so the spindle index signal does not seem to be the problem. The indicated RPM bounces around maybe +/- 1 rpm, which is pretty good to my way of thinking and certainly no cause to adjust the Z speed in mid thread.
Please Log in or Create an account to join the conversation.
26 Dec 2013 13:00 - 26 Dec 2013 13:09 #42019
by PCW
Replied by PCW on topic 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)
Heres a video that shows the gearing in action:
(this cannot work without a decent encoder)
Last edit: 26 Dec 2013 13:09 by PCW.
The following user(s) said Thank You: mtngun
Please Log in or Create an account to join the conversation.
28 Dec 2013 06:17 #42080
by andypugh
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?
Replied by andypugh on topic Hangs on G33/G76 command
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?
The following user(s) said Thank You: mtngun
Please Log in or Create an account to join the conversation.
28 Dec 2013 07:10 #42083
by mtngun
Replied by mtngun on topic Hangs on G33/G76 command
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: :whistle:](/media/kunena/emoticons/whistling.png)
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).
![:whistle: :whistle:](/media/kunena/emoticons/whistling.png)
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).
Please Log in or Create an account to join the conversation.
28 Dec 2013 07:55 #42088
by andypugh
You could have just asked![:-) :-)](/media/kunena/emoticons/smile.png)
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.
Replied by andypugh on topic Hangs on G33/G76 command
so apparently EMC does continue to monitor the RPM and tune the Z speed in mid-pass (unlike TurboCNC).
You could have just asked
![:-) :-)](/media/kunena/emoticons/smile.png)
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.
Please Log in or Create an account to join the conversation.
Time to create page: 0.127 seconds