Seems I was slightly mistaken about how Klipper works. It is NOT a FIFO command buffer. As pointed out, there could be problems with that. It is a schedule queue. The Linux side sends a command and a time to execute that command, and then a scheduler on the microcontroller fires off the command at the given time. The difference is subtle, as this allows out-of-order execution. For example, the Linux host side can send “stop RIGHT-NOW” and this gets executed without need to wait in a queue. Setting the time to “now” jumps the queue.
Also, the microcontroller can push “pin changed” commands in real time without polling (can respond to polling too) So the touch-off or “crash into a limit” is done by sending a move at some rate; the switch contact is sent with a timestamp for when the contact closed, and the Linux host can send “stop now.” So real-time events are handled just fine. What is gained is that the Linux host gets very accurate timing on when the switch closed, and the move command sees nearly zero timing jitter even on a very poor Linux host; the STOP command can be acted on immediately even if the buffer queue has many commands. The mistake was to assume the queue was FIFO. It is not; it is a scheduler queue, and commands are removed when their time tags match the current time. The clocks are not synchronized. The system maintains a two-way transform to map the clocks, and the transform is updated somehow in the background. The reason for this was to remove the need for real-time in the Linux system. Again, I’m not asking or suggesting a change. It seems to work well enough. > On Sep 29, 2026, at 4:44 PM, maurice e heskett <[email protected]> wrote: > > On 9/28/26 19:36, Peter Wallace wrote: >> On Mon, 28 Sep 2026, Chris Albertson wrote: >> >>> SOme math? moving at 200mm per second a 10ms uncertinaly is a 2 mm error. >>> That is not even close to acceptable. Wht they do is (1) have 1000x >>> better timing and (2) after finding the approximate location, back off and >>> move very slowly to find the exac point. >>>> On Sep 28, 2026, at 1:28?PM, Peter Wallace <[email protected]> wrote: >>>> >>>> On Mon, 28 Sep 2026, Chris Albertson wrote: >>>> >>>>> 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. >>>> >>>> Why would you? since it would result in the controller losing the ability >>>> to react in real time to external inputs. >>> >>> The way it works is that ther microcontroller has hardware that samples a >>> local clock when a pin changes. Sp by moving the timing out to the >>> microchtroller you actually gain real-time precision. It is easy to get >>> micosecond level timing. Lets say you start. hardware counter running at >>> 1MHz and then tell the hardware to capture the count when a limit switch >>> pin changes. You can now react to that real-time even in a micro second. >>> Linux could never by so fast. I didn?t invent this. It is why many micro >>> contreoller have this hardware for stuff like this. >>> >>> From linux?s point of view it is the idetical same thing, it get notice >>> that a limit switch is closed but now alomng with that notice is the exact >>> microsecond when that happened. >>> >> >> This is already done with many LinuxCNC I/O devices, what LinuxCNC does not >> do >> is buffer commands and data as this prevents real time control reactions. >> The fact that a peripheral can react quickly is not useful in many motion >> contexts as it affects motion planning for all axis, the controller must >> react quickly... > > Which, from my personal experience with the closed loop stepper/servo's is > fast enough to prevent broken chips or marks on the stationary chuck jaw it > ran into, creeping slow or at 60 ipm. The tool contacts the chuck jaw, Z > stops and this turns off the driver's output bugs and I have that signal > wired into the E-Stop which crowbars the lathes AC input, shutting > everything down in its tracks. Tool chip is not damaged & the shutdown kills > the PSU's allowing the drive train to unwind far enough to slip a 10 thou > feeler blade between the chip and the chuck jaw that stopped it. This "test" > has been done at least 100 times while I was trying to impress visiting > frogs. Pull the tool holder off the QCTH, F2 to repower the lathe, rehome the > lathe, put the tool holder back on and continue the job. All this with an > rpi4, a 7i90hd and a trio of 7i42's needed to make the 7i90HD survive in a 5 > volt world. Not cheap, but sure works nice. > > This is due to Peter W. and others who designed the stuff to make it possible > to do it with a pi. You know who you are and gave me lots of help to make it > happen. Thank you ALL. > > Cheers, Gene > >> >> >> >>> >>> >>> >>> _______________________________________________ >>> Emc-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/emc-users >> >> Peter Wallace >> Mesa Electronics >> >> >> _______________________________________________ >> 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
