Skip to content

Handle FluidNC error replies without side effects - #70

Open
f1adang wants to merge 2 commits into
bdring:mainfrom
f1adang:fix/config-requests-and-errors
Open

f1adang wants to merge 2 commits into
bdring:mainfrom
f1adang:fix/config-requests-and-errors

Conversation

@f1adang

@f1adang f1adang commented Sep 17, 2026

Copy link
Copy Markdown
  • Config queries for settings the machine doesn't have (e.g. an
    unconfigured axis) were retried every 500 ms forever. They blocked the
    rest of the queue and flooded the link with error:3. They're now dropped
    on the first error, or after four unanswered tries.
  • show_error() reset an in-flight JSON document before asking whether one
    was in flight, so an error for an earlier command could destroy a healthy
    macro file transfer.

f1adang and others added 2 commits September 17, 2026 18:50
show_error() reset the JSON depth and then called
file_request_failed_advance(), whose first step is to skip the advance while a
document is in progress. After the reset that check could never succeed.

FluidNC can deliver an error for an earlier command while the next command's
document is still arriving. The error then destroyed that healthy document and
advanced the macro chain past it, showing "No Macros". Leave an in-flight
document alone; the "ok" that ends it still resets the parser.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
service_config_requests() re-sent the front of the queue every 500 ms until a
matching "$name=value" arrived. For a setting the machine doesn't have, such
as an unconfigured axis, FluidNC replies with a bare error:3 that never
matches, so the item stayed at the front forever. detect_homing_info() queues
twelve of these on connect. One unanswerable item blocked the rest of the queue
and flooded the link with error:3.

- Drop an item as soon as FluidNC answers its query with an error.
- As a fallback, drop it after four unanswered tries.
- Don't send a request while a JSON document is streaming in, where the reply
  would corrupt it.

A dropped item stays !known(), which its users already handle.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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