Recommendations on LinuxCNC-native interface for continuous external motion.

I am doing some planning for the next major step in FabScan, my open-source LinuxCNC camera tracing project, and I would appreciate some input from people who understand the LinuxCNC motion layer better than I do.

FabScan recently reached `v0.6.0-alpha.1`.

Project:
github.com/FabLabRacing/FabScan

The current version follows a physical profile using a camera, persistent world-space path state, connected-path look-ahead, a planner, and a separate controller/safety layer.

At the moment, real-machine following is deliberately conservative:

capture frame
→ update path belief
→ plan bounded XY move
→ coordinated G1 XY move
→ stop / settle
→ repeat

That is now working quite well. On the latest difficult test shape, the real machine completed 800/800 planner steps without a HOLD, with most of the trace within a few thousandths of the exact SVG reference.

I still have some sharp-vertex work to finish before increasing speed, but I have started thinking about the eventual move from step-and-settle following to continuous velocity-based following.

My current development plan is roughly:

1. **Characterize the ceiling of the stepped approach.**

   Measure step size, cycle time, effective IPM, perception/planner time, accuracy, and HOLD behavior until I know how fast the current discrete method can realistically go.

2. **Measure predictor/dead-reckoning performance.**

   In the SVG simulator, feed the estimator camera observations at the actual achievable camera rate while predicting position/heading at a faster rate between frames.

   Since the simulator has exact geometry, I should be able to measure how prediction error grows versus time since the last observation and versus machine speed.

   The idea is to establish a real prediction/latency budget rather than guessing.

3. **Build the continuous loop entirely in simulation first.**

   FabScan already has a machine-dynamics simulator using the actual acceleration, velocity, and servo-period limits from my LinuxCNC machine.

   My thought is to let the planner produce a desired velocity/vector, let the estimator/predictor fill the gaps between camera frames, and let the simulated LinuxCNC/machine layer integrate that continuously.

   I would also test delayed/dropped frames, shrinking look-ahead, corners, confidence loss, and controlled deceleration to HOLD before trying it on hardware.

4. **Determine the correct LinuxCNC-native interface for continuous external motion.**

This last point is where I would especially appreciate advice.

Looking through the LinuxCNC Python interface, `JOG_CONTINUOUS` with Cartesian-axis jogging and teleop enabled looks like one possible route.

Conceptually, FabScan would want to update something equivalent to:

desired X velocity
desired Y velocity


at around tens of Hz, while LinuxCNC remains responsible for the actual real-time acceleration-limited motion at the servo rate.

I specifically do not want FabScan/Python attempting to become a real-time motion controller. LinuxCNC should continue owning that layer.

So my questions are:

Is Cartesian `JOG_CONTINUOUS` / teleop motion the appropriate LinuxCNC interface for this kind of sensor-driven velocity control?

Can the velocity of X and Y continuous jogs be updated repeatedly while they are already moving, without effectively stopping/restarting the jog?

If X and Y velocities are updated separately, does LinuxCNC treat them cleanly enough as a changing Cartesian velocity vector for this application?

Is there another interface inside LinuxCNC that would be more appropriate for continuously supplying an externally generated XY trajectory/velocity command?

And are there any particular concerns with doing this alongside QtPlasmaC, assuming FabScan continues to operate only while the machine is idle/manual and never controls Z, torch firing, THC, Cycle Start, or the cutting process?

I am not committed to any particular implementation yet. In fact, I would much rather learn that I am heading toward the wrong LinuxCNC interface before I design the continuous controller around it.

The project now has record/replay and an SVG ground-truth simulator, so once I understand the LinuxCNC side I should be able to model and test most of this before allowing continuous motion on the physical machine.

For anyone interested in how FabScan reached its current architecture, I added a `HISTORY.md` to the repository. It explains the earlier local follower and Corner Assist experiments, why the state estimator and connected-path planner were added, why replay led to the simulator, and what the first real-machine tests exposed.

Any advice on the LinuxCNC side of this would be very, very, welcome, especially from anyone familiar with teleop/jog internals, external motion control, or sensor-guided applications.

Thanks!!