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

NWE wrote:

I'm interested in trying this out. Where can I get the Arduino source code?

You can find everything here: Project Home & Documentation:  bobwolfrst.github.io/io_decoder-linuxCNC/demo_mode.en

Direct Download (.zip):
github.com/bobwolfrst/io_decoder-linuxCN..._decoder_eval-v1.zip

ciao
Roberto

So this is just another USB to serial implementation ?

unknown wrote:

So this is just another USB to serial implementation ?

Yes,
it's the usual USB/serial converter that anyone can make themselves.
Can you give me some working and usable examples?
I haven't found any, and I've probably wasted six months of my life trying to figure this out. image missing /media/kunena/emoticons/ermm.pngimage missing /media/kunena/emoticons/wassat.pngimage missing /media/kunena/emoticons/unsure.png

ciao
Roberto

 

Probably most mature
forum.linuxcnc.org/show-your-stuff/48630...-io-expansion#267799

Direct link to Alex's github
github.com/AlexmagToast/LinuxCNC_ArduinoConnector

I made one based on a Arduino micro using a HID USB stack on the arduino, showed a few pictures on the forum, not much response so really couldn't be bothered documenting it.
To tell the truth I'm can't be sure whether I still have the source code.

Tormach uses a USB I\O module with their machines with Path Pilot, no experience with it so unable to give a details.

Arduino > USB Serial > Linuxcnc is a pretty well trodden path for non RT I\O.

A lot of VFD control is implemented via a USB to RS485 controller.

The only real issue with USB is it's implementation (protocol) from the beginning isn't, IMHO, a good candidate for RT applications. A lot of people who use a Mesa FPGA card take advantage of the Smart Serial cards available from Mesa. When used with a Ethernet interface it does give some isolation from the PC. And I've never had a card drop out.

I was under the impression you may have been writing a ground up driver that talks to the Linuxcnc stack in a more fault tolerant way, not just a simple serial type project.

I totally get your point about USB and its limitations in RT applications. That's exactly why I started this project.

To answer your question: No, this is not just a 'simple serial project'.

Unlike the common Arduino-Serial implementations, io_decoder uses a dedicated HAL driver (written in C) that manages communication at a deeper level. I focused heavily on optimizing the packet structure and the polling cycle to minimize jitter and ensure that the HMI response feels 'instant' to the operator.

While motion control (step/dir) should definitely stay on Mesa/EtherCAT, io_decoder is designed to provide a professional-grade, low-latency interface for complex HMI panels where standard USB HID or generic serial bridges fail to deliver the required responsiveness.

Furthermore, io_decoder isn't just a coding experiment; it's a ready-to-use solution.

Along with the driver and firmware, I have designed dedicated hardware boards specifically for this project. The goal is to provide a plug-and-play experience: you take the board, flash the firmware, and you have an interface ready for your machine.

It's about bridging the gap between a 'DIY hack' and a reliable, documented interface.

I’d love for you to check the source code of the HAL driver on my GitHub—I think you’ll find it’s a bit different from the 'well-trodden paths' you mentioned!

Here is what is tripping me up: the Arduino UNO uses hardware serial converter between the USB and the mcu. That is much more limited than the Arduinos with native USB directly to the mcu without the serial converter. I understand the UNO is your "demo" config? Does your dedicated hardware do USB direct to the mcu? Does it use some version of the CDC class?