3D Printing Adventures - 111:1 Gearbox

Monday, June 22nd, 2020

Hello again! Today I'll be showing off some of my 3D designs for 3D printed gearboxes!

Why are you making Gearboxes?

Well there are a few reasons.

The first is that since I've been staying home a lot, and I've been distracting myself from the current news with building lots of projects. This is, in fact, what inspired my personal quote for 2020.

Feel free to justify you're crazy adventures with this quote :)

Along with this sudden urge to build things came the realization that I finally have some of the skills needed to build things I wish I had when I was younger. In turn I've started getting back to my roots, the childhood fascinations that led me to becoming so interested in engineering in the first place. One of these things was gears.

 *Sidenote, I set off to take a photo of the gear toys I had when I was really little but was unable to find where we kept them in the house. So have a stock image of them from Learning Resources instead. I am surprised that these things are still around and available for purchase. I'm not sponsored, but if you want your child to become as crazy as I am then here is a good place to start.

Gears Gears Gears! (That's the name of the toy if you're interested)

I'm not sure what about gears was so fascinating to me. You spin one, the next one spins, and so on. When I was younger, this was just a fun and interesting concept to think about. But now I am able to realize that you can use bigger and smaller gears to make things spin faster or slower, or with more force. I'm also able to use computer design software, something I couldn't even fathom when I was younger.

The second reason is that I need it for another project I'm working on. I bought a motor that spins way too fast for the project, and I figured why not make a gearbox to slow it down a little. (As a hint, 5000+ RPM is a bit fast for marbles). So not only am I going to build something that I'm likely going to be staring at for hours, but it will also aid me in powering something else I'll likely stare at for hours.

CAD Time

I've tried modeling gears in CAD, and it's not exactly easy if you want to do it correctly. You could just make some teeth out of a trapezoid, then use a rotational pattern to create a gear, but it isn't the best way to go about it. You have to manually do all of the math on the gear sizes, and the teeth won't mesh together well in the end.

Some quick googling led me to discover that Autodesk Fusion, my design software of choice, actually has a built in script for making spur gears (the most basic type of gear). Learning how to use it was a bit of an adventure, but once I figured out the basics, it was time to actually start designing the gearbox.

I didn't exactly set off with an exact gearing ratio I was trying to achieve, I just new I wanted to bring the final speed under 60RPM, or 1 rotation per second. This is 0.012 times the original RPM of 5000 (a totally rough estimate the package said it was somewhere between 5000 and 10000 and I don't have any tools to measure it). I absolutely could've done all of the math required, but because I wanted to get to modeling, I just kind of decided to stack gears together until I had something that worked.

Iteration 1

The first time of many during this project that I realized there's a reason I'm an electrical engineer and not a mechanical engineer was during my first iteration of the project.

Iteration 1 of my gearbox

Yeah it looks kind of fancy, and it was going to achieve a very high gear ratio, but it had many, many problems. The shafts could wiggle loose, the gears were absolutely massive, but the biggest problem I ran into was that when I went to print the frame, it failed.

Failed print

It failed because the support struts snapped in the middle of printing. Why? Because they were 5 millimeters thick. I don't know about you, but 5mm of plastic sort of fused together isn't going to sustain gears spinning at over 5000RPM. Why I even considered this was possible was beyond me, and that's the moment I thought "yeah this is why I chose to study electrical engineering instead of mechanical engineering".

Iteration 2

I decided to learn from my mistakes and make thicker support shafts, smaller gears, and have the whole thing be thicker and more sturdy overall. I also removed the threaded shaft design and instead designed it so that each pair of gears was a single part, with a hole through the middle for a central shaft that threaded onto the gearbox.

Iteration 2 of my gearbox

I was so proud of this design, I thought I'd finally cracked the code of making arguably my most mechanically complex CAD project to date. I quickly exported all of the parts, sliced them, and started the five and a half hour print for the frame. After that, I spent another two hours printing one of the main gears.

I popped the gear off my build plate, and held it in my hand. Then I looked at the frame, and then back to the gear. It was past midnight, and I realized my mistake.

I designed the whole thing backwards.

So no, the motor wouldn't spin and be reduced to 48RPM, the backwords gears meant that if force wasn't an issue, I could potentially be spinning the last gear at well over 500,000RPM. I was trying to lift marbles a few feet, not shoot them into orbit!

Defeated, I went to bed. The failed design haunted my dreams.

Iteration 3

Many say the third time is the charm. I woke up the next morning and opened my laptop, staring the beast in the face, knowing I was going to defeat it this time. I made a copy of the project file instead of starting from scratch, because in reality I just needed to change around which mount would drive the main shaft and which would be the motor mount.

The winner - Iteration 3 - Final gear ratio of roughly 111:1

I was even able to reuse the shafts, main gears, and most of the frame. Delighted with my design, I triple checked I wasn't making any mistakes, and send the new frame to the printer.

This thing took seven and a half hours to print, and unsure that I had enough white filament, I decided to print it in blue. In hindsight, it looks way cooler in blue, and really helps distinguish the different parts of the gearbox. I even printed the drive and motor gears in orange, and the three color print just helps highlight how the different parts fit together to make this thing work.

I tested my gear, and it fit perfectly. Satisfied this was going to work, I began printing all of parts I needed for the final assembly.

Bringing it into the real world

It took quite a while to print everything, but behold, the physical rendition of my final design with working motor:

They spin fast and it's loud as heck

This thing is gorgeous. It's nice to look at a theoretical design in CAD and think "yeah, I designed that," but bringing something into the real world and being able to hold what you built is just something else entirely. Having a tangible part that previously existed as merely a bunch of mathematical code and a spool of colored plastic is one of the coolest feelings ever. It's one of those things that make me joyful to live in the 21st century.

So there you have it, my adventures in designing a gearbox for use with a future project! The next step will be getting it working with some of my other stuff, and I'll be covering that in a future post.

Thank you so much for reading, and keep on making things!
-Will

Java Lighting Control Part 3 - The Art-Net Backbone

Thursday, May 21st, 2020

Welcome back! Today I'm going to be discussing the long awaited Art-Net backbone, an essential piece of processing for my Java projects involving stage lighting. I'll be taking a look at how it functions, the different data types and what they do, and how it all fits together to push lighting data to Art-Net.

External Libraries

Since I am not experienced enough to be writing my own Art-Net communication library from scratch, I'm building upon Artnet4J, a library written by Cansik (GitHub page here). This library is the final interface between Java and Art-Net, and what is doing the heavy lifting in terms of communicating with my lights.

What is Art-Net?

Art-Net is a protocol for sending DMX data over IP networking. An Art-Net network is built up of standard IP infrastructure like routers and switches, along with nodes, which are responsible for actually turning the Art-Net data into DMX that the lights can interpret. The Art-Net node I am using is an ELC DMXLan Buddy, which is capable of outputting 2 universes independently (a universe being a chain of 512 DMX channels).

<Photo of DMXLan Buddy>

The reason I am using Art-Net rather than something like USB to DMX conversion is because Art-Net is easier to support, since you don't have to worry about compatibility with all different USB to DMX dongles. With Art-Net, all you have to do is specify an IP address and universe, and any node that supports it will be able to read and convert the data.

Using Artnet4J

The basic thing to understand about Artnet4j is how data is packaged before being sent to Art-Net. The data takes the form of an array of 512 bytes containing values between 0 and 255. Each index position specifies a DMX channel, and each value is the value that gets pushed to that channel. From there all you have to do is create a client to handle the communications side of things, and push the array to an IP address and universe.

This is a very easy library to use, but because the software I am building is going to be relatively complex, I needed to build upon it to make things as solid as possible for use in the future. This includes creating objects for each universe to save things like IP address and universe ID, and defining different data objects for my software to work with.

Data Types

There are four main data types that my software is able to use, which are commands, frames, scenes, and stacks. These are essentially containers for each other, and the way they are encapsulated in the following way: each frame contains several commands, each scene contains several frames, and each stack contains several scenes. While I haven't yet created a project that utilizes scenes or stacks, every experiment with Art-Net in Java has extensively utilized frames.

Commands are simple, lightweight data types containing an address, universe, and data value. In essence, it is there to say "this channel at this value on this universe". By itself it simply controls a single light, but when there are many commands encapsulated in a single frame, things become more interesting.

Frames are what are actually sent to Art-Net, since they contain an array of commands which need to be read and sent out to each universe. The cool thing here is that frames are not universe specific, so you can control any lights in any universe together in a single frame.

One more step up the chain, we see that each scene contains a series of frames, much like a video contains a whole bunch of still images that it combines to create the illusion of video. This is going to be important in future projects where I need to worry about different scenes stepping through commands in sequential order, but for now it's just there for future implementation.

Finally, there is what is called a stack, which is a bunch of scenes meant to play side-by-side with each other. Once again, this is here for future implementation and isn't utilized currently.

Universes

The next thing I needed to do was to create an ArtnetUniverse object so I can reference each universe independently without worrying about specifying an IP address each time. I also store a Universe ID,  which is a unique identifier that my software can use to figure out which universe to send data to. The class also contains methods for writing data to the universe, and also for sending the universe data out to Art-Net.

Art-Net Router

The Art-Net router is an object that takes data and routes it to each universe, depending on the desired universe ID. When sending data to Art-Net, the data is encapsulated in a frame, and a router 'opens' a frame, reads each command, and sends it to the correct universe depending on the universe address in the command. This is essentially the link between the Art-Net part of Java and the rest of a program, as it serves as a hub for routing commands. However, unlike IP routers in the real world, this is merely an object in a Java program and not a physical router.

Putting it all Together

The last step is to combine all of these steps into a final project. For sake of example, I'll be explaining how I use this in my last project, the simple dimmer and color controller (see that project here).

First is to create and initialize all of the objects we need for Art-Net to work.

Initialization code

The first few lines create and start the Art-Net client on my machine, which is what will talk to all of the nodes over the network. Next, I create the router object. Then, I create two universe objects for each universe on my DMXLan buddy, which currently has the statically assigned IP address of 192.168.1.63 on my small, 2 device Art-Net network. Finally, I add references to both universes to the Art-Net router, and now the code is ready to send Art-Net.

The next step is to create a frame object. We only need one since this is a basic controller and isn't working with saved scenes and frames.

Creating and assigning the frames to the fader banks

This is a simple code to create a frame and assign it to the faders through use of the fader banks, which are explained in my last post.

Next is the code to write data to each frame. This is a simple method call for the frame object.

Code for adding a command to a frame

This code creates a command within the frame. In the context of the router, the channel is what channel the command is for, the DMXint is the data that is being sent to that channel, and the universe is what universe the command is supposed to go to. This is done within each fader when it receives a MIDI command from the Launchpads.

The last step is to send the frame to the router, which is done each cycle through the main loop.

Commands for sending Art-Net data

The first two lines send the DMX data from each fader bank to the active frame using the method we discussed above. The next line pushes the frame to the router, which sends it to each universe's data array. Finally, the last line pushes the data from each universe out to the specified node, and then to the lights.

And there you have it! This is the Art-Net framework I will be using in future projects since it offers simple functionality that builds upon existing Java Art-Net libraries. Thanks to Cansik for making the library exist so I don't have to start from scratch!

That's all for now, thanks for reading! Keep on making things!
-Will