New experimental firmware: all kinematics in host

Re: New experimental firmware: all kinematics in host

Anonymous User — Thu, 31 Jan 2019 04:09:09 -0500

@KevinOConnor, the described from you "contact methods" are not ok. Also you tend to close issues on Github without they to be solved etc.

As it was stated earlier, there are still problems with Klipper, currently when issues: DELTA_CALIBRATE command, I'm getting this respond:

// probe at 0.000,-0.000 is z=387.459954

Yesterday, it did disjoint the arm of a switch I use as a Z-probe etc.

Before begin to use Klipper, I was using Repetier, had some issues with it. Anyone tested the latest versions of Repetier or Marlin, which might be better for Delta 3D printer ?

Re: New experimental firmware: all kinematics in host

KevinOConnor — Tue, 29 Jan 2019 22:02:27 -0500

FYI, I don't monitor this forum much - for Klipper topics it is best to use the contact methods described at: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

@kdodman - for sensorless homing you may wish to check out: https://github.com/KevinOConnor/klipper/blob/master/docs/Sensorless_Homing.md

-Kevin

Re: New experimental firmware: all kinematics in host

JustAnotherOne — Tue, 29 Jan 2019 15:33:38 -0500

@kdodman the TMC2130 need a certain minimum speed for the homing to work. So if the axis moves to slowly, then the back EMF, that is used for the homing, is a too weak signal.

Re: New experimental firmware: all kinematics in host

Anonymous User — Tue, 29 Jan 2019 12:49:01 -0500

@kdodman, not so sure about TMC2130, probably you have to test it by yourself. On Zaxis quite unlikely those to fit ... . From what I read about Z-axis not recommendable at all to use senselessness homing. But probably someone with more experience can share their thoughts too. I use LV8729, not as silent as TMC2208, still they work fine.

@KevinOConnor, again problems:

DELTA_CALIBRATE

18:12:27.946: // Internal error on command:"PROBE"
18:12:27.946: // Once the underlying issue is corrected, use the
18:12:27.947: // "FIRMWARE_RESTART" command to reset the firmware, reload the
18:12:27.947: // config, and restart the host software.
18:12:27.947: // Printer is shutdown

Re: New experimental firmware: all kinematics in host

kdodman — Fri, 25 Jan 2019 12:18:59 -0500

Would it be worth getting TMC2130 drivers and using sensorless homing? Specifically on the Zaxis

Re: New experimental firmware: all kinematics in host

sudarshan — Mon, 10 Dec 2018 00:58:35 -0500

I wish to make a tool changer type printer.
Is there any cheap board (below 100$) which I can use?
Would klipper be helpful to substitute the lake of 32bit board thereof.

Kindly suggest.

Re: New experimental firmware: all kinematics in host

Nitram — Mon, 29 Oct 2018 16:39:30 -0400

Thanks @KevinOConnor

I will try the mailing list the next time...

/Martin

Re: New experimental firmware: all kinematics in host

KevinOConnor — Mon, 29 Oct 2018 12:02:57 -0400

Quote
Nitram
@KevinOConnor Is it possible to use an Arduino nano with an ATmega328P (old bootloader) as an aux-board

The atmega328p is basically the same as the atmega328 so it should work fine. I added the 328p to the "make menuconfig" selection (just so avrdude doesn't complain when flashing). Grab the latest Klipper code to use it.

Separately, I don't monitor this forum much - for Klipper topics it is best to use the contact methods described at: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

Cheers,
-Kevin

Re: New experimental firmware: all kinematics in host

Nitram — Sun, 28 Oct 2018 11:40:50 -0400

@KevinOConnor Is it possible to use an Arduino nano with an ATmega328P (old bootloader) as an aux-board

Why you might think...
Well I have one lying around and I need some analog pins for temperature readings...

/Martin

Re: New experimental firmware: all kinematics in host

Anonymous User — Wed, 24 Oct 2018 14:15:02 -0400

Again issue with Klipper. This time using Arduino Due (SAM3X8E):

MCU 'mcu' shutdown: Stepper too far in past
This generally occurs when the micro-controller has been
requested to step at a rate higher than it is capable of
obtaining.

F6000 suppose to be ok ?

Also would it be possible to add alternative commands ? For example, instead of RESTART and FIRMWARE_RESTART etc. I would prefer: RESET, FIRMWARE_RESET etc.

[attachment 107757 klippy.zip]

Re: New experimental firmware: all kinematics in host

Anonymous User — Sun, 09 Sep 2018 11:53:23 -0400

Thank you about the clarification, if understand correctly the requested speed exceeded the MCU capabilities, as well as it cancelled the print. It was good that it was on the beginning, so no much material was lost, but in such case shouldn’t there be some error checks, to prevent cancelling of prints and loss of material and time ?

Regarding GitHub, as I stated there, my accounts were deleted and I submitted a complain with the Bulgarian authorities regarding their practices. There many problems with GitHub but they are unwilling to change their practices etc.

Re: New experimental firmware: all kinematics in host

KevinOConnor — Sun, 09 Sep 2018 10:51:20 -0400

Quote
Dimitar
Just experienced another issue with Klipper:

MCU 'mcu' shutdown: Rescheduled timer in the past
This generally occurs when the micro-controller has been
requested to step at a rate higher than it is capable of
obtaining.

Running Klipper on Arduino Mega2560, it is an old file I printed before with another firmware. I do not remember what the slicer settings were, but do not think that the speed goes above 120 mm/s (95K steps/sec).

The log indicates that an XY diagonal move with F9000 was requested just prior to the error. That's 150mm/s, and on your config that translates to ~120K steps per second with two active steppers. That is greater than the benchmark rate for the atmega2560. (To be clear, the benchmarks are with the micro-controller doing nothing but stepping - you should not expect to be able to sustain the full benchmark rate during a real-world print.)

In the future, please use github to report an issue with Klipper. See: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

-Kevin

Re: New experimental firmware: all kinematics in host

Anonymous User — Sat, 08 Sep 2018 14:33:18 -0400

Just experienced another issue with Klipper:

MCU 'mcu' shutdown: Rescheduled timer in the past
This generally occurs when the micro-controller has been
requested to step at a rate higher than it is capable of
obtaining.

Running Klipper on Arduino Mega2560, it is an old file I printed before with another firmware. I do not remember what the slicer settings were, but do not think that the speed goes above 120 mm/s (95K steps/sec).

[attachment 106947 klippy.zip]

Re: New experimental firmware: all kinematics in host

KevinOConnor — Sun, 02 Sep 2018 11:05:21 -0400

Quote
SEA
Hi KevinOConnor,

I tried to connect display 12864 anet3d (aka RepRap Discount Mini graphical controller) with Tevo Tarantula (MKS Base 1.4)
I used UC1701 configuration, but it seems not yet implemented.
I assume it is planned. If so, when I can expect it to be done?

If you're experience an issue with Klipper, please follow the directions at: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

-Kevin

Re: New experimental firmware: all kinematics in host

KevinOConnor — Sun, 02 Sep 2018 11:03:49 -0400

Quote
Kespa
Hello, does Klipper support auto bed leveling feature?

Yes. See the config examples in the config/ directory for a description of the parameters needed to configure it.

-Kevin

Re: New experimental firmware: all kinematics in host

SEA — Sat, 01 Sep 2018 22:56:48 -0400

Hi KevinOConnor,

I tried to connect display 12864 anet3d (aka RepRap Discount Mini graphical controller) with Tevo Tarantula (MKS Base 1.4)
I used UC1701 configuration, but it seems not yet implemented.
I assume it is planned. If so, when I can expect it to be done?

Re: New experimental firmware: all kinematics in host

Kespa — Sat, 01 Sep 2018 15:14:11 -0400

Hello, does Klipper support auto bed leveling feature?

Re: New experimental firmware: all kinematics in host

obelisk79 — Thu, 09 Aug 2018 20:50:05 -0400

Edited. Problem solved in irc.

Re: New experimental firmware: all kinematics in host

KevinOConnor — Mon, 06 Aug 2018 10:54:33 -0400

Quote
Adjoe
Can I used board Gen7 with AVR ATMEGA32 on it ?

The ATMEGA32 isn't currently supported. At a quick glance, it does not look difficult to add support.

-Kevin

Re: New experimental firmware: all kinematics in host

Adjoe — Sun, 05 Aug 2018 07:05:48 -0400

Can I used board Gen7 with AVR ATMEGA32 on it ?

Re: New experimental firmware: all kinematics in host

KevinOConnor — Sun, 01 Jul 2018 08:34:42 -0400

Quote
MarkLogan
Kevin - I got a new extruder so needed to update my extrusion steps. I took the opportunity to update to the latest Klipper. Seemed to be working fine after the update. I did an 20mm XYZ cube and noticed my X and Y were a little long so I went back and recalculated the steps for them. I changed the X and Y steps and restarted and suddenly my square was way off. If you consider front/left as origin, the cube was drawn from left to right. That front face went back a bit so it was say 1mm back by the time it hit the corner. Same thing for the right side - from where it started to where it ended, it moved 'left' about 1mm. Reverse was true for back and right sides. So I ended up with a parallelogram. I played with the x and y steps some more and it was worse. Printed something bigger and the effect was even more pronounced. I went back to my original steps and it was 'almost' right - probably like its always been honestly and I just never noticed. Trouble is that I'm .2 to .4mm out in each direction on a 20mm square now. So I guess my question is: Would changing the steps for X and Y to different values (and different from each other) create that effect or is something else going on? I did some hardware troubleshooting and I can't find anything, and other than the extruder nothing has changed on the printer in a long time. Thoughts?

Hi. If you're having an issue with Klipper, it's best to open a github issue following the directions at: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md
In particular, we need the Klipper log file in order to assist.

-Kevin

Re: New experimental firmware: all kinematics in host

MarkLogan — Sat, 30 Jun 2018 14:29:48 -0400

Kevin - I got a new extruder so needed to update my extrusion steps. I took the opportunity to update to the latest Klipper. Seemed to be working fine after the update. I did an 20mm XYZ cube and noticed my X and Y were a little long so I went back and recalculated the steps for them. I changed the X and Y steps and restarted and suddenly my square was way off. If you consider front/left as origin, the cube was drawn from left to right. That front face went back a bit so it was say 1mm back by the time it hit the corner. Same thing for the right side - from where it started to where it ended, it moved 'left' about 1mm. Reverse was true for back and right sides. So I ended up with a parallelogram. I played with the x and y steps some more and it was worse. Printed something bigger and the effect was even more pronounced. I went back to my original steps and it was 'almost' right - probably like its always been honestly and I just never noticed. Trouble is that I'm .2 to .4mm out in each direction on a 20mm square now. So I guess my question is: Would changing the steps for X and Y to different values (and different from each other) create that effect or is something else going on? I did some hardware troubleshooting and I can't find anything, and other than the extruder nothing has changed on the printer in a long time. Thoughts?

Edit: Actually I lied (a little) - on the right side it actually went further 'right' rather than 'left'. i.e. if front-left is origin then as it traveled to front-right it went 'back' a bit. Then on the right side (i.e. front-right to back-right leg) it actually went 'right' a bit. Then it corrected itself on the remaining two legs leaving me with a pretty perfect parallelogram...

Re: New experimental firmware: all kinematics in host

TinHead — Fri, 22 Jun 2018 08:16:28 -0400

Thank you sir (takes a bow).

Re: New experimental firmware: all kinematics in host

KevinOConnor — Wed, 20 Jun 2018 15:40:11 -0400

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

Re: New experimental firmware: all kinematics in host

TinHead — Wed, 20 Jun 2018 13:14:07 -0400

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

Re: Klipper v0.6.0 release

rmichael_cd — Fri, 01 Jun 2018 07:24:35 -0400

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.

Re: Klipper v0.6.0 release

KevinOConnor — Thu, 31 May 2018 14:15:45 -0400

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

Re: Klipper v0.6.0 release

rmichael_cd — Mon, 28 May 2018 21:17:23 -0400

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

Re: Klipper v0.6.0 release

KevinOConnor — Sun, 27 May 2018 22:20:33 -0400

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

Re: Klipper v0.6.0 release

rmichael_cd — Sun, 27 May 2018 09:55:27 -0400

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.