G33 does not adjust IPM after the first one. 2.9.0 pre-3376

RBC wrote:

Also, which file holds the codes for G33 behaviour? So I can understand how it works in detail. Thanks.

G33 is a special case of a straight move:

github.com/LinuxCNC/linuxcnc/blob/master...erp_convert.cc#L4749

The tricky part of using a stepgen to emulate an encoder is that there is no index pulse.

Ideally you would add a physical index pulse from a sensor on the spindle, then modigy the stepgen.c code to output a scaled version of the stepgen counts that latches to zero whenever index-enable is high and the index pulse is seen.

Ideally you do really want to use an actual index, though you could emulate it at a modulus of the stepgen counts if the spindle to motor gearing is fixed (eg toothed belt not friction belt)

The position output pin should zero at index (but only when enabled) then count up by exactly 1.0 for ever revolution of the spindle.

Rather than get the step counts, it could watch the actual step pulses. (or is that what you meant?)

Hmm.... If you configure a second Mesa stepgen to run alongside the main one, but in quadrature mode, you could loop that straight back to an encoder counter. (Or configure your stepper drive for quadrature input, if it can do that)

Then you could use an actual real index sensor on the spindle.

There is a sim_encoder HAL component, but it would need to run in a base thread and probably isn't fast enough.

I was thinking physical loop-back. HAL would be too slow as it only runs once per mS (by default, you can run GPIO in a faster thread where necessary)

A physical index detector will work properly, the uP approach won't give a consistent index run-to-run. Admittedly that only matters if you start a thread one day, shut down and complete it the next day.

RBC wrote:

It probably should throw and error at some point that the IPM cannot catch up with the RPM requested.

There is a fix for that. I am trying to figure out if it went in or not.

github.com/LinuxCNC/linuxcnc/pull/479