@Preston_Bannister the reason printers are stuck at 60mm/s has nothing to do with the electrical/mechanical engineering, nothing to do with the “primitive” sensors, etc. Those limits are all imposed by the plastic we are depositing. 8-bit controller software is more than adequate for motor timings (if Klipper firmware is anything to go by), plastic state transitions aren’t controlled crudely in more well-engineered solutions such as the E3D hot ends. They are very much highly analyzed and simulated in CAD environments to ensure good performance.
Plenty of the enthusiasts here can push a printers mechanical aspects up to the 200mm/s range (in straight lines so acceleration can account for rigidity issues) without problem…so long as we aren’t also trying to push plastic at that speed. It’s the material that’s the limiting factor here, not the technology driving the motion platform.
@ThantiK that’s only true up to a point. Plastic melting/cooling speed is only a limit if you’re printing large strands relative to the nozzle speed. There’s absolutely no limit on the plastic deposition side of things that stops people from printing 0.1mm tall x 0.4mm wide strands at 200mm/s. You get finer resolution that way than if you print 0.3mm x 0.6mm strands at 45mm/s with the same volumetric flow rate of plastic.
I’ve run actual prints on some of my faster printers at 200-350mm/s this way. Most printers, even cheap Chinese ones, can hit 200mm/s from a mechanical standpoint. Simple speed isn’t what causes quality problems, it’s acceleration and cornering forces that cause print flaws. So why doesn’t everyone just print small strands at 200mm/s commanded feedrate all the time and let firmware figure out when to slow down?
The reason is lack of any substantial changes in motion code concepts over the last eight years. Sure, a lot of people have junk machines, but if you have a well-designed and well-tuned printer, it’s actually FIRMWARE ACCELERATION ALGORITHMS that limit the print speed/quality tradeoff. Namely, complex perimeter geometry that confuses the GRBL-derived acceleration code all the mainstream firmwares still use.
The basic approach of identifying a maximum corner speed and controlling acceleration in a straight line into / out of the corner was invented for GRBL to allow 1990s-vintage processors to do realtime motion control. And it has huge problems with arcs/contours because it doesn’t track centripetal acceleration. It basically just does contours at constant velocity, and different firmwares have various pathological behaviors on long runs of small segments due to issues with transmission speed and queue depth and so forth. That’s a major reason why we can’t print fast – the motion planning and acceleration code doesn’t work well on complex geometry. Every major change to Marlin, Smoothie, Repetier, RepRapFirmware, TinyG/G2, etc so far has perpetuated that model.
@Preston_Bannister The argument for Z braces is based on the X bridge reaction forces being out of alignment. The lines of force exerted by the X belt and the reaction force from accelerating the mass of the X carriage are offset from each other and from the XZ frame structure, so you get a moment/torque exerted on the XZ gantry during every X acceleration. That tends to TWIST the XZ gantry about the Z axis. Z braces keep the XZ frame structure from twisting.
