New experimental firmware: all kinematics in host

Quote
ekaggrat
the usb many times drops the connection

What does that mean?
Do you think it was an octoprint issue? Is is a cabling issue of you USB? Does the USB device disappear on the PC/Raspberry/whatever ? Or is the data transfer corrupted?

It depends on the details of your issue to say anything about how your experience in the future will be.

Hey,
just wanted to say thank you for the Klipper Firmware.

After a few Initial Tests i'm already in Love with it.

Tested the same Gcode file with Klipper and Marlin.

Overall Quality with Klipper is much higher with a decreased Printing time from 2H 20M to 1H 12H

Just amazing

I hope the recent exposure on Hack-a-day helps increase interest in Klipper. It's fantastic work.

I think the lesson to learn here is: "why are people exited by Klipper?"

Outperforming Marlin is no challenge and many firmwares do it already, so how comes it needs Klipper for some people to get this experience?

Smooth stepper movements are a long solved problem as well, so why does it take Klipper to get it to printer users.

Same for high step rates, extruder advance, web interface, whatever.

Technically, what Klipper does on the PC takes less than 10% of an ATmega's capabilities, so keeping this on the controller isn't exactly a challenge. Teacup does these calculations 500 times a second, Klipper only 25 times. How can a slower approach get the reception of being the better one?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi,

Quote
Traumflug
Technically, what Klipper does on the PC takes less than 10% of an ATmega's capabilities, so keeping this on the controller isn't exactly a challenge. Teacup does these calculations 500 times a second, Klipper only 25 times. How can a slower approach get the reception of being the better one?

I don't want to get into a Teacup vs Klipper discussion. You've done an excellent job with Teacup! I think of Klipper as a completely different approach. I am confused by your comment above, however.

Klipper calculates the precise clock time of every step on the host machine (typically a Raspberry Pi or similar) using the general formulas for acceleration and the printer kinematics. Those step times are then compressed, sent to the micro-controller, and then the mcu executes that schedule. These types of physics calculations can certainly be a limiting factor of the micro-controller. For example, on a delta machine, this can involve 100K+ sqrt() operations a second. That's trivial for an RPi, but quite difficult on an old atmega. There's some discussion of how this is done in the Klipper Code Overview document.

I don't know what you are referring to with "Klipper only 25 times" - I can think of nothing that klipper does 25 times a second..

Cheers,
-Kevin

Quote
KevinOConnor
I don't want to get into a Teacup vs Klipper discussion.

But me wants this :-)

Quote
KevinOConnor
You've done an excellent job with Teacup!

Thanks for the charming words, but I disagree. Teacup always came with excellent performance. It comes with not hackish, but well designed code. It has demonstrated to do 1'600'000 steps/seconds (right, that's 1.6 MHz of synchronized stepper movements). It does evenly distributed stepper steps, avoiding Bresenham. It comes with a dedicated configuration and build application. Still it's only reason of existence is received as kind of a really last resort for those poor guys who can't even afford a $30 RAMPS.

My personal conclusion about this is that technical quality doesn't really matter as long as the result somehow gets a printer moving. There's something else which makes people using a controller software solution. Klipper is apparently much better at this "something else".

Quote
KevinOConnor
I don't know what you are referring to with "Klipper only 25 times"

Taken from one of the descriptions as the frequency of how often stepper speeds are updated. One can do only a pretty limited number of stepper commands over 115200 baud, after all, certainly much less than the claimed 500'000 steps/second for each stepper. I think this is what you call "compressing and sending".

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I also don't think here is the right place to talk about TeaCup vs Klipper.

For me its sounds like jealousy that klipper is getting attention.

It's actually the first time i hear about the TeaCup Firmware but with such an attitude as a Developer i already decided to never give it a try.

Quote
KenshiHH
It's actually the first time i hear about the TeaCup Firmware but with such an attitude as a Developer i already decided to never give it a try.

Nice example of ignorance and certainly the ideal way to get the best out of our hardware. Ha ha.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

On 29. Mai 2016 13:41

Quote
Traumflug
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.

Quote
Rossini
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.

This code overview document briefly mentions time stamps, so I think synchronization is done by sending a command for each stepper, all with the same timestamp. A timestamp sufficiently into the future, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

@Traumflug I don't agree

Quote
Traumflug
Thanks for the charming words, but I disagree. Teacup always came with excellent performance. It comes with not hackish, but well designed code. It has demonstrated to do 1'600'000 steps/seconds (right, that's 1.6 MHz of synchronized stepper movements). It does evenly distributed stepper steps, avoiding Bresenham. It comes with a dedicated configuration and build application.

this sounds like heavily praising yourself, but I think you refer to Triffid Hunter's work?

Quote
Traumflug
Still it's only reason of existence is received as kind of a really last resort for those poor guys who can't even afford a $30 RAMPS.

as a developer I understand how frustrating it is to create and maintain a nice piece of software and see other not so "well designed" software getting the attention (I think of Marlin with it's fast pace and lesser code review).

Please look at it from a users point of view.
For a user it's totally unimportant (and not under his control or visibility), how well designed the code is. (S)He simply doesn't see it.
And if it comes to the wanted feature X the software wins, that provides X over a software that doesn't.

From the beginning years ago, I used a delta (when the first Rostock was born) and I figured Marlin to be too slow for this.
Searching for an alternative firmware resulted in Smoothieware as the only one that could handle delta kinematics fast enough.
I guess Teacup wasn't on the plot because it didn't have delta kinematics, right? I see a video from 2015 where someone added delta kinematics...really that late?
What should I have done instead? I wanted to print in the first place and not develop new kinematics, that already existed in at least two variations.

Now look at Klipper...it already has all I need, mainly delta and corexy kinematics and most wanted by me: physical exact stepping without tricks.

I think it already offers those kinematics, because that level runs on Python.
It is much easier to extend it with new functionality, because of it's concept.
You don't need to throw most of your time on efficiency. Instead you can put all your energy into the real world algorithm.

Quote
Traumflug
My personal conclusion about this is that technical quality doesn't really matter as long as the result somehow gets a printer moving. There's something else which makes people using a controller software solution. Klipper is apparently much better at this "something else".

I really hope, you don't think of Klipper here, because I am sure it has a lot of "technical quality". Especially conceptual.
If you read the docs carefully you will probably see how well it is designed.

And you are right, functionality counts more than good design if it is hardly noticeable for the user.


Most important for me is the one thing I always wanted:
all the real time hassle is hidden in a lower level and implemented once for each MCU model (only some simple io modules, gpio, analog, serial, etc., and timers, the rest is reusable).

This gives the comfort of an abstract higher level. I only have to plan the moves/events and put them in a queue.
If the kinematic is already there, you only need to implement gcode commands or things like autocalibration etc.
Or you simply start printing.

It is easy to add new functionality. In fact you no more think about if it could be implemented at all, instead you now have more a problem of choice.


Another nice feature is scalability.

You can distribute all those single tasks on as many MCUs as you want or need.

You could make a modular system, using an Arduino Nano (2-5 EUR) for each single task.
E.g.
* a single axis with stepper and endstops
* an extruder with heater and temperature
* a heated bed controller
just add stepper drivers or MOSFET modules.
You will never run out of computing power.

If you need something more tightly coupled like a delta, it may be better to gather these on an MCU with more power, like a fast 32bit controller.

But the stepper task is always the same, no matter how complex the kinematics are. The controller always has to work on a series of quadratic functions with scheduling times.
The quadratic functions also solve the transmission speed problem.

How uninstall klipper?
How to set the right code back to common micro-controllers for /dev/ttyACM0?
If set serialport /dev/ttyACM0 in Octoprint there is no connection.

Thank you.

Quote
hg42
this sounds like heavily praising yourself, but I think you refer to Triffid Hunter's work?

Generally I don't like to personalize collaboration projects. Yes, the foundation and the excellent G-code parser was done by Triffid. Acceleration (remember, we didn't have this in the early days) was done by me, Configtool was done by Jeff Bernardis, PC-Simulator was done by Phil Hord, running in the AVR simulator again by me, as well all endless performance optimizations, Regression and Unit Testing by Phil and me and over the last year or so, Wurstnase/Nico Tonnhofer brought a lot of fine improvements, like software PWM and one timer per stepper.

Quote
hg42
Please look at it from a users point of view.
For a user it's totally unimportant (and not under his control or visibility), how well designed the code is. (S)He simply doesn't see it.
And if it comes to the wanted feature X the software wins, that provides X over a software that doesn't.

Users do see code quality in form of reliability and performance. Everybody wants faster controllers and there are firmwares capable of delivering it, but they simply get ignored. Not exactly logical. Outstanding example was when I had to defend that accelerated movements do make sense. Everybody told me that printers max out at 200 mm/min (3 mm/s). Then I demonstrated 1000 mm/min after a weekend of work, and they still didn't believe it. Sprinter had to come along to make accelerated movements an accepted feature.

I don't talk about such experiences for whining, but to give an idea on how community reception works. Popular stuff apparently always wins, no matter how crappy it is. I take we still see RAMPS boards for the same reason. Popularity is gained by ??? Uhm. Hard to say.

TBH, I almost ceased development this year, simply because Teacup is double as fast as I need it and I didn't have a single step loss for years now. 100% reliable, 0% step loss. Pressure to further improve that is pretty low.

Quote
hg42
Now look at Klipper...it already has all I need, mainly delta and corexy kinematics and most wanted by me: physical exact stepping without tricks.

Klipper uses the same tricks as everybody else. Pre-calculate movements, then approximate steps. As far as I can see, acceleration is done on the host side, so it can accelerate by stair-stepping only. Stair-stepping is fine, but not "physically exact".

And then Klipper puts the performance and reliability bottleneck, serial communications, into one of the most sensible places: between step calculations and step executions. What does Klipper do if there's a sudden communications failure? I take such a failure means a ruined print with loss of the known position, no chance to pick up the print again. And with some bad luck, heaters running away. All other firmwares drain their movement buffer properly, keeping the known state.

Quote
hg42
You could make a modular system, using an Arduino Nano (2-5 EUR) for each single task.
E.g.
* a single axis with stepper and endstops
* an extruder with heater and temperature
* a heated bed controller
just add stepper drivers or MOSFET modules.
You will never run out of computing power.

You'll run out of serial ports. You'll run out of synchronization. Ignoring that one can do the same with all other firmwares.

P.S.: sorry, forgot that many firmwares are too bloated for an Arduino Nano. So "all other firmwares" -> "all other firmwares which fit into a Nano".

Quote
hg42
If you need something more tightly coupled like a delta, it may be better to gather these on an MCU with more power, like a fast 32bit controller.

Next logical evolutionary step would be to develop Klipper host into a converter from complex kinematics to straight kinematics, getting the best of both strategies.

Edited 1 time(s). Last edit at 12/30/2017 07:54AM by Traumflug.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Taken from one of the descriptions as the frequency of how often stepper speeds are updated. One can do only a pretty limited number of stepper commands over 115200 baud, after all, certainly much less than the claimed 500'000 steps/second for each stepper. I think this is what you call "compressing and sending".

There's documentation on how Klipper implements kinematics, how it handles low-level commands, its communication protocol, etc at: https://github.com/KevinOConnor/klipper/blob/master/docs/Overview.md. Nowhere in that documentation is there a reference to a "frequency of how often stepper speeds are updated" - Klipper fundamentally does not work that way. With Klipper, the host machine calculates the precise micro-controller clock time of each step, it compresses that series of clock times, transmits it to the micro-controller, and then the micro-controller pulses the step gpio lines at the scheduled times. There is no concept of a periodic "update to stepper speed".

Your assertion that this can not run at 115200 is absurd. It's regularly done. You could have easily installed the software and proven that to yourself.

For those interested in how Klipper implements movement, there's an overview in the documentation with code references for each phase. For those interested in installing Klipper start with the installation document.

Quote
ThomasSc
How uninstall klipper?
How to set the right code back to common micro-controllers for /dev/ttyACM0?
If set serialport /dev/ttyACM0 in Octoprint there is no connection.

Thank you.

If you wish to return to another firmware, you will need to flash the original firmware to the micro-controller. You'll need to follow the steps in that firmware's documentation to do so. Once you've done that, instruct Octoprint to connect directly with the firmware (eg, by connecting to /dev/ttyACM0).

Cheers,
-Kevin

Quote
KevinOConnor
Your assertion that this can not run at 115200 is absurd. It's regularly done. You could have easily installed the software and proven that to yourself.

The only absurd here is that you can't even tell us how often stepper speeds are updated. Instead you point to some documentation like a broken record. Documentation which does not answer the question.

On some private channel I've learned that Klipper groups steps by some (user adjustable) accuracy heuristics and sends these groups. Sounds like a plausible way and also means step groups to be sent at a dynamic frequency as well as a limitation on movement complexity at a given speed due to bandwidth limitations. So I'll assume this to be the strategy until somebody comes up with a better explanation.

Thank you for your help!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I don't understand the need for a measuring contest here between teacup or klipper. Both imo are good pieces of software that solve the same need in a different way. Perhaps starting a separate thread for this Might keep the discussion here on-topic?

Klipper has been around for 2 years, gets some high visibility on a popular hackerspace blog and all of a sudden Traumflug goes on the offensive. (Presumably he believes Klipper is misrepresenting itself with high advertised step counts?)

I don't see Kevin trying to make any money off of his firmware, no one asked him to create it. Sounds like a personal project that he decided to share, and it has slowly grown from there, with very little fanfare, just steady active development.

On the flipside. Teacup is the epitome of clean, no-frills quality design that is well optimized. So what if it doesn't get all of the shiny attention other firmwares do. I've used it and it worked well. I liked the concepts behind how Kevin approached his firmware and made the switch. It also works very well.

Options in the open-source world are a good thing. I've got multiple controllers each with a different firmware on them so I could easily experiment with the different options on the same printer. They each have their own pros and cons.

Edited 3 time(s). Last edit at 12/30/2017 12:39PM by obelisk79.

Quote
obelisk79
all of a sudden Traumflug goes on the offensive.

I wanted to learn how Klipper solves the communications problem. That's all. Apparently the communications protocol is a secret, so this learning has to wait until I get into a mood to reverse engineer it from source code.

Outcome of this question about the protocol is a reconfirmation that actors in this community are hostile as hell. Everything but flat cheering gets recognized as being offensive. And yes, I already regret to have clicked on "Log in" to participate in the discussion here. I'll correct that in a minute.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hasn't that discussion already taken place between you and Kevin on page 1 of this thread?

Additionally you didn't start posting at the top of this page asking a simple question about solving the communications problem.

From my limited experience in these types of technical details, the way I understand it, is steps are calculated on host, compressed to minimize data and sent to be queued up on the controller. Which in the case of the ATMega is 600+ commands?

Reference: [forums.reprap.org]

Quote

Klipper uses the same tricks as everybody else. Pre-calculate movements, then approximate steps. As far as I can see, acceleration is done on the host side, so it can accelerate by stair-stepping only. Stair-stepping is fine, but not "physically exact".

as I understand the docs (didn't look into the low level code yet), an acceleration fucntion (currently constant but may be S curve etc.) is exactly calculated on the host (not done) resulting in quadratic functions each from position A to B starting at time T (in the future). These are transferred through some communication channel to the MCU (it does not matter if serial or other, e.g. PRU on beaglebone). Time between all controllers is synchronized (which works well, I tested it), so every MCU has a queue of time scheduled actions to do. It simply waits for the next time schedule and executes the action.

Yes, quadratic functions are a kind of approximation, but this is not a problem at all if the error is kept below a desired limit. Digital system always do this. Even the acceleration is calculated digital. The key here is the word "desired".
If you have to lower your expectations because of limited computing resources you are lost.

Quote

And then Klipper puts the performance and reliability bottleneck, serial communications, into one of the most sensible places: between step calculations and step executions

• the queue is not filled with single steps but (simple) function parameters that describe step sequences over time. These functions are currently quadratic, but could be changed to some other algorithm if this would fit better. They only have to be simple enough for the MCUs
• each queue entry has a scheduling time, so the exactness of the timing is totally independent of the timing of the communication channel
• the channel rate must be higher than the execution rate, but this is easy because it's nnot on the step level
• the channel speed is know and usually fixed (e.g. baud rate), so you know how fast you can go, there are no unexpected situations. TBH there could be, because in worst case each step might need a single function, but because movement has it's physical limitations, this cannot happen
• a communication channel that has problems doesn't work in any environment. The serial interfaces use only very short cables, and it's all in a single housing if you want. So it is easy to build this reliable

Edited 1 time(s). Last edit at 12/30/2017 02:18PM by hg42.

Quote

The only absurd here is that you can't even tell us how often stepper speeds are updated. Instead you point to some documentation like a broken record. Documentation which does not answer the question.

because the question is absurd, if you read the documentation.

The documentation tells you, that

• the host calculates step times exactly with constant acceleration, no approximation, no stairs etc.
• the resulting step times (meaning the absolute time at which the step has to be executed in future) are compressed in some way (does not matter how exactly, if grouped, zipped or any other way)
• the controller decompresses them and executes each step at its planned absolute time

The only problems here are bandwidth and time synchronisation.

Bandwidth is addressed by compression. The compression is not lossless in this case, but it can be controlled how exact it is. I think this is only a limitation of the current implementation, may be there are other ways to do it.

Time is kept in sync in a way similar to NTP (if I understand the concept correctly), by sending time stamps and comparing the time on this side with that on the other side taking into account how long it takes to transfer it back and forth.

@Traumflug you are not asking a question but spitting out general offensive sentences about other people. Simply stop that and anything will go smoothly.

Example:

Quote

My personal conclusion about this is that technical quality doesn't really matter as long as the result somehow gets a printer moving

you are basically saying Klipper doesn't have technical quality and everybody is stupid

You can find the key in your own questions, if you would really look for answers and listen to "people".
"why are people exited by Klipper?"
"Outperforming Marlin is no challenge and many firmwares do it already, so how comes it needs Klipper for some people to get this experience?"
"Smooth stepper movements are a long solved problem as well, so why does it take Klipper to get it to printer users."

you don't think about it but only use these questions as rhetorical weapons.

Apart from that it is not true...Marlin is not as bad as you think...and you only see this little topic "stepper movement", which is important but not everything.

"Same for high step rates, extruder advance, web interface, whatever."
"Technically, what Klipper does on the PC takes less than 10% of an ATmega's capabilities, so keeping this on the controller isn't exactly a challenge. Teacup does these calculations 500 times a second, Klipper only 25 times. How can a slower approach get the reception of being the better one?"

you still did not answer from where you got the number 25.
You are still ignoring very factual and calm reactions of Kevin and others and are still spitting out emotional words like "absurd".
I still cannot see, that you really read the documentation (which is very good btw.) or you are reading it while searching for flaws to attack.

Read my other posts to get a feeling about "why" I like Klipper.

Let us all calm down a bit.

Not everybody is proficient in communicating his/her thoughts. And having somewhat correct English doesn't imply to be a natural speaker.

It will be the best for all of us to assume that we are all here to learn things. So lets focus on what we learned. Klipper and Teacup are very different firmwares that both operate a 3dprinter. So talking about up and downsides of both approaches seems to be fair.

From what I understood from the heated discussions is that Teacup is focused (and good at) exact step timing on (historically mostly) cartesian machines. Klipper has no performance issue on deltas as the trigonometric calculates are done on the host.

From hg42's explanations we also learn that after doing the exact step calculations on the host, Klipper tries to fit the step sequence to an quadratic function and then sends this quadratic function to the client. From the documentation I can see that it uses variable length ints to reduce the data bytes needed. This way of "compression" therefore allows for the high step rates at the cost of as hg42 put it "not lossless" compression. The quadratic function does not match ideally the steps and the small errors are accepted. So we learn that the teacup steps are more exact than the Klipper steps. If and how much of a problem that is would be something we still need to learn.

I did not find anything regarding clock synchronization (especially not NTP style) in the documentation. With a single client this is also not necessary. It is enough that the host starts the clients time (or knows the client time once). Due to the communication channel and data transport ahead of time further synchronization is not needed. If there is some active synchronizations as both host and client clocks will have jitter and drift then please let me know. I want to learn about that! I would therefore assume that one client per axis is not possible (due to lacking synchronization). In the time of USB to serial converters the number of serial interfaces should not pose a problem.

I hope I managed to be down to the facts and that we can continue with the discussion so that we all can learn new things.

I do not think that intended or not intended rude behavior helps. But I also don't think that calling people out on their rude behavior helps. Could everybody please just assume that the other people involved have the best intention and could we all try to ignore the trolls?

he seems just pissed about the sudden interesst in klipper due to the hackaday article. i'm sad that this topic is getting derailed just because of one "here, here, look at me, my stuff is so much better" guy.


back to topic.

made a comparrison between marlin and klipper with the same gcode file.

printed with pla at 100mm/s for the inner and outerwall at a 3000 acceleration.

i took pictures with a cheap usb microscop

source:




klipper:


marlin:



source2:


klipper:


marlin.



Marlin Printtime: 2h22m

Klipper Print Time: 1h12m

Edited 1 time(s). Last edit at 12/30/2017 04:07PM by KenshiHH.

Quote
hg42
you still did not answer from where you got the number 25.

He got it here.

Quote

FEATURES
Klipper touts several “compelling features”:

Each stepper event is scheduled with a precision of 25 microseconds or better. The software does not use kinematic estimations (such as the Bresenham algorithm). It calculates precise step times based on the physics of acceleration and the physics of the machine kinematics. More precise stepper movement translates to quieter and more stable printer operation.

When I needed help with a teacup, the Traumflug refused me. When I needed help with the klipper, Kevin completely helped me. Maybe that's why the klipper is better than "others firmwares"?

I assume you printed that on the same printer.

Do I see it correctly that the Marlin print has more details?

Quote
pamalofeev

Quote
hg42
you still did not answer from where you got the number 25.

He got it here.

25 microseconds is 25 millionths of a second. Different measurement.

Edited 1 time(s). Last edit at 12/30/2017 05:11PM by obelisk79.

nope, its like noise.

i usally don't print with 3000acc so its more like a worst case scenario.

while marlin completly fails and runs the steppers really noisy, klipper runs much smoother and faster

Quote
KenshiHH
while marlin completly fails and runs the steppers really noisy, klipper runs much smoother and faster

Just about every other firmware runs smoother and faster than Marlin. It's one of the few firmwares still using Bresenham. Neither of the major 32-bit firmwares uses Bresenham, nor it seems does Teacup. I'm not sure about Repetier, although I've seen several reports that it runs delta printers better than Marlin does on the same hardware.

Edited 1 time(s). Last edit at 12/30/2017 06:23PM by dc42.

---

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
KenshiHH
back to topic.

made a comparrison between marlin and klipper with the same gcode file.

printed with pla at 100mm/s for the inner and outerwall at a 3000 acceleration.

Thanks! I'd like to see more of these types of comparisons. It would also be great to see more youtube videos showing comparisons of the printer running (noise / vibration comparisons).

Quote

Marlin Printtime: 2h22m

Klipper Print Time: 1h12m

Impressive!

-Kevin