1. 6
  1.  

  2. 2

    Lots of nice new stuff!

    1. 1

      LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.

      Runs under Linux (optionally with realtime extensions).

      I see the dependency on Linux (even the name!) as unfortunate.

      1. 4

        What are your main concerns? What would you do differently?

        1. 1

          I’d care about supporting non-Linux OSs, particularly the OSS ones, and avoid including Linux in the project name.

          1. 5

            Patch or gtfo then :)

            1. 2

              Cross-OS for its own sake is fair enough I suppose, though I’d still be interested to know what about Linux you think is unfortunate as the OS of choice for this project, or why you think another would be better.

              My take on this is: it’s a piece of software designed for industrial control with hard real-time requirements. As one of my mentors liked to say, a mill or a lathe isn’t the kind of equipment that just hurts you, it rips your arm off and beats you to death with it. I’m glad that they’re limiting their scope to a single kernel. Last I read an article about achieving hard real-time on Linux, it wasn’t exactly lacking nuance or pitfalls. Add more supported kernels and you multiply the chances that you introduce a bug, miss timing, and destroy the work/machine/operator.

              I’d also like to point out that they don’t owe anyone cross-OS support. Including Linux in the name actually emphasizes their right to build what they want. The creators set out to create a CNC machine controller for Linux. If you want support for another OS, the source is GPLv2 :)

              1. 1

                what about Linux you think is unfortunate as the OS of choice for this project,

                I’ll say as a start I don’t think there’s anything terribly wrong with doing CNC with Linux.

                Yet my suspicion is that, despite the name, there’s technically not much tying this project to Linux specifically.

                Which makes the name truly unfortunate.

                1. 6

                  A brief look at the project reveals that they ship Linux kernel modules for controlling hardware via supported interfaces, and for any use with real hardware Linux kernel with -rt patchset is needed on the controlling computer. This surely makes moving to another kernel quite a large effort, as realtime drivers need to be ported. And the recommended installation method is a Debian-derivative GNU/Linux distribution.

                  So I would expect getting a good enough port to be a large undertaking, with benefits of using another OS inside that black box even harder to realise because the number of users with hardware access matters for testing.

                  1. 1

                    So it is forcibly an ugly design, as we know it has to resort to kernel modules as Linux itself is ill-suited to abstract the hardware and enable doing the heavy lifting in user space. Noted.

                    Maybe the name is not wrong, in hindsight.

                    1. 5

                      Sure, they do have a userspace implementation, and apparently recommend the standard Preempt-RT patchset with user-space control implementation for some cases. It’s just that for many cases RTAI kernel and a kernel-space driver yield lower latency. Indeed, Linux is not a microkernel, so context switches have some costs.

                      Sure, making something realtime on top of a general-purpose non-realtime OS has its drawbacks, and the best latency will need some amount of special-case work. But it improves the chances of reusing some computer that is already around.

                      User-space real-time API-wise they claim to support Preempt-RT, RTAI and Xenomai kernels (all Linux-based).

                      1. 3

                        Such machines rely on hard realtime controls and are very often done in microcontrollers. Latency is a huge constraint of the project. The project itself is very old: it dates back to the mid 90s: there wasn’t a lot of CPU power back then (especially on the ARM targets) and less knowledge and development to achieve hard real-time.

                        1. 1

                          Are you aware of an open effort using microcontrollers?

                          1. 2

                            GRBL, I guess? Somewhat limited and recently inactive, but apparently usable for many usecases.

                            1. 3

                              recently inactive

                              There seems to be a maintained fork. There’s not much in terms of changes, but I suspect that’s because it reached a “just works” point.

                              No strange latency surprises to be had with these microcontrollers.

                              1. 2

                                Yes, I meant this repository as the main development line, and it doesn’t seem to have firmly decided to never get to 5-axis support, so there is a clearly stated missing feature with respect to which it could be active but isn’t. Doesn’t matter for use cases where it fits, of course.

                            2. 1

                              The project wiki (section 4) describes why they chose not to use an external microcontroller as a motion controller.

                              It also says there was a hard fork which adds support for a particular external microcontroller.

                              1. 1

                                I see… ultimately they do like their scope and meters, on their computer.

                      2. 1

                        Yet my suspicion is that, despite the name, there’s technically not much tying this project to Linux specifically.

                        I’m unfamiliar with the real-time / CNC space. What other non-GPL/OSS kernel systems have support for the kind of real-time performance required by these machines?

                        1. 1

                          What other non-GPL/OSS kernel systems have support for the kind of real-time performance required by these machines?

                          As a reminder, Linux isn’t exactly awesome at real time, particularly awful without rt patchset (and project seems to work w/o that), thus the requirements can’t be that strict, and there should be plenty of systems that meet them.

                          1. 3

                            In the system requirements documentation:

                            It can, however run on a standard kernel in simulation mode for purposes such as checking G-code, testing config files and learning the system.

                            So, non-RT Linux allows to do a subset of work that doesn’t involve driving hardware.

                2. 3

                  Are you coming at it from a principle perspective or practical?

                  From a practical point, several of the newer commercial control systems like Heidenhain and Siemens and probably more I can’t remember, have Linux base for the user interface.

                  Both works fine in daily use at the day job.

                  And is Windows really a better option? I know Datron’s Next control is lovely and easy to use on the commercial side. Others include Centroid, UCCNC, Kflop, Planet CNC and Mach3 & 4.

                  All require specific electronics anyway that usually does the heavy lifting in serious (non hobby) use.

                  From a principle point, I’d like to hear more.