Ryan pointed this to me deep in another topic, but I don’t want to keep taking Andy’s post up with firmware stuff.
This thing is really unique. Instead of doing the motion and geometry computations on the microcontroller, they are all done on a faster processor, like a raspberry pi. It computes very raw commands, like “pulse this output 120 times at time 1:34:55”. I haven’t looked at the exact messages, but the microcontroller troller is free from computation, logic and physics. It’s just a slave to the klipper code. This is a great segmentation of responsibility because microcontrollers are great at output at a specific time, but lousy at physics. Python on the pi is great because the code can be developed and understood quickly, and it can integrate with more advanced components, like web GUIs or plot tools.
The Python code still accepts gcode as input, so slicers and cam software will still work.
The microcontroller’s responsibilities can even be split between multiple micros, so the micro responsible for the hotend could be different than the one responsible for motion. I’m not 100% sure they have the timing error low enough to split up x/y on different micros, but it’s possible.
Since all the complicated stuff is on the pi, you can switch firmwares by just starting a different version, or a different configuration. No need to flash, and no need to destroy the stable to try an experiment.
It’s a very interesting idea. I’d want to know more about error handling before I switch over, and I’m sure there will be growing pains w.r.t. catching up to features of other firmwares but it’s very promising. A lot of people know Python, and faster testing means faster development, so if this gets picked up, I’m sure it could run wild.
Ohhhhh, so you like it so far? I only read the initial docs but it seemed like it is pretty far along.
I have a pi and I know about 0.000001% of python so maybe I can try it out one day. Any idea how well the file structure is laid out, in terms of keeping things separate enough to easily add features and config tweaks?
I haven’t read the code, just some of the docs. But I think it’s a cool concept.
Python can be much easier to change than desktop C++.
Desktop C++ can be much easier to change than embedded C++.
But that all depends on the maturity of the code. You can write crap in any language. Marlin is pretty well laid out, but new programmers can get jammed on the compilation or some type cast errors, or even not understanding which code is included after all the #ifdefs. I’ll be looking at it more closely. It’s got me thinking in my idle time.
2.0 is a big improvement IMHO - the flat file structure of 1.x drives me crazy…but like so many projects was forced on them by arduino limitations for a long time.
That said…the ifdefs in marlin are totally driving me crazy right now. I’m trying to get 2.0 going on the archim I won from Ryan - I’ve got it most of the way there. The one problem I’m still struggling with is getting the current control working. The board has 5 drivers, but Marlin 2.0 only has support for 3. The Marlin4Due port has support for 5…but the stepper code in Marlin4Due has very little in common with the current stepper code in marlin2.0.
This kind of stuff is driving me crazy:
#if HAS_MOTOR_CURRENT_PWM
void Stepper::refresh_motor_power() {
for (uint8_t i = 0; i < COUNT(motor_current_setting); ++i) {
switch (i) {
#if PIN_EXISTS(MOTOR_CURRENT_PWM_XY)
case 0:
#endif
#if PIN_EXISTS(MOTOR_CURRENT_PWM_Z)
case 1:
#endif
#if PIN_EXISTS(MOTOR_CURRENT_PWM_E)
case 2:
#endif
digipot_current(i, motor_current_setting[i]);
default: break;
}
}
}
#endif // HAS_MOTOR_CURRENT_PWM
ifdef's inside a case statement inside an ifdef....it's melting my mind trying to keep it straight!
The real mess is that the current 2.0 code uses a single channel for X and Y. (It looks like RAMBO has them tied together for some reason) so I’m debating the cleanest way to give separate X and Y control. I see one way to do it that creates fairly ugly code and less intuitive ordering of the current variables…but would mean not having to mess with the existing configs. And another way that would give cleaner code…but would mean the configs for setups like RAMBO would have to change. Neither seems like a good option to me so I keep trying to think of a better way to approach it. Probably best to go with the cleaner code even if it means existing configs will have to change…it’s going to take a change to the eeprom map either way so it’s a breaking change no matter what.
Back on topic…I’m kind of torn. I agree that micros aren’t as good for doing the heavy lifting…but this kind of feels like a step back. It’s more like the “traditional” approach used by MACH and such where a dedicated computer does all the gcode and just talk to the stepper drivers. Basically klipper is just using a micro to talk to the stepper drivers to get away from needing to use a parallel port. Yeah, Pi’s and such are available now and are easier to dedicate to something like this…but still feels like my big complaint with Pi’s in general that they’re not powerful enough to replace a computer but are overkill for replacing a micro. In this case it feels kind of wasteful to use a Pi just for that.
And with newer micros being as powerful as they are it feels even less ideal to me. There are a couple of people working on Marlin boards with STM32F7’s - which…is kind of overkill the amount of processing power packed into a printer control board!
Though I do like the idea of it being more agile to develop for…but…I keep wanting to like Python but even though I have lots of reasons I want to love it I just can’t bring myself to enjoy it
That said I wish I didn’t have so many projects going on right now so I could take a deeper look and give it a try
If you can get your editor to properly gray out sections that aren’t defined, that works pretty well, but I’ve had trouble with Marlin because of the bizarre Arduino include order.
I really like Python, but I came from C++ and I have good long list of packages I like too. I do maybe 80/20 C++/Python at work. I can’t help but see the newer C++11/14/17 features making the language more like Python. Python is just neat. Duck typing, generators, decorators. I don’t use the features 99% of the time, but they are interesting enough that I enjoy reading and writing in Python. If you get a chance, you should definitely check out bottle, matplotlib, Python image library… They just do so much with their example code. It’s so slick.
I have read all the docs, and I think klipper is more than just using the micros for gpio extensions. It’s also about letting the micros run in sync and the pi run async. By having 100ms or so of commands queued, the micros can be resilient to the pi taking a short break to service your web request or do some kernel logging. The interface between the micros and the Python is really cool. The microcontroller compiles in all the functions it can handle. The Python queries all the functions at start up, and the micro transmits back compressed static human readable names for the functions. The compression is done during compilation, to keep the micro code smaller.
The interface functions are clever too. All moves are a “trapezoid” with a flat acceleration, flat constant speed and flat deceleration. Do pi sends count, interval, and interval change. The micro steps, waits interval, and changes interval. It does that count times.
So if you were ramping up speed, it might ask for 100 steps, with 2000 ticks between steps, and a reduction of 2 ticks per step. They explain it better. It’s just a very clever interface.
I started researching this klipper after reading this thread & it looks pretty interesting. There is a pretty good discussion thread of it here: http://forums.reprap.org/read.php?147,667655
I have a Makerfarm 10" Prusa i3v with a Rambo board & started going thru the configuration file (generic-rambo.cfg) before deciding to try it. I have been debating whether to get an 8bit or 32bit board to replace the electronics on my delta & this klipper might be the answer.
Ok, I’m gonna try this. I might try it on the zen first, since my printer has autolevel.
One thing that isn’t obvious is the cost of doing advanced code on microcontrollers. Making them dumb slaves makes the advancement faster. The Host code can be inefficient but clear, while the critical parts remain lightning fast. It would make improvement like the dual endstops much easier on Ryan and I, plus, it would be easier for the maintainer to review and test, which would make it merge faster (on average).
I have klipper working on my Makerfarm 10" Prusa i3v with Rambo board. I had a little hiccup getting the Z motors working correctly, but the author of the firmware found my problem. I had left the max_z_velocity & max_z_accel what they were in the example file & they were too high.
Along somewhat similar lines…some work in progress on something for Marlin:
Basically allows more direct access to the steppers and using an external planner instead of letting Marlin do all of the work. The guy working on it has been busy the past few months but recently indicated he hasn’t abandoned it and does plan to work on it more soon.
Whoa, that is a rabbit hole there. I read a bunch of that almost all of it…97% went over my head. I wonder what will come of it. Seems like Marlin Dev has exploded recently there used to be so few changes. So cool.
I did try this klipper version 0.5 for a week back in December on my Makerfarm 10"Prusa i3v and got it to work about as well as marlin, but did not want to spend more time tweaking it at that point. I see he just came out with version 0.6 the other day. Look in the Docs folder to see what updates he has done. I have my folgertech delta about back up and running using a MKS Gen 1.4 board and might try it again when that is working good. What he has added that is useful to me is Z-probe support and able display on 2004 LCD screen. I also just got one of the new Raspberry Pi 3 B+ to play with.
After having an extruder problem on my other printer, I spent a day configuring & fine tuning klipper to run on my delta printer. Here is a 15 minute video of it printing at 120mm/sec using an 8bit MKS Gen 1.4 & a raspberry pi running klipper. I was starting to print the files for the formula 1 car when my other printer failed. I am thinking printing the TPU might have worn the titan extruder hobbed gear, although I had only printed 1 tire so far. I have been printing with that titan extruder for 2.5 years, so it is probably time to replace some parts. Maybe get the hardened steel hobbed gear or just get a different extruder. Anyway with this delta running klipper, I am still getting some blobbing on the top of some layers & that might be the retraction settings.
Klipper is definitely an extremely interesting setup. I just moved my home-built CoreXY printer over to it, and I love it. Not having to flash firmware for every little tweak is nice, and there’s a lot of very useful features. One really nice thing is how one Klipper (host) process can orchestrate multiple microcontrollers (Arduino+RAMPS, for example) in order to control more motors. The Voron 2.1, for example, has 7 motors (4xZ, 1xA, 1xB, and 1xE), so they use Klipper with two RAMPS boards. The old setup was Duet with expansion boards that all-up was a few hundred dollars to purchase. Klipper coordinates all four Z motors to level the gantry with respect to the print bed.
Is anyone currently using klipper with their MPCNC (or LowRider)? I have it running on one of my printers and have been quite impressed with it in that application but wonder how well it would work for this purpose.
I am running klipper on my Ender 3. From what I can tell you are rare limited by the spindle/material. I don’t think klipper would help with speed. It might make tweaking the firmware easier.
I started to use Klipper with my Ender 3 Pro - with the SKR mini E3 v1.2 - as Marlin was driving me crazy with the random bugs and the opaque configuration. Klipper was a learning curve but it is, in my opinion, much more pleasant to use, configure and understand.
I have ordered the steel tubes (1.6mm cold drawn mild steel) for my LowerRider 2 and I will try out Klipper on that after I have verified that everything works OK with the V1Engineering supplied SKR board and stock firmware, of course. I want to be sure that everything with the LowRider works a expected using V1Engineering’s supplied parts and configuration before I start tinkering.
I just installed it on my Ender 3 Pro. Which I used to print my MPCNC. This is really neat stuff. Not only could it run other cards so that more axis could be added to the MPCNC. But it is independent of kinematics. Rather than computing line segments. It iteratively solves the kinematic equations. And it also looks ahead so it can apply mechanics optimization over several commands issued by a slicer. Either Marlin catches up, or this thing will just replace it. The only thing that may save Marlin is user base and small but significant entry barriers. If the klipper guys are able to simplify configuration by simplifying sharing profiles like cura has, it would be a no brainer. This thing shaved 20% printing time on an existing gcode file without any tweaks. And it can be much faster than that. I don’t have much time, but I really wanted to give readers a heads up. Klipper is awesome!!!
I need to try it. I really like the concept, and I am guessing it has gotten a lot smarter since I looked at it.
I don’t think Marlin is going anywhere though. It added some features where it would basically accept motion primitives from a connected computer. But the fact that it can run without a pi, without wifi, without USB cords, is a big plus. It is also still installed (well, an older version, butchered by manufacturers) in new printers coming from China. I doubt they are going to add in klipper and a SBC in the next creality or BTT printer. They might, and if they did, then I would expect a big shift.
