microcontroller vs parallel port

More
09 Mar 2021 21:50 #201605 by iplayfast
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.

Please Log in or Create an account to join the conversation.

More
09 Mar 2021 23:13 #201614 by tommylight
For that kind of money you can get a normal PC and a Mesa 7i92 or 5i25 or 6i25 and end up with a fully fledged CNC.
The GRBL way seems easy but very soon it start showing it's drawbacks.
Not the same thing by any stretch of imagination, LinuxCNC can run almost any machine, some of us here have 5 or more metric tons machines running it.
But for a hobby machine used once in a while, GRBL works fine.
The following user(s) said Thank You: RotarySMP

Please Log in or Create an account to join the conversation.

More
09 Mar 2021 23:13 #201615 by PCW
It great if you want to run GRBL

Doesn't help with LinuxCNC

Please Log in or Create an account to join the conversation.

More
10 Mar 2021 23:28 #201754 by andypugh

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.


I think that you might be working under the misapprehension that LinuxCNC only works with a parallel port.

LinuxCNC supports many different hardware interfaces, from Industrial EtherCAT systems, through PCI and ethernet interfaced systems right down to the basic, cheap and not-very-good parallel port.

The only thing that isn't supported is USB, as the only way to make that work is to move all the trajectory planning to a microcontroller and then you really might as well be using GRBL in the first place. Mach3 supports USB-interfaced motion hardware, not because it was a logical thing to do, but because they could make money doing it.

An incomplete list of the motion-control hardware supported by LinuxCNC is here: wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Supported_Hardware

Please Log in or Create an account to join the conversation.

More
22 Mar 2021 04:07 #203196 by iplayfast
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.

Please Log in or Create an account to join the conversation.

More
22 Mar 2021 04:57 #203198 by iplayfast
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.

Please Log in or Create an account to join the conversation.

More
22 Mar 2021 05:25 - 22 Mar 2021 05:26 #203200 by PCW
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.
Last edit: 22 Mar 2021 05:26 by PCW.

Please Log in or Create an account to join the conversation.

More
22 Mar 2021 16:01 #203258 by Aaroncnc
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.

Please Log in or Create an account to join the conversation.

More
22 Mar 2021 16:49 #203262 by PCW
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.
The following user(s) said Thank You: RotarySMP

Please Log in or Create an account to join the conversation.

More
22 Mar 2021 20:34 #203289 by rodw
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.
The following user(s) said Thank You: BeagleBrainz

Please Log in or Create an account to join the conversation.

Time to create page: 0.130 seconds
Powered by Kunena Forum