I thought this was super cool and just ran across it on http://hackaday.io. It does arc travel paths to reduce strain and jerking, and I think this could be really useful on machines utilizing servo motors. It drastically inflates file sizes because arc gcodes aren’t being used. Check out the video.
https://hackaday.io/project/7045-splinetravel
interesting, also I love the extruder heater wrapped in tinfoil.
Wow, that is some smooth motion. I want. I know turning segments into splines would decrease the printed part accuracy. But since STL is not an optimal format for dimensional accuracy anyway, I for one would take the trade-off.
That would probably increase the chance of geared down brushless DC motors working okay too. Same for any setup where acceleration is an issue.
I do not think that enough of the times where there are sharp edges are both intentional and desired, so rounding them should be okay. For the few times that you actually want then, define 2 points on the spline as the same point… if I recall correctly.
Am I reading this right? Only the travel moves are replaced with spline paths. I love the smooth motion, but I can see how the spline paths could often take longer due to longer travel paths, despite not having to stop.
The seam concealment produced very nice results, though I’m not sure I understand what he’s doing.
I wonder if they will make It so that it will use arc commands.
Also, this is not an April’s Fool’s Day joke, is it?
Not april fools. I was impressed by the surface quality improvements, and also the butter smooth movement. Aesthetically, it was a pleasing improvement. Additionally, the smooth travel moves reduce travel movement noise/rattling.
Hmm if it is only for travel moves… Still cool, but less interesting to me.
I could imagine a wave line infill being made for it so that you end up with kind of circle shapes or cardboard shapes in the infill. Or the curves could just be at the edges and straight lines in the middle.
This is excellent, huge benefits!
Fun fact: smoothly curving paths like this basically disable the acceleration scheme used by all the mainstream 3d printer controllers. The change in direction at each gcode vertex is too small for GRBL-derived controllers to register the need to slow down. So the controller barrels through these curves at the commanded feedrate or as fast as it can without buffer underruns.
On that note, SD printing would work a lot better here.
Spline paths are a really good idea, but making them faceted out of straight gcode segments is pretty nuts. You need to bake the splines into the firmware and toolchain for them to really be worthwhile. It’s a fairly sizable problem. Maybe proof-of-concept work like this will get somebody interested in working it on the firmware side.
Reminds me of lead in and lead out tool paths for CNC milling and plasma cutting
@Ryan_Carlyle I was thinking maybe Fusion360 could integrate into the CAD CAM side of things… But would need 3D printing specific settings. As you said, starting from native geometry is the only good way to do it. Just need controllers to be able to handle to output.
The lead ins and lead outs that I know about in path generation for milling, water jet and wire EDM are tangent arcs. Splining the path like this is interesting. I wonder if it’s really any better than TinyG2’s fancy acceleration system. It could be but getting there would take time and effort. I agree with Ryan that this really needs native spline support in the tool chain to be helpful.
The controller support is really the hard part. Very few people doing FOSS programming on the side have the technical chops to really dig into overhauling the realtime motion control code without wrecking the performance. It’s a big, big job. RepRapFirmware is probably the closest today since it already calculates every step pulse without assuming straight line paths… the segmentation-free delta support is already doing quadratic path functions, so going to cubic splines might be straightforward. But there’s still the problem of what command structure you use for splines, plus lots of open questions about how to do acceleration (e.g. true radial accel control would blow away even TinyG G2).
BTW, MachineKit’s motion planner already does something very similar to this (“blending”) using regular straight-line gcode input to produce smoothly-curving paths. It will generate smooth curve paths around corners (within a defined error tolerance) to keep from having to slow down at vertices.
(MK also doesn’t allow running through sharp corners with positive velocity, which GRBL-derived firmwares do. It’s a safe thing to do in 3d printers but can damage heavy mills.)
Spline based motion is definitely an interesting path (no pun intended), but like others have implied, it should start in the controller firmware and eventually extend the capabilities to allow for a more expressive interface than the G0-only that is used today. Without having read the guys implementation, a spline based implementation could very well accommodate all dimensions for color blending and velocity as well. If I ever get a sabbatical, I’ll embark on this:)