How are the DRO and Stepgen kept in sync?

After looking through a lot of code... I am wondering how it is that the stepgen/make-pulse code can be configured for things like Type 2 or DoubleStep (using reset) without the rest of LinuxCNC being aware.

I'm sure I'm lost, but if stepgen is called twice for each step: once for "on" and once for "off" -- how does LinuxCNC become aware when stepgen is configured to step on every call?

Is there a feedback to the motion controller that I haven't stumbled upon?

Also, is there a component for using a hardware-based step generator?

Thanks in advance. BTW, I'm using a 2.8 dev on Debian Wheezy.

I think I might be catching on: it appears the Trajectory Planner/Motion Controller sets position targets and StepGen (and similar) detect that movement is needed. It then issues steps to achieve the new position.

Is that right? If so, how does an F speed trickle down to stepgen?

Linuxcnc is constantly updating the commanded position (every servo period) to the stepgenerator. The feed rates are determined by the trajectory planner, and conveyed to the stepgenerator by the rate of change of the commanded position.

And there is a "feedback" the stepgenerator keeps track of the position that it has stepped to and reports that back to Linuxcnc. It is even possible to configure the stepgenerator like a servo. Sending it a velocity command (instead of a position command through a PID loop and use the stepgen's position feed back to close the PID loop.

So is it safe to say the Trajectory Planner sets a desired position, the stepgen component, always comparing current position to desired position, issues steps when they aren't equal?

Further, is it the case the Trajectory Planner just waits for the current position to become the desired position before executing the next block of gcode?

So is it safe to say the Trajectory Planner sets a desired position, the stepgen component, always comparing current position to desired position, issues steps when they aren't equal?

The stepgen issues steps at the current commanded velocity (from the TP) and makes very minor adjustments in the step rate if there is a position error.

Further, is it the case the Trajectory Planner just waits for the current position to become the desired position before executing the next block of gcode?

No, for normal motions, the TP does not wait (it does compare the commanded and feedback positions and will post a error
if they differ by more than the following error limits)

The TP does wait on probe motions and index detection for spindle synced motion

I'm getting the idea and I appreciate the answers.

But I don't understand how the Planner doesn't, in a manner of speaking, 'wait' for a position to be achieved. Stepgen doesn't have a queue of pos_cmd/pos_fb. If the Planner changes pos_cmd while stepgen is executing it, it seems that would upset the 'system'.

I'm not thinking it goes into a spin-loop, but I don't understand how it could move on to decoding another block of G code which may finish sooner than the last commanded position does. When does it know the stepgen code is officially done? When pos_fb reaches the pos_cmd position?

BTW, I'm just looking at stepgen as type 0 step/dir and position mode. This started out as trying to use type 2 in order to double the base_freq or double the pulses.