6 ms·

This is big for the CNC community. RT is a must have, and this makes builds that much easier.

dale_glass 2y ago
Why use Linux for that though? Why not build the machine like a 3D printer, with a dedicated microcontroller that doesn't even run an OS and has completely predicable timing, and a separate non-RT Linux system for the GUI?
- juliangmp 2y ago
  I feel like Klippers approach is fairly reasonable, let an non-RT system (that generally has better performance than your micro controller) calculate the movement but leave the actual commanding of the stepper motors to the micro controller.
  - tonyarkles 2y ago
    Yeah, I looked at Klipper a few months ago and really liked what I saw. Haven't had a chance to try it out yet but like you say they seem to have nailed the interface boundary between "things that should run fast" (on an embedded computer) and "things that need precise timing" (on a microcontroller). One thing to keep in mind for people looking at the RT patches and thinking about things like this: these patches allow you to do RT processing on Linux, but they don't make some of the complexity go away. In the Klipper case, for example, writing to the GPIOs that actually send the signals to the steppers motors in Linux is relatively complex. You're usually making a write() syscall that's going through the VFS layer etc. to finally get to the actual pin register. On a microcontroller you can write directly to the pin register and know exactly how many clock cycles that operation is going to take. I've seen embedded Linux code that actually opened /dev/mem and did the same thing, writing directly to GPIO registers... and that is horrifying :)
    - cwillu 2y ago
      At the same time, RT permits some more offload to the computer. More effort can be devoted to microsecond-level concerns if the microprocessor can have a 1ms buffer of instructions reliably provided by the computer, vs if it has to be prepared to be on its own for hundreds of ms.
      - tonyarkles 2y ago
        Totally! I’m pumped for this in general, just want people to remember it’s not a silver bullet.
- bubaumba 2y ago
  I played with it years ago, but it's still alive and well http://linuxcnc.org/ These days not sure, hard to find computer with parallel port. Combined version with microcontroller like raspberry pico (which costs < $10) should be the right way to do it. Hard real time, WiFi remote for cheap. Then computer doesn't need to be fat or realtime, almost anything, including smartphone.
  - RockRobotRock 2y ago
    https://youtu.be/FEPfznStd0s https://youtu.be/FEPfznStd0s Marco Reps has some entertaining and informative videos on LinuxCNC with EtherCAT
  - GeorgeTirebiter 2y ago
    USB to Parallel are common. so, easy.
    - cwillu 2y ago
      A “real” parallel port provides interrupts on each individual data line of the port, _much_ lower latency than a USB dongle can provide. Microseconds vs milliseconds.
      - bubaumba 2y ago
        I think it's possible do to it all on raspberry pico. Having pico doing low level driving and javascript in browser taking high level, feeding pico and providing UI. That would be close to perfect solution
      - YZF 2y ago
        A standard PC parallel port does not provide interrupts on data lines. The difference is more that you can control those output lines with really low latency and guaranteed timing. USB has a protocol layer that is less deterministic. So if you need to generate a step signal for a stepper motor e.g. you can bit bang it a lot more accurately through a direct parallel port than a USB to parallel adapter (which is really designed for printing through USB and has very different set of requirements).
- alangibson 2y ago
  Because LinuxCNC runs on Linux. It's an incredibly capable CNC controller.
  - dale_glass 2y ago
    I mean yeah, but the more I know about computers the less I like the idea of it. On a PC you have millions of lines of kernel code, BIOS/EFI code, firmware, etc. You have complex video card drivers, complex storage devices. You have the SMM that yanks control away from the OS whenever it pleases. The idea of running a dangerous machine controlled by that mess is frankly scary.
    - chiffre01 2y ago
      LinuxCNC isn't the only thing out there either, lots of commercial machine tools use Linux to power their controllers.
    - HeyLaughingBoy 2y ago
      You'd probably be even more scared if you knew how many medical instruments ran on Windows ;-)
kragen 2y ago
linuxcnc aka emc2 runs linux under a real-time hypervisor, and so doesn't need these patches, which i believe (and correct me if i'm wrong) aim at guaranteed response time around a millisecond, rather than the microseconds delivered by linuxcnc (disclaimer: i've never run linuxcnc) but nowadays usually people do the hard real-time stuff on a microcontroller or fpga. amd64 processors have gotten worse and worse at hard-real-time stuff over the last 30 years, they don't come with parallel ports anymore (or any gpios), and microcontrollers have gotten much faster, much bigger, much easier to program and debug, and much cheaper. even fpgas have gotten cheaper and easier there's not much reason nowadays to try to do your hard-real-time processing on a desktop computer with caches, virtual memory, shitty device drivers, shitty hardware you can't control, and a timesharing operating system the interrupt processing jitter on an avr is one clock cycle normally, and i think the total interrupt latency is about 8 cycles before you can toggle a gpio. that's a guaranteed response time around 500 nanoseconds if you clock it at 16 megahertz. you are never going to get close to that with a userland process on linux, or probably anything on an amd64 cpu, and nowadays avr is a slow microcontroller. things like raspberry pi pico pioasm, padauk fppa, and especially fpgas can do a lot better than that (disclaimer: though i have done hard-real-time processing on an avr, i haven't done it on the other platforms mentioned, and i didn't even write the interrupt handlers, just the background c++. i did have to debug with an oscilloscope though)
- mlyle 2y ago
  > linuxcnc aka emc2 runs linux under a real-time hypervisor Historically it used RTAI; now everyone is moving to preempt-rt. The install image is now preempt-rt. I've been on the flipside where you're streaming g-code from something that isn't hard-realtime to the realtime system. You can be surprised and let the realtime system starve, and linuxcnc does a lot more than you can fit onto a really small controller. (In particular, the way you can have fairly complicated kinematics defined in a data-driven way lets you do cool stuff). Today my large milling machine is on a windows computer + GRBL; but I'm probably going to become impatient and go to linuxcnc.
  - kragen 2y ago
    thank you for the correction! are my response time ballparks for rtai and preempt-rt correct?

Why use Linux for that though? Why not build the machine like a 3D printer, with a dedicated microcontroller that doesn't even run an OS and has completely predicable timing, and a separate non-RT Linux system for the GUI?

juliangmp 2y ago
I feel like Klippers approach is fairly reasonable, let an non-RT system (that generally has better performance than your micro controller) calculate the movement but leave the actual commanding of the stepper motors to the micro controller.
- tonyarkles 2y ago
  Yeah, I looked at Klipper a few months ago and really liked what I saw. Haven't had a chance to try it out yet but like you say they seem to have nailed the interface boundary between "things that should run fast" (on an embedded computer) and "things that need precise timing" (on a microcontroller). One thing to keep in mind for people looking at the RT patches and thinking about things like this: these patches allow you to do RT processing on Linux, but they don't make some of the complexity go away. In the Klipper case, for example, writing to the GPIOs that actually send the signals to the steppers motors in Linux is relatively complex. You're usually making a write() syscall that's going through the VFS layer etc. to finally get to the actual pin register. On a microcontroller you can write directly to the pin register and know exactly how many clock cycles that operation is going to take. I've seen embedded Linux code that actually opened /dev/mem and did the same thing, writing directly to GPIO registers... and that is horrifying :)
  - cwillu 2y ago
    At the same time, RT permits some more offload to the computer. More effort can be devoted to microsecond-level concerns if the microprocessor can have a 1ms buffer of instructions reliably provided by the computer, vs if it has to be prepared to be on its own for hundreds of ms.
    - tonyarkles 2y ago
      Totally! I’m pumped for this in general, just want people to remember it’s not a silver bullet.
bubaumba 2y ago
I played with it years ago, but it's still alive and well http://linuxcnc.org/ These days not sure, hard to find computer with parallel port. Combined version with microcontroller like raspberry pico (which costs < $10) should be the right way to do it. Hard real time, WiFi remote for cheap. Then computer doesn't need to be fat or realtime, almost anything, including smartphone.
- RockRobotRock 2y ago
  https://youtu.be/FEPfznStd0s https://youtu.be/FEPfznStd0s Marco Reps has some entertaining and informative videos on LinuxCNC with EtherCAT
- GeorgeTirebiter 2y ago
  USB to Parallel are common. so, easy.
  - cwillu 2y ago
    A “real” parallel port provides interrupts on each individual data line of the port, _much_ lower latency than a USB dongle can provide. Microseconds vs milliseconds.
    - bubaumba 2y ago
      I think it's possible do to it all on raspberry pico. Having pico doing low level driving and javascript in browser taking high level, feeding pico and providing UI. That would be close to perfect solution
    - YZF 2y ago
      A standard PC parallel port does not provide interrupts on data lines. The difference is more that you can control those output lines with really low latency and guaranteed timing. USB has a protocol layer that is less deterministic. So if you need to generate a step signal for a stepper motor e.g. you can bit bang it a lot more accurately through a direct parallel port than a USB to parallel adapter (which is really designed for printing through USB and has very different set of requirements).
alangibson 2y ago
Because LinuxCNC runs on Linux. It's an incredibly capable CNC controller.
- dale_glass 2y ago
  I mean yeah, but the more I know about computers the less I like the idea of it. On a PC you have millions of lines of kernel code, BIOS/EFI code, firmware, etc. You have complex video card drivers, complex storage devices. You have the SMM that yanks control away from the OS whenever it pleases. The idea of running a dangerous machine controlled by that mess is frankly scary.
  - chiffre01 2y ago
    LinuxCNC isn't the only thing out there either, lots of commercial machine tools use Linux to power their controllers.
  - HeyLaughingBoy 2y ago
    You'd probably be even more scared if you knew how many medical instruments ran on Windows ;-)

kragen 2y ago

linuxcnc aka emc2 runs linux under a real-time hypervisor, and so doesn't need these patches, which i believe (and correct me if i'm wrong) aim at guaranteed response time around a millisecond, rather than the microseconds delivered by linuxcnc (disclaimer: i've never run linuxcnc) but nowadays usually people do the hard real-time stuff on a microcontroller or fpga. amd64 processors have gotten worse and worse at hard-real-time stuff over the last 30 years, they don't come with parallel ports anymore (or any gpios), and microcontrollers have gotten much faster, much bigger, much easier to program and debug, and much cheaper. even fpgas have gotten cheaper and easier there's not much reason nowadays to try to do your hard-real-time processing on a desktop computer with caches, virtual memory, shitty device drivers, shitty hardware you can't control, and a timesharing operating system the interrupt processing jitter on an avr is one clock cycle normally, and i think the total interrupt latency is about 8 cycles before you can toggle a gpio. that's a guaranteed response time around 500 nanoseconds if you clock it at 16 megahertz. you are never going to get close to that with a userland process on linux, or probably anything on an amd64 cpu, and nowadays avr is a slow microcontroller. things like raspberry pi pico pioasm, padauk fppa, and especially fpgas can do a lot better than that (disclaimer: though i have done hard-real-time processing on an avr, i haven't done it on the other platforms mentioned, and i didn't even write the interrupt handlers, just the background c++. i did have to debug with an oscilloscope though)

mlyle 2y ago
> linuxcnc aka emc2 runs linux under a real-time hypervisor Historically it used RTAI; now everyone is moving to preempt-rt. The install image is now preempt-rt. I've been on the flipside where you're streaming g-code from something that isn't hard-realtime to the realtime system. You can be surprised and let the realtime system starve, and linuxcnc does a lot more than you can fit onto a really small controller. (In particular, the way you can have fairly complicated kinematics defined in a data-driven way lets you do cool stuff). Today my large milling machine is on a windows computer + GRBL; but I'm probably going to become impatient and go to linuxcnc.
- kragen 2y ago
  thank you for the correction! are my response time ballparks for rtai and preempt-rt correct?