microcontroller vs parallel port

Sorry for asking the noob questions.
It seems to me that using a ramps type controller with arduino (or 32 bit equivilent) is a much simpler solution then using the parallel port. Especially since it's getting hard to find a parallel port these days.

Is there some advantage to the parallel port over a controller card? I've been looking at www.aliexpress.com/item/4000636348443.ht....424c3c00oQk6Tv&mp=1 which seems to cover it. I'll just replace the drivers with my own heavy duty ones to handle the larger steppers that I've got. I can load grbl firmware github.com/terjeio/grblHAL/ on it to run the cnc then it's just a matter of a user interface github.com/vlachoudis/bCNC

I feel like I'm missing something really obvious since this solution looks very easy to implement.

It great if you want to run GRBL

Doesn't help with LinuxCNC

Thanks everyone for your replies. Yes, I did think that Linuxcncn only works with a parallel port. I'll review the hardware in the link.

I've noticed that the wiki page has mostly broken links.
Thanks to tommylight for store.mesanet.com/index.php?route=produc...83_84&product_id=215 which looks like the closest thing to what I was expecting.

I understand that using a real time kernel helps keep pulses correct through the parallel port (the wiki page lists mostly parallel ports or other very expensive options), and I guess that's where my confusion lies. I can get an arduino atmega micro controller dedicated to drive 24 bits up and down with very accurate timing. (and I could communicate with it with usb and not have to worry about a real time kernel).

Maybe I've got the wrong idea about how linuxcnc works.
This is what I think:
file->user interface->low latancy hardware interface-> drivers->motors
This is what I think it should be:
file->user interface->serial usb ->microcontroller->drivers->motors

Hard stop button and endstops can be wired directly to microcontroller, which can commicate back to linux cnc

I'm not suggesting re-writing the whole system, it's just that this seems the obvious way to go, so I'm sure I'm not getting it. I've compiled the kernel and got low latency but I don't understand were to go from here.

What you are suggesting is a buffered motion system like Mach or GRBL (and others)
This is certainly possible but suffers from a number of issues that a real time,
single locus of control system like LinuxCNC avoids.
The cost with LinuxCNC is the need to run on a real time OS.

What are the drawbacks of using a GRBL or other buffered / microcontroller system?

I have a emco pc55 mill running linux cnc and it was a pain to find a PC with the right hardware's then bios settings to get a good latency with the parallel port. (i know not the best way)
I am looking at retro fitting a new machine and after having years with my 3d printers and familiarity with them i have wondered about switching to microcontroller based system.

Is the limitations simply max speeds? specific features (rigid tapping)? Worse trajectory planner?

At what machine size would one say its fine to use GBRL vs linux cnc?
GBRL is fine for desktop systems like the cheap 200$ routers and converted seig x1/x2 machines?
Linux CNC is more for large knee mills and VMC's?

In understand that both would "work" but one machine might get limited by the control much faster than the other.

I think GRBL/Mach etc are fine for systems that are simple and fixed purpose
and do no rely on real time feedback with complex response requirements
like threading, probing, rigid tapping, adaptive feed, plasma THC etc, and where you
are satisfied with somewhat laggy HMI (because the OS and communication
delays compromise things like MPG jogging)

Most of these real time features _can_ be implemented in buffered systems
but the more you do, the more you reinvent LinuxCNC in the remote device.

Buffered and unbuffered systems both have compromises, so which is a
better choice really depends on you requirements and preferences.

Every computer application has its own paradigm. One of the most valuable pieces of advice I received was from a sales person for a cloud based inventory system. "Don't fight the paradigm" he said. "you must decide if the paradigm we devised suits your business. If you try to align the paradigm to agree with your current systems, you will be forever fighting the system and life will be unpleasant".

So the Linuxcnc paradigm requires a real time operating system so it can use the massive power of a real PC's CPU (v's the puny power of an embedded controller) to do things that are not possible in a buffered system.

If you continue down the path of attempting to build a buffered system controlled by Linuxcnc you are way outside of the paradigm and life will be forever unpleasant.

Don't fight the paradigm.