Understanding hardware stepgens

I am sure this will be an easy question for you guys.

I get the power of generating steps from hardware instead of letting LinuxCNC do it, Thats not the issue for me. I am confused about how this works on a hardware level.

How does LinuxCNC tell the hardware what to generate, or how does the hardware know?
How does HAL know if the position is reached? When we use the stepgen, "feedback" is given to stepgen (I think) to let it think the loop is closed. So how does the loop close with hardware generators?

I have been pondering over this ever since I read about it, and since I have yet to come across the answer, I guess its time to ask.

The hardware stepgens work very much like LinuxCNCs software stepgen. They are basically rate generators (digitally controlled clocks or oscillators) with position feedback (a step counter) fed back to linuxCNC. The position feedback allows linuxCNC to correct for small errors due to differences in linuxCNCs and hardware timebase and delays from direction reversals. Basically the whole system is like a velocity mode servo where LinuxCNC reads the current position (step count+fractional step count) and sets the step rate every servo cycle

So basically CNC says -x move this fast, Y move that fast. Then the step gen reports back in the next exchange how far they went. And so forth and so on.

I was thinking CNC gave a distance to move, then maybe checked if the move was completed.

Now would the base thread be the same rate as if software gen were used? Or do we get to slow down the base thread as a result of not needing to command each step?

Yes basically, with the added detail that how fast its asked to move is the current TP velocity + feedback info calculated from the current stepgen position vs LinuxCNCs TP position

No base thread is needed (well effectively the base thread is now in hardware and many MHz)

Oh no base thread sounds really cool. The updates are done at a servo thread time then? I could see where that would REALLY free up the PC cycles!

Just dawned on me, I guess this is how the gecko's are able to change step size on the fly? Because LinuxCNC is not counting steps, so the distance traveled is whatever the gecko reports.

I think I have learned my quota of trivial information for the day

Thank you Peter

Geckos dont really change step size on the fly (its always takes 10 pulses to make a full step)
what Geckos do is "morph" between micro stepping and full stepping (with a divide by 10 prescale) by gradually changing the step motor current setpoints from sine/cosine to square waves over some speed range. This allows better torque at higher speeds where the current never reaches the setpoint peaks

Back on this topic again. I am thinking about generating steps in my hardware. I think I fully understand from my side how to generate the steps. By this I mean setting up a 32 bit accumulator, and every time the 17th (or whatever) bit changes that is my step bit. then every timebase add or subtract some number up to 65535 to the accumulator. Ok, that is easy I think - now for the hard part (for me).

Exactly what is sent to my hardware? is it a number between 0 and 65535 (in this example) so really LinuxCNC is sending the "adder" if you will? if so how is this part set up in HAL file?
If not is someone willing to take my hand and lead me through this? Keep in mind I get tripped up on Jargon sometimes, I have no issue with concepts and implementing them, once I understand what I am being told.

PCW wrote:

The hardware stepgens work very much like LinuxCNCs software stepgen. They are basically rate generators (digitally controlled clocks or oscillators) with position feedback (a step counter) fed back to linuxCNC. The position feedback allows linuxCNC to correct for small errors due to differences in linuxCNCs and hardware timebase and delays from direction reversals. Basically the whole system is like a velocity mode servo where LinuxCNC reads the current position (step count+fractional step count) and sets the step rate every servo cycle

Not sure if Mesa hardware can do this, but the Pico Systems Universal Stepper Controller can be
set so any axis can count a real encoder instead of counting the steps going out. With our
Gecko Interface module, you can use Gecko 320 step-servo drives like real servos, such
as being able to E-stop and move the machine manually with LinuxCNC acting as a DRO,
then resume CNC operation without losing your position. You can do the same with steppers,
other than the drag of the motors always being present.

Otherwise, our boards do step generation and position counting pretty much the same way.

Jon

Hostmot2 has no built-in way to do this, but its easily done (and has been done on real machines) by setting up the axis like a servo axis and using a PID loop with encoder feedback and the PID output connected to the step generator running in velocity mode (the PID loop with only P and FF1=1)

Basically with the rate generator you have an almost perfect velocity mode servo (so only FF1 and a bit of P are needed)