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

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

Very interesting. A few points.
1. You don't say anywhere how to get the boards which are very well thought out. I'd love to test it.
2. New software to go into Master branch (2.10) which will be released in a few months.... This needs to be tested on this version (I'm finalizing a how to build linuxcnc video on my @MrRodW YouTube channel
3. Reformulate (or recreate) the git repo so this can be packaged as a PR to Linuxcnc. This would give you the best chance of success with your hardware project.
4. Your business model is similar to Mesa's so having an open source driver for your hardware in the Linuxcnc distro is not really controversial.

I'm a little unconvinced how changing to USB would have an affect on the "wiring nightmare or EMI issues".
At the end of the day one still has to make a connection from the input or output device on a control panel to the interface board.
The wiring nightmare and/or EMI issues will be a creation of the practices used by the person doing the work. In summary these issues are going to be site specific.
From memory Mesa did have a USB interface board, but is now listed as obsolete. It also supported EPP, only mentioned for completeness.

bobwolf wrote:

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.

 

+1
More hardware support for LinuxCNC.

I am very much interested in this project. I have experience with embedded mcu applications, but zero experience doing development with the USB stack. Last year I was thinking that this type of I/O via USB connection should be developed, but did not find time to start on it.

I like the mechanical format of your boards, for edge-mounting them on a DIN rail.

Ethernet is very good for EMI prone applications, however, there are plenty use cases with less EMI where USB is just fine. For example, I have LinuxCNC reading an industrial position sensor through a cheap USB to RS232 dongle going on about 10 years by now. It substitutes for an encoder, providing feedback for a relatively slow moving PID controlled axis. This is on a setworks on a lumber mill, to set board thickness. The only interference problems they've had was of a mechanical nature, when a log jams in the wrong spot and rams the $2500 USD magnetorestrictive position sensor. It gets all bent out of shape, but lasts more than 5 years.

So many great comments!

unknown wrote:

I'm a little unconvinced how changing to USB would have an affect on the "wiring nightmare or EMI issues".

 

I'm Italian. Italians are all dramatic and exaggerated in their statements.image missing /media/kunena/emoticons/cool.png
But to get serious: I imagined installing the system near the operator panel, so that all the controls are wired nearby; thus, keeping the wiring and connections clean and organized. Only the USB cable runs from the panel to the PC.

NWE writes
Last year I was thinking that this type of I/O via USB connection should be developed, but did not find time to start on it.

Over the past few months, I've had a lot of free time, and at first it was just a test to see if it worked... and gradually, things took shape, and I saw that there was a viable solution. I started with bit-banging from the Mesa board to control the shift registers... but I wasn't satisfied with the solution.

To reply to rodw:
1. The project started as a personal challenge, and the ones you see in the videos are the boards with "sins of youth" that I had built after the breadboard phase. I'm planning on making some basic kits with the correct versions. For now, I have some old boards.
2. It would be a dream. image missing /media/kunena/emoticons/w00t.png But I'd like the project to be further tested by others as well.
3 See point 2. Then I'll get organized, and if it's accepted, they'll include it in some update of the new version.
4 If you compare me to Mesa, you'll make me blush... I'm a hobbyist, they're professionals. image missing /media/kunena/emoticons/blush.png

ciao
Roberto
 

Once you have hardware, submit the PR, Look at the S curve motion. It was pushed to Master branch with bugs in it so it could be tested more widely. Money is made by original thought. You just need one good idea and you might be surprised.

This would be good where a PC like an Odroid H4 was embedded in the HMI enclosure itself