G76 - Pause in Z during exit taper Linux CNC 2.7.0

Went straight from 2.6.9 to 2.7.0 (not pre)
The config attached is a sim config. Should run without gardware. I run it in a virtual session using vmware player. I was quite suprised to see same blip on the physical machine and the virtual machine too. I'll have a ho with sim axis tonight.
Thanks for all the help with this.

Jeff has been goofing around with it. Could you see if setting F0 before the g33/g76 fixes the problem?

Sam

I'll have a go when I get home, assuming I can sneak out to the shed . F0 interesting thought. The test code fragment nowhere sets the feed rate using an F code, but the full version does for the prior operations. That might explain why running the test code after the full version still hiccups - the last F code is still active. Not sure why running the test code again works though.

Might also try without the G96 - I'll just set a constant spindle RPM and see if any difference.

Did you observe the flip to G17 during running of the test code BTW - or is that just me too

As always, thanks.

Keith

Genius!
If I set F0 prior to G76, I just get that tiny glitch you can see in the test code, but the velocity dropping to zero goes away.
If I run the code again and set say an F100 before the G76, the pause where zvel drops to zero reappears.

I can see the same effect in the HAL-SIM-LATHE sample config - so problem identified, and temporary work around found.

Now somebody needs to dig into the code and see why it would need an F0 before invoking G76 (and I suspect the fix will be invoke a F0 internally as part of the G76 internals!)

Anybody else using G76 on 2.7.0 put an F0 in just to be sure!

Thanks a lot guys, most appreciated.

Great!

I opened a bug on sourceforge

sourceforge.net/p/emc/bugs/438/

sam

I compiled 2.7.2 with the TP debug output on, and ran a stripped-down version of the example program. I see the velocity blip too running the axis sim config. It's due a bug in how the TP calculates desired velocity for an arc blend. It always uses the requested feed in distance / time, rather than distance / rev (which is what actually controls feed in synced motions). I have a hotfix ready to test in the hotfix/bug438 branch on my github page. All it does is skip arc blends for any spindle-synced motion, which will fall back to 2.6.x behavior.