Skip to content

Route job encoding by driver capability, not leftover dialect - #421

Open
knipknap wants to merge 2 commits into
fix/415-ruida-driver-switch-crashfrom
fix/420-ruida-stale-dialect-encoding
Open

knipknap wants to merge 2 commits into
fix/415-ruida-driver-switch-crashfrom
fix/420-ruida-stale-dialect-encoding

Conversation

@knipknap

Copy link
Copy Markdown
Contributor

Problem

Sending a job to a machine that was switched over to the new Ruida (RPA) driver crashed the send-job task (#420):

RuntimeError: Failed to parse gluescript line: 'G21 ;Set units to mm': Missing '(' in gluescript line: 'G21 ;Set units to mm'. Expected format: method_name(arg1, arg2, ...)

Jogging worked, but every job sent GRBL G-code to the Ruida driver.

Root cause

Every machine carries a dialect_uid describing the G-code flavor of its controller, and new machines default to grbl. Switching the machine to a driver that does not speak G-code (RuidaRPAAdapter) did not clear that setting, so the machine still claimed to be a GRBL speaker.

The job encoder route in IntentBuilder._build_encoder() picked the native GRBL encoder purely from the dialect (_is_grbl(dialect)), without consulting the connected driver. The resulting GRBL G-code (G21 ;Set units to mm preamble) was then handed to RuidaRPAAdapter.run()stage_gluescript(), whose parser only accepts method(arg) transcript lines.

Fix

  1. Machine.set_driver() now syncs the dialect with the driver's G-code capability (_sync_dialect_with_driver):
    • non-G-code drivers (uses_gcode == False) clear the leftover dialect,
    • switching back to a G-code driver while no dialect is set restores the framework default (grbl), mirroring the deserialization fallback in Machine.from_dict().
  2. IntentBuilder._build_encoder() only routes to the native GRBL GcodeSpec when the driver itself consumes G-code (new _driver_uses_gcode() helper), so job encoding always follows the connected driver — defense in depth against any stale dialect.

Testing

  • New machine model tests: switching to RuidaRPAAdapter clears the stale grbl dialect; switching back to a G-code driver restores it. Removed the now-redundant set_dialect_uid(None) workaround from test_supports_travel_speed_non_gcode_driver.
  • New intent builder tests: a G-code driver on the Grbl dialect still routes to the native GcodeSpec; a non-G-code driver with a leftover Grbl dialect routes to the driver's PythonEncoder.
  • tests/machine/driver/ruidarpa/ (326), tests/machine/models/ (983), tests/pipeline/ (324), tests/machine/device/ + tests/machine/driver/ (985): all pass. pixi run lint and pixi run format clean.

Stacked on #417 (base branch: fix/415-ruida-driver-switch-crash).

Fixes #420

When a machine is switched to a non-G-code driver such as the Ruida
RPA adapter, its dialect_uid kept pointing at the Grbl dialect. Job
encoding picked the native Grbl encoder based on that stale dialect
and handed GRBL G-code to the Ruida driver, which failed to stage the
job with 'Missing '(' in gluescript line: G21 ;Set units to mm'.

- Machine.set_driver now syncs the dialect with the driver's G-code
  capability: non-G-code drivers clear the leftover dialect, and
  switching back to a G-code driver restores the framework default.
- IntentBuilder._build_encoder now consults the driver's uses_gcode
  flag before routing to the native Grbl encoder, so encoding always
  follows the connected driver even if a stale dialect survives.

Fixes #420
Setting driver_name on a machine backed by the real context lazily
creates a MachineController, which schedules the debounced
rebuild-driver-on-init coroutine on the task manager. Sync tests never
pump the event loop, so the task can still be pending at teardown and
the task_mgr fixture fails with 'Task manager still has tasks'.

Build the routing tests on the isolated_machine fixture instead: its
mocked context never constructs a real controller, so no background
task is scheduled. This matches the other encoder-routing tests in
the file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant