Although we tend to think of 3D printers as high-tech toys, most of them are not especially powerful in the brain department. There are some exceptions, but most 3D printers run on either an 8-bit Arduino or some Arduino variant with a lot of I/O. There are a few 32-bit boards, but if you grab a random 3D printer, its brain is going to be an 8-bit AVR running something like Marlin or Repetier. It isn’t uncommon to see a Raspberry Pi connected to a printer, too, but — again, in general — it is a network interface that handles sending G-code to the 8-bit controller that runs the stepper motors. Would it make more sense to do things like parse G-code, map out curves, and set accelerations in the relatively powerful Raspberry Pi and relegate the 8-bit AVR to just commanding motors and heaters? [KevinOConnor] thinks so, and he wrote Klipper to prove it.
Klipper is mostly written in Python and it does most of the functions of traditional 3D printing firmware. It communicates with the onboard microprocessor by providing a schedule of when to do what tasks. The microprocessor then handles the timing and things like motion control for the axes and extruder. Klipper can control multiple microprocessors with no trouble and keeps them in synchronization, so you could have a processor for your extruder and one for each stepper, for example. You can use Klipper with a Cartesian machine, a delta, or a Core XY-style printer.
The host computer doesn’t even have to be a Raspberry Pi. The BeagleBone will work and — in theory, at least — so will any Linux computer. There’s a small bit of firmware you program on the microcontroller that speaks a lightweight protocol to the host computer. As for user interface, that’s easy. The host can talk to Octoprint and you can run that on the same Raspberry Pi that runs Klipper.
The microcontroller firmware only has a handful of commands. Most of those are related to something to do at a given time: operating a stepper motor or setting a PWM output. Because it is simple, you could have a small CPU and you could possibly get much faster rates. Of course, that assumes your hardware can handle a faster rate.
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.
Since the microcontroller firmware is very simple, it is easy to reconfigure things in Klipper just by changing a file on the host computer. The firmware is simple and in C so it can support many microprocessors including common 8-bit and 32-bit CPUs found in 3D printers.
Klipper is able to achieve precise high stepping rates. An older AVR can apparently achieve rates of over 175,000 steps per second and rates up to 500,000 per second are possible. Higher stepper rates enable higher print velocities.
At high print speeds, oozing can be a problem. Klipper implements a “pressure advance” algorithm for extruders. When properly tuned, pressure advance reduces extruder ooze, possibly allowing faster printing. You can see a video, below, of [Bradley Muller] printing at 100 mm/s using Klipper.
If that’s not fast enough, check out this cube at 150 mm/s (wait for the first layer to finish) from [lenne 0815]:
There’s also a novel “stepper phase endstop” algorithm that can improve the accuracy of typical endstop switches. This is especially important for the Z endstop since that can lead to a more precise first layer height and improve print quality and adhesion.
Tuning
Some of these features do require tuning. The pressure advance algorithm, for example, requires a machine-specific constant. Here’s some text from the document describing the software’s kinematics:
The “pressure advance” system attempts to account for this by using a different model for the extruder. Instead of naively believing that each cubic mm of filament fed into the extruder will result in that amount of cubic mm immediately exiting the extruder, it uses a model based on pressure. Pressure increases when filament is pushed into the extruder (as in Hooke’s law) and the pressure necessary to extrude is dominated by the flow rate through the nozzle orifice (as in Poiseuille’s law). The key idea is that the relationship between filament, pressure, and flow rate can be modeled using a linear coefficient.
You can find that value experimentally by printing a test square and finding the lowest number that gives a good-looking corner. For example, below is a mistuned corner on the left and a correctly tuned one on the right.
The endstop feature utilizes the phases of the stepper motor driver. For example, a stepper driver with 16 microsteps has 64 distinct phases. Instead of homing with one step resolution, you can home to the resolution of the stepper motor.
Barrier to Entry
What’s stopping you from trying Klipper? You probably have a Raspberry Pi hanging around. Klipper’s firmware probably works with your current printer’s CPU (just be sure you know how to flash code on it and have a copy of your current firmware).
We couldn’t help but think that if you could field this on a Linux laptop, you could just have a kind of super control panel for your printer. Of course, you could do that anyway, but you’d be leaving even more computing horsepower on the table if you used a laptop to just hook into Octoprint.
From a hacking point of view, being able to make changes in the 3D printing algorithms over ssh using Python without having to flash a microcontroller ought to open up a lot of experimenting possibilities. If you have an interesting fork, be sure to send us a tip and we’ll cover it here.
This is potentially a huge leap forward in any CNC system, not just printers.
this is how saner CNC systems (linuxcnc/machinekit) with appropriate hardware already operate.
the software and electronics in inexpensive 3D printers worked themselves up to “barely acceptable” and then stopped improving, as everyone went off to chase fancy bearings or whatever.
What?
i don’t know about Machinekit but the last time I heard anyone talk about LinuxCNC it was a Linux computer controlling steppers via the output lines of a few parallel printer ports. Everyone I talked to said even the puny 8-bit micro was better because Linux is a multi-tasking operating system with no real-time guarantees. At the moment it needs to step it might be busy managing the filesystem cache or some other non time critical task.
Given what I could learn from a quick scanning of Klipper’s readme and FAQ it looks like Klipper is actually a bit different from both of these. It uses the processing power of a more powerful computer to calculate better stepping from the G-code and still sends that to an plane old 8-bit micro to cache it and actually make the moves when the proper time comes. This makes sense to me.
I’m always wondered “why reach a position according the speed and the time set, instead according (re)calculated data using feedback like temperature and/or torque ?”
Plus, if we add the performances of the most powerful SBC, with some electronic like a ADC, it’s widely feasible.
if you’re starting a comment with “i know know about [thing now under discussion]” there might be some time savings available by researching the topic.
linuxcnc doesn’t run the normal linux kernel. and it can control all sorts of hardware, from parallel ports, to inexpensive FPGA boards with special motion control hardware http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mesa_Cards
machinekit on the beagleboard gets to use the little secondary PRU microcontrollers built into the larger processor to handle the motion control, the same way linuxcnc can use FPGAs to do it.
in both high-level non-realtime code can perform calculations and planning which are then passed down to the increasingly realtime layers of the system.
(and to be clear, good on the Klipper guy for doing cool work, and in particular for producing an implementation which can work with existing hardware. that others are doing it in no way diminishes from his hard work.)
huh. s/know know/don’t know/
And interestingly enough, Klipper has testing on the Beaglebone using the PRUs, and sure enough, achieves blinding-fast step rates on that too. Because the PRUs run at 200MHz, which pretty much leaves most other microcontrollers in the dust. And they’re closely coupled to the ARM cores, so communication between the non-realtime tasks and the PRUs is also low overhead.
Linux CNC uses real time kernel extensions, it always has.
https://web.archive.org/web/20041027135943/http://www.isd.mel.nist.gov/documents/shackleford/4191_05.pdf
Link goes to a 2004 PDF copy of a NIST paper detailing how they were using Linux with a real time kernel to develop EMC, which became the codebase of Linux CNC.
Clarification: the above PDF has a citation that the real time EMC Linux code was placed on Sourceforge in 2000. The sourceforge email archive for EMC corroborates this, documenting use of realtime code (and nonrealtime GUI code). https://sourceforge.net/p/emc/mailman/emc-developers/?viewmonth=200011
Yah.. it used RTLinux. Wasn’t that discontinued years ago? Are they using some really old kernel in order to stay compatible?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RealTime
RTLinux extensions for the 2.2, 2.4, and 2.6 kernels, still being developed: “RTLinux co-exists along with the Linux kernel since it leaves the Linux kernel untouched. Via a set of relatively simple modifications, it manages to convert the existing Linux kernel into a hard realtime environment without hindering future Linux development.”
And, as is discussed in the above link, most of us using linuxcnc on multicore systems disable kernel loading on one core so the kernel doesn’t schedule processes on it.
You also forgot to mention RTAI and the newer work on preemptive kernels. The nice thing about the latter is that RT-Preempt now comes standard with the Linux kernel, so no mucking about with patches. I was looking around for comparative latency reports, but I think that an RPi can do better than 25us, but I could be wrong. On a modern PC, I remember seeing 2us running RT-Linux back in 2005, and I am not sure how for it got polished down.
Also, I remember getting a copy of the EMC from NIST back in ’97 or ’98, and it has been around since ’89 or the early 90’s .
SO True. Settled on “just enough to not be a constant pain most of the time”
The whole landscape has settled on STL (with no color/material information and no metadata) -> gcode over 115200bps serial -> 8bit micro -> open loop steppers. Nothing has really changed since reprap switched from a slicer written in java and a DC motor running the extruder. It’s a sad day when some of the most forward-thinking formats are makerbot’s *.thing and stuff (documentation now released: https://github.com/makerbot/labs) or microsoft’s horrible voxel-based format that at least could be used to store color and material etc.
This is why we still have to deal with multiple-STL-file and multiple-gcode-file nonsense and other stupidity when printing with multiple heads, and why color printing with mixer heads and CMYBW are going to be such a pain in the @$$. A tiny little 8-bit micro (and arguably some of the 32-bit arm boards) are going to have a very hard time buffering enough data to control a continuously varying ratio of five different filaments. This rework of the printer control stack promises to make thngs a lot better.
And what are you contributing to change all that?
@Daniel
Oh sod off. What are YOU contributing?
I’ve been pushing forward trying to put together a system that builds on octoprint, providing a system of acces control and such for a local library hackerspace. I’ve also fiddled with building my own slicer to try and incorporate new features. You can bet I’ll be installing this as soon as is allowed by the laws of physics and will probably start my own fork down the road too. I’m sure it will play very nicely with afformentioned octoprint management system.
Mackinekit/BBB/CRAMPS has had no issues driving our CYMKW+ 6 channel mixing print head. That’s 9 synchronized 16x microstepping channels for 500mm/sec motion, and 6 channels of PWM all running on *one* PRU so the main processor is ~70% idle.
The mixing stuff still uses gcode to do it, and the injected color information is pretty verbose so definitely not ideal, but we had to start somewhere and the data rate has never been an issue. That software is open source, but most of the magic was provided by Machinekit anyway.
It is still good to see others pushing this forward as a Pi Zero + 8bit solution could provide a decent hard real-time solution on a shoestring budget and with the trajectory planner running where it belongs: on the Pi.
@M
Nice! I suspected you where one of those ”you suck for not implementing my feature request on your spare time!” people.
Me? I don’t contribute anything
Read the OFF and COFF format specs. Color is defined but optional. Maybe you just need to flesh out the implementation a bit (or just access what is already there).
A lot has changed in some respects, the machines are a tenth the cost to build now and by and large, they’re made better now too. You’re talking about a market that’s largely allergic to spending any more than they have to, and I think they’d stick with the current stack even if a demonstrable improvement can be made by spending $20 more. Printing over a virtual serial connection needs to go away for a lot of reasons, but if you print from SD card you can get away from that serial bottleneck.
I think the problem with colors is when you’re talking about FFF, multiple filaments multiplies the potential problems. Even just soluble support to the process gives people grief. Multiple materials ends up being a niche project. Once you do go multiple filament, such as with Pallette and what Prusa was making the multi material option, you’re doubling the amount of plastic needed (or more!) for the purge blocks, and if the print fails, you’re at least doubling the waste. Then to say nothing of the companies that failed, like botObjects, which got bought up by 3D Systems and barely heard from again. XYZ has their full color FDM printer but that uses inkjets on the carriage to add color so that carriage gets to be pretty big and their machine costs $3000.
@aging: parallell port only lived on with LinuxCNC because it was “free”. There have been much better options available for a long time and LinuxCNC is still the best open source option for controlling everything larger than a 3d printer.
Any serious builder are not using parallell port with LinuxCNC, we left them a long time ago for FPGA-accelerated interface cards like the Mesa Electronics 7i76e that does all step generation on the card and communicates with LinuxCNC via ethernet.
Or you can go the MachineKit route and use the PRU’s on the BBB to generate steps in real time and the backend on the ARM processor. The only problem there is that the BBB really is not powerful enough to handle the GUI in a good way, in combination with no finished remote interfaces, this has kept me from going to MachineKit.
The BBB does have enough horsepower for a decent GUI. Issue has been that the TI drivers for the built-in GPU are not open and have never worked right on Debian, so everything (read as openGL) was emulated. It performs great considering that..
Last month has been interesting though: Machinekit now runs on 4.4x-rt kernels, so this is closer to getting sorted than it ever has been before.
I personally use the remote interfaces (Machineface/Cetus) as they are nicely hackable anyway.
@ Aging troll, who so ignorantly claims: “Yah.. it used RTLinux. Wasn’t that discontinued years ago? Are they using some really old kernel in order to stay compatible?”
Yah, commercial support was dropped when development was picked up by the community nearly a decade ago. Latest development version (4.13) is dated 2017.11.17; latest supported version (4.09) is dated 2017.11.21. Both versions are for the associated current kernel versions.
For lasers and 3D printers yes, for cncs not so much as you ideally need “S curve acceleration” which is only possible with tinyG or older host based motion controllers like Mach3 f.e. Klippers motion planner is based on grbl, smoothie uses the same planner f.e. Still Klipper is a milestone in hobbyist 3D printing, it allows for cheap 8 bit controllers while still achieving smoothieboard levels of performance.
Take a look at MachineKit , which started life as a fork of LinuxCNC (nee EMC). There are lots of reasons to look into using it over LinuxCNC (including S-curve acceleration). tinyG is interesting in that it can do higher order profile smoothing above jerk, but last I knew was not configurable for delta kinematics (that is why I did not go with the tinyG on several machine rebuilds).
In general I found that MK has more features and is easier to work with, while LCNC is more stable.
Right direction and makes sense. New to all this but not to timing , electronics, and core level software. USB great for ultra slow speed stuff Pio has always been for high speed and accurate stuff. Everyone can use Pc->USB->dumb controller->motor . My Anita project is full scale CNC with 3D Print head (removable) with built in RPI3B+ and looking for way to not have to use USB->Arduino for Gcode processing. My old Z80 circa 1972 ran 1MHz and was faster in all regards to the Arduino. The RPI at 700 to 1400MHz and trimming down to 11,520cps to talk to a Arduino which then has to translate/parse a 4 to 6 byte code into a single bit just has me scratching my head. Talk about latency! What I think would be good move is to not use slow rxd/txd at 115200 over USB to talk to Arduino but to send op codes via parallel to the Arduino at say 290KBps (that’s bytes not bits). As op codes it takes far less storage space, 0 need to parse them into action, and the Arduino since everyone thinks it is better at motor control than a rpi can live happy. Now all we need to do is figure a way to either rewrite octapi to not send gcode to Arduino but instead send it to RPI gcode opcoder (klipper).
I was skeptical about how fast it could speed things up till I watched the video… damn!
Wait till they discover closed loop feedback, and brushless servo motors. ;)
I “discovered” them a long time ago, a typical stepper kicks out at about 1k rpm which would give a theoretical top speed of 600mm/s I dont see any reason to try to up that by implementing rather expensive servo systems. Furthermore closed loop has been introduced to 3d printing by trynamic quite some time ago, even if the need for it might be controversial.
A typical stepper reaches a top speed of 600mm/s in a typical 3D printer application, servos are pointless there. Closed loop has been implemented by trynamic f.e. but the benefits of it for printing are up to debate imo.
isn’t this exactly what Machinekit on a beaglebone black does with a CRAMPS cape? machinekit on the OS side reads plans and schedules the moves, and sends to the PRUs to execute. I’m all for new things, but i’m genuinely wondering if its the same thing or not.
Yes, and yes. Same thing, with a real trajectory planner to boot.
The BBB is the architecture being discussed here implemented on a single chip. It also has much higher clock speeds, a shared memory interface between the OS processor and hard real-time components, and is overall a better solution.
But…
– The BBB itself is still $50. You could get similar levels of performance this way on a couple channels for $13.
– The BBB is delicate electrically compared to what the 8 bit stuff will tolerate.
– You need to program the PRU’s in assembly for predictable single clock cycle operation.
– The cheaper variants such as the BBG/BBGW are not fully pin compatible with the common/existing capes.
I’m actually working on that last point myself with an ultra simplified BBGW compatible cape in use on our latest experiment. It’s still on perf-board as of yet though, but simple enough it could just stay that way.
How is the trajectory planner from machinekit different ? does it use jerk controlled motion ?
from the MK code:
file: machinekit/src/emc/motion/control.c
/*
* 07/09/2005 – S-curve implementation by Bas Laarhoven
*
* Implementation:
* Generate a ramped velocity profile for backlash or screw error comp.
* The velocity is ramped up to the maximum speed setting (if possible),
* using the maximum acceleration setting.
* At the end, the speed is ramped dowm using the same acceleration.
* The algorithm keeps looking ahead. Depending on the distance to go,
* the speed is increased, kept constant or decreased.
*
* Limitations:
* Since the compensation adds up to the normal movement, total
* accelleration and total velocity may exceed maximum settings!
* Currently this is limited to 150% by implementation.
* To fix this, the calculations in get_pos_cmd should include
* information from the backlash corection. This makes things
* rather complicated and it might be better to implement the
* backlash compensation at another place to prevent this kind
* of interaction.
* More testing under different circumstances will show if this
* needs a more complicate solution.
* For now this implementation seems to generate smoother
* movements and less following errors than the original code.
*/
Where is the configuration for backlash setting?
In the configuration .ini file, per axis, you set BACKLASH. Then whenever the axis needs to switch directions, it automatically adds this amount to account for it. http://www.machinekit.io/docs/config/ini_config/
Let’s integrate tensorflow :)
Is that the new “can it run a Beowulf cluster”? ;-)
Is that like “can it run Doom”? :-D
or how about Zork or Rogue? I still marvel at the time I joked that we should port Zork or Rogue into OSv, and someone when and did it that very night…
Okay, now I need to port Rogue to my 3D printer. Who needs tractor fed greenbar printers with an infinite print volume? https://hackaday.com/2017/06/06/the-ip-of-the-infinite-build-volume-3d-printer/
:-)
@ar0cketman. This is why I love you guys ;-)
Not sure how it would work but I’ve been kicking an idea around in the back of my head lately of integrating a STM32 with the TCM2130 driver then controlling each motor over CANBUS, CANopen or some variant. Combine it with an open framework design like https://hackaday.com/2015/03/01/cardboard-cnc-machine-boxes-up-both-a-tool-and-a-framework/ and the possible configurations should be very open, fast and accurate. What am I not seeing downside wise?
Synchronization.
CANopen has the Synchronization Object (SYNC) protocol which appears to be able to keep everything coordinated and combined with PDO can even lock multiple nodes together to act as one unit.
I think about that every time I’m lacing a bundle of wires on a printer.
Ouch, looking into it a bit I found an off the self product already doing this on CANopen but at +$500 per stepper/servo the TSM17C is not going to be home experimentation friendly. It actually sounds more like the programming is the biggest hurdle but there does appear to be some open sources to use for examples so down the rabbit hole I fall.
LOL, while it was a fun thought and I found several Industrial examples (see for an idea- https://www.trinamic.com/fileadmin/assets/Products/Modules_Documents/TMCM-6210_6211_hardware_manual_V095.pdf) it would be a project that is way beyond what I have the time or experience to tackle.
I just leave it here:
https://www.ebay.com/itm/172998817736
That sounds so awesome! Can’t wait to come home to try this out.
Did I get it right? I install Klipper on my raspberry pi 3, connect it to my ultrtronics (Due) and switch the Ultratronics Firmware with a Klipper firmware right?
Possible game changers:
1) re think the idea of the slicer. Would it be possible to
use the Z-axis in co-ordination with X and Y to produce
a smooth transition in Z as opposed to discrete steps
2) Feedback motion control (servo drive) that is the de-facto
standard in all desktop printers we use today. Steppers
are easy to drive, but lets face it folks, they SUCK when
compared to servo.
something like this?? https://hackaday.com/2014/04/13/printing-in-three-dimensions-for-real-this-time/
something like this?? https://hackaday.com/2014/04/13/printing-in-three-dimensions-for-real-this-time/
Exactly — I saw that write-up in 2014 just like you — and then — POOF? gone. What happened to that ? Was it just too damn complex to do? I would love it if HAD did a followup..
“Topolabs Technology LLC was founded in late 2013 by James Page and Mark Sears. It was acquired by Autodesk in July 2014..” — ‘Nuff said. Just like Eagle, ruined by AutoDesk.
It’s about the trade-offs, especially to the self-builder. Servos add cost and complexity and the return really isn’t as significant as people hope. When you have an engineering department and sales volume to get you economies of scale, servos make sense. Even the home CNC hobby can’t justify it so much either.
Also, some of the advantages that were once the sole domain of servos are now available to steppers with the Trinamic family of stepper drivers. StallGuard can detect a skip, home that axis and continue printing as if nothing happened.
One thing I really dislike about most 32-bit printer controller boards is that they try to use their extra power to be everything. They include Wifi or some other form of networking. That sounds nice and all but they still aren’t as full featured as Octoprint. I would rather have a powerful processor on a printer control board just taking it’s input via a ttl serial line just like any old 8-bit board and using all it’s processing power to do the best possible job printing. Then I can attach a RasPi to that ttl serial line to provide all the fancy networking stuff.
Of course I can just ignore the boards networking features and do it this way anyway but… then it’s still there. I know that the board has some feature I am not using. That bugs me. Maybe I need help but that’s how I am.
I wonder which boards you’ve looked at. With the Duet, the only thing I really miss with Octoprint is time lapse handling. Duet does a better job printing than any 8 bit board that I’m aware of, it’s easier to tune and adjust and has a lot of controls that make Octoprint seem sparse.
I feel similarly about the 32bit boards, luckily there has been a lot of development on projects such as Marlin 2.0 which features a hardware abstraction layer allowing it to run on Arduino due, and smoothie boards. Repetier host also has similar capabilities but as of now it’s limited to the Arduino due. The tinyg g2 project is also worth checking out, it’s known for it’s incredibly intelligent path planning and no frills features.
“I know that the board has some feature I am not using. That bugs me.”
What about all the features of the Raspberry Pi that Octoprint doesn’t use?
(I admit to feeling the same way about leaving features unused sometimes. I also feel compelled to put something in every compartment of my backpack or suitcase.)
I have a printer or two I am willing to sacrifice to this. What changes on the Octoprints end? Would the whole process of sending gcode files from Slic3r/Cura stay the same or would they have to be sliced in Octoprint every time?
You can create your gcode wherever you want as long as its repetier compliant. Beside configuring klipper host as the “output” port there are no changes to octoprint to be made. Its far from a sacrifice, to put it florid: You are finally giving them the chance to ascend to the heavens of a proper 2nd order motion planner.
That’s also what Replicape HW and Redeem SW is doing – check it out, it’s pretty cool! It’s using the Beaglebone PRUs for the low-level stepper control and the high-level planning runs in the regular CPU. I’m planning to build a printer with thermocouples, a heated enclosure and some other stuff using it because it is also easily hackable since the high-level layers run in Python. Link: https://www.thing-printer.com/product/replicape/
Thanks for mentioning Replicape/redeem! There are a lot of similararities: Python, I assume a pre-calculation of path segments, getting rid of Breshnam, and an implementation of Pressure advance, OctoPrint integration. I’ve considered porting redeem to other platforms like raspberry pi, but instead I’ve chosen to stay with the BeagleBone platform because it is much more suited for industrial applications like CNC/3D-printing.
What else do you use for path planning ? the only info i could find points to a mention of “repetiers planner” which is breshnam based afaik ?
Found it myself here ! https://replicape.github.io/replicape/configuration.html So a trapezoidal implementation aswell ! Very nice ! now we have three players i know of: Smoothie, klipper and replicape ( Am i missing one ? – Not mentioned due to cnc centric focus- Grbl, Tiny G2 )
There’s interesting concepts but the article makes a bit too much about pressure advance. Pressure advance is not new, various firmwares haven’t been using it. I think Makerbot was doing it in the Replicator 2 era. Prusa just added it to its Mk series of printer firmwares, Duet added it this year it seems.
It’s not clear to me that the machines in the video are moving any faster than it could with other firmwares.
This might be an improvement but I’ll stick with my regular Duet firmware for now.
Linear Advance has existed in Marlin since Jun 2016. PRUSA uses a modified version of Marlin and they just recently made reference to it.
http://marlinfw.org/docs/features/lin_advance.html
JKN Advance K has been in Sailfish since Oct 2012
http://www.sailfishfirmware.com/doc/tuning-jkn-advance.html
JKN Advanced K2
http://www.sailfishfirmware.com/doc/tuning-jkn-advance2.html
DUET is still too high priced for what it does. Alot more people would own them if they would drive the price down. I can buy laptops for how much the DUET costs.
I’m not convinced you know the full breadth of what Duet does though. Duet is the most powerful and flexible 3d printer control board available right now. You have to push very hard to find something it can’t do. Just the motor driver chips cost 2-3 times as much as the drivers you’re used to, I run a machine with NEMA 23 motors on it and it performs with zero issues. The klipper docs even suggest that Duet can run at about five times the step rate of an AVR-based board.
> I can buy laptops for how much the DUET costs.
That really doesn’t say anything though. The only thing similar about them is they’re both electronics. They’re otherwise totally different products, for totally different markets. I’m pretty sure the Duet developers aren’t buying Ferraris with sales. Even the Chinese clones of the Duet boards aren’t any cheaper.
@JRDM I know what it does and what it can do and how long its been out and I do not see its adoption rate increasing as fast as it should be even by people seeking to upgrade their existing Chinese printer.
Even the Duet Wiki mentions the same thing about adoption rates being an issue in the Cost section.
http://reprap.org/wiki/Duet_design
Every year consumers, investors and reviewers do price breakdowns of every piece of hardware from PC’s, Motherboards. Ram, Storage, Cell phones, Game Consoles, and LCD TVs. So don’t think for one second that 3D Printing and its associated hardware has not been left out of the process. So from my point of view using laptops is a valid example because the parts that it takes to build complicated hardware fall continuously year after year.
Here is an example if you are not aware of ‘cost breakdown by component’.
http://www.businessinsider.com/iphone-7-ihs-teardown-list-of-component-prices-2016-9
So you can’t argue that the TSMC chips or Atmel Processors are going to stay forever priced the same.
It costs $196.49 US Dollar to ship a Duet Wifi to the US. That is almost the cost of an entire printer. It’s actually $50 less than what it cost me to buy a CR-10 in 2017.
I only found one Chinese clone and its currently listed at $130.
https://pt.aliexpress.com/item/S-aqui-dueto-Wifi-placa-Controladora-DuetWifi-Motherboard-para-Impressora-3D-e-cnc/32841078160.html
I am sure many more people would purchase it if it were at the $100 price point. Maybe it will go down once there are more competitors in its range since Marlin is pushing to 32 bit in 2018.
The problem is the economies of scale. A laptop and a 3d printer controller aren’t comparable because the markets aren’t anywhere nearly the same volume scale. I too believe that more people would buy it if it costs half as much but basic economics says you need 10x the sales volume to do that, any less and it’s less profitable. That’s a huge risk to take.
Also, 32bit marlin adds almost nothing to the table while carrying forward a preponderance of legacy cruft. That project seems to be maintained by people that know nothing about other 32 bit firmwares.
@JDRM
Forgive my ignorance, but, how does firmware maintained by “people that know 32-bit” look like?
I am a new learner, so, any pointers would be helpful.
@Afdhal Atiff Tan
I look for a few things. One is how much configuration can I do without reflashing the firmware. The only times you need to reflash smoothieware or Duet is to upgrade the firmware to a new version. All configuration is by SD card, and editing that file is all you need to do to change how the board operates. With Duet, just sending it g code can change anything setting on the board’s while it runs.
Another thing I look for is how I can configure thermistors. Marlin relies on thermistor tables, whereas with Smoothieware and Duet, I can just give it three key numbers and I can configure any arbitrary thermistor. So it’s a few minutes vs 30 minutes grinding out a new thermistor table if the thermistor is that supported with an existing table. And any adjustment I can do right away by changing the numbers instead of grinding out another thermistor table with improved values.
I like Duet’s deadtime heating algorithm. Tune it in one cycle and it’s good for a much wider range of temperatures than PID. The wider range of temperatures you use, the more the difference is noticeable.
I can change all fan behavior without flashing as well, such as a fan that turns on when a sensor is above a set temperature.
Those are the examples I can think of right away.
@JDRM
That is a very helpful thorough reply, thank you!
To me it’s not about whether it’s better than something like a Duet. It’s about expanding the capabilities of the hundreds of thousands of 8 bit boards that already exist for only the $35 cost of a Pi (or possibly nothing as many people already run OctoPi). If you’ve already sunk $180 into a Duet and you like it, that’s great. I spent about that much on a Replicape and Beaglebone Black wireless setup. In hindsight I probably should have bought a Duet wifi instead, but I’m not going to double my investment at this point. I also have an older 8 bit MKS Gen board with TMC2100 drivers that already had a Pi attached. So for the cost of zero dollars and a couple hours of tinkering, I ended up with a much more user friendly printer (no more flashing firmware to change settings, much simpler config file) that also runs quieter due to better motion planning. And as a bonus I can run the same firmware on both the MKS board and the Replicape meaning I don’t need to learn yet another firmware.
I’ve been working with inkjet and stepper control for some years now; the stepper control do have a big impact on all the movement and really most of what I have seen in average to low cost 3D printers is enough to make it work; not efficient and I also noted most people do not realize how important and what does exist to enhance the movements and thus, the print results. With no absurd costs.
Please post a list of suggestions. I know I know of a half dozen, but it would be nice to see what else others have to suggest.
Yes please. Post a list.
I’m working on a delta to try this firmware on, and any additional pointers to good directions of research are appreciated.
I think i am spoiled by having smoothieware delta for the last 3 years or so. Cause that 150mm/s seemed slow. Since I often peak at around 180mm/s.
Sounds impressive, any video?
to lazy lol, cause of how messy my printer/parts room is. Honestly the 150-200mm/s peak range, has been reachable by the 1000$+ FDM printers for a quite a while. Its part of the reason Ultimaker runs the 2.85/3mm filament, or atleast its part of their claim. So they can force more through the hot end quicker. For fast prints. One of these days I will swap a E3d Volcano onto the delta. That would help a bunch with high speed printing. I mostly print ABS, which has a much lower friction through the hot end than most PLA’s do. PETG in my experience doesn’t do well at high speeds, but i haven’t played with it much. Fastest I have ever printed a TPU is is closer to 90mm/s but it was fairly stiff TPU, and i always turn retraction off for TPU’s.
https://www.youtube.com/watch?v=clixTeZ3fJA 250mms topspeed.
I just started very much the same project for a different reason. I am using high speed galvanometers and I want to drive them with gcode but I could not be bothered with doing all the work in C in the micro-controller. After 20+ years of doing C I have been doing python for the last 10 and I CBFed doing all the parsing and such in C so, much the same as this, I interpret the gcode and do the maths in python and stream XY coordinates with timing and power to the C on the controller where it can run fast and efficiently with no FP or math. It also makes the code really simple.
I looked at doing essentially the same thing, but starting with PH-ccurves (which are splines parameterized in arch-length), and also looked into variants of NURBS parameterized in time and steps, so you get the time, step and direction lists for each axis. If you can do that off-line then motion is just sending the pulses. Nice thing is that this can account for microstepping, so you get very smooth motion and can also calculate various dirivitives and smooth over them (think jerk, snap, crackle, or pop).
Will it work on a Monoprice Mini?
It would be iffy. The monprice board is closed source although we did a post about someone reverse engineering some of it. It is a 32-bit board and if you could map your I/O and get code into the bootloader, it _ought_ to work. But a lot of work. If someone did that, I would be willing to bet it would get posted here.
I am working on a project where I have to code my own motion planner (basically a cable-driven robot). Is there any books/resources that anyone can recommend?
I just learned that some planners use Brensemham’ Algorithm. I think this alone is not enough.
The best video on this subject that I found was (by Derek Schulte): https://www.youtube.com/watch?v=fQcRxt9qlIY
I tried to read through other open-source projects like Marlin and the like, but I find it difficult to comprehend.
Any tips?
Look at the absolute top end https://github.com/synthetos/g2/wiki/Jerk-Controlled-Motion-Explained Klipper and smoothieboard are “one step below” both implement trapezoidal acceleration first seen in grbl.
Thank you for the link!
take a look at the early work of LinuxCNC (nee EMC) which had as one of its very early use cases a cable based “robocrane”. I cannot find the videos I have seen before… Anyway, setting up the kinematics is tricky, but all the code is already done in LinuxCNC.
Thank you!
> An older AVR can apparently achieve rates of over 175,000 steps per second and rates up to 500,000 per second are possible.
Which is a load of bollocks. At the end of https://github.com/KevinOConnor/klipper/blob/master/docs/Features.md
It clearly states that it can only reach 100k steps/sec as soon as 3 motors are running. 3D printing requires 4 motors. So inflated stats for high numbers.
Which matches the results of my experiments that you run into interrupt overhead issues when you go over 60 kilosteps/sec on 5 motors.
(Still a whole lot better then the 40kilo steps that Marlin can achieve on a resolution of 10khz)
At what point in the process of a Cartesian machine do you run more than 3 motors at once unless you are doing “vase mode” or multiple extruders? Normally, you run XYE and then Z. That’s it. I agree there are other things that would prevent you from hitting very high numbers (limits on extrusion, etc.) but I think they were trying to show an asymptote to how much motor performance is possible. After all, a laser engraver wouldn’t have the E motor nor limits on extrusion.
If you do software bed leveling, you are stepping the Z as well.
As to the maximum steps pr second needed, Wiley from the Replicape Slack forum ran the numbers on that, since they looked a bit odd in this article. It’s rare that you need anything beyond 375 K pr stepper. Assuming you have TMC2100 drivers for instance, the maximum full step speed is 23.4 K if using the internal oscillator. With 1/16th micro stepping that translates to some 375 K. If you have TMC2130, that number goes up to ~6 M steps pr second if you want to go all in on the 256x microstepping without interpolation.
The 689 K quoted on Klipper seems on par with what we have for Replicape/Redeem as well, but it’s in total, not pr stepper.
The replicape uses repertiers motion planner which is akin to “nonexisting” so no matter how fast it pulses, its out of the game early.
Edit: ( as i somehow cant edit comments here ) I might be very well wrong on that.
That is completely wrong. The first C++ implementation of the path planner done some 3-4 years ago was based on Repetier, yes, but it’s since been rewritten several times, and other than the licence and the reference to the original work, there are very few similarities. All calculations are done with floating point numbers using the NEON SIMD, the Bresenham algorithm is gone, it’s scalable to 8 axes, theres pressure advance and of course, step and direction is pre-calculated rather than counted, so yes, you are very wrong o that : )
Yes, i found more recent documentation, sorry for my mistake ! I found it exceedingly difficult to get good information on the replicape firmware ( google seems to hate it for some reason ) so i had to read through a lot of outdated stuff until i found this https://replicape.github.io/replicape/configuration.html
> > An older AVR can apparently achieve rates of over 175,000 steps per second and rates up to 500,000 per second are possible.
> Which is a load of bollocks. At the end of https://github.com/KevinOConnor/klipper/blob/master/docs/Features.md
> It clearly states that it can only reach 100k steps/sec as soon as 3 motors are running. 3D printing requires 4 motors. So inflated stats for high numbers.
> Which matches the results of my experiments that you run into interrupt overhead issues when you go over 60 kilosteps/sec on 5 motors.
I think you’ve missed that Klipper does something fundamentally different from Marlin. Klipper does not use the Bresenham algorithm. Klipper does not raise a hardware interrupt for each step event. Each motor event is scheduled independently, so a stepper that is stepping infrequently has a negligible impact on performance. The AVR single stepper benchmark is equivalent to a Z move on a traditional cartesian robot. The 3 stepper benchmark is 3 steppers all simultaneously stepping at high rates – it’s a bit of a worst case scenario (think Z moves on a delta robot). No common gcode printing move steps three motors simultaneously at high rates (the E is almost always a negligible amount of steps compared to XY).
The benchmarks are just benchmarks – they’re intended to guide development and provide some baseline numbers. However, the greater accuracy of step timing and the significantly higher real world speeds have been demonstrated repeatedly. Install it and prove it for yourself!
So, could we be using one $2 ATmega328 Arduino Pro mini per stepper instead of one expensive a Arduino Mega2560 + RAMPs?
Sure we’d need to come up with breakout boards for the stepper driver, hotend and heated bed but since it’s safer to use one of those external MOFSET for the heated bed anyway, I’m pretty sure the total cost would still be below the regular low-cost setup. And the display, file loading, etc would be much better handled with a RPiZ.
The only missing part is a PCB to easily connect everything together.
I don’t think they’re advocating using separate MCUs for each driver. I suppose you could though. Closed-loop motor operation is easier if you have one MCU per motor.
On-board FETs can be fine but the problem is people are using dodgy, unfixed boards with “thermals” that reduce thermal conductivity. One simple fix would probably reduce the problem significantly.
https://blog.adafruit.com/2017/03/23/the-melzi-problem-or-why-did-my-wanhao-i3-duplicator-catch-on-fire/
They also seem to use screw terminals by the lowest bidder. Using 12V power isn’t helping either, 24V gets better motor performance and cuts heater current in half.
Oh…. htat nonsense again. Those “thermals” are short. They do not act as a long wire: They conduct heat to the bigger power-plane much more than a wire of that width would. I notice this in that it is much more difficult to solder on pins that have those “thermals” instead of just a simple wire for the non-power-pins. Even when those thermals are MEANT to prevent those soldering problems!
The reason thermal make it easier to solder is because it’s resisting sinking heat, and that’s detrimental to actual operation. You use a higher power iron to deal with that. Notice how the power pin with full plating on the same board is perfectly clean.
As Nate B replied to my post above “Synchronization”. While you could run your pro minis as slaves of an uno or RPI there is not a good way to synchronize them to the degree we need for motor control.
Wouldn’t a simple “execute command” clock signal from the RPI shared by the slaves do the necessary synchronization? It’s more of a matter of cost and component count to use an MCU per motor rather than a control issue.
Now consider hitting emergency stop, or just a simple speed/feed override, and coordinating them across multiple distributed machines. It is possible, but a pain…
Estops and feed changes are important, but they operate at the speed of a human. 10-100ms is all the time in the world for an mcu based system doing several kHz motion control.
I installed this last night on a printer I’m getting ready to sell. I’m swapping out the control board anyways before I sell it, so I figured I would give this a test run before tearing it apart. Now I don’t want to go back. My setup is a Tevo Tarantula with MKS Gen 1.4 board and TMC2100 drivers at 24V. It worked fine with Marlin, but I’m not a fan of the need to re-flash every time I want to change something that’s not available in eeprom. I also found Marlin to run the printer somewhat loud even at 24V. I definitely notice a difference in the acceleration and deceleration setup for Klipper versus Marlin, and the entire printer runs noticeably quieter even with pressure advance enabled. I’m also getting much more stable hotend temps and less overshoot on Klipper, even though I made numerous firmware adjustments and various attempts at PID tuning on Marlin. I’m also getting comparable print quality with Klipper after an hour of tinkering, versus the dozens of hours I spent tuning Marlin over the past 18 months. A few more adjustments in the firmware and slicer settings will likely yield even better results. All of this has convinced me that I’m done with Marlin. As an extra benefit Klipper also recently added support for the Replicape, and I happen to have one sitting in a box waiting to be installed on a new Hypercube. I’m looking forward to seeing where this project goes in the future.
I have a Replicape and after many months of frustration and lack luster prints using Redeem I actually shelved the Replicape and bought a Duet.
I approached Kevin and asked if he would port his brilliant firmware to the Replicape and to Kevin’s credit he had a port up and running is a very short time.
I can say without hesitation I was getting smoother better prints in no time at all and issues that arose Kevin fixed in hours to a few days at most.
Don’t get me wrong Redeem has most likely improved greatly since my experience. Just for me I will stick with Klipper.
I think Klipper has great potential to be able to use on a old Ramps or a Replicape. and a lot of other controllers.
Challenge accepted, Al! After your statement about the barriers to entry, I thought “Yeah, why not?”. I’ve been in the process of updating my MP Maker Select V2, and had already ordered an MKS Gen 1.4 to replace the Melzie sitting in the case so I could use the Trinamic TMC2100 in StealthChop mode. Grabbing a spare RPi Zero W wasn’t too far out of my way. Because of my upgrade directly from Melzi to Klipper + TMC2100 + Ramps, It’s tough to tell what benefits are due to which bit of hardware, but I’m awfully pleased with the combo. It does turn out that the speed is taken down quite a bit due to the stealthchop function due to current limiting. I am considering adding switches to the case to enable Trinamic’s other function, spreadcycle, which would support the additional speed capabilities from Klipper.
I am sorely tempted to move one of the two big printers over to try it. Sadly, I use Repetier Server instead of Octoprint and I hate to break my workflow. Just think of how easy it would be to add a really sharp touchscreen LCD to this compared to trying to cram it into the 128K with Repetier (no offense to Repetier’s LCD system, but there is just not a lot of room to work).
Don’t get a Pi Zero. It’s not fast enough to handle Klipper without some hiccups. I have one I thought about trying, but others are reporting issues, and the developer has indicated it won’t likely work very well. You really need a Pi 2 or Pi 3.
It is not klipper that’s the problem. It is octoprint.
So while klipper is deconstructing GCODE commands from a “move 10mm” into 1000+ step commands for each of the steppers, compressing them and sending them to the firmware, Octoprint is having trouble sending that single 30-byte GCODE command to klipper.
Measurements indicate klipper needs about 10% of a pi-zero-cpu for all this, while Octoprint can require more than what is available.
Fortunately this has been resolved in a recent feature addition. Klipper can now emulate an SD card which allows Octoprint to hand off the gcode file directly to the host portion of Klipper. I was having significant host buffer issues with my BeagleBone Black, but printing from “SD” has completely eliminated this problem. I also have a Pi Zero W that I plan to test, but I’m guessing it will work fine as a host computer now with this feature.
Can a PocketBeagle Board run Klipper? Would it be better or worse than a Pi 3?
Linux CNC has always been real-time since our involvement and has CNC machine, mills, lathes, etc.., running at much faster speeds than the Kipper printer. In fact I’ve seen several 32 bit systems running twice that speed. I would think the Pi has a better advantage than given though nowadays enough x86 mini boards exist like Intel’s Aaeon Up Squared (pi platform/more powerful) which can run a printer or CNC using any number of processes for $89 and up to $599 depending upon model and starter kit involved. So it makes far more sense to invest into Intel technology as not only a cost effective but quality alternative to a desktop or any other standalone process and the Atom and Celerons love to run Ubuntu/Linux platforms. I’ve even seen 1050ti gpu on youtube connected To the Aaeon M.2 card slot which tells me connecting a Mesa 5i25 or similar pcie board is not only doable but can be done in a small box controller kept inside the builders panel enclosure with a touch screen interface swing arm hanging off the z column or face of printer enclosure. We are working on such a project at work but I’m sure someone will have theirs completed before we do.
[I’m new to this so could be a dumb question.]
Could Klipper just save the more complex operations to a file to be run directly from SD card by the printers 8-bit processor? So that it wouldn’t need to have a raspberry pi or additional processor connected doing it in real time. Perhaps it could be like a ‘Klipper Lite’ option for better prints, but without the real time config changes.
Sorry if I’ve misunderstood things.
In the process of upgrading 2 Printrbot printers I had ordered the G2 controller. That failed epically. I am looking to replace the controllers with a Raspberry Pi / Klipper combo. If someone has done this, what would be a recommendation for the controller interface?