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

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

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

On my machine, I have a 30ft active USB cable going from the control box to the spindle mount (it's for a camera, but I have other wires up there for other things and the cable chain is getting full).  I could see a use for another going to the tool rack (it's on the far side of the machine wrt the control box) for monitoring the pockets etc .  It's no different than running 24V and RS422 between Mesa cards, or ethernet/ethercat, but with hubs and latency
As for noise, I imagine cases where replacing "home runs" to sensors with a single USB cable with CRCs would prevent some EMI spikes from triggering faults.
As always, we each have different needs and having a wide range of options available is good
 

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. 

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?

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.