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.

Thanks for the details.
From all this information, I decided to use a microcontroller to get the step counts and output 3 pins into a mesa encoder's A,B and Z.
Do you see any issues with this approach?

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.

Yes. I was planning to read the actual step pulses using a timer/counter on the microcontroller and feed them to the encoder module on 7i92.

The idea to run another stepgen in quadrature mode is promising. I will try that idea first.

andypugh wrote: 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) .

Would this be a physical connection from the quadrature output to encoder counter or a hal pin connection?
But there will no index pulse as you said. So microcontroller will also solve that problem.

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.

I have completed the uP integration. It seems to work as expected. I used the step/dir mode on hm2 to make things easier.

One thing I notice using G33, it does not seem to obey the max Velocity setting on Axis. It probably should throw and error at some point that the IPM cannot catch up with the RPM requested.

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