Seeing the planner output is something I’ve wanted before too. When I increase the joystick position from slow to fast, it will momentarily slow down and then speed up. I am pretty confident my movement commands are not doing that, and I have no visibility into why the planner is doing that.
It looks like the simulation machine is to compile the thing as a Linux program and it looks like you can log the position trajectory over time. You would have to back out the segment trapezoids, if that’s even possible.
The gcode parser/interpreter does the vast majority of the calculation and inserts segments (called “blocks”) into the movement queue, and ISRs dequeue from the movement queue and manage the steppers. (This is why the queue not being depleted implies the 8-bit hamster wheel is keeping up with fancy gcode.)
When movements are inserted into the queue they can modify adjacent movements that are already in the queue, like forcing different acceleration if the start of the new movement is not compatible acceleration-wise with the end of the previous movement. This means it’s not enough to capture the segments as they are inserted into the queue. You have to capture them as they are coming out of the queue (or at least are not near the tail of the queue).
It’s not feasible to add serial diagnostic to the ISR that pulls from the head of the queue but perhaps there could be a mid-queue reporting feature that spews some segment information to the console…