New experimental firmware: all kinematics in host

Klipper is a new experimental firmware! It is designed to run on both a micro-controller and a low cost host computer such as a Raspberry Pi. The host does all the work of determining how and when to move each stepper motor, it compresses that information, and sends it to the micro-controller. The micro-controller then uncompresses the given schedule and executes it at the specified times. The same host computer can be used to run both Klipper and OctoPrint.

There are several advantages to splitting work between a micro-controller and a host machine:
* It is fast. On a 16Mhz AVR micro-controller, Klipper can reach 90K steps per second. (On a 20Mhz chip, 110K steps per second.)
* It has more reproducible results. Other firmware (in particular ones running on slower AVR chips) can cause print stalls due to CPU bottlenecks or serial port communication issues. Klipper specifies exact event times which leads to more reproducible prints. (In the unfortunate event of a severe communication outage between host and micro-controller, the Klipper micro-controller code would detect the outage and cancel the print.)
* The code is more portable. The micro-controller code (written in C) is small and focused, and should be easier to port to new micro-controller architectures. The host code (written in Python and C) is not hardware specific. Indeed, the most interesting code - the kinematics, the acceleration, the lookahead algorithm, the PID - are written in Python.
* It does not use the Bresenham algorithm or similar kinematic estimations. Instead, Klipper calculates precise event times using full 64bit floating point math (even a low cost Raspberry Pi has full hardware support for 64bit doubles). It is hoped that this will facilitate novel acceleration, extrusion, and kinematic designs.

The code is available at:
https://github.com/KevinOConnor/klipper

The code is in an experimental state. It currently works with Atmel ATMega micro-controllers and with OctoPrint running on the same Raspberry Pi computer. I have been regularly testing it on my RAMBo based cartesian 3d printer. However, it is possible some quirks or bugs may appear. For those willing to experiment, I am interested in hearing the results of tests and feedback from those tests.

Interesting!

On one hand I like the idea a lot.

The other hand is screaming win driver type architecture, avoid avoid!..... At least your code isn’t windows specific

A third hand is also screaming that this is similar to what makerbot did to a large extent, they removed all the math on the controller and just send raw axis steps to the controller, their error was then distributing objects in that format.. making their objects incompatible with everyone else. (at least that is my take on it)
I don’t think they did any compression

A forth hand is also mumbling that 8 bit arduino is dead and your flogging a dead horse. But there is nothing stopping this working on 32 bit machines
Perhaps a dual protocol system could be developed supporting both systems on 32bit machines

Edited 2 time(s). Last edit at 05/26/2016 03:05AM by Dust.

Interesting! There was always talk about doing this so it's good to see someone has finally done it.

My thoughts are how much faster would it be if running on a 32 bit platform, I might look into that.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

Quote
Dust
A forth hand is also mumbling that 8 bit arduino is dead and your flogging a dead horse. But there is nothing stopping this working on 32 bit machines

Right - I tried to keep the AVR code to a minimum and to make sure hardware details are isolated from the high-level logic, so I think Klipper should be portable to a variety of micro-controllers.

Quote
KevinOConnor
Klipper is a new experimental firmware! It is designed to run on both a micro-controller and a low cost host computer such as a Raspberry Pi. The host does all the work of determining how and when to move each stepper motor, it compresses that information, and sends it to the micro-controller. The micro-controller then uncompresses the given schedule and executes it at the specified times. The same host computer can be used to run both Klipper and OctoPrint.

There are several advantages to splitting work between a micro-controller and a host machine:
* It is fast. On a 16Mhz AVR micro-controller, Klipper can reach 90K steps per second. (On a 20Mhz chip, 110K steps per second.)
* It has more reproducible results. Other firmware (in particular ones running on slower AVR chips) can cause print stalls due to CPU bottlenecks or serial port communication issues. Klipper specifies exact event times which leads to more reproducible prints. (In the unfortunate event of a severe communication outage between host and micro-controller, the Klipper micro-controller code would detect the outage and cancel the print.)
* The code is more portable. The micro-controller code (written in C) is small and focused, and should be easier to port to new micro-controller architectures. The host code (written in Python and C) is not hardware specific. Indeed, the most interesting code - the kinematics, the acceleration, the lookahead algorithm, the PID - are written in Python.
* It does not use the Bresenham algorithm or similar kinematic estimations. Instead, Klipper calculates precise event times using full 64bit floating point math (even a low cost Raspberry Pi has full hardware support for 64bit doubles). It is hoped that this will facilitate novel acceleration, extrusion, and kinematic designs.

The code is available at:
https://github.com/KevinOConnor/klipper

The code is in an experimental state. It currently works with Atmel ATMega micro-controllers and with OctoPrint running on the same Raspberry Pi computer. I have been regularly testing it on my RAMBo based cartesian 3d printer. However, it is possible some quirks or bugs may appear. For those willing to experiment, I am interested in hearing the results of tests and feedback from those tests.

Interesting; but I think the advantages you quote are only by comparison with Arduino/RAMPS and similar ancient 8-bit electronics:

- 32-bit boards such as Duet and Smoothieboard already reach more than 100k steps/second.
- Likewise these boards don't use the ridiculous serial-over-USB protocol without flow control that Arduino uses, they use true USB with flow control - which makes a much higher data throughput possible. In any case, printing form SD card is the preferred approach because it removes the dependency on a host PC.
- Modern firmwares separate the hardware interface layer from the rest (RepRapFirmware certainly does) and it's all written in C++, so it's quite portable.
- RepRapFirmware doesn't use Bresenham, it calculates the step times precisely - even for long moves on delta printers. It also implements pressure advance for extruder motion. You don't need 64-bit FP to do this, 32 bit integer with occasional 64 bit integer maths is sufficient.

So I think the idea of calculating the kinematics on a host PC been overtaken by the availability of low-cost 32-bit processors, which now cost less than high pin count 8-bit processors such as the atmega2560. But your code may be interesting to existing Arduino/RAMPS/RPi/Octoprint users who are looking for better movement algorithms without upgrading the hardware.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hey Kevin,
Thanks for that. It was an area of experimentation I was intending to look into some time.

My views:

I see something like this being necessary for the 3D-printer to evolve. G-code is becoming a limiting factor. For example, Gcode really isn't good at handling full-color mixing extrusion (assuming this is possible!), where the extrusion rates of each colour is continuously varied to give different shades.

There's no particular need to throw out the old 8-bit Arduinos. When the 8-bit Arduino horse does actually die, *then* move to some other platform. Arduinos can do a perfectly adequate job of handling the real-time stepper motor control, and there's no particular need to load them down with a whole lot of 3D math and Gcode interpretation and other fancy stuff. In fact, why not have one small processor (I'm thinking of something like a programmable timer/counter and maybe a shift register) per stepper which would generate the pulse stream for that stepper?

It makes sense to use a desktop computer with 8 cores@3GHz that is idle 99% of the time (or a Raspberry Pi) for the heavy lifting and precise calculation and so on.

I don't see any sense in using this format for distributing objects (in the same way that distributing Gcode files is a bad idea), and I don't think anyone will push in that direction.

I'm curious about the 64-bit timing... I suspect that timing information could be left out of the protocol, and just steps sent to the AVR. The AVR should be able to work out the accelerations and therefore pulse timings itself, knowing the max acceleration and speed of each stepper.

Another thought I had was that a whole series of steps could be defined by some kind of polynomial. That would be simple and quick for the AVR to calculate exact timings, and give maximum compression of data transmission to the AVR.

I guess that to make this system work, the host end would need to know printer-specific things like steps/mm in each axis, and also bed-levelling information. Does your protocol get that information from the printer, or does it need to be manually entered into the host?

Quote
frankvdh
I'm curious about the 64-bit timing... I suspect that timing information could be left out of the protocol, and just steps sent to the AVR. The AVR should be able to work out the accelerations and therefore pulse timings itself, knowing the max acceleration and speed of each stepper.

The 64bit timing is done in the host. The commands sent to the micro-controller are sent relative to the mcu clock counter. Stepper events are relative to the previous stepper event and so are small and compress well.

Quote
frankvdh
Another thought I had was that a whole series of steps could be defined by some kind of polynomial. That would be simple and quick for the AVR to calculate exact timings, and give maximum compression of data transmission to the AVR.

That is how the Klipper step compression works - it finds a series of quadratic functions to approximate a series of stepper step events.

Quote
frankvdh
I guess that to make this system work, the host end would need to know printer-specific things like steps/mm in each axis, and also bed-levelling information. Does your protocol get that information from the printer, or does it need to be manually entered into the host?

All configuration is in the host. The micro-controller has no printer configuration at all. The host instructs the micro-controller on how each pin is supposed to be configured and used.

Apologies for the barrage of questions, but this is very interesting...

Is there any reason not to download the Klipper data to a file on the SD card on the printer, and then print from there? That would allow stand-alone printing. Although that wouldn't be a big deal for someone printing from a RPi, it would mean that a desktop machine could be turned off once the file had been transferred. Someone without a connection between their desktop & printer could still use Klipper. And it might also be useful for testing & debugging.

How do I print some arbitrary .STL (or whatever) file using Klipper? Does it need a conventional slicer to generate G-code which is then read to make the Klipper data?

Is there a manual or Wiki or something like that?

Quote
frankvdh
Is there any reason not to download the Klipper data to a file on the SD card on the printer, and then print from there? That would allow stand-alone printing. Although that wouldn't be a big deal for someone printing from a RPi, it would mean that a desktop machine could be turned off once the file had been transferred. Someone without a connection between their desktop & printer could still use Klipper. And it might also be useful for testing & debugging.

Beyond just step timing information (which could be stored in a file) Klipper also does printer configuration, buffer management, thermistor calculations, the PID, etc in the host. So, for users that wish to be able to disconnect their desktop, the recommendation would be to acquire an RPi.

Quote
frankvdh
How do I print some arbitrary .STL (or whatever) file using Klipper? Does it need a conventional slicer to generate G-code which is then read to make the Klipper data?

In its current experimental state it works best with a traditional slicer, with OctoPrint, and on an RPi - OctoPrint sends regular gcode to Klippy (the host part of Klipper) which translates the gcode to commands for the micro-controller.

Quote
frankvdh
Is there a manual or Wiki or something like that?

There's a little bit of documentation if you follow the links at https://github.com/KevinOConnor/klipper. It is admittedly sparse right now.

Quote
dc42
So I think the idea of calculating the kinematics on a host PC been overtaken by the availability of low-cost 32-bit processors, which now cost less than high pin count 8-bit processors such as the atmega2560.

I understand that 32bit micro-controllers are significantly more powerful than 8bit micro-controllers. However, I still think 32bit micro-controllers are vastly under-powered. Specifically, I think a printer should have webcam support, built-in STL/AMF slicing, web server, wifi, etc. This is readily available with a low-cost Raspberry Pi. Further, I see these low-cost application processors getting cheaper and more powerful, while I don't see that with the current set of micro-controllers (32bit or other).

So investing in custom code for micro-controllers (eg, tcpip stacks, web servers) does not appeal to me. And, once one pairs an application processor with their printer, then I think it makes sense to do the acceleration and kinematics on that application processor.

Quote
dc42
But your code may be interesting to existing Arduino/RAMPS/RPi/Octoprint users who are looking for better movement algorithms without upgrading the hardware.

One thing I would like to see is the ability for users to be able to deploy a firmware irrespective of their hardware. I think it is unfortunate that RepRapFirmware doesn't run on AVRs or Smoothieboards, that Smoothieware doesn't run on Duet or AVR, that Redeem only runs on the BeagleBone, etc. I think a truly portable firmware would be a great thing to have.

Quote
KevinOConnor
I think a truly portable firmware would be a great thing to have.

Meet Teacup Firmware. Not yet ported to all these platforms, but well capable of getting it done. Currently existing ports: All ATmegas, including native USB ones, ARM LPC1114 and ARM STM32F411.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Had a look at the firmware code now. Nice work! Quite readable once one groks this DECL_... mechanism.

Of course I'm curious how klipper manages to about double the maximum step rate compared to Teacup. After reading sources I think it's because there is no stepper motor synchronisation. At least I can find none. Each movement command is for one stepper only, so the only synchronisation is that the host sends commands in a tight sequence.

Now, assuming that such a command is 6 bytes, it takes about ((8 data bits + 1 stop bit) * 6 bytes) / 250000 baud = 0.224 ms to send a command. A movement involving 3 steppers (quite common: X, Y, E) has an offset of 0.448 ms or, at 100'000 steps/seconds, of 44 steps. Being 44 steps off track is quite a bit for my taste.

Did I miss something with my considerations?

That said, I do see chances for klipper. It could learn synchronized movements. Adding acceleration, too, would make it very similar to the original RepRap firmware, but that's not neccessary. For acceleration, one update every 2 ms is sufficient. Then it's similar to Teacup firmware with ACCELERATION_TEMPORAL, which currently does neither acceleration nor lookahead, but evenly distributes all participating steppers like klipper. It'd need a parser for the klipper protocol, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Had a look at the firmware code now. Nice work! Quite readable once one groks this DECL_... mechanism.

Thank you for reviewing the code.

Quote
Traumflug
Of course I'm curious how klipper manages to about double the maximum step rate compared to Teacup. After reading sources I think it's because there is no stepper motor synchronisation. At least I can find none. Each movement command is for one stepper only, so the only synchronisation is that the host sends commands in a tight sequence.

You are correct that stepper movement is accomplished with the "queue_step" command and that this command only controls the steps for a single stepper. However, the steps are synchronized with other stepper motors. The synchronization is done by virtue of the clock offset that is implicit in the queue_step command. For example, if the x stepper is told to step 5 times with an interval of 10000 starting at clock 20000 and the y stepper is told to step 2 times with an interval of 14000 starting at clock 35000, then you'll get steps: x, x, y, x, y, x, x. Each step event will be scheduled at the requested clock time and the order of steps will be preserved.

The clock time is "implicit" in queue_step in that it is not an explicit parameter of the command. To reduce bandwidth and to simplify the mcu code, the default starting clock time for queue_step is the clock time of the last step for that stepper. The host code (see klippy/stepcompress.c) tracks the clock of each stepper and knows to issue new queue_step commands relative to that clock.

Quote
Traumflug
Now, assuming that such a command is 6 bytes, it takes about ((8 data bits + 1 stop bit) * 6 bytes) / 250000 baud = 0.224 ms to send a command. A movement involving 3 steppers (quite common: X, Y, E) has an offset of 0.448 ms or, at 100'000 steps/seconds, of 44 steps. Being 44 steps off track is quite a bit for my taste.

I don't understand the above. I think you may have incorrectly concluded that the queue_step command starts issuing steps relative to when the command is parsed. This is not the case - queue_step adds the requested interval/count/add stepper sequence onto the end of a per-stepper queue. So, the commands are received (and queued) well in advance of the actual stepper movement. On my atmega2560 based RAMBo printer, the "move queue" can hold up to 646 of these stepper sequences in ram. In practice this means the command stream is almost always several seconds ahead of the actual stepper events. (Should some severe communication issue cause a queue under-run then the mcu would detect that and cancel the print.)

Quote
Traumflug
That said, I do see chances for klipper. It could learn synchronized movements. Adding acceleration, too, would make it very similar to the original RepRap firmware, but that's not neccessary. For acceleration, one update every 2 ms is sufficient. Then it's similar to Teacup firmware with ACCELERATION_TEMPORAL, which currently does neither acceleration nor lookahead, but evenly distributes all participating steppers like klipper. It'd need a parser for the klipper protocol, of course.

Just to be clear, Klipper does implement acceleration (along with lookahead). It's implemented in the host software (see klippy/cartesian.py:Move.process). The interval/count/add sequence in queue_step implements a quadratic function that is part of a compression algorithm that reduces the bandwidth between host and mcu. The host determines when to step each stepper motor (in Move.process), those steps are compressed (into a series of quadratic functions), sent to the mcu (as queue_step commands), and then the mcu pulses the stepper at the specified times (via the stepper_event timer). I don't think it is similar to ACCELERATION_TEMPORAL.

Quote
KevinOConnor
So, the commands are received (and queued) well in advance of the actual stepper movement. On my atmega2560 based RAMBo printer, the "move queue" can hold up to 646 of these stepper sequences in ram. In practice this means the command stream is almost always several seconds ahead of the actual stepper events. (Should some severe communication issue cause a queue under-run then the mcu would detect that and cancel the print.)

In the case of an object which is very irregular and organic in shape (and consequently doesn't model well to your quadratic model), and very detailed, could the printer consume commands faster than they can be sent to it? Either due to slow calculation by the host, or insufficient comm bandwidth? I.e. once printing has started, can you *guarantee* that the queue won't become empty until the item is finished? If not, then a simple queue under-run should just result in a pause rather than cancellation of the print.

Frank

Quote
KevinOConnor
You are correct that stepper movement is accomplished with the "queue_step" command and that this command only controls the steps for a single stepper. However, the steps are synchronized with other stepper motors. The synchronization is done by virtue of the clock offset that is implicit in the queue_step command.

Thanks, this explains what I was missing.

Quote
KevinOConnor
I think you may have incorrectly concluded that the queue_step command starts issuing steps relative to when the command is parsed.

Well, all firmwares except klipper do this, so yes, I assumed it without looking closer.

Quote
KevinOConnor
The host determines when to step each stepper motor (in Move.process), those steps are compressed (into a series of quadratic functions), sent to the mcu (as queue_step commands), and then the mcu pulses the stepper at the specified times (via the stepper_event timer). I don't think it is similar to ACCELERATION_TEMPORAL.

Actually, on the firmware side that's exactly what ACCELERATION_TEMPORAL does, except that the communications protocol is different. Klipper receives a number of steps and timing, the other one receives an endpoint and a speed and calculates steps/timing from that. During stepper movement both do the same. Hence the idea to combine klipper host with Teacup firmware. That said, an idea I'll keep in mind but don't plan to implement in the next future.

Quote
frankvdh
If not, then a simple queue under-run should just result in a pause rather than cancellation of the print.

A sudden interrupt of movement means likely step losses, so continuing a print makes no sense.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
frankvdh

Quote
KevinOConnor
So, the commands are received (and queued) well in advance of the actual stepper movement. On my atmega2560 based RAMBo printer, the "move queue" can hold up to 646 of these stepper sequences in ram. In practice this means the command stream is almost always several seconds ahead of the actual stepper events. (Should some severe communication issue cause a queue under-run then the mcu would detect that and cancel the print.)

In the case of an object which is very irregular and organic in shape (and consequently doesn't model well to your quadratic model), and very detailed, could the printer consume commands faster than they can be sent to it? Either due to slow calculation by the host, or insufficient comm bandwidth? I.e. once printing has started, can you *guarantee* that the queue won't become empty until the item is finished? If not, then a simple queue under-run should just result in a pause rather than cancellation of the print.

There are no guarantees or warranties. Klipper is free software.

The host does attempt to detect if it can't keep up, and it will insert delays into the print if so (and note the event in the statistics). It's unclear how well this works in practice.

If the host can keep up, but the serial can not keep up, then the mcu has no choice but to cancel the print. In my tests, I have never come even close to saturating the serial bandwidth (max was ~20%). It's not something I plan to focus on unless testing shows an issue.

Quote
KevinOConnor

Quote
frankvdh

In the case of an object which is very irregular and organic in shape (and consequently doesn't model well to your quadratic model), and very detailed, could the printer consume commands faster than they can be sent to it? Either due to slow calculation by the host, or insufficient comm bandwidth? I.e. once printing has started, can you *guarantee* that the queue won't become empty until the item is finished? If not, then a simple queue under-run should just result in a pause rather than cancellation of the print.

There are no guarantees or warranties. Klipper is free software.

Sorry, I wasn't meaning anything legalistic or whatever about it. I was just hoping you had already done the calculations to save me having to.

From what you've said, it's unlikely to be an issue in reality, and (on reflection) I realise that pausing when running at 110K steps/sec isn't going to work. So I agree that cancelling the print would be the right thing to do.

But I do like to have numbers to base things on. For others like me, here's my rough calculations (feel free to correct me if I'm wrong)...
Assuming 115200Kbps serial and 11.52 bytes/command, a command would take about a millisecond to transmit. The worst case (when running at 110K steps/sec) command would be to move 1 step in about 10 microseconds. (Of course you wouldn't have a whole series of these because a whole series of pulses the same time apart would be encoded as a single quadratic command). So, worst case, your buffer is about 6-7 seconds long. At (say) 1000 steps/mm for movement and with 10 steppers (X, Y, 2*Z axes and 6 filament (super-Diamond hot-end!)), you would have run off the edge of a metre square! bed in that time. Not to mention going through 6 spools of filament in no time at all. So I think it's guaranteed that the buffer wouldn't overflow in any sub-industrial printer.

I hadn't thought about the host monitoring its own speed and slowing down the printer to match... looks like you're way ahead of me!

This sort of architecture sounds perfect for a BeagleBone assuming you could adapt the stepper/endstop/thermistor code to run on its two PRU's.

Quote
WZ9V
This sort of architecture sounds perfect for a BeagleBone assuming you could adapt the stepper/endstop/thermistor code to run on its two PRU's.

Yes - I think it should be possible to compile the Klipper micro-controller C code for the PRU using the PRU gcc port. With that, the ARM cores in the BeagleBone would be considered the host and one of the PRU cores would be considered the micro-controller.

FYI, I have made some recent updates to Klipper:

* The code has been ported to the Arduino Due ARM based platform. On the Due, Klipper can obtain up to 380K steps per second. Although the ARM and AVR platforms have significant differences, only a small amount of Klipper code needed to be updated to run on this platform.
* Some additional optimizations were made on the Atmega AVR micro-controllers. It's now possible to reach 150K steps per second on a 20mhz chip (120K on a 16Mhz chip).
* The code has been ported to the AVR at90usb chip with native USB support. (Just about every AVR chip should work now - if anyone wants to test and finds their chip not present, let me know.)

Klipper can be found at:
https://github.com/KevinOConnor/klipper

Kevin,
This is very good work!

As I have just written in another place, I've been thinking of a scenario for this kind of thing - for a robotics project with a great number of motors.

Quote
Paul W
Instead of interpreting gcode and sending step pulses, a multi-core master controller (like a Pi 3) could send "motion frames" to slave controllers (like 1GHZ Pi Zeros running bare metal, $5 each).
Think of a Pi-3 plugged into a daughter board that has a row of Pi-Zeros socketed into it, each controlling multiple socketed or on-board stepper drivers...
The motion frames would contain pre-computed speed, # of steps, and acceleration profiles. Running without interrupts the bare metal Pi Zeros could supply the step pulses without jitter.

Of course the same thing could be done for Reprap printers. You would need to change the gcode motion planner module to run on a PI, and output motion frames, and program the Pi Zeros to communicate with it and process the motion frames into pulses...
And that could cost more than the existing boards that are already working well. It would however allow very high performance, graphical interfaces, a real operating system (Linux), fast communications, and a continual upgrade path with new Pi models.

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

Quote
Paul Wanamaker
Kevin,
This is very good work!

As I have just written in another place, I've been thinking of a scenario for this kind of thing - for a robotics project with a great number of motors.

Quote
Paul W
Instead of interpreting gcode and sending step pulses, a multi-core master controller (like a Pi 3) could send "motion frames" to slave controllers (like 1GHZ Pi Zeros running bare metal, $5 each).
Think of a Pi-3 plugged into a daughter board that has a row of Pi-Zeros socketed into it, each controlling multiple socketed or on-board stepper drivers...
The motion frames would contain pre-computed speed, # of steps, and acceleration profiles. Running without interrupts the bare metal Pi Zeros could supply the step pulses without jitter.

Of course the same thing could be done for Reprap printers. You would need to change the gcode motion planner module to run on a PI, and output motion frames, and program the Pi Zeros to communicate with it and process the motion frames into pulses...
And that could cost more than the existing boards that are already working well. It would however allow very high performance, graphical interfaces, a real operating system (Linux), fast communications, and a continual upgrade path with new Pi models.

Thanks Paul.

In your scenario above, the RPi3 could act as the host running Klippy and the RPi Zeros could act as the "micro-controllers". It should be possible to port the Klipper micro-controller code to support the RPi Zero. There are different ways to accomplish this, but the easiest might be to run a real-time OS and then extend the Klipper code to support the RPi GPIOs.

Also, supporting multiple micro-controllers is something I tried to keep in mind while writing the code. So, I think it would only take a little more work for Klippy to support that. With that support, multiple micro-controllers (RPi Zeros, Arduinos, or a heterogeneous mix) should be possible.

-Kevin

Please consider using not quadratic, but cubic curves - to implement real jerk limiting/S-shape acceleration profile.
Great project, I was thinking about doing similar myself.
Also with this architecture it's easy to use FPGA as controller - it can achive tenth of millions of steps per second if there is need for such speeds.

Quote
shadowjack
Please consider using not quadratic, but cubic curves - to implement real jerk limiting/S-shape acceleration profile.
Great project, I was thinking about doing similar myself.
Also with this architecture it's easy to use FPGA as controller - it can achive tenth of millions of steps per second if there is need for such speeds.

Thanks.

The step timing via quadratic functions is used as a compression system. The host computes a series of actual stepper event times and then the code computes a series of quadratic functions that approximate those actual step times. So, Klipper does implement real constant acceleration and does do real jerk limiting. The compression system reduces bandwidth; it doesn't fundamentally limit the robot kinematics.

That said, I do think cubic functions would improve compression and I did spend some time considering them. However, an algorithm to efficiently compute them given a series of step times was not readily apparent to me.

-Kevin

Do you really need to convert some geometry + acceleration profile - > steps - > quadratic (cubic) functions of t - > steps? After first conversion to steps you loose some information. Maybe skip it and convert to cubic functions directly? At least that's what I was planning to do.
As to possible compression algorithm I can think of splitting step series in some segments (0.1 sec) and trying to fit cubic curve to it using least squares. If error > epsilon split interval in two. Can be split in the middle or some other point using some metric. Then do recursion for each part.

Quote
shadowjack
Do you really need to convert some geometry + acceleration profile - > steps - > quadratic (cubic) functions of t - > steps?

The main gain of converting to steps and then compressing those steps is that it naturally enables compression across gcode moves. On prints with curves the gcode slicer will emit lots of tiny moves, but after lookahead those moves generally become smooth motions. When considering these motions from the perspective of a single stepper motor, the duration between steps is often smooth and continuous. The compression scheme is thus able to merge many small gcode moves into a handful of low-level "queue_step" firmware commands.

I do agree that it should be possible to go directly from a series of kinematic equations to a series of polynomials. I did look at it a few months back, but the math got "really funky", and I ultimately wasn't confident I'd find a correct solution. So I went with the slightly more CPU intensive, but easier to understand algorithm.

Quote
shadowjack
After first conversion to steps you loose some information.

The compression scheme does allow for some loss of information (ie, slightly different scheduled times vs requested times), but it is strictly limited. (By default, after compression, no step may be scheduled more than 50 micro-seconds ahead of it's target time, and any deviation must not be more than half the time since the last step on that stepper.)

Quote
shadowjack
Maybe skip it and convert to cubic functions directly? At least that's what I was planning to do.
As to possible compression algorithm I can think of splitting step series in some segments (0.1 sec) and trying to fit cubic curve to it using least squares. If error > epsilon split interval in two. Can be split in the middle or some other point using some metric. Then do recursion for each part.

Early on I looked at the least squares implementation in numpy, but it was really slow. I also couldn't see a way to enforce a limitation on the deviation on each step. (The least squares error effectively limits the deviation across all steps - but the possibility of having most steps close but a handful way off wasn't something I was comfortable with.)

I'm certainly open to improvements here. The kinematic code is in klippy/cartesian.py:move() - it ultimately calls klippy/mcu.py:MCU_stepper:step_factor() and step_sqrt() to generate the steps - which really just calls klippy/stepcompress.c:stepcompress_push_factor() and stepcompress_push_sqrt(). The step compression code (which generates the firmware queue_step parameters) is in stepcompress.c:compress_bisect_add().

-Kevin

I find this approach very appealing. How is the project coming along - would you rate it as usable now, or still at the proof of concept stage? Feature-wise, does it compare with marlin or repetier firmware in terms of being able to control fans for the electronics and hotends?

Where does the low frequency code for things like fans and heaters live, is that on the host side or the mcu? I guess if it's on the host you then have to either interface to the sensors from the application processor, or provide a protocol for passing the readings from the mcu to the application processor.

Is there support for a local interface on an LCD, either connected to the mcu or the RPi (or I guess both if it's useful)?

Quote
JamesK
I find this approach very appealing. How is the project coming along - would you rate it as usable now, or still at the proof of concept stage?

Thanks. I'd say it's in an "experimenting stage". I've been using it regularly on my printer. However, the host software can be finicky at times and its error reporting needs to be improved. Testers are welcome, but expect some bumps.

Quote
JamesK
Feature-wise, does it compare with marlin or repetier firmware in terms of being able to control fans for the electronics and hotends?

I'm not sure I understand your question. An extruder fan is supported via the regular g-code commands (eg, M106). It's also possible to turn on cpu and nozzle cooling fans at startup via the config file (my printer has a nozzle cooling fan which I enable this way).

If you follow the documentation links from https://github.com/KevinOConnor/klipper you can find the todo list for hardware support.

Quote
JamesK
Where does the low frequency code for things like fans and heaters live, is that on the host side or the mcu? I guess if it's on the host you then have to either interface to the sensors from the application processor, or provide a protocol for passing the readings from the mcu to the application processor.

It's split between host and micro-controller. For example, the host implements the PID algorithm. However, the micro-controller measures the thermistor and changes the heater pins as scheduled by the host.

I'm not currently using the RPi as anything other than an application processor. It's not necessary to use any of the RPi's GPIO pins.

Quote
JamesK
Is there support for a local interface on an LCD, either connected to the mcu or the RPi (or I guess both if it's useful)?

My understanding is that Octoprint has some support for LCDs connected directly to the RPi. Klipper doesn't have support for LCDs connected to the micro-controller, but it's something that could be implemented (it's an item on the todo list mentioned above).

Hi Kevin, thanks for the reply. It sounds really interesting, I think I need to get myself a Pi and experiment.

The fan features I was thinking of with Repetier are, for the electronics, it can turn on a fan whenever either the stepper drivers are enabled or the heatbed is enabled, and for each hotend it can turn on the fan for the heatbreak whenever the heater is enabled and turn it off again once the temperature falls below a set temperature. It works well to keep things cool when necessary and keep the noise down when cooling isn't needed. Sounds like you already have something very similar.

Just FYI:

I did a bit of checking on jitter when using a Raspberry pi. The experiment I read about was using an RTOS called Ubito - an RTOS specifically for R. PI.

I can't find the exact discussion again, but the relevant detail is that they were testing jitter when pulsing a GPIO as rapidly as possible. They got over 1 mhz pulse rate, and at that rate there was occasional Jitter of about .5 microseconds (as the Pi is not designed for pure realtime, and it was probably saturating a bus). So then I wondered how much that amount of jitter would matter.

So I read here about the impact of jitter on motor power:
[www.researchgate.net]

So from my reading of that, perhaps that amount of jitter will not matter - at the pulse rates needed? I don't know.
I don't think an RTOS is needed for an auxillary Pi Zero - bare metal is enough for the simple task it needs to do.

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!