On 9/28/26 13:53, Nicklas SB Karlsson wrote:
Happy if I could send Ethernet frames reliable with a periodicity of one
millisecond. Though a small buffer of
ten values and reduced demand to within 10 millisecond would most certainly
work equally well for a CNC machine.
Guess 10 millisecond delay or jitter while probing would not make much of
difference.
To make it work I however have to spend some extra time on this. Have also
considered split real time part of
Linuxcnc from graphical user interface but this also take extra time and extra
thread for receive as it seems
sending work more reliable than receive.
An extra delay of one millisecond on average once an hour is good enough right
now.
Nicklas Karlsson
mån 2026-09-28 klockan 10:05 -0700 skrev Chris Albertson:
Realistically, no one is going to redesign LCNC to use target times. It would
be too large of an effort relative to the size of the project.
If you want to see some hardcore electric motor control porn, it is not the CNC
or printer guys doing it. Look at this 56-axis machine, all done with 3-phase
BLDC motors and EtherCAT. (Yes, 56 motors)
https://www.facebook.com/watch/?v=1421798356402556
On Sep 28, 2026, at 3:54 AM, maurice e heskett <[email protected]> wrote:
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.
Not kidding, I am carving a hard maple bench vice screw on my rebuilt
6040 gantry, with a buttress 2 start thread, 50mm dia by 400mm long at
500 revs of the stick.
Cheers, Gene
_______________________________________________
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
_______________________________________________
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
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
