Close
0%
0%

SplineTravel

A g-code filter to smooth out 3D-printing process

deepsoicDeepSOIC
Following
Liked Like project

Just one more thing

To make the experience fit your profile, pick a username and tell us what interests you.

Pick an awesome username
hackaday.io/
Your profile's URL: hackaday.io/username. Max 25 alphanumeric characters.
Pick a few interests
Projects that share your interests
People that share your interests

We found and based on your interests.

Choose more interests.

OK, I'm done! Skip
Similar projects worth following
6k views
7 comments
349 followers
View Gallery
Normally, slicers generate straight travel paths to get the extruder head into next position in a straight line. However, that involves decelerating when ending the previous extrusion loop, accelerating to travel speed, decelerating to come to the point of next extrusion, and accelerating when starting the extrusion.

The idea of SplineTravel is to generate a smooth path for traveling to avoid stopping the motion of the print head. SplineTravel is a stand-alone g-code processing program, that takes the output from a slicer and replaces straight travel commands with smooth paths.

Currently, apart from smoothing out the motion, it also features a seam concealement technique, which seems capable of completely eliminating blobs where perimeter loops start and stop.

The project is in alpha state. It works, but the UI is very raw, and it currently only tested over a limited range of settings of one slicer (Slic3r).

SplineTravel is currently doing two things: smoothing out travel moves (the original goal), and concealment of seams (which I came up with when fighting communication choke when combining smooth travel and retraction)

Smoothing out travel moves

This is done by computing exit velocity after preceding build move, enter velocity of the next build move, and creating a Bezier-curved travel path that matches exit and enter velocities. The Bezier curve is generated so as not to exceed a user-specified acceleration limit.

Retraction and unretraction are injected into the travel g-code, so that the printer doesn't have to stop moving. There is an experimental support for raising Z during the move, but I couldn't get it work on my printer.

Seam concealment

This is done similarly to Slic3r's option "Wipe while retracting", but:

  • wipe is being done without changing the speed of head moving over the perimeter
  • unretraction is also done while tracing the perimeter.

This is only possible for looped perimeters.

Video

This is the video of the first more-or-less successful print.

Is it worth it?

That's a tough question, actually. First of all. take a look at the test results (here, and here, in project logs).

The good:

* smooth travel reduces printer wear... probably =p

* smooth travel reduces noise when printing. substantially. (at least on my PrintBox3D)

* retraction blended into travel improves seams toughness

The bad:

* blows up G-code size insanely (typical figure is three times, on objects with mostly straight lines this can be much worse a factor)

* increases printing time (while in theory, it should be capable of reducing it)

* It is tricky to get it right. Too fine a tessellation = comm choke. Too rough - and the printer will stop at every joint, then the travel takes forever. This is the main reason, why SplineTravel can't improve printing time.

* in some cases (when there is a cusp in bezier, mostly), my printer stops and thinks for a while. It might be caused by cordinates precision limits. So far, I have no idea how to fight this problem.

* on my printer, combining SplineTravel and Z-hopping proved impossible (due to firmware not being capable of processing XYZ curve, I think). Without Z-hopping, there is ooze all over the place.

* SplineTravel is not very compatible with Repetier-Host's Feedrate slider that adjusts the speed in real time. Well, it works, but running at anything other than 100% causes speed mismatches. Retraction/unretraction blended into curved travel is also confusing Repetier-host, causing it to report wrong filament consumption, not counting layers properly, and visualization issues, and in some cases repetier-host even fails to estimate printing time!

So, SplineTravel was a fun hack, but I don't think I'm going to use it a lot.

All that doesn't apply to seam concealment technique, which seems to be fantastic. More to come on this =)

  • 1 × 3D printer
  • 1 × Windows PC (may also run on Wine)

  • Documentation

    DeepSOIC • 08/23/2015 at 20:11 • 0 comments

    I have written some documentation. Click here to take a look =)

    Hopefully, SplineTravel has just become usable.

    EDIT: I have stopped intensely working on the project, so I mark it as completed, although there's quite a lot more I can do.

  • Seam cross-section closeup

    DeepSOIC • 08/22/2015 at 15:05 • 0 comments

  • Mechanical test results

    DeepSOIC • 08/22/2015 at 14:17 • 0 comments

    This is how I did it.

    First, I subjected all the ribbons to tension test. The measurement was done quite roughly, by observing weigh scale. Anything close to 12 kg means that the seam isn't really weaker than the bulk of the ribbon.

    Next, I subjected all the ribbons with the seam intact to a "belt test": I rubbed a 6 mm diameter metallic rod with the ribbons. When I say "very robust", I mean it didn't break after about 50 times the seam was against the rod; very fragile means it snapped after three or four rubs.

    The precious results follow:

    6. SplineTravel+SeamConcealment. snapped at 14 kg, close to the seam (~20mm to the right of the melted-like zone). Belt test: couldn't test it well because it broke near the seam, but it is very robust.

    5. SeamConcealment alone. snapped at 9kg, at the false seam. Belt test impossible...

    4. SplineTravel alone. snapped at 12.5 kg, away from the seam. In belt test it proved durable, but weaker than 6.

    3. Slic3r's wipe while retracting. snapped at 11.5 kg, at the seam. Belt test impossible.

    2. Slic3r with forced retract. snapped at 11.5 kg away from the seam. Belt test - very fragile.

    1. Slic3r plain. snapped at 12.5 kg away from the seam. Belt test - slightly more durable than 2, but still quite fragile.

  • Test prints

    DeepSOIC • 08/22/2015 at 10:36 • 0 comments

    Test model:

    It is a 0.4 mm thick ribbon, on a support shape to keep it from detaching from print bed. Modeled in FreeCAD.

    6. SplineTravel+SeamConcealment. On this photo, it looks best; however, there is a lot of ooze on the internal side, which is reasonably easy to clean up.

    5. SeamConcealment alone. There is a false seam (the visible stuff). It is the place where extruder lands onto the perimeter, but the actual extrusion starts later, in the melted-looking zone on the right, which is the true seam.

    The false seam is actually very bad thing: it is an almost complete gap. It is caused by an ooze bump blocking the flow of plastic when the perimeter is completed later.

    Overall, this is the best looking print, with no ooze at all, and a not very noticeable seam.

    4. SplineTravel alone is also quite good actually, but it looks terrible on this picture. It is very clean on the inside. I is very much similar to 6, except good and bad sides are reversed.

    3. Slic3r's wipe while retracting. I'm disappointed, it doesn't look like an improvement over 1 and 2

    1 and 2. reference prints.

    Update:

    Print speed = 80 mm/s

    Extrusion width = 0.4 mm (setting; actual ribbon thickness is 0.38 mm)

    Ribbon width = 9.1 mm

    Material = ABS

    Extruder temperature = 240 °C

    nozzle: 0.3 mm

    Mechanical test results coming soon.

  • big update

    DeepSOIC • 08/20/2015 at 16:58 • 0 comments

    I've recently pushed a number of commits to github. Here's a brief list of what changed:

    • UI layout
    • Option to switch off SplineTravel, to use seam concealment alone. Separate retract speed setting for within seam-concealment.
    • tessellation logic fix
    • add notes field to presets; allow inclusion of filenames into presets

    Also, I've added a UI screenshot to the gallery, so that you can take a look of what are the options.

  • Updated

    DeepSOIC • 08/19/2015 at 13:44 • 0 comments

    I've just pushed some changes to github. The main update is the preset manager.

  • updated

    DeepSOIC • 08/10/2015 at 19:50 • 0 comments

    I've pushed a few changes to GitHub recently, the most major of them being the refactoring of spline tessellation logic (better match to the jerk limit; no more large steps; added some logic to avoid ridiculously small step at the end of travel).

  • Preparing comparison

    DeepSOIC • 08/06/2015 at 18:58 • 0 comments

    I'm slowly doing a few prints to showcase my seam concealment. It's not looking too impressive so far, to be honest.

  • Updated

    DeepSOIC • 08/01/2015 at 15:33 • 0 comments

    I've just pushed the latest state of the project to github. Previous one was with buggy seam concealment

View all 9 project logs

  • 1
    Step 1

    Download the executable from github repository. Make sure it runs.

  • 2
    Step 2

    Slice your model, write the resulting g-code to a file. When slicing:

    • Use relative E values (using absolute E values may work, but it is untested so far).
    • In Slic3r, make sure "Wipe while retracting" is off (in printer settings tab).

    Note: Retraction length and Z hopping settings in slicer are going to be ignored, because all travel moves are going to be replaced by SplineTravel.

  • 3
    Step 3

    In SplineTravel, specify the filename of the g-code program file as an input, and another file as the output. Note that the output file is going to be overwritten if it exists, without any questions.

    Adjust the settings of SplineTravel (manual is to be written later), and hit the Go button. Wait till it finishes (may take a few minutes).

View all 5 instructions

Enjoy this project?

Share

Discussions

Tim Kuipers wrote 04/04/2017 at 09:32 • point

The exit and enter velocity you use are skewed.
Because extrusion is stopping / starting the movement of the head is actually limited by the jerk and acceleration on the E axis. Perhaps that is why the time estimates don't come out as being faster than normal.

  Are you sure? yes | no

RigTig wrote 01/26/2017 at 12:12 • point

Love the idea. I am currently working on a GCODE interpreter for a special printer and having a curved movement is super helpful for a 'dragged' effector as well as avoiding acceleration and deceleration of a swinging effector. I've just gotta have a go at replacing all non-printing moves with curves, even if I only use an arc. Thank you for the inspiration. (If you want to see my printer project, go to https://hackaday.io/project/13420-rigtigs-big-3d-printer.)

  Are you sure? yes | no

Hatch wrote 09/03/2015 at 23:14 • point

This is quite the amazing bit of experimental slicing! its a shame that the people who write the slicers have yet to innovate on this level. as soon as I get my production delta completed, I will be testing this extensively, and having a smoothie board, I feel as if it may be able to handle this.... Thank you for this wonderful tool!

  Are you sure? yes | no

DeepSOIC wrote 09/04/2015 at 10:02 • point

Thanks =) .

Please let me know if you can get Z-hopping work. It is one thing I couldn't get out of my printer.

Good news is that my printer turned out to be compatible with standard firmwares, so I'm considering wacking an arduino due and trying embedding splinetravel into the firmware, where it should be able to work much better.

  Are you sure? yes | no

Josha Foust wrote 08/23/2015 at 16:08 • point
Maybe this would work better in firmware. Like on something with a more powerful processor like the Smoothieboard.

  Are you sure? yes | no

DeepSOIC wrote 08/23/2015 at 16:52 • point

Totally agree that it is worth doing in firmware. The problem is, writing firmware is quite a bit harder, especially considering that my 3d printer is not open source (there are heavily custom stepper drivers, which are crazy good IMO)

  Are you sure? yes | no

Mike Turvey wrote 08/05/2015 at 21:29 • point

The video looks awesome.  Quite a stark contrast from the usual jerking motions I'm used to watching.

  Are you sure? yes | no

Similar Projects

A shape memory alloy actuator that can move useful loads over decent distances.
Project Owner Contributor

Useful SMA Actuator

a-mana man

Pocket Sized, 3d Printable, Coaxial Scout Drone
Project Owner Contributor

NAVI - "Hey, listen!"

glytchGlytch

3D printing, with lasers!
Project Owner Contributor

SLS 3D Printer

bfozbfoz

Biomat >> 3D Printer
Project Owner Contributor

Biomat 3D Printer Conversion

albert-lathamAlbert Latham

Does this project spark your interest?

Become a member to follow this project and never miss any updates

Going up?

About Us Contact Hackaday.io Give Feedback Terms of Use Privacy Policy Hackaday API

© 2024 Hackaday

Yes, delete it Cancel

Report project as inappropriate

You are about to report the project "SplineTravel", please tell us the reason.

Send message

Your application has been submitted.

Remove Member

Are you sure you want to remove yourself as a member for this project?

Project owner will be notified upon removal.