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!!

Linuxcnc has no ability to 'drip' feed gcode commands.
You can stack MDI commands but that doesn't always work the same as a program.

I realize neither of these is what you want to do anyways.

So the other two ways to control movement is jogging and external offsets.
Jogging seems to most appropriate for what you are doing.
jogging is made to be re-targeted mid movement.
Each axis has it's own planner and they are not coordinated with each other.

If you want to coordinate with QtPlasmac, best to have them integrate a 'scan' mode to lock out the user from trying to jog but otherwise I think if idle, Qtplasmac won't mind.

Thanks, that is very helpful.

Jogging being designed to be re-targeted while already moving is the key point I was hoping to confirm.

The note that each axis has its own planner and is not coordinated with the others is also important. That means FabScan should probably generate the desired Cartesian velocity vector itself, while LinuxCNC remains responsible for the real-time per-axis acceleration/velocity limits.

Your QtPlasmaC “scan mode” suggestion also makes a lot of sense. For early testing I can keep FabScan limited to idle/manual operation, but a dedicated mode that prevents conflicting user jogging would be a cleaner long-term solution.

This gives me a much better direction for the simulation and LinuxCNC SIM testing before I try any continuous motion on the real machine.

Thanks again!
Jeff