New experimental firmware: all kinematics in host

Interesting piece of software and concept.
Unfortunately I don't have a printer to be used as testprinter and I don't like to tinker with my production printers so this is just my thoughts about klipper.

Comparing the list of supported G-codes with my latest prints sliced using Simplify3D only two G-codes fall out.

The first was M84-Disable steppers and that is easily fixed because M18 is an alternative. (alias code like G0 and G1)

The other code that I found missing was G29. I have seen that some experimental code is supplied as alternative but for me the G29 command is an essential code because sometimes I print on clean glass and other prints is on blue tape. I use a BL-touch probe.

So a before G29 is implemented I won't change to klipper.

Have fun
Niels

Another observation when looking through example.cfg

The diameters of the nozzle and filament is burried in the cfg file and as I understand those parameters is used in the print process.

When I change the nozzle I then have to log-on the Pi and alter the printer.cfg with actual parameters.

I would instead like an extra parameter to the FIRMWARE_RESTART command so the process can be done from the Octoprint terminal.

Example: FIRMWARE_RESTART nozzle03mm.cfg

If FIRMWARE_RESTART is given without parameters the default printer.cfg is loaded.

An alternative could be a M-code with the parameters.

Have fun
Niels

Heya, so I recently moved from a MKS base to RAMPS, and am currently using 2xA4988 (1/16 step) and 2xDRV8825 (1/32 step).

I've read that with an 8-bit Arduino, it'll be hard to keep up if I used 4xDRV8825 on all of my motors.

Would using klipper allow me to use more stepper drivers, or even something like the LV8729 (that does up to 1/128)

It depends on your printer's steps per mm (or inch) and speeds you want to print. Klipper doc says that 8bit AVR can do 100k steps when moving all three steppers.

For example, assuming 20mm pulleys, 128micro steps* 200 (steps in one turn aka 1.8deg stepper) = 25600 steps per 20mm of travel. You probably want to travel at 40mm/s which is 2*25600= 51200steps/s for one stepper. Considering that at least two steppers will work in tandem that's probably your upper limit.

32 microsteps should work up to about 160mm/s (with above specs). 0.9deg stepper will cut calculated speeds in half.

Edited 3 time(s). Last edit at 02/13/2018 10:27AM by newbob.

Quote
newbob
For example, assuming 20mm pulleys, 128micro steps* 200 (steps in one turn aka 1.8deg stepper) = 25600 steps per 20mm of travel. You probably want to travel at 40mm/s which is 2*25600= 51200steps/s for one stepper. Considering that at least two steppers will work in tandem that's probably your upper limit.

Whoa, thanks for the explanation. Guess it seems I will have to look into how I can add more MCUs...

Good afternoon KevinOConnor.
Do you plan to modify the Klipper firmware under the STM32 controller (F1 / F4 / F7) ?? (combine host + client)
That would be very cool. I think a lot of people would appreciate it.
Your firmware is very good and shows very good quality print. But buying it for BBB + replicate is very expensive.
Is it possible to make a versatile Klipper firmware for different STM32 boards with flexible pin configuration and print configuration? Or at least under Nuсleo or Discovery?
Sorry for my Google English.

Quote
Tomcat NN
Good afternoon KevinOConnor.
Do you plan to modify the Klipper firmware under the STM32 controller (F1 / F4 / F7) ?? (combine host + client)
That would be very cool. I think a lot of people would appreciate it.
Your firmware is very good and shows very good quality print. But buying it for BBB + replicate is very expensive.
Is it possible to make a versatile Klipper firmware for different STM32 boards with flexible pin configuration and print configuration? Or at least under Nuсleo or Discovery?
Sorry for my Google English.

FYI, there was some discussion about this on github: https://github.com/KevinOConnor/klipper/issues/137

-Kevin

Question, not sure its been asked, ordered a laser, how would one hook that up via Ramps, and still use Klipper?

Quote
kdodman
Question, not sure its been asked, ordered a laser, how would one hook that up via Ramps, and still use Klipper?

I suspect some development work would be required before one could use Klipper to control a laser cutter. See github issue #133 for the details.

-Kevin

Been using klipper with a laser for a few days now. Working well. I have not run the laser with "normal" marlin firmware, so I cant tell you if there is a difference between them.
I can request that you add G2 and G3 moves, as software tends to make extensive use of those for cutting and engraving,

Quote
kdodman
Been using klipper with a laser for a few days now. Working well. I have not run the laser with "normal" marlin firmware, so I cant tell you if there is a difference between them.
I can request that you add G2 and G3 moves, as software tends to make extensive use of those for cutting and engraving,

Support for G2 and G3 was raised on github a couple of weeks ago: https://github.com/KevinOConnor/klipper/issues/202

-Kevin

Hello all, so I picked up another RAMPS board, and am planning to run two MCUs along with LV8729 stepper drivers.

To maximize the stepping I can use, would it be possible to split the duties of X and Y to two different RAMPS boards? I took a look at the sample multi mcu config file on GitHub and it notes that X and Y should be in the same MCU.

Is this a strict requirement? Because I would like to see how high I can take the stepping to. (LV8729 supports up to 1/128)

Thanks.

Am I right in assuming the issue with splitting X and Y into different MCU's relates to potential step timing issues between the MCUs possibly inducing slight positional accuracy problems? It would be interesting to see how such a configuration would perform in real-world setups though.

teikjoon, if you successfully run such a configuration please let us know.

Quote
teikjoon
Hello all, so I picked up another RAMPS board, and am planning to run two MCUs along with LV8729 stepper drivers.

To maximize the stepping I can use, would it be possible to split the duties of X and Y to two different RAMPS boards? I took a look at the sample multi mcu config file on GitHub and it notes that X and Y should be in the same MCU.

Is this a strict requirement? Because I would like to see how high I can take the stepping to. (LV8729 supports up to 1/128)

Thanks.

On a cartesian robot, one can configure the X and Y on different MCUs. (One cannot, however, do that currently for a corexy robot - this is due to the requirement that an endstop signal be on the same MCU as the steppers the endstop stops during a homing operation.)

If you are using a cartesian, and want to try it out, you'll have to designate one MCU as the primary (clock master) - just choose any MCU for that - it wont really matter which. Be aware that the slight timing differences introduced from clock synchronization may reduce print quality. Feel free to test - I'm certainly curious what the results would be.

-Kevin

Quote
KevinOConnor
(One cannot, however, do that currently for a corexy robot - this is due to the requirement that an endstop signal be on the same MCU as the steppers the endstop stops during a homing operation.)

-Kevin

Kevin,

I'm at work right now so can't really dig around and check the code at the moment, but could that requirement be changed to allow such a setup? I don't really have a need for it, but the idea is intriguing.

-Joe

Quote
obelisk79

Quote
KevinOConnor
(One cannot, however, do that currently for a corexy robot - this is due to the requirement that an endstop signal be on the same MCU as the steppers the endstop stops during a homing operation.)

I'm at work right now so can't really dig around and check the code at the moment, but could that requirement be changed to allow such a setup? I don't really have a need for it, but the idea is intriguing.

Sure - @hg42 did this already (see his posts on page 9 of this thread). It does require some code changes and it does require wiring the endstop pins a particular way.

-Kevin

Quote
KevinOConnor
On a cartesian robot, one can configure the X and Y on different MCUs. (One cannot, however, do that currently for a corexy robot - this is due to the requirement that an endstop signal be on the same MCU as the steppers the endstop stops during a homing operation.)

If you are using a cartesian, and want to try it out, you'll have to designate one MCU as the primary (clock master) - just choose any MCU for that - it wont really matter which. Be aware that the slight timing differences introduced from clock synchronization may reduce print quality. Feel free to test - I'm certainly curious what the results would be.

-Kevin

Alright, I'll set up the hardware and give it a go

I've been thinking what would be an optimal klipper controller board. Due to timing requirements, end stops, stepper drivers, MCU controlling Enable, Dir and Step, digitalWrite and comm link (UART) to rpi would have to be on the controller,. Sdcard reader, display, rotary encoder functionality should be on rpi as well as PWM (fan, heat), ADC (temperature)

Would you agree? Are there be any advantages on controlling heaters and measuring temperature on a controller rather than rpi?

Quote
newbob
Are there be any advantages on controlling heaters and measuring temperature on a controller rather than rpi?

In theory the rpi is not real time, and a control loop should run regularly. But especially for temperatures that is no problem.

The bigger issue is that you can not connect the Heater directly to a rpi GPIO pin. So you will need some kind of board. PWM and ADC are hardware component in the µC so this does not put a lot of load to the µC therefore the usual solution is to put them there.

But you can use a board that converts an PWM signal into a High power switch signal with the rpi. There are also boards available that have a connector for the temperature sensor and a chip that can then be read from SPI. I found very cheap boards like that on ebay from china.

The software side is then another issue. You need a Software on the host that can talk to your controller (Klipper - Klippy) but the host software then also need to create the PWM signal and read the Temperature value and do the PID computation. There will be some work there. But that might be regarding and open up new possibilities...

You're right, a shield would be needed on rpi. There are plenty of GPIO shields for rpi and, like you say, standalone MOSFET boards so hardware should not be difficult. Probably software is the only bit that is missing.

EDIT: added benefit on doing PWM and ADC on rpi would be, of course, less io between rpi and controller and faster updates. Another would be cost savings when using multiple controller boards as they would not have extraneous mosfets. Negative would be the need for some kind of watchdog to make sure that PWM is off in case of failure of control software, OS, or ADC readout.

Edited 2 time(s). Last edit at 03/23/2018 09:41AM by newbob.

The 0.6.0 version of Klipper has now been released. For more information on the release, please see:

https://github.com/KevinOConnor/klipper/blob/master/docs/Releases.md

There is now a Patreon page for those who want to donate to Klipper:

https://www.patreon.com/koconnor


New in this release:
* Enhanced heater and thermistor hardware failure checks
* Support for Z probes
* Initial support for automatic parameter calibration on deltas (via a new delta_calibrate command)
* Initial support for bed tilt compensation (via bed_tilt_calibrate command)
* Initial support for "safe homing" and homing overrides
* Initial support for displaying status on RepRapDiscount style 2004 and 12864 displays
* New multi-extruder improvements: Support for shared heaters, Initial support for dual carriages
* Support for configuring multiple steppers per axis (eg, dual Z)
* Support for custom digital and pwm output pins (with a new SET_PIN command)
* Initial support for a "virtual sdcard" that allows printing directly from Klipper (helps on machines too slow to run OctoPrint well)
* Support for setting different arm lengths on each tower of a delta
* Support for G-Code M220/M221 commands (speed factor override / extrude factor override)
* Several documentation updates.
* Initial support for continuous integration testing on all github commits
* Several bug fixes and code cleanups

For further information on Klipper, please see:

https://github.com/KevinOConnor/klipper

What is the new Set_Pin command? is it any different from the old one?

Quote
kdodman
What is the new Set_Pin command? is it any different from the old one?

It's new in the sense that it wasn't in the previous Klipper release. It's behavior in Klipper hasn't changed since it was introduced. There's some brief documentation on Klipper commands at: https://github.com/KevinOConnor/klipper/blob/master/docs/G-Codes.md

-Kevin

I understand that in Klipper position is described by distance and time.

What is the resolution of the time variable?
I would imagine that it depends on speed of the controller - is it derived from max velocity? Can you have different interval for each stepper?
Does position depend on given point in time or time on given position?
What happens if steppers resolution does not allow to achieve certain position at certain time?


As you can see I'm quite confused. Any answer to above would be helpful thank you.

Quote
rmichael_cd
I understand that in Klipper position is described by distance and time.

What is the resolution of the time variable?
I would imagine that it depends on speed of the controller - is it derived from max velocity? Can you have different interval for each stepper?
Does position depend on given point in time or time on given position?
What happens if steppers resolution does not allow to achieve certain position at certain time?

The kinematics code stores both time and positions as 64bit "double precision" floating point values. There's some information on how this is handled at: https://github.com/KevinOConnor/klipper/blob/master/docs/Code_Overview.md

In Klipper motion is implemented by calculating when each stepper should step and then commanding them to do so at (nearly) those times. Thus, the kinematics aren't calculated around the limits of the hardware; instead, the hardware follows the ideal kinematics as closely as it can.

So, for arguments sake, if an X stepper had a step distance of one millimeter, and a g-code command moved the X axis from position 3.2 to 3.3 then Klipper would not schedule a step at all. But, should it then be command to move from position 3.3 to 4.2 then one step would be scheduled. It would be scheduled at the ideal time that the axis was closer to step position 4 than step position 3. (That is, the kinematic/velocity equations would be "solved" to find the time that the stepper axis is at position 3.5 - the resulting time would be the ideal step time for that stepper.)

-Kevin

Thanks for the explanation. Your first few posts to this thread were enlightening as well - such as that compression algorithm is lossy.
Forgetting about compression for a moment, where in the code is the time rounded up to the nearest tick?

How well do you think would Klipper work with 250kHz (step) clock on the MCU (controller with shift registers connected to 10 steppers)?

EDIT: I think I'm getting there. CLOCK_FREQ is hardcoded within klipper/src/{controller}/Kconfig. Presumably this variable is sent to host via DECL_COMMAND

Edited 3 time(s). Last edit at 05/30/2018 02:28PM by rmichael_cd.

Quote
rmichael_cd
Thanks for the explanation. Your first few posts to this thread were enlightening as well - such as that compression algorithm is lossy.
Forgetting about compression for a moment, where in the code is the time rounded up to the nearest tick?

You'll want to walk through the "code flow of a move command" as described at: https://github.com/KevinOConnor/klipper/blob/master/docs/Code_Overview.md#code-flow-of-a-move-command. The conversion to clock time is done as part of stepcompress.c:stepcompress_push_const().

Quote

How well do you think would Klipper work with 250kHz (step) clock on the MCU (controller with shift registers connected to 10 steppers)?

The Klipper host code is designed to work with the Klipper micro-controller code. The Klipper micro-controller code doesn't use a fixed frequency update mechanism - instead the code is designed to work in a "tickless" manner - the code uses "software timers" that are scheduled to run at certain times, and a hardware irq is scheduled accordingly if needed.

We've ported the Klipper micro-controller code to a number of platforms. So, it may be possible to port it to the architecture you have in mind.

Quote

EDIT: I think I'm getting there. CLOCK_FREQ is hardcoded within klipper/src/{controller}/Kconfig. Presumably this variable is sent to host via DECL_COMMAND

Yes, each micro-controller declares its clock frequency via the DECL_CONSTANT() macro. For example, see the src/avr/timer.c.

-Kevin

I am interested in boundary conditions a point at which point frequency of the controller would start affecting accuracy or break it's assumptions. I am trying to read the code but it's going to take some time as I learn as I go. So far it seems to me that the code is not expecting to have less than one tick per 1us.

Hello Kevin,

I know you are on patreon now and I'm sorry I can't (at least for now) support your work.
The above being said can you shed some light (if possible) in math peasant language on the new iterative solver stuff?

Thank you,
TH

Quote
TinHead
The above being said can you shed some light (if possible) in math peasant language on the new iterative solver stuff?

The "iterative solver" is a recent change to the way Klipper calculates step times in the host software. It's a new way of calculating the same stepper timings - it should be imperceptible to
users of the software. The main reason for making the change is that it significantly reduces the amount of complex math in Klipper.

The Klipper host software calculates precise step times for all the steppers using the kinematic formulas for the particular printer (eg, delta, cartesian, corexy). It turns out that some kinematics (eg, delta) require some pretty complex math to determine precisely what time is the ideal step time. That is, the formula for taking a stepper position and calculating the time the stepper should be at that position:

time = stepper_position_to_time(position)

can be very complex. It turns out, however, that the inverse function:

position = stepper_time_to_position(time)

is generally trivial to calculate. In particular, it's just a simple extension of the basic kinematic formulas for the printer:

position = stepper_position_from_coord(move_coord_from_distance(move_calc_distance(time)))

where stepper_position_from_coord() takes a cartesian coordinate and converts it into a stepper position. There's more details of this in the Klipper Kinematics document:

https://github.com/KevinOConnor/klipper/blob/master/docs/Kinematics.md

The key idea of the "iterative solver" is that it allows the code to automatically calculate a time given a position from the formula for a position given a time. That is, we don't need to implement the complex math because the computer can figure it out itself. The algorithm to do this is actually pretty straight forward - the code guesses a likely time, checks if the calculated position for that time matches the desired position, and then keeps guessing until a time is found that matches the desired position. Once that time is found, then we know the ideal step time and can schedule the stepper to step at that time. The guessed times and calculated positions are used to improve future guesses so that the code rapidly converges to an accurate solution.

It turns out that, in practice, we can almost always guess a nearly perfect time by using the last step time as a guide (the steppers don't have extreme velocity changes). As a result, the overall host cpu overhead of this iterative method is about the same as the previous method that used lots of complex math.

Finally, because this method simplifies the kinematics math, it is hoped that the code will be more accessible to those wishing to experiment with different kinematics.

Cheers,
-Kevin