New experimental firmware: all kinematics in host

Hello, Kevin!
Thanks for your efforts.
Could you tell me - is there any doc or clue how to connect arduino part to drivers and thermisors?
for example, i've got an old machine with ramps & mega sandvich, prusa style (double Z motors), 2 thermistors, heaters for extruder and the bed, running Marlin.
what could my steps look like to make this machine run using Klipper?
pins declarations, thermistor-tables and all this low-level setup.

is there any plans to support Delta kinematics, may be?

Edited 1 time(s). Last edit at 12/19/2016 06:22PM by keedley.

Hi, I am playing around with klipper
I can upload the firmware to my RAMPS, run klippy host and connect with OctoPrint. I get the temperature readings for my hotend and bed. I also get position reading with M114. I checked endstop with M119 and got all triggered. So I think need to invert the endstops config. My endsops are all mechanical, so pull-up must be enabled, which correctly set by using '^' (^ar3 for X). But how to invert it, shall I use the combination of '!' and '^' ? This should be easily tried by changing the configuration, but whenever I changed the configuration and re-run the klippy host, I got this error message:

MCU error during connect
Traceback (most recent call last):
File "/home/pi/klipper/klippy/klippy.py", line 152, in connect
self.build_config()
File "/home/pi/klipper/klippy/klippy.py", line 130, in build_config
self.mcu.build_config()
File "/home/pi/klipper/klippy/mcu.py", line 444, in build_config
self._send_config()
File "/home/pi/klipper/klippy/mcu.py", line 459, in _send_config
raise error("Printer CRC does not match config")
error: Printer CRC does not match config

Any hints appreciated....

Quote
keedley
Hello, Kevin!
Thanks for your efforts.
Could you tell me - is there any doc or clue how to connect arduino part to drivers and thermisors?
for example, i've got an old machine with ramps & mega sandvich, prusa style (double Z motors), 2 thermistors, heaters for extruder and the bed, running Marlin.
what could my steps look like to make this machine run using Klipper?
pins declarations, thermistor-tables and all this low-level setup.

is there any plans to support Delta kinematics, may be?

Yes! See the installation document at: https://github.com/KevinOConnor/klipper/blob/master/docs/Installation.md. The example configuration file in the config/ directory should be similar to a standard RAMPS config. (Though, if the printer has two stepper motor drivers for the Z axis, then coding changes will be needed to support the hardware.)

The most recent Klipper code does support delta kinematics.

-Kevin

Quote
zungmann
Hi, I am playing around with klipper
I can upload the firmware to my RAMPS, run klippy host and connect with OctoPrint. I get the temperature readings for my hotend and bed. I also get position reading with M114. I checked endstop with M119 and got all triggered. So I think need to invert the endstops config. My endsops are all mechanical, so pull-up must be enabled, which correctly set by using '^' (^ar3 for X). But how to invert it, shall I use the combination of '!' and '^' ? This should be easily tried by changing the configuration, but whenever I changed the configuration and re-run the klippy host, I got this error message:

MCU error during connect
Traceback (most recent call last):
File "/home/pi/klipper/klippy/klippy.py", line 152, in connect
self.build_config()
File "/home/pi/klipper/klippy/klippy.py", line 130, in build_config
self.mcu.build_config()
File "/home/pi/klipper/klippy/mcu.py", line 444, in build_config
self._send_config()
File "/home/pi/klipper/klippy/mcu.py", line 459, in _send_config
raise error("Printer CRC does not match config")
error: Printer CRC does not match config

Any hints appreciated....

Yes - if the endstops have pullups and trigger low, then use ^ and ! (eg, ^!ar3).

To fix the above error, manually reset the microcontroller and then issue the "RESTART" command in the Octoprint terminal window. (The host should automatically reset the micro-controller on a config change, but that hasn't been implemented yet.)

Thanks. Manually restarting the microcontroller works and helps alot since whenever hit an 'unhandled communication error' in the OctoPrint, the connection to the host is terminated. Reconnect does not help, the problem remains there until restarting the microcontroller and restart the klippy host. I find this quite annoying.

Now I am stuck with error when homing the Z. It just run like 10th of second and stop and error.: Failed to home Z stepper....

Quote
zungmann
Thanks. Manually restarting the microcontroller works and helps alot since whenever hit an 'unhandled communication error' in the OctoPrint, the connection to the host is terminated. Reconnect does not help, the problem remains there until restarting the microcontroller and restart the klippy host. I find this quite annoying.

You can instruct OctoPrint to not disconnect on error by unchecking "Not only cancel ongoing prints but also disconnect on unhandled errors from the firmware" under Settions->Serial Connection.

Quote
zungmann
Now I am stuck with error when homing the Z. It just run like 10th of second and stop and error.: Failed to home Z stepper....

I'll take a look - can you email me ([email protected]) your config file and the log file (/tmp/klippy.log) containing the error.

-Kevin

Kevin,

I have to say, reading the thread and understanding at least some of the planning, consideration and work that has gone into this I'm both impressed and gracious. I intend try this out on my RAMPS/MEGA setup some time in the next couple of weeks. Seeing this inexpensive hardware being pushed to higher levels of performance is both impressive and good for the community at large.

Since it is python code, I should be able to easily run klippy directly on a laptop (or old netbook) instead of a RPi, correct? would I need a specific OS to support it?

Thanks again,
Joe

Edited 3 time(s). Last edit at 12/20/2016 11:45PM by obelisk79.

Quote
obelisk79
Kevin,

I have to say, reading the thread and understanding at least some of the planning, consideration and work that has gone into this I'm both impressed and gracious. I intend try this out on my RAMPS/MEGA setup some time in the next couple of weeks. Seeing this inexpensive hardware being pushed to higher levels of performance is both impressive and good for the community at large.

Since it is python code, I should be able to easily run klippy directly on a laptop (or old netbook) instead of a RPi, correct? would I need a specific OS to support it?

Thanks! There is nothing specific to the RPi in the host code (though there are a handful of unix/posix assumptions). However, I don't recommend using a desktop class machine as the host. Dedicating a low cost application processor (eg, an RPi) to the printer really improves the overall experience - in particular, it pairs well with OctoPrint which enables full web browser control of the printer, supports web cams, wireless networking (RPi3), etc.

-Kevin

This is an announcement for the Klipper v0.3.0 release. There have been many improvements since the initial release. For highlights see:
https://github.com/KevinOConnor/klipper/blob/master/docs/Features.md
and:
https://github.com/KevinOConnor/klipper/blob/master/docs/Releases.md

The biggest news in this release is support for printers with delta kinematics! Klipper works by using a host processor (such as a low-cost Raspberry Pi) to perform acceleration and kinematic calculations - the host determines the step times for all steppers, compresses them, transmits them to a micro-controller, and then the micro-controller executes the steps according to the provided schedule. The delta printer implementation proves that this design is scalable and flexible - the micro-controller knows nothing about the kinematics and still obtains excellent step rates on delta printers.

We're seeing very impressive results on a delta printer attached to a 16Mhz AVR micro-controller. On a delta printer with a step distance of 10um (100 steps per mm) this older AVR processor can comfortably reach a stepping rate sufficient to support printing speeds of
300mm/sec. It's worth noting that Klipper does not do kinematic approximations (no bresenham algorithm, no segmenting of moves into small chunks) nor does it do step multiplication (no double stepping, quad stepping, etc.). Instead, Klipper calculates the exact time for each step and every step. This means even at very high speeds the step timing will be precise; this helps limit vibrations and noise.

To be clear, Klipper also supports ARM processors (in particular the Arduino Due). Calculations indicate a Due could obtain three times the printing rate of a 16Mhz AVR. The Klipper architecture makes it easier to port to new micro-controllers, and once ported all of Klipper's functionality (eg, delta support, pressure advance, etc.) becomes available.

To try running Klipper, start by reading the installation document:
https://github.com/KevinOConnor/klipper/blob/master/docs/Installation.md

This release also includes a number of documentation updates aimed at developers (including details on firmware commands and protocol). See:
https://github.com/KevinOConnor/klipper/blob/master/docs/Overview.md

Quote
KevinOConnor

Quote
zungmann
Thanks. Manually restarting the microcontroller works and helps alot since whenever hit an 'unhandled communication error' in the OctoPrint, the connection to the host is terminated. Reconnect does not help, the problem remains there until restarting the microcontroller and restart the klippy host. I find this quite annoying.

You can instruct OctoPrint to not disconnect on error by unchecking "Not only cancel ongoing prints but also disconnect on unhandled errors from the firmware" under Settions->Serial Connection.

Quote
zungmann
Now I am stuck with error when homing the Z. It just run like 10th of second and stop and error.: Failed to home Z stepper....

I'll take a look - can you email me ([email protected]) your config file and the log file (/tmp/klippy.log) containing the error.

-Kevin

Hi Kevin,
I sent you the config and log.

Thanks.

Quote
KevinOConnor
It's worth noting that Klipper does not do kinematic approximations (no bresenham algorithm, no segmenting of moves into small chunks) nor does it do step multiplication (no double stepping, quad stepping, etc.). Instead, Klipper calculates the exact time for each step and every step. This means even at very high speeds the step timing will be precise; this helps limit vibrations and noise.

It's good to see Klipper doing precise step generation for deltas without segementing moves or using Bresenham - just as RepRapFirmware has done for the last two years. You don't need to put the kinematics in the host to achieve this, just a decent ARM processor.

There is no disadvantage to using double, quad etc. stepping provided that they only kick in at high enough step rates. Stepper drivers use a chopper frequency of about 40kHz and the step pulse rate needs to be several times lower than that for the motors to notice the timing of individual microsteps.

---

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].

Quote
dc42
You don't need to put the kinematics in the host to achieve this, just a decent ARM processor.

or you put decent software in allready obtained hardware instead of buying new.

thumbs up from me for this amazing project.

Quote
dc42
There is no disadvantage to using double, quad etc. stepping provided that they only kick in at high enough step rates. Stepper drivers use a chopper frequency of about 40kHz and the step pulse rate needs to be several times lower than that for the motors to notice the timing of individual microsteps.

Interesting. Thanks.

I'm curious why you say "several times lower". I agree that if the stepper motor driver is using a 25us PWM cycle time then scheduling steps with a finer granularity than 25us is going to provide marginal benefit. However, in that situation I'd think one really would want to get each step executed with a deviation no larger than 25us from its ideal time.

After got several fixes I finally managed to print my fave test: Swan with Klipper using my Prusa Steel. Overall looks pretty good, some small blobs at sharp edges but not all layers which I did not get using other firmware (the same gcode). One other thing: I noticed high pitch humming during extruder heating toward end of target temp and few occasions during print.

I will post the print picture later.

Quote
zungmann
After got several fixes I finally managed to print my fave test: Swan with Klipper using my Prusa Steel. Overall looks pretty good, some small blobs at sharp edges but not all layers which I did not get using other firmware (the same gcode). One other thing: I noticed high pitch humming during extruder heating toward end of target temp and few occasions during print.

I will post the print picture later.

As promised:


PLA, 0.25 mm layer height, nozzle 0.8 mm, printing speed 55 mm/s, 100 mm/s travel (capped by the printed config). I did not see any movement glitch during printing. Heater temp also stable @ 195C using the supplied PID parameters, not noticed any large temp swing.

Quote
zungmann
After got several fixes I finally managed to print my fave test: Swan with Klipper using my Prusa Steel. Overall looks pretty good, some small blobs at sharp edges but not all layers which I did not get using other firmware (the same gcode).

Thanks for testing!

I can't see the blobs in the picture, but if you're seeing more blobs at sharp edges on klipper (vs other firmwares) then I suspect it's due to the cornering algorithm. Klipper uses a cornering algorithm based on "centripetal acceleration" - the same algorithm used in GRBL and Smoothieware. The original author's description of it is pretty detailed. In contrast, several other firmwares implement cornering based on limiting the jerk of the individual stepper motors. The end result is that Klipper is likely going to be more conservative on cornering speed at sharp edges, and I suspect that the longer time the head spent traveling these corners resulted is slightly more blobbing.

I much prefer the "centripetal" cornering algorithm as I find that the rapid jerks on sharp edges of other firmwares disturbs filament already put down. In particular, I was unable to get good first layer adhesion on prints with sharp edges when I used Marlin. (In contrast, on Klipper, I get great first layer adhesion - to the point where I can now print very complex first layers at 100mm/sec in PLA on heated glass without failure - a huge improvement considering I couldn't get those types of prints to adhere at any speed on that printer back when I used Marlin.)

I can recommend two ways to proceed:

In earlier configs you sent me, it looks like you had the acceleration set to 1000mm/s^2. That's a bit lower than I typically see. The centripetal acceleration cornering scheme uses the moves' acceleration when determining maximum cornering speed. If you choose 1000 just to be conservative then you may want to try a more common acceleration of 3000. If you really want to accelerate the motors no faster than 1000mm/s^2 then I'd try increasing junction_deviation in the Klipper config from its default of 0.02 to 0.06.

The other method to reduce blobbing is to enable and tune pressure advance. Alas, I don't know of a good guide for tuning pressure advance. A typical value is between 0.05 and 0.15 though. I've nearly eliminated ooze on my printer; I set pressure_advance to 0.07.

Quote
zungmann
One other thing: I noticed high pitch humming during extruder heating toward end of target temp and few occasions during print.

I don't know why that would be. Klipper uses a pretty standard PID algorithm and it doesn't toggle the heater more than 10 times a second. There's a bunch of info we can grab with the logs though, so I'm sure we can track it down. I'll contact you via email.

Quote
zungmann
100 mm/s travel (capped by the printed config).

FYI, with the stepper precision you had in the config you sent me, the MCU (16Mhz AVR) should be able to reach a stepping rate equivalent of 300mm/s without issue.

Edited 1 time(s). Last edit at 01/04/2017 10:59AM by KevinOConnor.

Quote
KevinOConnor
Thanks for testing!

I can't see the blobs in the picture, but if you're seeing more blobs at sharp edges on klipper (vs other firmwares) then I suspect it's due to the cornering algorithm. Klipper uses a cornering algorithm based on "centripetal acceleration" - the same algorithm used in GRBL and Smoothieware. The original author's description of it is pretty detailed. In contrast, several other firmwares implement cornering based on limiting the jerk of the individual stepper motors. The end result is that Klipper is likely going to be more conservative on cornering speed at sharp edges, and I suspect that the longer time the head spent traveling these corners resulted is slightly more blobbing.

The blobs are in the tip of the wings, so not shown in that picture. Probably these two pictures give an idea:

There are some excess of extrusion, not all the layers though. Whereas using Teacup I before I got this:

I got clean tip.

Quote
KevinOConnor
I much prefer the "centripetal" cornering algorithm as I find that the rapid jerks on sharp edges of other firmwares disturbs filament already put down. In particular, I was unable to get good first layer adhesion on prints with sharp edges when I used Marlin. (In contrast, on Klipper, I get great first layer adhesion - to the point where I can now print very complex first layers at 100mm/sec in PLA on heated glass without failure - a huge improvement considering I couldn't get those types of prints to adhere at any speed on that printer back when I used Marlin.)

I can recommend two ways to proceed:

In earlier configs you sent me, it looks like you had the acceleration set to 1000mm/s^2. That's a bit lower than I typically see. The centripetal acceleration cornering scheme uses the moves' acceleration when determining maximum cornering speed. If you choose 1000 just to be conservative then you may want to try a more common acceleration of 3000. If you really want to accelerate the motors no faster than 1000mm/s^2 then I'd try increasing junction_deviation in the Klipper config from its default of 0.02 to 0.06.

I think so. After that first print, I change my configuration of junction_deviation from default example of 0.02 to 0.1 and gave better result, but still a few blobs seen. I will increase my acceleration to 3000 and run another print.

Quote
KevinOConnor
The other method to reduce blobbing is to enable and tune pressure advance. Alas, I don't know of a good guide for tuning pressure advance. A typical value is between 0.05 and 0.15 though. I've nearly eliminated ooze on my printer; I set pressure_advance to 0.07.

Quote
zungmann
One other thing: I noticed high pitch humming during extruder heating toward end of target temp and few occasions during print.

I don't know why that would be. Klipper uses a pretty standard PID algorithm and it doesn't toggle the heater more than 10 times a second. There's a bunch of info we can grab with the logs though, so I'm sure we can track it down. I'll contact you via email.

Quote
zungmann
100 mm/s travel (capped by the printed config).

FYI, with the stepper precision you had in the config you sent me, the MCU (16Mhz AVR) should be able to reach a stepping rate equivalent of 300mm/s without issue.

There are some print tests with different config I want to try. Will let you know later....

Very interesting project. I'd love to test it out. Any idea when corexy might be implemented?

Quote
chromedome1964
Very interesting project. I'd love to test it out. Any idea when corexy might be implemented?

Implementing corexy should not be very difficult. If you or someone else has the hardware and is willing to run tests, I'll code it up. If interested, send me an email or PM.

-Kevin

Hi Kevin,

Glad to hear new features, would love to test it again.

One question: is there a way to limit the 'power' of the bed heater? My current setup for bed is 12V and using 24V so my config limit the current to say 1/4 of pull power (255).

Quote
zungmann
Hi Kevin,

Glad to hear new features, would love to test it again.

One question: is there a way to limit the 'power' of the bed heater? My current setup for bed is 12V and using 24V so my config limit the current to say 1/4 of pull power (255).

Great!

There wasn't a way to limit power, but I just added the feature. Grab the latest code and look at "max_power" in the heater sections of the example.cfg file. (Note that the heater pwm uses a "software pwm" implementation with a cycle time of 100ms, which means a "max_power: 0.25" setting would still allow the heater to be enabled for periods of up to 25ms. It's not difficult to support hardware pwm if you need that though.)

-Kevin

Hi Kevin,

I tested the pressure.advance feature. It was jittering a lot, especially on beginning of print. There were in many ocassions during print. I think or guess it happens on low speed printing.

Quote
zungmann
Hi Kevin,

I tested the pressure.advance feature. It was jittering a lot, especially on beginning of print. There were in many ocassions during print. I think or guess it happens on low speed printing.

Thanks. What did you set the pressure_advance to? Can you send me the log of a print?

-Kevin

Great project Kevin, I'd love to test it as well, seems a great way forward.

Would it be difficult to add support for thermocouples? (e.g AD595, À la Marlin "TEMP_SENSOR -1")

Quote
Swift
Great project Kevin, I'd love to test it as well, seems a great way forward.

Would it be difficult to add support for thermocouples? (e.g AD595, À la Marlin "TEMP_SENSOR -1")

It's not difficult to add. If you have the hardware and are willing to run tests, I'll code it up. Send me a PM or email and I'll send directions for running a test version of the code.

-Kevin

pressure_advance is 0.07 and lookahead_time 10ms

here you go the log.

Quote
zungmann
pressure_advance is 0.07 and lookahead_time 10ms

here you go the log.

Thanks.

My guess is that a pressure_advance of 0.07 is a bit high for a direct drive extruder with a nozzle diameter of 0.6mm.

Pressure advance does two useful things - it reduces blobbing during cornering and it reduces ooze during non-extrude moves. What's changed since the last time you tested is that I added the pressure_advance_lookahead_time parameter and its default is effectively smaller than it used to be. (I did this because I found that the previous settings would help with ooze, but didn't help as much with blobbing on cornering.)

You could try increasing pressure_advance_lookahead_time, but really I think the best thing would be to tune pressure_advance for your printer. I wish I had a good guide I could point to for tuning pressure advance. I'll try with a description here - let me know if you have any questions.

Before tuning pressure advance, I suggest returning junction_deviation, pid_integral_max, max_extrude_only_velocity, and max_extrude_only_accel to their defaults as the configured values from your log are high.

Then set both pressure_advance_lookahead_time and pressure_advance to 0.0. Then print at least 10 layers of a large hollow cube (eg, 40mm per side) at high speed (eg, 100mm/s). What many people see here is blobbing occurring at the corners - extra filament at the corner in the direction the head travels followed by a lack of filament on the side immediately after that corner. This is the result of pressure building up in the extruder being released as a blob when the head slows down to corner.

The next step is to slowly increase pressure_advance (eg, to 0.05) while keeping pressure_advance_lookahead_time at 0.0 and reprint the test object - the goal is to attempt to eliminate the blobbing during cornering. (With pressure advance, the extruder will retract when the head slows down, thus countering the pressure buildup and ideally eliminate the blobbing.) If a test run is done with a pressure_advance setting that is too high, one typically sees blobbing on the other side of the corner (too much filament is retracted during slow down and then too much filament is extruded during the following speed up after cornering). The goal is to find the smallest pressure_advance value that results in good quality corners. Typical pressure_advance values are between 0.05 and 0.2 (the high end usually only with bowden extruders).

Once a good pressure_advance value is found, I'd return pressure_advance_lookahead_time to its default (0.010). This parameter controls how far in advance the code will look to see if a head slow-down is immediately followed by a speed-up - it reduces pointless pressure changes in the head. It's possible to tune this - higher values will reduce pressure changes (and reduce possible filament "jitter") at the expense of permitting more blobbing at cornering. I found 10ms worked well on my printer - I didn't notice any change in corner quality and it significantly reduced the amount of retractions.

Finally, once pressure_advance is tuned, I still configure a small retract value in the slicer (eg, 0.75mm), I disable z-lift on retract, and I like slic3r's wipe on retract option. I've basically eliminated ooze on my prints.

Let me know if you have any questions.
-Kevin

Quote
KevinOConnor

Quote
chromedome1964
Very interesting project. I'd love to test it out. Any idea when corexy might be implemented?

Implementing corexy should not be very difficult. If you or someone else has the hardware and is willing to run tests, I'll code it up. If interested, send me an email or PM.

-Kevin

Hi,

I'm also interested to test on core xy, opened an issue on github too: [github.com]

Regards,
TH

Is the Raspberry Pi Zero powerful enough to run Klipper without issue? I'm thinking about pairing this up with the new Zero W and my RAMPS 1.4

Specs below:

1GHz, single-core CPU
512MB RAM
Mini-HDMI port
Micro-USB On-The-Go port
Micro-USB power
HAT-compatible 40-pin header
Composite video and reset headers
CSI camera connector
802.11n wireless LAN
Bluetooth 4.0

Edited 1 time(s). Last edit at 03/13/2017 04:39PM by obelisk79.

Quote
obelisk79
Is the Raspberry Pi Zero powerful enough to run Klipper without issue? I'm thinking about pairing this up with the new Zero W and my RAMPS 1.4

As I understand it, the Zero has the same processor as the RPi1 (though, clocked a little faster). That processor is powerful enough to run Klipper, but I found it wasn't sufficient for Octoprint. I found that some prints with lots of tiny g-code moves could result in print stalls. Add a webcam and the processor was really stressed.

I don't have first hand experience with the Zero and it is possible that the higher clock rate would help. As it stands though, I'd recommend sticking with an RPi2 or RPi3 (the processors on these versions are dramatically faster than the original).

-Kevin