Why two previews may not form one sequence
Assume the real robot stays at A during Dry Run and the task list requests moves to B then C. With batching enabled, one MTC task produces a connected preview A to B to C. With batching disabled, each row creates a task from live CurrentState: first A to B, then A to C. The GUI replaces its preview when a new trajectory arrives rather than queuing both previews. Execute with Dry Run cleared performs motion; after a successful first move, the live robot can be at B before the next row plans. A schematic path shows order, not physical geometry.
EROBS / PREVIEW COMPARISON
Why two previews may not form one sequence
Same task list: move to B, then C. The real robot stays at A during Dry Run.
Batching on
Both moves share one MTC task.
Batching off
Each row creates a new MTC task.
One connected preview
A
B
C
live start
target 1
target 2
A → B → C
The later stage continues from the
earlier stage’s planned endpoint.
First row
A
B
Second row
A
C
Both start at live CurrentState = A.
The preview never moved the robot to B.
What the GUI displays
A new trajectory replaces the active preview; the viewer does not queue it.
With batching off, A → C replaces A → B, even if its animation has not finished.
Execution changes the live state
Clear Dry Run, then Execute to request motion. After the first unbatched move succeeds,
the robot is at B, so the next row can plan from B. Cached replay has separate eligibility checks.
Schematic order only; arrows do not depict physical paths or distances.