# Tactile Math Explorations

Although I took math in high school and college, my math skills have atrophied over time due to lack of usage.  How can I possibly do 3D graphics if I can’t remember the math?  It takes a lot of referencing back to books, and code I wrote years ago.  So, perhaps there’s a better way of teaching some math skills which will make the lessons stick?

Here we see 3 of the quadrics.  The cone, cylinder, and hyperboloid.  Each of them has their own bi-parametric equation that describes them.  In this particular case though, I’ve used only one formula to describe three different shapes.  I have used the Hyperboloid, because by slightly changing various parameters, you can get all three shapes.  The Banate CAD code looks like this:

``` local usteps = 180 local wsteps = 80 local radius = 5 local height = 10 ```
``` local con = {{radius, 0, 0}, {0, 0, height}} local cyl = {{radius, 0, 0}, {radius, 0, height}} local hyp = {{radius, 0, 0}, {0, radius, height}} ```
``` function hyper(params) hyperboloid({ USteps = usteps, WSteps = wsteps, StartPoint = params[1], EndPoint = params[2], --ColorSampler = checkerboard:new({Columns=usteps, Rows=wsteps}) }) end ```
``` color("Red") hyper(con) ```
``` color("Green") translate({12, 0, 0}) hyper(cyl) ```
``` color("Blue") translate({24, 0, 0}) hyper(hyp) ```

In the beginning there, I setup the radius, height, and resolution I’m going to generate the curves.  Now, the hyperboloid takes some explanation.  Of course you can look it up online, but the thing to realize is that you take a line, any line, and sweep it around in a circle.  for the simplest case, the cone, just take a stick, stand it straight up on your desk, some distance from the center of your circle, and move it around that center.  You have just traced out a cylinder in space.

Now, let’s say you want to make a cone.  Take that stick again, and instead of it standing straight up and down, lean it in towards the center.  Now as you sweep it around, the top part stays fixed, as the bottom traces out a circle.

And lastly, for the hyperboloid, tiltl the stick slightly back, and to the left, and again, trace it around.

This is kind of hard to describe in words, and some visual aids would sure make it easier.

I’ve done exactly the same thing here, execept I’ve changed the resolution to make the facets more obvious.  Now if you go back and read the explanation again, it might make a little more sense.

In each case, all I’ve done is change the starting and ending points for the stick to be traced around the circle.
``` local con = {{radius, 0, 0}, {0, 0, height}} local cyl = {{radius, 0, 0}, {radius, 0, height}} local hyp = {{radius, 0, 0}, {0, radius, height}} ```

Each of these little arrays defines a starting and ending point for the hyperboloid function.  The con (cone), has a bottom radius of ‘radius’ and a top radius of 0.  The cylinder maintains the same radius at the bottom and top.  The hyperboloid maintains the same radius, but with a twist as it shifts from the x-axis to the y-axis.

This is a nice revelation.  For the code itself, it means that I don’t actually have to write three different functors to represent these things.  I can write just one, the hyperboloid, and just change the parameters I feed it in order to get the others.  Same for ellipse/sphere.  A sphere is just an ellipse where the two axes are the same length.

How does this help me learn maths?  Well, I can write the hyperboloid equation on paper, or better yet, plug it into a graphing calculator, and play around with the results.  Better still, I can plug it into Banate CAD, and see it on the screen in real time.  And even bestest of all, I can lower the facet count, and print these out so I can play with them in my hands.  It’s this latter case that’s the most exciting to me.  If I can make maths a tangible physical thing, then I’m more likely to remember it.  A set of these hyperboloid relatives, printed out as play things, would really help me retain and understand the math behind them.

Hum Banate – We Make

Introducing BanateCAD.  I have spent the past year playing with OpenScad, doing 3D modeling, learning how to make interesting things to print on my printer.

Although I’ve been able to do a great many things with OpenScad, I finally came to the point where it made more sense for me to create my own 3D modeling package, rather than living within the constraints of OpenScad.

Banate CAD is the beginning of my effort to create what I will term as a 3D visualization and modeling package.  At the moment, it possesses many of the primitives that I have created in OpenScad over the past year, from cubic surfaces, to blobs.  I’ve thrown in some extras like being able to specify colors using Crayola color names.

There is NO CSG at the moment.  CSG operations will be great, and I will probably add them over time.  I want to implement the CSG operations as native Lua code, not simply bind to an existing library.  In that way, more of the codebase will be transferable to other platforms, without having to worry about porting monsterous libraries that I know nothing about.

Banate CAD is written completely in Lua.  I use the IUP library, and LuaGL.  As long as these two packages are available in your Lua distribution, it should work on your platform.  At the moment, it’s “Windows Only”, simply because I use the LuaForWindows package, and I haven’t tested with anything else.  I do have a Mac, and I’ll try it out there, and work out whatever differences may exist.

In creating Banate CAD, I am hoping to accelerate the advancement of this genre of CAD tools.  It is freely and easily modified/improved by anyone who has some basic Lua coding skills.  There should be a few people from the “World of Warcraft” universe who can apply some skills to making this better.

I do provide some basics, like being able to turn a triangle mesh into an OpenScad polyhedron().  That might make it relatively easy to move between environments.

So, there you have it.  On the one year anniversary of my first upload to Thingiverse, I am putting out a “Thing” that I think might be useful to some people.

# Bicubic Surfaces

And finally, the kitchen sink!

After a whole bunch of the basic primitives, if you consider the SuperShape/Formula a “basic”, I have come to the bicubic surfaces.  I originally wrote the code for this in OpenScad.  Translating it over to work in FabuCad was pretty simple, and largely involves eliminating code, and merging things back together.

If you look at the example, it’s pretty straight forward to use.  In this particular case, I’m using the Bezier basis by default.  You could just as easily substitute the Catmull-Rom or the Hermite (they’re both built in).  It’s not quite splines or nurbs, but those will come along soon enough.  The intention here is that you can pretty easily create and play with all sorts of forms of things, and quickly see them rendered and print out samples on your 3D printer.

This is reasonably fast code.  In the picture, there are 16 of these bezier surfaces, and the rendering time is a matter of seconds, not minutes or hours.  And of course creating the .stl from there is just a menu click away.

…and even if you do 100 of them,  with a facet count of 1600 apiece, it still only takes about 20 seconds to render.

Well, that’s it.

Enough functions for phase I of this thing.  I guess it’s time to write up some documentation and actually release it.

# Solid Blobs

I must admit, although it is very exciting to think about not having to slice a .stl file for printing, and sending high level commands to a printer directly, we’re not there as yet.

The reality is, today, every printer consumes .stl files.  So, if I want to share and print metaball based objects, I have to go the extra step of creating surfaces for those softly defined entities.  Well, If you’ve done any metaball/blob programming, you might realize that they are a computational nightmare, if you actually want to generate an actual 2-manifold surface for them.  If you want to render them in real time, no problem.  These days graphics hardware will make short work of them.  Mainly because you can use ray casting and determine on a per pixel basis what color something should be.

Problem is, I need a mesh, so it’s not quite good enough to simply cast all those rays.  Of course I could cast rays, and create a mesh made up of single ‘pixel’ sized rectangles, but that’s not very satisfying, and will take quite a long time.  I could take those cubes I created and do something with those…

I came up with another idea, and right now I’m trying to figure out if it’s a novel approach.  It’s kind of a hybrid of approaches used for typical graphical rendering, but with a bent towards meshing.

At any rate, using this approach, I can render these metaball structures in relative realtime, and create 2-manifold surfaces in the bargain.  I think that’s pretty nifty.  At the same time, I added a simple “blobs()” function to the arsenal, so everyone can play with their meta…  fairly easily.  There are a couple of ways to refine the mesh.  You can go with higher resolution when generating it in the first place, or you can use good old fashioned mesh refinement techniques after the fact.  The latter is probably faster, and gives you more options.

And so it goes.

Now what am I missing… Oh yah, those Cubic surfaces.  And let’s not forget realtime collaboration!

# Dreaming in 3D

What’s this then?  Is that a screen moch up or what?

It was roughly Thanksgiving of last year when I uploaded my first designs to Thingiverse.  Actually it was slightly before that I think.  At any rate, I’ve now spent a year doing design, almost exclusively with OpenScad.  I’ve talked numerous times with people about the greatness and constraints of that particular system.  At one point, my daughter said to me; “Why don’t you just build your own?”

Knowing what I know now, these are the features I’d like to have in my text based CAD program:

• Ability to read and write multiple file formats (particularly AMF)
• Using materials and textures during rendering
• Have built-ins for things like curves and varying swept surfaces
• Have the full expressive power of a modern scripting language
• Be embeddable in printing devices
• Have the ability to easily extend the basic framework of the program
• Have some advanced features, such as those found in MeshLab, etc
• Have user definable color schemes

These are just a few of my most favorite things.  Additionally, I’d like to be able to have the thing connect to a number of printers, so that “Print”, just works.

And lest I forget, the most important “feature” of all, my mother has to be able to use it!  What?  She’s not a programmer, nor a designer!!  How the heck is that possible?  Well, it is a dream after all.

Who knows.  Anniversaries are times when magical things happen…

# Super Shaping with Lua

There are literally thousands of ways to produce 3D models for printing and other purposes.  Over the past year, I have chosen to focus on the non-visual forms of creation, particularly using OpenScad as my primary design tool.  As I’ve written before, OpenScad is a great design tool for a programmer like me who’s not particularly familiar with the more visual design tools.

Time and again though, I’m looking for ways to enhance my experiences with OpenScad.  There’s always that extra feature I want, or speed enhancements, or whatever.  A while back, I started exploring using Lua as a programming language to do my modeling.  Lua is a nice little embeddable scripting language.  It’s been around for quite a long time, and is fairly fast.  It’s simple in concepts, if a bit quirky in some of its syntax.  It’s not that I want to dump OpenScad in favor of Lua, but what I do want to do is enhance my modeling toolchain to improve in some areas, without resorting to creating big monolithic be-all end-all applications.

Recently, I have produced some models derived from the SuperFormula.  I used OpenScad alone to produce the results, and they can be found here: OpenScad SuperShape

One of the limitations of OpenScad is that there are no dynamic arrays.  That is, you can not append to an array.  Ideally what you would do in order to construct a mesh based object is figure out all the vertices, and then construct a Polyhedron object using those vertices.

Since I can not construct an array dynamically, I have to resort to actually creating the polyhedron piecemeal.  I have gotten this technique to work.  In the case of the SuperShape, it looks like the following:
polyhedron(
points = [pa,pb,pc,pd],
triangles = [
[0,3,2], // pa, pd, pc
[0, 2, 1] // pa, pc, pb
]);

There is an outer loop where I am calculating the vertices (pa, pb, pc, pd), and then generating a piece of the polyhedron based on those vertices.  I am responsible for stitching it together in such a way that I end up with a nicely 2-manifold object.

This technique works fairly well, and I don’t know of another/better way of doing it in OpenScad.

The disadvantage of this technique is that if you want to perform CSG operations within the same script, you will have problems.  Although in my mind, what I am doing is creating one big giant solid object, what is in fact happening is that I am creating a whole bunch of little tiny objects, and they so happen to stitch together nicely enough to form a solid.

When it comes time to perform CSG operations, I do NOT in fact have one big solid object, but a bunch of little tiny objects that must be individually compared and dealt with by the CSG system.  Even for a fairly small number of objects (thousands), this can take an extremely long time (10s of minutes, even hours).

A possible solution here is to use some other program, which does have dynamic arrays, to generate the polygon, and then just output the result to OpenScad.

Enter Lua.  I could use Python, Ruby, JavaScript, or pick your favorite programming language.  It doesn’t really matter, the process will remain the same.

The setup is like this.  First of all, you have your program generate some OpenScad file.  In the case of SuperShape, I have rewritten the code in Lua.  The core of the routine looks like the following:

``` local pa = mesh:addvertex(pocart(1/r0,1/r1,theta1,phi1)) local pb = mesh:addvertex(pocart(1/r2, 1/r1, theta2, phi1)) local pc = mesh:addvertex(pocart(1/r2, 1/r3, theta2, phi2)) local pd = mesh:addvertex(pocart(1/r0, 1/r3, theta1, phi2))```
What’s going on here is that I have a PolyMesh object, the ‘mesh’ instance here.  You can fill a PolyMesh objects with vertices, then you can come back later and tell it how the vertices relate to create faces, and edges, if you like.

Separately, I have created a simple function that will turn a PolyMesh into an OpenScad polyhedron() module call.

```function PolyMesh_print(f, mesh) f:write("polyhedron(points= [\n"); for i,pt in ipairs(mesh:Vertices()) do vec3_print(f, pt); f:write(",\n"); end f:write("],\n");```

f:write(“triangles=[\n”);
for i,v in ipairs(mesh:Faces()) do
print_face_tuple(f, v)
f:write(‘,\n’)
end
f:write(“]);\n”);
end

The end result is that I can write the following, to generate a supershape and get OpenScad output:

PolyMesh_print(f,RenderSuperShape(
supershape(7, 0.2, 1.7, 1.7, 1, 1),
supershape(7, 0.2, 1.7, 1.7, 1, 1),
64,
128))

By default, I just write to a file with the name “test_supershape.scad”.  On the OpenScad side of thing, I simply open this file, press F5, and I get a visualization of the thing.  This will give me a quick visualization using OpenCSG.  To go further, you can press F6, and get an actual compile through CGAL.  In this particular case, it took 1 minute, 16 seconds to do the render and display.

This is a very fast result.  While I am typing this post, I am still waiting for the plain OpenScad method to complete its render, and it has already been 20 minutes!

UPDATE:  The render for the method using OpenScad directly finally completed:  It took 18 hours 50 minutes!  That’s a few orders of magnitude slower than the technique where you have a complete polyhedron to play with.  Same number of vertices, exact same geometry and topology.  Just piecewise vs having a single polyhedron call.

To go one step further, I don’t just want one static polyhedron, and be done.  I want to play with it, changing parameters, messing around with things.  I want to change something on the Lua side, and see the render instantly on the OpenScad side.  There is a feature in OpenScad that allows you to deal with this.

In the OpenScad window, under the “Design” menu, the first item is “Automatic Reload and Compile”.  If you check this item, whenever the file changes on disk, it will be automatically realoaded and compiled.  What that means is, you can go ahead and make your changes in the Lua side, and regenerate the file, and it will just automatically re-render.  The best way to take advantage of this is to have both your Lua editor open, and the OpenScad file, and just make changes, save, and view the results on the OpenScad side.

This design flow works well for me.  Many of the objects that I am creating are ultimately just meshes.  All of the geometry, height map, and other random stuff, that’s not heavy on the CSG side, can be created simply, and OpenScad used as the viewing tool.

Similarly, OpenScad serves as the CSG tool, providing the connection to CGAL for me.  Of course I could bind to CGAL from Lua directly.  But, OpenScad is already doing this part for me, so I don’t have to bother with it.

Another benefit of generating the Polyhedron completely like this is I can actually perform CSG operations within script, without taking a ton of time.  No warnings about too many vertices, or CSG operations being disabled.  That’s really nice.

Doing this CGAL operation, from within OpenScad, using my previous method of piecewise construction of the polyhedron, would literally take all day to perform, and might not actually complete.

And one last thing.  As long as I’ve gotten things into that PolyMesh object on the Lua side, I can directly generate .stl files.  Since I’m not actually doing any CSG operations, I don’t need the help of CGAL.  So, in the end, OpenScad is a nice visualizer for this particular tool chain.  It’s a viable way of working for me, and it makes things go a lot faster.

# More Plastic Parts for Construction

After creating the first quad connector, I thought about how I could improve upon the design.

The design is pretty straight forward.  I want to support some slats of corrugated plastic panel that are arranged in a torsion box fashion.  That just means the pieces interlock with each other with notches cut into them to accomodate the overlap.  The support piece simply has slots within which the slats can slide and be supported.  For the base of the connector, I didn’t want to simply make it square, because I don’t think that is the optimal shape for saving on plastic.  So, in the first design, I reduced the amount of plastic by cutting out the corners with a cylinder.

This design works well enough.  As you can specify the length and depth of the supporting walls, it’s fairly straightforward to specify exactly how much support you want out of the piece.

There are two sides to a circle though.  I decided to try it the other way, by making the connector base circular.

This one has the advantage that it does not have the sharp edges on the base like the previous one does.  It still has sharp edges on the supports though.  I think this one is more aesthetically pleasing, and easier to “understand”.  It’s just a round cap that goes over some joined pieces of material.

As this is as much a study in how to use OpenScad as it is about creating an actually useable piece, the OpenScad code has been updated in the github library.

One of the nice things about OpenScad, since it is a text based modeling program, is that you can easily change some parameters and generate a different result.  In this particular case, the primary routine is called ‘connector()’.  The full list of parameters is as follows:

connector(length, thickness, height, gap, corners, hole, style)

This last parameter determines the style of the connector.  It can be either ‘CIRCULAR’ or ‘CUTOUT’.  The default style is ‘CIRCULAR’.

Just to pull it altogether, I created a more complete image of the torsion box.

This shows a more completely, if fairly minimal, torsion box, with circular connectors installed on all of the vertices.  The torsion box can be of any size, and utilize any appropriate material.  My original intent was to use the corrugated plastic panel.  As I have not as yet tried, I don’t really know how well it will work.  I tend to think the connectors will actually face down to the ground, leaving a totally flat surface on the top to support flat flooring panels.

The code found in connector.scad is fairly straightforward, with an emphasis on modularity.  I could have coded this up in a single routine, but instead I broke it down into constituent parts so the design could be easily modified, altered, and improved.  If you’re into studying OpenScad code, this might be a good one to look at for a simple object.

# Printing Plastic Parts for Construction

On a recent visit to my daughter’s school, I sat and listened to her art teacher who explained their project for the year being an origami based dwelling.  The good intention is that you’d be able to easily ship a light weight flat pack of materials to a possible disaster recovery site, and instantly pop up a dwelling.  Well, of course there are already hundreds, or thousands of instant tent designs out in the world already, but it is a high school art project, and the origami throws a bit of a twist on the concept.

In talking with my daughter about the parameters of the build, one of the interesting aspects was a raised floor.  My thought was, if you’re in a flooded area, why would you build a dwelling in water?  You’d first just move to high dry ground, and go from there.  But, it’s not up to me to figure out the constraints, I’m sure there is a valid need for a raised floor.  This poses a particular challenge.  Getting a load bearing floor into easily liftable flat pack form didn’t seem obvious.

Then I walked by a store front display that had some cardboard pieces with notches cut into them.  Seeing that display I thought about torsion boxes, and how you could construct them using light weight materials.  My thought was to use corrugated plastic panels.  These are light weight, fairly strong on their own, and come in bio-sensitive forms (recycled, recyclable).  To use it for flooring, there are two things.  One is to stand the pieces such that the holes that run through them are directed vertically.  This way, they can take the most compression, which is what is needed to support flooring.  The second is they need to be secured at the vertices such that they can resist a certain amount of shear and twist forces.

As I was thinking through all sorts of “L” brackets, glues, and whatnot, I thought about just constructing a simple plastic piece that could be used to support the vertices.  So, I sat down with OpenScad, and fiddled about for 10 minutes, and came up with the following:

This is a very simple design for Quad Connector to hold things together at a joint in a torsion box.  Being OpenScad, you can adjust the amount of the gap, to match the material thickness.  Similarly, you can adjust the height and length of the walls, to get more or less support, depending on the nature of the wall material.

I added cutouts to each of the quadrants because I don’t think having the extra plastic is necessary, thus saving on both print time and overall piece cost.  I also thought it looked a bit nicer to have the scalloped corners.  I could have gone the other way and made it a circle instead.  That might also look nice, and eliminate sharp edges, and still reduce the amount of plastic.

As a final touch, I added a hole in the center.  The thinking here is that you could thread some attachment wire, or zip ties or something, up through the bottom, for extra attachment possibilities.

And here is an image of how it might look in action:

The corrugated panels would be cut into sizes that are 4 ft long, and perhaps 1ft in height.  This might work particularly well for panels that are 8mm-10mm in thickness.

In addition to being the flooring material, the paneling can serve as the shipping container as well.  That is, the sides and bottomm of the shipping container can be made of panels that are 2ftx4ft, sitting on a palette, then those materials can actually serve as the flooring after the torsion box is formed.

Overall, this design would give a relatively light weight, and strong flooring that would likely be able to support the weight of a couple of high school girls.  The added bit of plastic might add just enough stability to make it viable.

The moral to the story for me is, once you have rapid prototyping tools available, you can go from a simple idea to an actual field testable product rapidly.  Seems obvious.  But really being able to do it is actually quite amazing.

One other thought I had was, what if they’re deploying in the field, and they figure out they need some slight modifications to meet the needs they find locally?  Well, if they take a fabrication device, and some raw materials with them, it’s a small matter to send them a new design even over their phone through an SMS, and have them print it locally.

That’s the real true power of personal fabrication, and the ready availability of design files.  Any place, any time manufacturing.

At any rate, this has been a fun little project.  A little thought provoking due to the constraints of the challenge, and a big reward due to the relative ease with which designs can be considered.

# Lua Modeling Basics

Recently, I pushed OpenScad to the limit with the texture mapping and height mapping stuff.  These routines are not particularly challenging computationally.  They essentially just walk through pixel arrays, and apply those values as either color, in the case of texture mapping, or as a Z value, for the height mapping.

What I was finding is that these models might take literally hours to render.  Well, that simply did not make any sense, so I started wondering as to how OpenScad deals with its variables.  I did notice that if the source image was particularly large, the thing would take an exponentially larger amount of time.  Little tiny images were faster.  So, it seemed the amount of time spent was due to the size of the source image, no matter how complex the actual polyhedron mesh was.

As it turns out, I store the image in an array.  That array gets copied almost every time it is accessed.  When you’re dealing with very small arrays, you’ll never really notice the difference.  But, in my case, my arrays might be 64K of data.  Well, passing arrays, by value from routine to routine just is not the way to go.  I confirmed this by optimizing the routines to reduce the number of copies as much as possible, and things got dramatically better.  The fundamental problem is the ‘pass by value’ nature of OpenScad.  It’s just one of those limitations.

In steps Lua.  I rewrote the core of the height mapping routine in Lua, and in the end generate a polyhedron in OpenScad format.

In this particular case, I used Lua to generate all the points, and then simply export.  The vertex generation takes only a few seconds, as compared to minutes, or hours, as would be the case in OpenScad.  But OpenScad still plays a role in this particular case.  After I generate all the vertices, I write them out to a file in OpenScad Polynedron format.  That way, you can open up the .scad file, and play with the generated polyhedron within OpenScad.  Mash it up with other stuff, and the like.  When you go to “Compile” the mesh, it will only take a few seconds to compile, because it’s not actually doing any calculations.  It’s just rendering a mesh.  It’s roughly the equivalent of importing a .stl file, except the format is .scad instead of .stl.

Well, this is pretty nice.  It means a couple of things to me.  First of all, the tool chain of Lua->OpenScad is perfectly reasonable.  I use the SciTE editor for editing my Lua code.  As this editor is fairly mature, and is used by many languages, it gives nice syntax highliting, compiler errors, and debugging.  These are all things that I miss out on with the OpenScad editor.

As Lua code has only one real data type, the table, tables are optimized to the maximum.  That means the challenge of passing arrays by value simply does not exist in my Lua code.  I get very fast performance, so I can experiment a lot more with the types of things I want to create.

One example is I generated some metaballs using Lua as my modeling language:

Here, I simply ported my metaball code to Lua, and ran it there to generate a point cloud.  From here, I can use a tool like MeshLab to turn the point cloud into an actual polyhedron mesh, and thus a 3D object that I can print.  Here it becomes interesting, as I don’t actually need MeshLab either.  Since Lua is perfectly capable of doing some computation, I could create the routine to turn the point cloud into a mesh directly from Lua.

One of the basic things that I have found I need for doing modeling is some form of representation of the Polyhedron Mesh.  So, one of the first objects in my new Lua library is the PolyMesh class.  “Objects” are not strictly a part of the Lua language, but it’s fairly easy to construct an object abstraction in the language, so I did.  The PolyMesh object has three routines at the moment:

Between these routines, I have the rudimentary beginnings of a modeling library.  I can generate points, and faces.  Once I can generate faces, I can create polyhedra, and since I can easily export those to OpenScad, the sky’s the limit.

.What’s the use of doing all this?  Why go down this Lua rabbit hole?  I have a dream, that one day, I can send some rendering code directly to my fabricator, and it will just do the right things, no matter whether it is a lathe, 3D FDM printer, or a CNC router.  Lua is a light weight and fairly decently powered, free, language runtime that will easily run on just about any device I care to put it on.  If that’s the ultimate outcome, then I’d like to ride that food chain all the way from the beginning, starting at the modeling program itself.

At any rate, I’m making progress on my little library, porting some, creating new stuff, and generally having fun.

And of course, all the code is readily available on GitHub: https://github.com/Wiladams/LuaModeling

# Improved Tubing Connector

The first version of the tubing connector looked nice, and was functional in theory, but it was a bit challenging to actually print on my Up! printer.  There was an ‘overhang’ which required the use of support, and that’s kind of a waste of plastic on such a small piece.  Besides that, it was hard to print at very small sizes.

I made a couple of improvements to the design

So, now there is Flanged Connector – V2.  On this connector, there is a cylinder located at the hub.  This provides a nice strong flat spot from which the rest of the print can be supported.  Also, the tubing coming from that center out to the flanges is now the same diameter as the widest part of the flange.  This ensures there is no overhang for this portion of the object.  This design is much easier to print than the first one, even down at smaller sizes.

One of the challenges is that with small sizes, depending on your printer, there might be support material inserted inside the tubing.  That’s very hard to get out.  But, if you’re just using them as connectors, and not flowing liquid through them, you can just leave the support material inside.

I have used the connectors to form my favorite tetrahedron, albeit in spherical form.  This is vinyl tubing with a 1/4″ interior diameter, and the connectors were done with a 5/16″ outer diameter.  The fitting is snug for hand pressing.  The tubing is removable, but won’t come off easily.  I imagine that if I had used a spot of glue, it would be permanently affixed.

I am very pleased with the outcome of this design.  It is a useful item, that required only 2-3 hours of work between the first and second, and third iterations.  Now I have something added to my little toolbox of bits of plastic that can be used to do interesting things.