How are the DRO and Stepgen kept in sync?

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.

If, for example, the HAL file were (psuedo-coded):

loadrt hardware_Interface_PRE_motion servo_thread
loadrt motion_controller_handler servo_thread
loadrt hardware_Interface_POST_motion servo_thread

In this example, a feedback item is updated in "pre", then the motion controller items are invoked, then the new pos_cmd/freq is pushed out to the hardware by "post".

Assuming a 1ms servo thread time, how does the hardware have any idea of how long it actually has to perform the move? The time from POST acquiring the new cmd_pos/freq and the time PRE needs to update pos_fb can vary due to execution time of motion_controller_handler.

How can it calculate items such as velocity/acceleration over time and be assured to land at the new cmd_pos before PRE requires the update info? It seems to me the 1ms frequency of the servo thread will vary and rarely be exactly 1ms.

Does this not have an effect on hardware's ability to arrive at the given location in the allotted time?

JItter in the 1 ms servo thread does cause position errors in the stepgen.

Typically they are too small to worry about unless you have a combination of high speed
and high accuracy requirements, as they are in to 50 to 100 uinch range with typical
latencies and typical machining speeds.

There are 2 main components of the error:

1. Delay from reading the position to writing the new velocity.
This only affects accelerated motion and the error is proportional
to the acceleration*delay

2. Servo thread jitter causing errors in the position feedback
This does not cause a direct error but generates an error
proportional to velocity that causes the position feedback loop to
make a incorrect adjustment in the velocity

Neither of these errors cause static position errors, but rather inject a small amount of noise
into motion profiles. In most real machines, these errors are swamped by mechanical errors.

#1 can be compensated for by adding FF2 to the control loop (FF2 = seconds between position read and velocity write)

#2 can be compensated for by lowered servo thread jitter or on Mesa hardware, by using the DPLL to sample the position.

Not sure about other hardware but the combination of the 2 remedies above with Mesa hardware reduce the errors to a few uinches at normal cutting speeds ( say to 200 IPM )