[LinuxCNC/linuxcnc PR#354] adding optional I parameter to G33.1 which scales the spindle speed u…

#1 – rene-dev 于 2017-11-26

currently the I is modal… I will update this and check for block->i_flag so no I will always use a scale of 1

#2 – rene-dev 于 2017-11-27

working as expected now

#3 – rene-dev 于 2017-11-27

probably affects #167, which has not been merged…

#4 – rene-dev 于 2018-07-31

Any reason this is not merged? Im happy to rebase it, once #167 is merged…

#5 – zultron 于 2018-07-31

The patch LGTM.

I grepped through the tests/ directory and didn’t immediately find any G30 regression tests to add this to.

#6 – SebKuzminsky 于 2018-08-01

@rene-dev, just so I understand, the intent here is to retract a tap faster than we fed it in, right? On the theory that the coordinated retract move shouldn’t cut, so we can go fast.

The variable that holds the spindle scale factor is sometimes called scale, sometimes mult, and sometimes reversal_scale. Future hackers will surely benefit from consistent, descriptive naming here.

I’d like to see a mention of the spindle speed change in the G33.1 description in gcode.txt (after “step 3”?), and a mention of the speed returning to the programmed S-word (after “step 6”?).

A test would be valuable too, but as @zultron points out there’s no existing suite to tack it on to…

That’s my feedback on this branch.

#7 – SebKuzminsky 于 2018-08-01

Would it make more sense to have the I-word specify the retract spindle speed, rather then a multiplier/scale to be applied to the “feed-in” spindle speed?

Whatever interface we choose, we’re stuck with for the foreseeable future.

#8 – rene-dev 于 2018-08-01

the spindle speed is set by the S word anyway, other controls also seem use a multiplier.
I would like to add a default multiplier somewhere, so it can be used by cam without changing the post.
but not sure where to set that.

https://www.youtube.com/watch?v=GrPdQDpGQMI

#9 – rene-dev 于 2018-08-01

I will do a cleanup of the naming, and add some more docs.

#10 – KimK 于 2018-08-01

I would agree with Seb that the retract spindle speed should be selected in RPM rather than a multiplier, for at least three reasons: (1) That is how the advance spindle speed is specified (makes them consistent); (2) It will help make it more obvious when an upper limit is being exceeded, since the spindle is likely to be in a low gear during the entire tapping cycle. So if low gear on that machine is 10 to 350 RPM, the operator will know not to exceed 350 RPM when retracting; and (3), it makes it possible to adjust (increase?) the tapping speed without causing an excess of retract speed (which is probably already set to maximum). Other than that, it sounds great, Rene, thanks for doing this! I look forward to seeing it run.

#11 – KimK 于 2018-08-01

Number (3) above could also be written as, “Makes it possible to adjust the two speeds independently.”

#12 – andypugh 于 2018-08-01

I think I prefer a factor. Possibly because it is then unitless. I know that rpm is the only supported unit for spindle speed, but nevertheless a factor seems more robust.

#13 – rene-dev 于 2018-08-01

A factor is easier, more obvious, and makes much more sense. why would you have rpm in 2 places?
then you need to think about the speed, and think of a bigger number.
a factor can also be a default number greater than one, independent of the tap size/rpm

#14 – SebKuzminsky 于 2018-08-02

I’m happy to go with a speed scale factor if that’s the consensus.

There was a question on IRC about spindle-sync tracking error, and a concern that the tracking error might be proportional to spindle speed. If that’s the case, changing the spindle speed on the retract (unscrew) move would follow a different track through the part and cut material, even through it ideally shouldn’t.

Have you checked (with halscope maybe?) if this is worth worrying about?

Have you cut threads using this feature? Did it work well?

#15 – KimK 于 2018-08-02

I still think that two RPMs are better to avoid having one adjustment affect another; however, if the other controls are doing it with a reverse speed factor, then I can live with that since there is the benefit of doing it in a way compatible with other controls. (Too bad, for a moment I imagined that one day Fanuc, Haas, etc., might add a parameter to their controls to enable G33.1 in “LinuxCNC mode”. )

The default (unprogrammed) retract speed factor, IMO, should be “one”, although I would be OK with an INI file entry setting another value as the default.

On the matter of the spindle-sync tracking error, isn’t it doing that already? I mean, when Z is following the spindle down, isn’t lagging behind being “too high”? And when Z is following the spindle back up, isn’t lagging behind being “too low”? So aren’t we already getting two tracks through the material? This feature would only increase/multiply the retract-side error. It seems like this problem should be fairly minor, especially at these relatively low Z travel speeds, assuming that tuning is good. I look forward to hearing following-error reports, either real or simulated, if anyone does them.

#16 – rene-dev 于 2018-08-02

there is a jitter issue, for which there is a fix which has not been merged. I dont understand why. https://github.com/LinuxCNC/linuxcnc/issues/164

if there is a tracking issue, your servo/drive system is badly designed or not tuned properly.
there is not ever any significant lag, if there would, threading on a lathe would be impossible.
again, the motion is synced, so whatever happens to the spindle the axis will follow. at any speed.
unless your spindle goes too fast, then bad things will happen, and linuxcnc will not warn you about that.
but there is a fix, which has also not been merged. https://github.com/LinuxCNC/linuxcnc/issues/167

Why you would rigid tap at low speeds is also beyond me. You need to get to the cutting speed of the cutter to be efficient. The whole point is that its fast. I regularly do rigid tapping in excess of 1000 rpm with no problems. And I want to go even quicker.

but none of these problems are in any way related to this feature, you can also break taps with stock behaviour. If your machine is not capable of a faster retract move, dont use one.

the idea of another default value is, to tap faster when using a cam, without the need to add the multiplier to the post processor. But im not sure where to specify that. Ideally it should be possible to adjust that value without changing the configuration. maybe a model code?

#17 – andypugh 于 2018-08-02

Maybe retract factor could be a persistent numbered parameter?

#18 – KimK 于 2018-08-02

Sounds good to me. Looks like the next available one in sequence would be #5602 if we don’t mind going back to persistent after a run of volatile. Oops! That would be for 2.7, didn’t check master.

#19 – shulter 于 2018-08-15

This is an awesome improvement and will save me lots of time. Thanks @rene-dev !

btw. I do experience jitter problems with G33.1 and S4000-6000. The original controller with the same hardware did not show such jitter. Looking forward to #164 and #354 getting merged!