Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

You can build firmware to enumerate as a HID class device, Linuxcnc already has a generic driver, config for the USB firmware side can be a little tricky. The original Microchip dev kits were a nightmare to get going.

1. I am put off by the fact that the firmware is not open source.
2. The HAL driver seems a bit over-engineered to me, a user component is perfectly adequate for MPG/HMI. it does not need to be a real-time component !
3. Another problem with USB is that it is not really error tolerant. After a minor error, the entire connection usually has to be reinitialised, which causes long timeouts.
4. Serial/USB is also not suitable for real-time tasks in the servo thread, i.e. not only as described for direct step/dir tasks in the base thread.
This is not a myth but has already been tested by many.

My assessment is that a serial driver as a real-time component offers no advantage whatsoever and only slows down the real-time threads.

I try this bot with the command ls -l /dev/io_decoder show this error
ls: cannot access '/dev/io_decoder': No such file or directory

COFHAL wrote:

I try this bot with the command ls -l /dev/io_decoder show this error
ls: cannot access '/dev/io_decoder': No such file or directory

Go to the "Create a udev Rule" section described in bobwolfrst.github.io/io_decoder-linuxCNC/demo_mode.en
or insert the following in the line that calls the component in the .hal file describing your machine: loadrt io_decoder firmware=255 usb_port_name="[the port address obtained with lsusb]"

Thanks for the feedback! You’ve raised some classic points about LinuxCNC architecture. Let me clarify my design choices:
1. Why Arduino UNO & Serial Converter? You’re right, native USB (like 32u4) is faster, but the UNO is the most ubiquitous board on the planet. I chose it for the Evaluation to make it accessible to everyone. My dedicated hardware is optimized for the task. Regarding CDC, the driver handles the communication stream to ensure packet integrity without the overhead of complex generic protocols.
2. Closed Firmware & 'Over-engineering' I respect the Open Source philosophy, but io_decoder is a professional project that includes dedicated hardware. The 'over-engineering' you see in the HAL driver is actually optimization. While a user-space component can work, a dedicated C component ensures deterministic polling and much lower jitter. If you want a 'professional feel' on the handwheel, those milliseconds matter.
3. USB Stability & Real-Time Thread I’m well aware that USB isn't for the Servo Thread. In fact, io_decoder doesn't try to be a motion controller. It’s an HMI driver. The reason it’s written as a component is to ensure that the communication window is synchronized and doesn't suffer from the unpredictable latencies of user-space scheduling.Regarding errors: the driver includes a specific state-machine to handle reconnections much faster than a standard generic serial bridge.
4. The Goal Most 'standard' serial-to-HAL projects are hacks. io_decoder is a finished product. It’s for the user who wants to plug in a board, load a component, and have a 100% reliable, low-latency control panel without writing a single line of Python or C.I invite you to actually test the Eval version.
You’ll see that the 'over-engineering' results in a responsiveness that user-space scripts simply can't match.

Thanks, I had an error in the rules file, that's why that error appeared.