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!

I finally got my butt in gear and sorted out the new spindle motor and LCNC config using @Aciera's template.

I can confirm a few things:

• His configuration works for me
  • Single motor for spindle/orient/c-axis using step/dir drive.
  • Mode changes using encoder-disconnect component in config template
  • Orient using his s-orient component
• The G33.1 problem exists as he describes (clearly) in the github post.
  • Instant Z-negative rapid at start of G33.1 move
  • Magnitude of rapid move is dependent on how far from the index signal the spindle is when the program starts.
• The workaround (disconnect joint.N.index-enable in spindle/orient mode) works.

I've responded on github here:
github.com/LinuxCNC/linuxcnc/issues/3556

@Aciera - Thank you VERY much for looking in to this.

Take care here. Not many 15.6" screens are 1080p which most of the new look GUI's require. I had to replace one to run qtdragon or probe basic.

Here it is. This is on a live boot without trying any latency optimization stuff. While this was running, I installed some software and ran glxgears.

Thanks for the explanation, the outputs are working with these settings. I was surprised that there are hidden parameters for the outputs. I didn't see them in any manual, or in asda soft either. But the inputs are still not working. Maybe there are hidden settings for the inputs too? Or am I missing something else?

Jocman wrote:

Code:

[code]2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000     link/ether e8:4e:06:84:dc:c9 brd ff:ff:ff:ff:ff:ff     inet 10.10.10.11/8 brd 10.255.255.255 scope global eth0 and: [code][code]2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000     link/ether e8:4e:06:84:dc:c9 brd ff:ff:ff:ff:ff:ff     inet 192.168.1.245/24 brd 192.168.1.255 scope global dynamic eth0  

[/code][/code][/code]

 

Just to clarify, do you have everything connected to the router? Or did you have just the Mesa card plugged in the first time, then just the router, the second time?

You will likely get better performance connecting one network cable directly from Mesa card to the first network port on the pc, then another network cable from your router to the second network port on the pc. Then you can choose eth1 for your web connection.

I think what I might try with that, would be to figure out which traces on the motherboard are step and direction for each axis. I would cut each trace on the motherboard somewhere between the I.C. and the blue card edge connectors in locations where I'd have a chance of bridging the cut with solder in case I later wanted to undo it. This would tend to be near the solder points where the blue card edge connectors are soldered in. This is to prevent the original I.C. from interfering with the signals from LinuxCNC.

Then I would solder maybe 24 AWG wires to the solder pins of each step and direction on the back side of the card edge connectors for wiring into a 4 or 5 axis parallel port bob that can be bought at low cost.

This would allow the power and motor connections to stay original. Spindle and e-stop signals I would wire direct to the bob. Make sure to connect bob's ground to a common ground on that motherboard.

Hope that helps.

 

Thank you for the interesting idea. I think it would not work to drive the stepper motor drivers from the blue Centronics connector because the drivers have each two Optocouplers, for STEP and DIR (see white frame on the front side of the driver board).

Below are some more pictures attached.

Good news for the RPi guys, should be back into the swing of things round mid to late February, once I've found which box has what.

It's a PITA looking for a place to stay in Oz. Gumbernment is bringing "skilled workers" to build new houses because of a housing shortage, but hasn't thought about where these people are going to live whilst they are building the "new houses". If someone can explain the thought process behind this policy I'd be quite interested.

I was starting to think I'd have to sell a lot of stuff.

Guess I might have been in a bit of a panic.

Thanks for the update — much appreciated.

That timeline works well for my planning. I’ll wait for the 7I84U and 7i96S restocks and proceed with the all-Mesa setup as discussed.

Thanks again for the clarification.

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.

Note our Email is borked for a while

7i84U is probably next week and the 7I96S about 3 weeks out

Looks great. Took awhile to get that look?
Ya keep us updated.