Why real time kernel is needed with board like MESA?

Just trying to understand how this model works. Hoping someone can clear this up for me. Perhaps my understanding of what a MESA card does is incorrect.

If the computer is doing what it does best: calculating movements and floating point positions etc and then handing that information off to a mesa card to do what it does best: exact feeding of pulses out to the hardware.

Why is there the real time kernel requirement and latency issues of concern? Why doesn't linuxcnc just load up the buffer of the mesa card with some length of time worth of movements, like 10ms or 100ms or even more depending on latency/jitter time and then just refill the buffer the next time it gets serviced? The mesa card is still just doing what it is told so functions can still be added to software. E-stop should really be handled at the hardware driver level, not leaving it up to an operating system somewhere. Or maybe it is doing that and there is another reason for the kernel requirement?

The only reason that I can see is perhaps for limit switches or height gauge/trigger (input back to linuxcnc) but seems that they could be "searched/homed" at a speed accommodating to the latency since generally they are utilized at setup time.

Am I understanding incorrectly what the mesa card does? Or is there some sort of feedback that I am overlooking? Or maybe the latency/jitter discussions that I read about aren't actually causing performance issues? I would think that using ethernet introduces its own timing nuances requiring some sort of buffered input to the mesa card.

I'm sure someone can fill in the piece of this puzzle that I am missing.

Regards.

I/O cards/drives etc used with LinuxCNC are not buffered, LinuxCNC provides
real time position (and velocity) waypoints at typically 1 ms intervals.

This means the the trajectory planner is implemented entirely in LinuxCNC
(including spindle synchronized motion for threading and rigid tapping,
real time feed control and probing) while these more complex trajectory planning
operations can be implemented in external hardware, there are advantages to
having these implemented on the host.

One advantage is that all motion features are available regardless of the external
hardware. Another advantage is that application specific real time features can be
easily added to LinuxCNC (and again available to any external interface hardware)
Yet another advantage is that compared to most external motion cards, The complex
trajectory features are implemented on a device with basically unlimited memory and
floating point math horsepower.

The chief disadvantage is the requirement for a real time host OS

If the computer buffered in 5 moves to a mesa card every 5ms, that then the mesa card processed in 1ms incriments is that command string to the drivers somehow different than what is sent on 1ms intervals?

Lets take rigid taping. Is there some changing variable that is happening that the computer knows about that changes the command string real-time that cant be predicted by the computer ahead of time? Thus causing the real time control to be different then a buffered prediction of what the future looks like?

Yes, because you would have a fixed motion profile of 5 ms rather than a motion profile
that can react in 1 ms (perhaps in quite complex ways) to external events/settings/adaptive feed etc etc

Certainly all motion features could be implemented in external hardware
( This is how hardware for buffered interfaces like Mach3/4/UCC support features like threading )
But as I mentioned there are significant advantages to implementing these features on the host

Does that only come into effect for things like servos that have a feedback loop? Aside from limit switches, is there some sort of feedback happening for steppers? I guess I always assumed that linuxcnc is kinda just blindly sending out commands to the drivers/steppers and then just assuming that the hardware has done what it was told to do.

Things like spindle synchronized motion, homing, probing, adaptive feed, plasma torch height
control etc all depend on real time reaction to external inputs even for open loop step motor
driven joints

Okay, buffering movement from one corner to the other is not an issue, and wouldn't require real time kernel. Or really any of the things people do with their first cnc when they start out like setting height with a piece of paper and using an edge finder, etc... Even cutting out whole parts.... But "more advanced (still basic)" items like homing a gantry with 2 switches and up (in complication) are what require the real time kernel to be able to be aware of changes and adjust accordingly. Got it.

Thanks PCW!

I guess the main difference with boards like the Smooth stepper is that they are the motion controller where Linuxcnc is the motion controller so as PCW says it has much more processing power than any external motion card. The power it gets with Mesa stepgens is that Lincuxcnc tells the Mesa board to generate steps at a specific frequency until its told otherwise. And Linuxcnc can change that commanded frequency every millisecond. So buffering command wold reduce the responsiveness of the whole system.

Plus the ability Linuxcnc has as the motion controller to insert custom components into the servo thread so that it operates as if its part of the Linuxcnc core is just amazing architecture. This is LinuxCNC's best kept secret if you can code in C. Just look at the plasmac component which when combined with custom Python scripting and matching GUI interface is going to send many plasma THC manufacturers to the wall. Its that good!

I think this is one of LinuxCNCs greatest strengths, It provides an accessible and extensible
real time toolkit on an open platform allowing collaborative development of complex real time control solutions ( is that enough buzzwords? )

Unfortunately, you are absolutely right to look for logic - why does LinuxCNC have real time after it has a Mesa card?
The answer is simple - because LinuxCNC is not evolving to use the available hardware. Meats are also not interested in such development, they just make money!
Otherwise, FPGA can do perfectly the critical part of the job - real time and work with inputs and outputs. You just have to tell her exactly what you want!
What's worse is that people who are really involved in the development of the Linux CNC don't really understand what it should look like in order to be liked by people, not just themselves.

PP And I do not agree at all with the reasoning, how can LinuxCNC not work with a buffer because it had to change the pulse frequency every 1 ms. What are you talking about? Why, once you have planned your movement and have the ability to set whatever pulse sequence you want to the FPGA, will you change it in motion? The FPGA can perform vector control or PID or C curve or whatever you choose from measuring rulers without dealing with LinuxCNC). Even part of the PLC logic will naturally be transferred to FPGA (I accidentally wrote in another topic that branded CNCs are PLC / FPGA). Thus, the problems with THC will be able to be solved successfully. Simply the FPGA will be set parameters with which, following the feedback (arc voltage) it will react with the Z axis.
All the while, you forget that a $ 2 Arduino can play (not quite successfully, of course) the role of FPGA and run a 12-hour file, while on the PC that sends it the code, you browse YouTube.