Advanced Search

With Mesa cards latency isn't such as issue as with using the Parallel port. I think the rule of thumb is under 100000ns is good for a mesa card, for about 99% of uses, cos I know someone will have an example that breaks the rule of thumb. Or my numbers may be wrong.
Unlike one forum I can think of we dont have p*$##&€ contests.
If it works and does the job reliably that's the goal.

@NVE,
can you do the latency test with no base period and with added --show at the end as there are excursions on both periods on your screenshot, and base period is not used for Mesa boards.
Thank you.

Mesa 7i96S is the best choice for Plasma.
I would really not advise using 7i92 for plasma unless you are very good at wiring and grounding and shielding.

im newbie, and think need update my cnc machine whit mesa card, but true not understand and know what card need order, and totally not understand how flash firmware to card, if need flash. my old cnc machine has now only cheap paraller port BOB but problem is no have input pins, i want add my machine MPG pendant help lot whit work. what card i need order i not undrstand.
my cnc have 4 stepper motor dual Y axis, X,and Z,
input have now only XYZ home inductive sensor,
probe.

need add MPG hand wheel and switch,
one more stepper motor whit limit SW (4th axle to lathe on table addon)
cool flood output relay,
air cool relay,
maybe future some addons.
What card need buy ???
and were have download all speak lot this different bit files.

second project is buy cheap 7i92 mesa clone board aliexpress and need make plasma table.
how this add or flash bit file and were can download good bit file,
can 92 board use palsma X,Y,Z axis, THC what need doing ????
this need maybe 3 motors 6pin out,
THC i not know what need,
home SW 3 input,
output to plasma ?
what more need be?

this is great, thanks for the info! what do these results indicate regarding how good this setup is for the linuxcnc application? im new to linuxcnc so the raw data doesn't mean much to me...

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