microcontroller vs parallel port

rodw wrote:

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.

I know puny is relative but considering that for a long time cnc machines used cpus in the mhz and ram in the single digit mb.
how much power would an embedded system needed to get full functioning cnc machine?

What is a feature that is not possible in a buffered system?
Doing some more reading today and it seems in some forks there is direct jog control to the micro so no delay from a sender GUI.
Others have synchronous spindle control for threading with videos showing them working. These seem to be recent as in the last few months.

From some of the things i am reading they are getting less limited than was true just 1 year ago and much better than they were 3 years ago when i set out to do my conversion to linux cnc on my mill.

For me the question is, does it worse to drive a 5000 Euro machine with parallel port or would I invest 200 Euro for a Mesa hardware and run that with nearly every computer.

I have 1 Acer Laptop and drive 3 machines with that one, just using Mesa Ethernet hardware. The Laptop is not a real good solution but it does work perfect, even having a bad latency. I just plug the Ethernet cable to the machine I want to use and start the corresponding config. I do this not of cost reason, it is just space saving

I have also one lathe I drive with low budget China steppers an d a 3D Step over parport with an Athlon 1700 and Ubuntu 8.04 it does work reliable too.

So you are free to decide

Norbert

There is flexibility built into Linuxcnc that doesn't require jumping into the source.

There is the flexibility to code your own modules without having to know all the ins and outs of the linuxcnc source code.

Also the different types of machine that can be controlled.

Look at the work done for Plasma, I can't think of any OSS CNC projects that would allow that functionality without a major fork.

I think the best features of Linuxcnc is the modularity.

At the end of the day no one is forcing anyone to use Linuxcnc, but one has to remember there are design goals in place. These design goals may not suit everyone and that is ok.

andypugh wrote:

I think that the point that Rod was making with his "don't fight the paradigm" is that LinuxCNC is a terrible starting point if that is what you want to do.

Absolutely 100% Andy.

Plus if you take the time to understand the paradigm, you will find there is no need to develop code on a microprocessor as its all done for you already.

PCW wrote:

It great if you want to run GRBL

Doesn't help with LinuxCNC

In reality it now does help LinuxCNC when you put Remora Firmware on it and connect over SPI from a Raspberry Pi running LinuxCNC.
The Remora firware does all the stepgen stuff on the controller while LinuxCNC does the rest. Currently Remora support SKR v1.4 and MKS Sbase v1.3 boards but if people jump in to help it can start supporting more boards.

Not the same thing, SpiPRU is still using a real time host

The OP was talking about buffered non-realtime host systems

Seemed like the question was about using cheap buffered 3DP hardware/firmware and free software compared to LinuxCNC on a hard to find PC with a parallel port and addon controller(Mesa, etc).

Hence the mention of an easy to find, and cheap, computer hardware(Raspberry Pi) and cheap easy to find 3DP hardware with realtime firmware.

That's fine but my comment was about the OPs suggestion to use a buffered interface. Buffered interface are fine if you want to run Mach, GRBL etc

To be honest i had not thought of this use case for the 3DP hardware.
Well not 100% what i was looking for it achieves a similar goal.
I have a spare rpi4 4gb board and could order the controller and tinker away and see if this would fit.

If this works i see no reason to go to a buffered system for my next build, heck i may convert my main cnc machine just to get rid of the full atx tower.