comparing to Grbl, or FluidNC
27 Apr 2025 13:18 #327148
by pgf
Replied by pgf on topic comparing to Grbl, or FluidNC
I hadn't gotten to the "asking for help" part yet. I only started last night. 
And much of that was trying to work around bugs in pncconf. Yes, I'll report them.
It's definitely a programming language -- you just find it easy, since apparently you have a background in electronics. I do too. But there's a reason circuits are designed graphically, and not in text files -- they're easier to understand that way.
And much of that was trying to work around bugs in pncconf. Yes, I'll report them.It's definitely a programming language -- you just find it easy, since apparently you have a background in electronics. I do too. But there's a reason circuits are designed graphically, and not in text files -- they're easier to understand that way.
Please Log in or Create an account to join the conversation.
27 Apr 2025 13:23 - 27 Apr 2025 13:29 #327152
by unknown
Replied by unknown on topic comparing to Grbl, or FluidNC
Verilog & VHDL are text files
And there were also (still there) PAL & GAL text files again.
Tho I might be a little special in the head, I didn't use a schematics when wiring the control box for my mill...I can kind visualise things in my......not to the level of Dr Hawking,most of physics confuses me.Quantum Mechanics just requires not trying to relate it reality as we experience in day to day life. Maybe if I did more than 3 and a bit years of high school and was less interested in playing Rugby.
And there were also (still there) PAL & GAL text files again.
Tho I might be a little special in the head, I didn't use a schematics when wiring the control box for my mill...I can kind visualise things in my......not to the level of Dr Hawking,most of physics confuses me.Quantum Mechanics just requires not trying to relate it reality as we experience in day to day life. Maybe if I did more than 3 and a bit years of high school and was less interested in playing Rugby.
Please Log in or Create an account to join the conversation.
27 Apr 2025 13:50 #327156
by tommylight
-
-GRBL is simple and quite easy to setup and use, once you figure out the quirks.
-FluidNC is simple and easy to setup and use and runs on an ESP32, magnificent!
-Klipper is complicated in every way possible, but quite easy to setup after spending weeks of reading, it is very good at what it does, can be modified a lot, but the huge overhead (hundreds of required packages) makes it not very reliable (works for months without issues then suddenly goes on hiatus), with very little ability for troubleshooting
-Marlin is not easy to setup but luckily there are ready made configs/images, easy to use, runs even on 8Bit micros, works "stand alone", and frankly it is amazing how much functionality is crammed into it.
-LinuxCNC is very dependent on what you need from it, very easy when using parallel port, easy enough when using most Mesa cards, all thanks to the insane amount of work put in by members of this forum and developers, but can be complicated as much as you are willing to ask from it. I can go on for days...
-
To better understand the flexibility of LinuxCNC, just pick one of the projects started on this forum, like QtPyVCP Probe Basic (or Basic Probe, i always mix those), QtPlasmaC, QtDragon, PlasmaC, MonoKrom, etc. Some of them started just by someone asking here and inside a week there were actual working GUI's being developed, search for "Brender".
I have to stop...
Replied by tommylight on topic comparing to Grbl, or FluidNC
That is a nice way to explain it, thank you.... designing arbitrarily complex digital "circuits" in a text file.
-
-GRBL is simple and quite easy to setup and use, once you figure out the quirks.
-FluidNC is simple and easy to setup and use and runs on an ESP32, magnificent!
-Klipper is complicated in every way possible, but quite easy to setup after spending weeks of reading, it is very good at what it does, can be modified a lot, but the huge overhead (hundreds of required packages) makes it not very reliable (works for months without issues then suddenly goes on hiatus), with very little ability for troubleshooting
-Marlin is not easy to setup but luckily there are ready made configs/images, easy to use, runs even on 8Bit micros, works "stand alone", and frankly it is amazing how much functionality is crammed into it.
-LinuxCNC is very dependent on what you need from it, very easy when using parallel port, easy enough when using most Mesa cards, all thanks to the insane amount of work put in by members of this forum and developers, but can be complicated as much as you are willing to ask from it. I can go on for days...
-
To better understand the flexibility of LinuxCNC, just pick one of the projects started on this forum, like QtPyVCP Probe Basic (or Basic Probe, i always mix those), QtPlasmaC, QtDragon, PlasmaC, MonoKrom, etc. Some of them started just by someone asking here and inside a week there were actual working GUI's being developed, search for "Brender".
I have to stop...
Please Log in or Create an account to join the conversation.
27 Apr 2025 17:09 #327174
by 3404gerber
(But also, there is no encoder feedback, no routines, no special kinematics and many other no.)
Replied by 3404gerber on topic comparing to Grbl, or FluidNC
Sorry if it wasn't clear, my english skills must be just as poor as my coding; I'm coding a component to use TMC5160 drivers over SPI without any step/dir signal. What I wanted to say is that I'm sure I would have a working LinuxCNC configuration by now if I would just have bought a Mesa card. To me LinuxCNC is a bit more complicated to set up, even if you definitively don't need more coding skills than for FluidNC, which also have a config file.I don't know where this idea comes from that you need any coding skills to setup Linuxcnc. This is one of the biggest lies ...
Maybe because I want to use the power of LinuxCNC for something that is not a mill. Like a pick & place machine that would adapt the position according to a vision result, or for a PUMA arm or any other automation machine in which a "master" would send g-code to a LinuxCNC slave to move the axis. OpenPNP is a good example and there already is an interface .I don't know why you would want to send a gcode file line by line to linuxcnc when it can open and read the file directly.
I don't propose anything; I just have the feeling that if there is one area where FluidNC or any micro controller based G-Code interpreter is better than a computer based solution, it is for step/dir generation. There is no Latency-test in FluidNC, just hardware interrupts!One thing that is very intriguing, you admit to poor coding skills, yet propose some major replacement of the Linuxcnc internal workings.
(But also, there is no encoder feedback, no routines, no special kinematics and many other no.) Please Log in or Create an account to join the conversation.
Moderators: piasdom
Time to create page: 0.140 seconds