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.

Aciera wrote:

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576
 
defenetly is great to have something faster then 1ms .. ethercat can run at 50us with 16axis but this complex calculations are far slower for now 

I think 250us is very pretty goal (common industrial standard) at any hardware and then reduce it based at used hardware 


Note than many ethercat drives are also limited to 1khz in position mode. lichuan is, stepperonline/jss i think is and Im pretty sure the delta b3 is. My omrons I think are restricted to 2khz in csp mode.

For 4khz or 8khz usually you are restricted to other modes. At least in the drives I have. There definitely are (much) faster ones, but they are more specialised gear vs generic milling cnc applications.

Point being, 250us sounds great, but I don't know it needs to be any sort of priority cause only few people could use it. But then maybe those few people are important (like the people I know wanting to nanometer scale optical things and MUST have the higher "loop" speed so can't entertain linuxcnc right now)
 
You are right, I agree with you 100%, main goal is get lcnc with curves at 1khz ... Timig is very wide and difficult topic but faster code means more play to some latency or timig issues of something, stability, rigidity etc...

I think it is reachable timing .. faster tick means better final result of movement and better regulation feedback with velocity or current control.. 

Then we can say isolated cpu to sleep if it will runs at longer timing then 250us .. finally we can use more masters at other network interface to run it with different timing if it is needed and then let cpu to sleep

I think Luca's goal are very very well definied .. from my point of view there is missing just pos(t+1) or pos(t-1) for position commands to any drivers which is not using the velocity setpoint(its cosmetic to not see the ferror during movement with position setpoint)

We can runs 16khz with beckhoff but there is latency restictions... for now... I am running 0.5khz with profibus equidistant and it works well but with trapeziodal its was pain.. now with scurve its smooth like butter... lower timing than 1khz are for gentelmen which they know what they are doing.. its advanced I think
 

Gentelmen, I am sorry for talking about editing and adding the positionCmd(t+1) or positionCmd(t-1) to active creating planner but there is a problem of unsynchronized movement or synchronized(t+-x) motion ... it is common issue of any outsourced position control stuff

if somebody has stuff for example running at ethercat with CSP, he/she will be still in lag for cycle or two cycles(if he/she will not has reference cycle negative) behind stuff at same control master for example CSV which will have PID- with FF1 set to 1.0 ... feedforward compensation will not be present and lagging axis will create(during higher speed motion) unsynchronization and it could influence final shape during some 3d pathing or finishing...  with higher speed it will create higher lag (I am talking about ethercat because I can test it myself at my HW)

this is just my ideas, please let me know your point of view ... 

thanks

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.

Not a PC platform, but the RPi5 is more than capable running with a Mesa card, Ethernet or SPi......... Not something Tommy would recommend. I didn't for a while.....but things change.

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?

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.