Investigate verified ACE discovery through generic USB-RS485 adapters

[Tareku99]

Problem

Investigate a maintainable way to discover and positively identify ACE units connected through generic USB-to-RS485 adapters, without requiring users to know the adapter's USB VID/PID and without treating unrelated serial hardware as an ACE.

This is a separate feature proposal from the managed-package contract in #151. Standalone and platform-managed installations should share the same provider-side discovery behavior.

Confirmed hardware evidence

Tested on a Snapmaker U1 using PAXX integration PR paxx12-snapmaker-u1/SnapmakerU1-Extended-Firmware#738, with multiACE 1.11b from the #151 test package:

• ACE 2 Pro, device firmware V1.1.31.
• Generic adapter exposed as CH340/CH341 USB Serial, VID/PID 1a86:7523, /dev/ttyUSB0.
• Default discovery reported zero ACEs. Adding v2_extra_usb_ids: 1a86:7523 to the existing [ace] section allowed the port to be selected.
• A separate host permission issue then prevented Klipper's lava user from opening the port: the device was root:dialout, mode 0660. Opening it as lava reproduced SerialException: [Errno 13] Permission denied.
• After granting the Klipper user access and restarting Klipper, live status reported connected: true, model ACE 2 Pro, firmware V1.1.31, and status: ready. Temperature, humidity, slot occupancy, and an Anycubic PLA tag were reported correctly.
• Load/unload and printing have not yet been validated with this package.

The device-permission fix belongs to the host/platform integration. Discovery must report permission failures accurately rather than attempting to change permissions itself.

Related prior report: #46 already addressed CH340 support and sysfs lookup differences between ttyACM and ttyUSB. This proposal is about reducing manual configuration through verified discovery, not adding CH340 support again.

Current behavior and prior implementation

The current V2 discovery uses USB IDs, with 1a86:55d3 accepted by default and additional IDs explicitly configured through v2_extra_usb_ids.

The earlier PAXX ACE implementation in PR paxx12-snapmaker-u1/SnapmakerU1-Extended-Firmware#630 also contains USB-ID-based discovery and the explicit extra-ID option. The inspected code does not establish that it safely auto-probed arbitrary adapters; review the earlier branches/history before claiming or reusing that behavior.

USB VID/PID identifies a generic adapter, not the device wired to its RS485 side. Automatically accepting every CH340 port would not establish that an ACE is attached.

ACELink source and implementation

ACELink was also reviewed as a source. Its single-device flow selects a candidate using USB adapter metadata and confirms the model with GET_INFO. That supports protocol identity confirmation, but does not establish safe arbitrary-port or multiple-unit discovery. multiACE already provides the V2 protocol primitives; the implementation uses those rather than copying ACELink's first-match scanner.

Implementation is tracked in #155. The PR now targets automatic discovery by default, with idle-only bounded probes, configured/open-port exclusions, identity validation, candidate rotation, retry backoff, and an optional disable switch. It remains a draft pending hardware validation; the observed live-status success above came from the earlier explicit-USB-ID path, not this new automatic flow.

Proposed investigation

1. Separate candidate-port discovery from confirmed ACE identification.
2. Evaluate a bounded identification exchange using existing protocol code, with no filament movement, drying, firmware update, or other actuator commands.
3. Target automatic discovery by default, without adapter-specific configuration or an opt-in scan setting. Review the safety of sending identification bytes to eligible unrelated USB serial devices, enforce configured/in-use-port exclusions, and retain an optional disable switch. Hardware validation is required before merging this default behavior.
4. Exclude known printer MCU ports and ports configured/owned by Klipper or other services. Determine how port ownership is checked without claiming that an advisory lock alone prevents all collisions.
5. Validate response framing, CRC, command/sequence matching, and meaningful ACE identity before accepting a candidate. An openable port or VID/PID match is insufficient.
6. Preserve current genuine-cable behavior and v2_extra_usb_ids as supported explicit configuration; define override precedence and fallback behavior.
7. Define bounded scan time, retry/backoff, stable device ordering, and idle-only rediscovery where required to avoid disrupting prints.

Diagnostics gap observed during testing

The serial-open exception handler logged only Conn error idx=0, hiding the original permission error. The UI showed an ACE card with default busy, zero temperature, and empty slots even though live status had connected: false and no model/firmware.

Report the original connection failure and distinguish a discovered candidate from a connected, identified unit. Default values must not imply that the ACE is reporting real measurements. Diagnostic improvements can be a small separate fix if discovery needs more investigation.

Acceptance criteria

• A supported generic adapter is identified automatically without hand-entering its USB ID or enabling a discovery option, when access permissions are correct. Existing explicit disable settings remain respected.
• No unrelated serial device is accepted merely because its adapter ID matches.
• Printer MCUs and in-use serial ports are not disrupted.
• Permission denied, no reply, invalid reply, and device disconnection are distinguishable; scans and retries have bounded duration.
• No motion, heating, firmware writes, or host permission changes are performed by discovery.
• Existing genuine V2 cables, V1 detection, explicit adapter configuration, and standalone installations retain their supported behavior.
• Multiple ACE units and mixed adapters have deterministic identification/order; USB disconnect/reconnect behavior is defined.
• Tests cover valid ACE replies, unrelated devices, invalid CRC/identity, absent hardware, permission failures, occupied ports, and reconnects. Hardware validation includes genuine and generic adapters; V1 and multiple-unit coverage is explicitly recorded rather than assumed.

Ownership and scope

multiACE owns discovery, protocol identification, and connection diagnostics. PAXX owns durable access permissions, package upgrades, and service activation. Keep this feature in a dedicated follow-up PR rather than expanding #151 or the current PAXX packaging PR.

[decay71]

Thanks Before anyone builds this: are you planning to do it yourself, or was it meant as a note?

The diagnostics part I'll do on my side right away: the connect error will log its actual reason (e.g. [Errno 13] Permission denied) instead of just Conn error idx=0, and the web card of a unit that never connected will say "not connected" instead of showing placeholder values.

[Tareku99]

Thanks Before anyone builds this: are you planning to do it yourself, or was it meant as a note?

The diagnostics part I'll do on my side right away: the connect error will log its actual reason (e.g. [Errno 13] Permission denied) instead of just Conn error idx=0, and the web card of a unit that never connected will say "not connected" instead of showing placeholder values.

I had some very complicated PAXX's branches before I decided to reach out about integrating multiAce this way. I had that logic already coded in there somewhere, so I wanted to make the issue, so I don't forget. I can prob take a stab at this right now since it should already be "done" and make a branch now that #151 is merged down.