On 9/27/26 23:53, Chris Albertson wrote:
On Sep 27, 2026, at 2:43 PM, Peter Wallace<[email protected]> wrote:
On Sun, 27 Sep 2026, Chris Albertson wrote:
I like the way Klipper solved the communications jitter issue. Kiliiper is a
lot like LCNC. There is a central Linux computer that reads the G-code file,
does planning and the math, and then the low-level stuff like generating
wavforms to drive a stepper motor or whatever is some on microcontrollers that
can be truely ?hard? real time.
What Klipper does is simple. The microcontroller clocks are synchronized to
the Linux system. Then the Linux host attaches a ?target time? with each
movement command. The microcontroller then buffers the command until the exact
right time. This way, millisecond-level RT jitter in Linux does not show up on
the motors.
This way, one can get 10-microsecond-level timing without real-time Linux.
The difference is that LinuxCNC is an unbuffered system at the motion level.
Buffering removes the real time requirement from the upper level controller but
loses the ability for the upper level controller and therefore motion to repond
to real time inputs.
The way Klipper works for a real-time event like hitting a limit switch is that
the microcontroller is interrupted. The controller captures the clock and then
invalidates the buffer and sends the captured clock value back to the Linux
computer.
What makes this work so well is that, unlike Linux, a typical microcontroller
can capture a clock or timer value on an interrupt entirely in hardware,
without needing software to manually read the timer. We can get nanosecond or
microsecond timing even in a buffered system.
The other thing that makes this work is the Linux system continuously polls the
microcontroller’s clock and maintains a transformation equation that accounts
for any difference in phase and rate between the two clocks.
I don’t think all real-time events have to clear the buffer. I’m not expert
enough on details like that. But because the clocks are tracked, the Linux
machine can drive any reasonable number of microcontrollers using CAN bus,
serial, USB or whatever.
Another advantage is that this system can be very low cost. I can use a $4
rp2040 development board to drive a stepper at one million steps per second.
Better microcontrollers do better.
No one will implement this. It is too much work.
Is it? Let me propose a test procedure:
A bananapi-m5, driving a BTT octopus-pro V1.1 controller board. It
can drive 8 motors in real time, monitoring all 8 limit switches
while maintaining 3 or more temperatures.
Talk to Kevin about a fork of klipper to drive our very extensive list
of hdwe.
Borrow our test suite, feed it to klipper and see what falls out. The
list for functions for a 3d printer is maybe 10% of what we are doing in
LinuxCNC. How much work would it take to fix each fallout?
Then we would have a far better understanding of the work involved.
Another of my fav subjects:
The advent of closed loop stepper/servo's has, at my place, been an eye
opener in terms of the speed limits and accuracy, taking an elderly
Ender5 from 16mm/sec for y travel, to 200mm/sec or better. Actual
limit is imposed by the hot ends ability to deliver enough hot plastic
from a 60 watt heater. The hot ends ability to deliver the plastic is
now that printers speed limit. The hot end needs more heat. Where that
printer had layer shifts at 20mm/sec, now with 72 volts for the main
motors, details in the print are much better defined now & a 3 day job
is now done in 9 hours. That heater is rated for 320C but has a short
life, but it does a fine job with a spool of polycarb loaded. I have a
bed booster fitted, and a 36 volt, 800watt bed supply, can now hit 125C
for printing polycarb.
My sheldon 11" x 56" now has 42 volt 3 phase closed loop motors, around
3x faster & much quieter than the 24 volt regular steppers. Watching it
run you'd swear Casper the ghost was turning the cranks. My 4 axis 6040
gantry has 2 of these motors on Z & B axises. My G0704 has an A for its
4th. 500+ rpms, .1 degree accuracy.
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
