6
$\begingroup$

Recently (in 2017) there was a paper that got some publicity by researchers who are using a B spline algorithm to reduce vibrations in 3D printers. But before them, a B Spline implementation seems to have been first been made open-source by an alias named DeepSoic here. I would like to be able to print faster using the method described in the research paper, through post-processing G-code. I'm pretty sure these two sources use basically the same technique but I could be misunderstanding things.

Basically instead of stopping and starting for travel moves, speed changes are done in a curvy fashion, so the head never stops and the printer never shakes. This makes the print smoother and also faster. I think printing 10 times faster is something that is really awesome once you try it. Laser cutting relies on cubic splines for a different reason; to create curves in space. But it seems like these techniques are doing something unique to to 3D printing -- using them to adjust head acceleration/de-acceleration to create smoother movement arcs of the print head. Since laser cutters have a constant head movement, this technique wouldn't help them much.

The downside seems to be that it makes way more G-code commands, overloading the USB port, since it's sending all the points on a curve so quickly. I'm assuming a smart person today would really only use it through an SD card (which has disadvantages) or if they bought a 3D printer with a free Wi-Fi module thrown in (which also has disadvantages). Maybe a high baud rate helps.

I was wondering if there are any more established ways to use this obviously extremely important and beneficial and simple algorithm. Initially I was thinking that this is obviously something that should be added as a checkbox in a slicer, and not something to be implemented in Marlin. But after writing this post I realized that a Marlin implementation would allow you to use this technique over USB, but only if the slicer steedleaders are also using its special G-codes for this optimization. I don't care if it's a post-processing technique like the research paper's or a special Marlin-friendly version, I just want to use this technique even if I have to use this Huawei Wi-Fi module.

Basically I would like to know the best way to get started using this technique through a slicer or other software.

I think there is a miscommunication between users of CNC laser cutters and users of 3D printers. In laser cutting the arcs are used to define the path of the cut, which would be equivalent to filament extrusion. In laser cutting, the motion of the laser itself is constant. But in 3D printing, arcs can be used to smooth the speed of the printhead as it moves across the perimeter, and then to infill. It is using arcs for controlling the head well which isn't a problem in laser cutting. Since it's about the head movement, and not the model itself, I don't see how the STL file really matters.

It's really about using an arc to set head speed (a first derivative of position). Not anything about the shape of the model (which would just be position). At least that's my interpretation.

The Wi-Fi module is interesting because it receives an IP address from my router, then my router stops listing it as a connected device. But it still connected, because I can access it wirelessly. I am going to look into it more once I can fix some other problems with this dual-head. But so far there's a reason to think it might be backdoored.

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ The problem with G2 and G3 moves (arcs and circles) is that STLs are composed of only flat surfaces. $\endgroup$
    – Davo
    Jul 10, 2019 at 11:33
  • 1
    $\begingroup$ I find it curious that the question refers to faster printing, but the hack-a-day project linked to claims nothing about speed. The article in 3dprint.com seems like a different project than the hack-a-day link in the question. $\endgroup$
    – cmm
    Jul 11, 2019 at 14:23
  • $\begingroup$ @Davo That should not matter, intelligent slicer software should be able to detect if consecutive points are part of a circle segment and could theoretically be sliced into G2/G3 codes. Alternatively a post processing plugin or program can do that, but that is not a limitation of the STL file. $\endgroup$
    – 0scar ♦
    Jul 22, 2019 at 5:55
  • $\begingroup$ see github.com/FormerLurker/ArcWelderLib/issues/33 $\endgroup$
    – Vincent Alex
    Feb 2, 2021 at 10:22
  • $\begingroup$ Klipper firmware allows the user to measure resonances and then it will filter out the stepper moves to cancel those resonances. It achieves about the same effect with little effort from the user. $\endgroup$
    – FarO
    May 13, 2021 at 7:06

2 Answers 2

Reset to default
6
+50
$\begingroup$

I would have liked to answer linking to credible official sources, but I cannot add references either on direct B-spline printing. So I'm writing down my thoughts. I've familiarized myself in B-splines to understand what they are and read into the 2 references given by the OP.

Basically, the printer software only allows printing of straight lines. Yes I know we can give orders to the printer to print a curve (using G2 or G3), but these eventually will be converted to printing straight lines. There is no ready made printer firmware available to print cubic curves directly to my knowledge. If it would be possible, these curves should eventually be translated into smaller straight lines by the firmware of timed stepper rotational output. These extra calculations would demand a considerable effort of the printer board processor, most probably far more an 8-bit processor would be able to handle.

Comparing the paper released in 2017 to the G-code pre-processing software reveals that although both seem to refer to B-spline techniques, they are implemented differently. For example, the pre-processing software aims to reduce the linear travel moves by replacing these with B-spline curves (and not affect the actual print object), while the paper focuses on the optimization of the actual printing curves being optimized by B-spline curves (also using a pre-processor). Both eventually would need to create a multitude of small straight lines to have the printer be able to actually print the object as there is no 3D printing firmware solution to print curves. Do note that the method in the paper has been questioned by the RepRap community, which demonstrated that they could print the same object way faster than the B-spline optimized example. Furthermore, do note that the Marlin community is probably moving in that direction as can be seen from e.g. this feature request and this G-code meta overview; G-code instruction G5.

So, both methods rely on pre-processing G-codes by identification of sliced coordinate (print) moves, translation into Bézier/B-spline curves for (print) moves, which eventually are translated into normal G0/G1 (print) moves. It does not appear that the Marlin community/developers are aiming to implement Bézier or B-spline curves soon. This implies that if you want to pursuit printing B-splines, you need to make your own pre-processor, or dive into Marlin C++ development; an 8-bit based printer board would not be sufficient indeed like the OP mentioned, up-scaling to 32-bit or interfacing with USB might be the only solution.

Improve this answer
$\endgroup$
0
3
$\begingroup$

In more practical terms, you could design the part so that the corners are rounded (also known as fillets). This will help keep the print head moving and would prevent the sudden stop and start effect that causes "jerking". Further 8 bit controllers tend to get saturated when reading large amounts of g-code from the sd card or the serial port. Upgrading to a 32 bit controller will prevent that kind of jerking.

Both of these methods pale in comparison to just speeding up the print. Upgrading the hardware to be faster (various methods exist) would yield more of a reduced time than trying to optimize the g-code (in my humble opinion). Delta printers have the potential to be the fastest type of FDM printer, assuming that you could get the filament to melt fast enough.

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ This answer is spot-on that what OP is trying to do is virtually useless. Neither vibration/acceleration/jerk limits due to linear segmentation, nor the gcode parsing rate from making the segments small enough that acceleration pattern is essentially the same as with true curved paths, is the limiting factor to print speed. The limits are going to be fundamental vibration/acceleration limits in the mechanical parts and volumetric melt/extrusion rate of the extruder. $\endgroup$
    – R.. GitHub STOP HELPING ICE
    Jul 21, 2019 at 3:17
  • $\begingroup$ The source OP gave showed standard printing failing when print speed was increased, but print time decreased when using bezier curves. The technique turns corners from stop-start to a curved path, which avoids sudden transfer of momentum into the frame in one direction. Marlin now has a specific G-code for bezier curves (and for arcs), so the approach is reasonable. Melt rate is a limit, but often the print speed is low because of acceleration limits, so you can print at 30mm^3/s but only print at 3mm^3 sometimes. $\endgroup$
    – John Moser
    May 5, 2021 at 4:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .