Advanced Search

@endian I discussed this with YangYang who attends the EtherCAT consortium meetings. AitalMAC is part of the consortium and we design I/O for EtherCAT, so we're not guessing here.
The standard already solves this problem. You don't need pos(t+1).
The 1 cycle delay is real, but it's identical for all axes. With Distributed Clocks everything executes on the same SYNC edge, synchronized to ~100ns. Every axis is "late" by the same amount, so the path shape is correct. Calculate it last week, execute it this week, the part is the same.
The CiA 402 standard provides feedforward objects exactly for this: 0x60B1 (velocity offset) and 0x60B2 (torque offset). The master can send position plus velocity feedforward so the drive can anticipate acceleration. This is the standard's solution, it just needs to be mapped in lcec.
Also, good drives interpolate internally. The servo loop runs faster than the bus cycle (Maxon runs 0.4ms internal vs 1ms bus). The drive doesn't jump between positions, it interpolates. That's what 0x60C2 configures.
If you're seeing ferror correlate with velocity in halscope, that's likely a display artifact. The ferror compares "commanded from 1 cycle ago" with "actual now", so it shows an offset proportional to velocity. It's not a real machining error.
What does your actual part surface look like? Any real deviation you can measure?

Yeah I know, I dunno what's happened to Australia, it's shameful and I'm embarrassed.

Hang in there unknown it's not just the USA loosing it's sanity. The world is becoming Idiocracy incarnate.

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]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.