Klipper firmware/software combination

[aerogeek]

Hi All, has anyone tried the klipper firmware on the printrbot board rev D or any of the printrbot boards? https://github.com/KevinOConnor/klipper

What is your experience of it?

[RetireeJay]

Looking at the description, it appears that implementing Klipper will require you to be rather expert in both hardware and software, because it's generic (written for many different hardware platforms). You will need to customize it for the Printrboard and the specific printer. All of that is do-able, but you can find versions of Marlin that are already configured for your specific hardware so you'll have less of a learning curve (or no learning curve) to get all the pieces of the system working together. If you do decide to implement Klipper, please post here so others can benefit from your discoveries.

[Mooselake]

Klipper is similar to the Sailfish firmware for Makerbots, offload part of the processing from the lower powered MCU to another processor.

IMHO it's part of the ongoing death throes of underpowered 8 bit controllers, trying to substitute an 8 bit low (by today's standards, still way faster than mainframes when I started and PCs of 30 years ago) speed processor for a similar price device that's 10 to hundreds of times faster with considerably more firmware and ram space. Remember these AVRs we're already considered underpowered (but cheap!) when they picked them for Arduinos, and more so when the 3D printing pioneers hacked grbl for firmware

[aerogeek]

Hi Guys, thanks for the heads up Jay. I'll stick to marlin. I want to do more and as a ex hardware engineer programmer and mechanic I know I could learn to so it just keep forgetting that as a parent life may want me to do something else.

[frankv]

I differ a bit from Mr Moose's and Mr Jay's positions.

My understanding is that klipper originated on a Mega2560 client and a RPi host, although it has been migrated to other platforms. So migrating it to a PrintrBoard should be just a matter of assigning the correct pins to the correct functions.

There's also a project called Pacemaker which IMHO has more promise than klipper in that it moves away from G-code. Having said that, the klipper project is moving at a very fast pace (but in the wrong direction?) whereas Pacemaker doesn't seem to be moving at all.

Whilst a 32-bit processor might give you 10x the processing power, the limitations are more about physical constraints like acceleration and deceleration rates. So going to a super-fast processor isn't going to give you super-fast processing; conceivably you could get smoother prints by increasing micro-stepping, although the consensus seems to be that there's little benefit in more than 32x. And it isn't going to speed up the transfer to the printer either. OTOH, we are running up against RAM size limits, especially for graphic displays, so there is benefit to be had by increasing that.

IMHO 3D printing is increasingly being constrained by the limitations of STL and G-code (notably straight lines and flat triangles, effectively no curves), and klipper is a step in the right direction. Although, IMHO not a big enough step. OTOH, on my desktop, I have a computer with a brain the size of a planet that sits idle 99% of the time; it doesn't seem to me sensible to put a brain the size of the moon in my printer, which will also be idle 90% of the time (even while it's printing). I think it's sensible to give all the heavy-duty math and calculations to the slicer on the desktop, and have a relatively dumb printer that just controls temperatures and drives stepper motors. I don't really care whether the printer controller is 8 or 16 or 32 or 64 bits, or whether it runs at 4.77MHz or 3GHz; the important thing is to integrate motion control *calculations* into the slicer. For example, perhaps the path of the nozzle could be described by a start point and a series of coefficients for a quadratic or perhaps an even higher-power equation. A single command could draw an entire ellipse of any size, or a Bezier curve, or any arbitrary curve. Or perhaps 3 or 4 or 5 or 6 speed vs time curves could be described to the printer as coefficients of higher-order equations, one for each stepper motor. The printer generates the individual steps to match the speed profiles. e.g. if X and Y are sinusoidal the nozzle will move in a circle (I think). If E is a sawtooth with the same frequency as X and Y , then one side of the circle will be heavily extruded, and the other thinly. All of a sudden, fading from one colour to another is simple; just ramp E0 up at the same rate that E1 is ramped down. Compare that to G-code where you have to give a command for every individual colour change, and also for each direction change (if the G2 command isn't implemented).

[RetireeJay]

I totally agree with Frank's remarks about processing power; what good does it do anyone to have a CPU that's executing No-Op instructions 90% of the time? And on my printer with my materials and models, I never run more than half the maximum possible speed, so a faster processor would do very little for me.

On the other hand, the case for replacing G-code is a perfectly rational ideal but probably never going to happen. In an ideal world, we'd be typing on Dvorak keyboards instead of inefficient QWERTY layouts. We'd all be using the Metric system and nobody would ever have to figure out the size of a 13/64 inch drill or the number of teaspoons in a gallon. Everyone in the world would drive on the same side of the road. There would only be one standard for television. And so on. G-code is a pre-existing standard that the first people exploring the world of 3D printing adopted to save themselves a ton of work. It wasn't a perfect fit, but it worked "well enough". Now it's used by so many different organizations that it's an embedded standard and essentially impossible to replace. The best scenario I can imagine is a pre-processor that takes G-code and intelligently examines it to produce an intermediate code for the actual printer CPU and hardware to use. Kinda like back in the old days of computer programming on the Apple II, where you wrote in a high level language that got translated into "p-code" which then got compiled into machine code.

[aerogeek]

Standardisation around G code is probably what has helped hobby 3d printers. I would imagine with a bit of effort the additional processing power offered by the more powerful boards even 8bits/16bit running much higher clock speeds would be in the loop adaptive printing where the axis positions are accounted for and adaptive printing is made possible. I have seen adaptive machining use to good effect and thought klipper would allow that additionally/capability.

[Mooselake]

32 bit processors offer more speed to allow higher order acceleration, quicker recalculations during moves, better path planning, better extruder coordination and physics handling, and vastly increased memory that allows greater buffering and look ahead. Plus there's 9000 point <ducks> probing and autoleveling. My plywood V1 Plus is already limited by Marlin's step rate in X.

Faster microstepping helps with the chopper effect, but some of the new driver chips (like the Trinamics) will smooth out the choppy pulsy microstepping currents, another reason why replaceable driver chips is a good thing.

[rho-wan]

I flashed Klipper on the Printrboard rev D and it works very well
Since I already had an unused raspberry pi B+, it was a free upgrade.

Marlin was slowing down during certain moves due to recalculation of curves and acceleration, and it had no knowledge of the nozzle pressure. Marlin 1.1.x has it, but then it's even slower, see https://youtu.be/Hrkht3E2ThA (not my video).

Now it's flawless and quieter. And with the raspberry pi I also use octoprint. Anyone already using octoprint could benefit from Klipper at no cost.

I'm very happy.
I plan to attach TMC2208 to the expansion header of the Printrboard, since processor-wise there is no reason to buy a 32 bit boards anymore.

[Mooselake]

I've been giving some serious thought, although the project list ahead of it is pretty long. I have a (gasp) Ender 3 Pro (only mod a dual geared extruder that was around $15), the KSPP is in the other house. It could also be a potential PB replacement. Over in the Printrbot FacePlant group there's somebody making Printrbot mounting kits for them. The firmware is on github but you have to dig a bit for it. Haven't looked to see if it's a Marlin 2.x port or something else.

Half the price of a Printrboard at the end, a third of when they first started offering them. Had Brook gone with outsourcing them from the megafactories likely a Printrboard would be around this price or less too, and maybe PB would still be around. Think the Geeeeeeeeetech boards were less so a quality printrboard should only be similarly priced. Brook just did an (gosh, does everybody add a hundred characters of tracking to their URLs that has to be edited off?), one his big regrets was bringing board production in-house and having those big payments on the half million dollar (his estimate) PCB line. Interesting casual mention of the G on FP, they picked a rather expensive and slow 32bit CPU rather than the less expensive family most of the 32 bitters have picked

With the monstrous mob that's descended on us for the holidays (happens in SW FL..., darn yankees won't just freeze in the dark ) neither the E3P or 3018 are getting much use, but architect girl and I 3D printed a copper silk pla pro 100mm holey sphere tree ornament. Not perfect, some overhand issues on the bottom and knocked off the bead (no brim) 10 minutes (out of 3 hours) before completing, but some ribbon and it became a basket instead. New to silk pla (apparently pla with some polyester) and the metallic copper is a decent coppery equivalent if you squint a bit. Missed the filament type when it first came out so don't know how new and exciting it is, but I'd consider it again.

Kirk