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.

Other than spindle synchronized motion or probing, (or waiting for digital input pins) The TP does not wait
for any "motion complete" signal from the lower level motion logic

One of the TPs jobs is to supply motion waypoints to the low level motion components via hal.
These low level components may be a stepgen, a PID component etc. The TP does not
overrun the low level motion, because in fact its _providing_ the low level motion commands as a series
of position waypoints (and associated velocity) every servo thread invocation (typically 1000 time a second)

So in fact the TP _is_ changing the commanded position handed to the stepgen and changing it 1000 times a second!

These position waypoints may in fact be the blended combination of a number of gcode statements.
Its also the TPs job to guarantee that the stream of waypoints do no violate the acceleration or velocity limits
of any axis or joint. Its the low level motion components (say stepgen) job to follow the provided stream of waypoints
with minimal error.

As I mentioned before, the only thing that the TP does with position feedback is check that it is
within the following error limits

Thanks so much for your answer. I was reading 'output_to_hal()' in control.c and what you've said started to occur to me. The only question it raises is accel/decel. If TP is spoon-feeding commands:

How does stepgen know how long it ultimately has for acceleration?
How does stepgen know when deceleration is in its future?

Or are you saying that the velocity information is being calculated by TP and just obeyed by stepgen? Meaning pos_cmd and velocity info are written at the same time? If so, I misunderstood what I was reading in stepgen.c

I'm sorry I'm a little daft here, but I'm trying to understand how this all works for several reasons. Having a background in text processing and compilers, I would like to write a stronger error checker/more precise error reporter front end for the G code input file. I also want to change my mill to using one step per base_period instead of the one-on/one-off style of type 0.

How does stepgen know how long it ultimately has for acceleration?
How does stepgen know when deceleration is in its future?

The simple answer is that it does not know either of these things
nor does it need them since all motion planning is in the TP,

The stepgen only needs the next position and the velocity to get there

Note that changing the software stepgen mode does not affect any of this

I do see that the 'type' of output by stepgen will not be affected by any of this. I guess my fault was not seeing how the TP and stepgen and parport all communicated via HAL's shared memory.

I was looking for items like 'valid' flags or 'completed' flags etc. to keep them in-sync, but somewhat disconnected. I now realize they are very much interconnected using the base thread's and servo thread's timing and execution order.