- Hardware & Machines
- Driver Boards
- Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request
Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request
- bobwolf
- Offline
- Senior Member
-
Less
More
- Posts: 56
- Thank you received: 13
17 Jan 2026 16:42 #341490
by bobwolf
Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request was created by bobwolf
Subject: Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request
Hi all,
I’d like to open a technical discussion about a project I’ve been working on, io_decoder, focusing on the software solution I've implemented to handle USB communication within LinuxCNC.
I am well aware that in the official LinuxCNC documentation and Wiki, USB is often described as 'the evil' (or, more formally, as 'not suitable for real-time control'). However, if one looks closely at the context of those warnings, they are strictly related to step generation and primary motion control, where microsecond-level jitter is fatal.
For HMI panels, MPGs, and secondary I/O, I believe this 'dogma' can be challenged if the HAL component is designed to manage the USB stack correctly. My goal is to allow users with complex retrofits (like those using Mesa 7i80/7i92) to offload all non-critical I/O to a single USB bus, freeing up high-speed pins and reducing the 'wiring nightmare' and EMI risks.
To test the limits of my custom HAL component, I’ve pushed it to handle real-time axis tracking via an encoder (not just simple buttons).
You can see the fluid response in this playlist:
www.youtube.com/playlist?list=PL9D_TSVxg...tA9_k6njBeVTL0IYY7Ct
In other communities, the mere mention of 'USB' triggers an immediate rejection. I’m posting here because I’d like a more nuanced, engineering-focused feedback:
1. Given that a human operator has a reaction time of ~200ms, is a stable 20ms update cycle (50Hz) really a bottleneck for MPG tracking or HMI interaction, considering it's handled by a dedicated non-blocking HAL component?
2. How can I further improve the HAL component to make the communication even more robust against bus jitter?
The project is Open Source and I'm looking for peers to discuss the driver implementation rather than the hardware itself. What do you think about the responsiveness shown in the videos?
Documentation & Wiring:
bobwolfrst.github.io/io_decoder-linuxCNC/
Best regards,
Roberto
Hi all,
I’d like to open a technical discussion about a project I’ve been working on, io_decoder, focusing on the software solution I've implemented to handle USB communication within LinuxCNC.
I am well aware that in the official LinuxCNC documentation and Wiki, USB is often described as 'the evil' (or, more formally, as 'not suitable for real-time control'). However, if one looks closely at the context of those warnings, they are strictly related to step generation and primary motion control, where microsecond-level jitter is fatal.
For HMI panels, MPGs, and secondary I/O, I believe this 'dogma' can be challenged if the HAL component is designed to manage the USB stack correctly. My goal is to allow users with complex retrofits (like those using Mesa 7i80/7i92) to offload all non-critical I/O to a single USB bus, freeing up high-speed pins and reducing the 'wiring nightmare' and EMI risks.
To test the limits of my custom HAL component, I’ve pushed it to handle real-time axis tracking via an encoder (not just simple buttons).
You can see the fluid response in this playlist:
www.youtube.com/playlist?list=PL9D_TSVxg...tA9_k6njBeVTL0IYY7Ct
In other communities, the mere mention of 'USB' triggers an immediate rejection. I’m posting here because I’d like a more nuanced, engineering-focused feedback:
1. Given that a human operator has a reaction time of ~200ms, is a stable 20ms update cycle (50Hz) really a bottleneck for MPG tracking or HMI interaction, considering it's handled by a dedicated non-blocking HAL component?
2. How can I further improve the HAL component to make the communication even more robust against bus jitter?
The project is Open Source and I'm looking for peers to discuss the driver implementation rather than the hardware itself. What do you think about the responsiveness shown in the videos?
Documentation & Wiring:
bobwolfrst.github.io/io_decoder-linuxCNC/
Best regards,
Roberto
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
Moderators: PCW, jmelson
- Hardware & Machines
- Driver Boards
- Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request
Time to create page: 0.106 seconds