Saturday, October 17, 2020

A Few Tips For Using Wi-Fi Enabled Light Bulbs

I've been making some lamps using cheap, Wi-Fi enabled light bulbs for a while and I've learned the hard way that there are a few things they don't tell you up-front about getting them working. You can save yourself a lot of trouble by following a few simple rules.

1) They only work on 2.4 GHz Wi-Fi. If you have a dual band or triple band router, they will only connect on the 2.4 GHz band, so you have to connect your phone to the 2.4 GHz band if you want to control the bulbs from an app on your phone. See #3 below... If you have one of the newer routers that automagically assigns things to 2.4 or 5 GHz bands, you may have to set up a guest network specifically for 2.4 GHz light bulbs and similar IOT devices.

2) The SSID of the 2.4 GHz wireless network should not contain any Chinese characters and/or punctuation including spaces, underscores, or hyphens. Use a simple SSID like XYz1234. The SSID must not be hidden. You have to access your router's control panel to make changes to the SSID.

3) WPA2 security is OK. Set your router to use WPA2 on the 2.4 GHz network that the light bulbs will use.

4) If your phone runs a recent version of the Android operating system and you have a dual or triple band router, your phone will connect to one of the 5 GHz bands by default. You'll need to force it to connect to the 2.4 GHz Wi-Fi band/network to set up the lightbulb(s). 

My Pixel 3 phone runs Android 11 and it connects to the fastest connection it can find which is one of the 5 GHz bands that my router uses. I had to install a couple apps in the phone to allow me to force it to connect to the slower 2.4 GHz Wi-Fi band that the light bulbs use. I installed "Wi-Fi analyzer" that shows all the Wi-Fi networks within range of the phone and "Wi-Fi connector library" that allows you to force the phone to connect to whatever network you want, in this case, the 2.4 GHz network.

5) If your phone uses a VPN when it connects to Wi-Fi, you'll have to disable it when you want to connect to the light bulbs. 

My Pixel 3 uses the GoogleFi VPN.  I had to disable it when controlling the bulbs, and reenable it after I had programmed the bulbs. 

Once you have your phone and lightbulbs connected to the same 2.4 GHz network, and VPN turned off, you should have no trouble using the App that your lightbulb maker recommends for controlling the bulb. I have some bulbs from Tuya and some from Feit Electric. They all show up on the Feit Electric app in my phone. 

Thursday, October 15, 2020

Coasters, anyone?

I Needed Some Coasters, So...

The coasters are orange, the bottom of the box is yellow, and the top is pink, all at least a little fluorescent. 

I printed some coasters and a storage box for them using TPU filament. I think they came out alright.

These coasters are all 100 mm in diameter and 2.88 mm high (I printed in 0.24 mm layers) and the box holds a stack of six of them.  Each coaster has a different pattern. The patterns and the lip around the edge of each coaster are designed to trap condensation that dribbles off your cold glass so it doesn't end up on your furniture. I kept the patterns shallow in Z. If the patterns get too deep it starts to become a problem keeping them clean.

The box's lid fits loosely so it's easy to remove. You can put it under the bottom of the box if you turn it upside down. The rounded corners have enough space to use a finger to lift the coasters out of the box, one at a time.

Being printed in TPU, the coasters are great for hot and cold drinks, but I would not set a pot right off the stove on them. I tried washing them on the top rack in a dishwasher and they came out looking like they just came off the printer- perfect, but who knows? Maybe they'll show some wear after multiple cycles.


I used TPU because I like the way it looks, especially when it fluoresces. The photo shows the result of four printing sessions split among three colors. The first two sessions were to print three coasters at a time, one more session to print the box bottom, and finally one to print the box lid. 

Another reason to use TPU was because I liked the idea of the surface being a little soft.  Setting a glass or cup down on a soft surface will sound and feel different from setting it down on a hard surface. I have a granite counter top, and setting a glass or cup down on it always makes me feel like I'm going damage either the glass/cup or the counter top.

I printed at 240C- a bit higher than the recommended temperature range for TPU, but the plastic really flows at that temperature, yields a super shiny finish, and the interlayer adhesion is amazing. I get almost no hairs on the prints. They seem to be leakproof. Of course, with use they will probably start to look bad because spills will inevitably find tiny gaps between lines in the print that can't be properly cleaned out. It's no big deal - I have a 3D printer, so I'll just replace them with another set before they start to look bad.

Print speed was 40 mm/sec, no cooling fan, 45C PEI bed.

It should be easy to print these in as many colors as there are pieces (8 in total). You can do all sorts of crazy stuff, if your printer can produce multicolor prints.

You don't have to print with TPU if you don't want to. PC, ABS, PETG, or PLA, will work too, but you might have to be careful about putting hot drinks on PLA.

The box lid is printed with the top side down on the bed. My printer's PEI bed has scratches that transfer to the print, so the top cover doesn't look as perfect as the sides and everything else. I think printing on glass would be a good idea, at least for the top cover. 

It's easy to change the shape and size of the prints by scaling them when you slice the files to print. If you think they aren't deep enough just scale them in Z for the (any) depth you want. If you want larger or smaller or oval coasters (??), just scale the X and Y axes appropriately after you put them on the plater in the slicer.

I printed with concentric infill for the top and bottom layers and they came out with some interesting patterns.

Finally, clean the nozzle thoroughly just before the print starts, while it's at print temperature.  That will help prevent getting little blobs of charred plastic embedded in the print. Avoiding over extrusion helps, too.

STL files are here.

Friday, July 24, 2020

The Effect of Drawing Speed on a Sand Table Pattern

Most people run their sand tables at 100 mm/sec or less which helps keep noise down and detail in the drawing high, though it can be a little dull to watch. I run The Spice Must Flow at 500 mm/sec most of the time so that it will be entertaining to watch as the pattern is being drawn. I have always suspected that running at such speeds reduces the detail in the final drawing but didn't really know how much, so I tested it.

I ran one detailed pattern at 100 mm/sec and the same pattern at 500 mm/sec, and took some pictures so I can compare the resulting drawings.

Here You Go

100 mm/sec, acceleration 10k mm/sec^2, jerk 200 mm/sec, 190 minutes drawing time

500 mm/sec, acceleration 10k mm/sec^2, jerk 200 mm/sec, 38 minutes drawing time

100 mm/sec, acceleration 10k mm/sec^2, jerk 200 mm/sec

500 mm/sec, acceleration 10k mm/sec^2, jerk 200 mm/sec


Yes, loss of detail as expected. Is it acceptable? I guess it depends on which aspect of the table's performance interests you. If you're more interested in the final pattern, go slow and maximize detail. If you're more interested in the process of drawing the image, go fast!

Note: acceleration is high at 10k mm/sec^2. That ensures that regardless of speed, the drawing time will be minimized because most drawn segments will hit the target speed. That also tends to cause the ball to throw sand at the start of each new segment as the ball rapidly accelerates to the target speed. Throwing the sand (onto previously drawn lines) is one way that detail is lost when running at high speeds such as the example here.

One last thing, because who doesn't like cat videos?

Friday, July 17, 2020

A Car Stand for a OneWheel Pint

My son rides around on something called a OneWheel. It's like an electric skateboard but it has only one large tire and it sort of self-balances. I think he's nuts, but what are you going to do?

The OneWheel weighs about 9 kg. When he transports it his car, its odd shape allows it to tumble around every time he hits the bakes or gas or turns, so he needed some sort of stand for it that would hold it stable and keep it from damaging the back of the car. He showed me a couple designs for stands on Thingiverse, but as is often the case with models on Thingiverse, they are best used to illustrate how not to do something.

I started my design the usual way, by making a 3D model of the OneWheel with just the pertinent details modeled to the accurate dimensions, measured with a caliper and measuring tape. I used that model to design the stand. The design has a large, flat base, 286 mm in diameter by 6 mm thick, that is a silly waste of time to print. It would be more sensible to start with a wood, metal, or plastic base, either round or square, and then screw down some printed parts designed to hold the OneWheel, but I didn't have any suitable material on-hand so I went ahead and printed the stand with the large base.

CAD model of the OneWheel on the stand. The side of the tire and wheel rim rest on the stand.

The tabs just fit into the rim of the wheel but don't interfere with the valve stem.

Print in progress on UMMD- it took about 10 hours and 45 minutes, about half of which was spent printing the large circular base, and used 307 g of PETG filament.  It was printed in 0.3 mm layers at 50 mm/sec with 20% triangular infill, 4 perimeters, 0.5 mm line width, and 4 top and bottom solid layers, in one piece without supports.

Here is the OneWheel on the printed stand. Like our genius president, it's quite stable!

Wednesday, July 8, 2020

To a Hammer, Everything Looks Like a Nail

A couple years ago I installed a timer switch on my front porch light so it would turn on at dusk and off at dawn. It was one of those smart switches that knows what time it is and when the sun sets and rises and even keeps track of daylight savings time. The light uses two candelabra type bulbs and is about 12' (almost 4m) off the ground. At about the same time I installed the timer, I installed a couple LED type bulbs because they are supposed to last 20 years and I don't like climbing up on a ladder to change light bulbs that are 12' in the air.

Well, it's two years later and one of the so-called 20-year LED bulbs failed. I wanted to replace both of them with yellow bulbs because the white light attracts bugs, and the bugs attract spiders, and the spiders make webs and catch the bugs and leave things looking very messy. I found a couple candelabra base yellow LED bulbs at Home Depot, got out the ladder and went to install the new bulbs.  

The fixture hangs from a chain, way up in the air, and requires two hands to get it apart to install the bulbs. That means I'm up on a ladder, with two hands on the fixture and none on the ladder, not a good situation. I unscrewed the bottom part of the lamp fixture, and it and the glass then came down, granting access to the bulbs. I had forgotten that the glass doesn't actually attach to the bottom part of the fixture and ended up dropping it. Oops!

So now I had to replace the glass, an impossible task because that stuff is not standard and even if I could figure out who made the lamp, they've long since stopped making them or stocking the glass parts. So my choices were either buy a whole new fixture or make my own replacement for the broken glass. Being a cheapskate and 3D printing type person- you know the type, every problem can be solved with a 3D printer- and having recently made a nice lamp using some beautiful edge-glow glass PETG filament from Keene Village Plastics, I decided to try using the stuff to make a replacement for the broken glass. If it didn't work, I'd only be out about $1 worth of plastic and a couple hours of print time and I could always replace the whole fixture.

After I finished cleaning up the broken glass, I made a couple quick measurements of the fixture and went to work. The only dimensions that matter are the diameters of the top (222 mm) and bottom (102 mm) parts of the fixture, and the distance between the top and bottom (180 mm) when the fixture is screwed together. In Fusion360 I created a profile of 1/2 of the glass using a few straight lines and a spline curve, then revolved it 360 degrees to make a solid of the correct size and shape, then exported the STL file. I sliced it with 2 perimeters with 0.5 mm line width and 0.3 mm layers, no top, no bottom, and no infill. It literally took less than five minutes to design and slice.

The print took about 3 hours at 50mm/sec. Judging by the surface of the print, I'd say 50 mm/sec may be pushing the speed a little high for this filament. No matter- it will be 12' in the air and no one will ever get close enough to see any imperfections. The whole thing is pretty flexible, but rigid enough to maintain its shape as long as I don't screw the bottom of the fixture on too tightly.  

The print doesn't look particularly transparent, but it actually lets a lot of light through. 

And here it is installed, with the new yellow bug lights on:

Yes, those are bugs sitting on it! So much for the idea that yellow light bulbs don't attract bugs...

Next project: clean all the spider webs and dead bugs off the porch walls and ceiling.

Wednesday, July 1, 2020

YAFL: Yet Another Fractal Lamp

My brother, the distiller, built a bar in his living room, and I thought that he might like a bar-worthy lamp for it, so I got busy.

I recently bought a couple 5 lb spools of transparent PETG filament (edge glow glass from Keene Village Plastics) that has some bluing in it to make it look like the glass that old Coke bottles were made from- I thought it would be great for a lamp shade, especially for colored lights because the bluing in the filament emits a beautiful, pale blue fluorescence. I've used PETG filament before, but this is the best I've used. It printed without a lot of hairs or charred blobs ending up all over the prints. I will be buying more. I suspect that all the "edge glow" colors they sell are fluorescent.

In a single wall, the stuff really does look like glass:

I searched through my collection of fractal based designs and settled on one I had previously used. I made some changes to make it more printable and for esthetic purposes, and sliced it for the new filament.

The print failed twice with the controller complaining of a heater fault. The first time I thought it might be because of a power outage (that's not a heater fault, is it?) due to a local thunderstorm, so I examined the printer and restarted the print. It got to about 23 hours and failed again. I took the cover off the printer so I could access the controller board and found that the screw terminals on the PT1000 interface board were stripped and had let the pressure off the wire enough to make the connection intermittent. 

The nice thing about prints like this is that even the failures can be useful, and no one knows they're failures if you don't tell them!

I replaced the cable and switched to the other PT1000 input on the interface board, then restarted the print. It made it all the way this time- 564.5 mm. It used 759 g of filament.  I printed it with a 0.4mm nozzle at 50 mm/sec, 3 perimeters, 0.25 mm layers. Total print time was 36 hours, 13 minutes and 57 seconds. Print time was included about 2 seconds per layer in order to make the layer synchronized time lapse video. 564.5 mm x 4 layer/mm x 2 sec/layer = 4516 sec = 75.27 minutes.

The camera had a problem when shooting the photo sequence that would become a layer synchronized time lapse movie. Even though I locked white balance, focus, and exposure, the brightness of the images varied a lot resulting in some really annoying flickering in the video. This only seems to happen when the print is lit by UV. I couldn't see any brightness variation or flickering of the light in the printer, so I checked the EXIF data of some of the brighter and darker images and found that the camera was varying the ISO value. Maybe a bug in Open Camera? I also found that the Mooni button suddenly isn't reliably working with the camera. Sometimes it triggers the camera and sometimes it tries to change the speaker volume setting. Hmmm. More problems to solve...

Here are some still photos shot while the print was running and almost finished:

This lamp has a round base, printed with black PETG. Unfortunately, the filament pigmentation wasn't consistent so parts of the print look lighter than the deep black color it started with. I used concentric top solid infill that makes the base look like a stack of vinyl records.

The light source is the same type Feit Electric 1600 Lumen, multicolor, wifi controlled LED bulb that I used in the last lamp, treated the same way- the two PCBs were separated and laid flat. The LED board is clamped to the top of the base by three screws that go through the heatsink plate inside the base. Yeah, I know it isn't going to be very good at dissipating heat that way, but the original heatsink was smaller and covered with plastic, so how warm is it going to get?

Pink/purple light, which is a combo of light from red and and blue LEDs, looks particularly nice. The bright center of the lamp looks pink while the rest of the shade fluoresces a pale blue color because of the blue LEDs. This photo doesn't quite do it justice:

Tuesday, June 2, 2020

The Spice Must Flow Gets Servomotors

This is an update to my often-updated sand table project, The Spice Must Flow. 

Different types of motors for different uses

Stepper motors provide lots of low speed torque and high precision positioning without the need for closed loop control. Those characteristics make them great for machines like 3D printers because they don't have to go too fast, they can deliver the precise positioning that 3D printing requires, and open loop drivers are cheap. Stepper motors operate in clicky detented motion, so they tend to vibrate and make noise. Better drivers can microstep them to get smoother motion.

A sand table isn't a 3D printer. While it needs positional control, it doesn't need the high precision positioning of a 3D printer because sand is a low resolution medium. What it needs is speed (well, mine does) and quiet operation more than resolution. I've been trying to make The Spice Must Flow sand table run both fast and quiet, neither of which are characteristic of stepper motors. 

There is another type of motor that can deliver positioning control, speed, and quiet operation. They are called servomotors. Servomotors integrate a brushless motor (smooth and quiet operation) with an encoder to monitor shaft position and driver electronics to provide positioning control at high speeds. 

At the suggestion of someone on the Duet forums, I decided to try installing iHSV servomotors in The Spice Must Flow. I took a look at the range of those motors- they go from 52W NEMA-17 size motors up to 660W NEMA-34 beasts. Without knowing much about them, I chose to stay with NEMA-17 size motors because I couldn't imagine needing a NEMA-34 motor to move a little steel ball around in sand. Based on my experience with steppers (even the NEMA-23 steppers I used in the sand table were rated for only about 12W- rated voltage x rated current x 2 coils) I figured a NEMA-17 sized motor ought to be able to get things moving. There are 52 and 78W motors available for almost the same price, so I chose to go with the higher powered motors, "just in case". In hindsight, the 52W motors would probably have been more than adequate. 

Another big difference between a stepper and a servomotor is the price. You can buy a microstepping driver and NEMA-17 stepper motor for about $25-30. The servo motors I used are "integrated" meaning they come equipped with a driver and encoder so that (mostly) all I have to do is treat them like steppers and provide step/direction/enable signals. Each motor cost about $100 shipped from China

Torque Specs

Another big difference between a stepper and a servomotor is the way torque is specified. The servomotors I used are specced for 0.185 Nm torque. That translates to 26 oz-in. A stepper motor with a 26 oz-in torque spec is a small stepper.

One thing I have learned from experience with steppers is that torque is proportional to motor length, all other things being held constant.

Ada Fruit 28 oz-in stepper

Now compare that motor's length to the servomotor:
Servo motor- 83 mm long
This is the servomotor, NEMA-17 size, but the length of the motor is 83 mm.

How can it be that a servomotor that is 83 mm long can have a little less torque than a stepper that is 34 mm long? I have to admit I was skeptical about whether such a low torque motor could be used to drive the sand table. With a little time spent researching the issue, I learned that the difference has to do with the way the torque is specified.

Stepper motor specs include something called "holding torque". Here's a simple explanation:

"A stepper motor’s holding torque is the amount of torque needed in order to move the motor one full step when the windings are energized but the rotor is stationary. Holding torque is one of the primary benefits that stepper motors offer versus servo motors, making stepper designs a good choice for cases where a load needs to be held in place.

Stepper motors can hold a load against an external force when the motor is stationary.
Image credit: Oriental Motor U.S.A. Corp

Holding torque is typically higher than running torque, and is limited primarily by the maximum current the motor can withstand. From a practical standpoint, holding torque is the sum of the magnetic force exerted by the coils to hold the motor’s current position, plus the detent torque. Once the motor is moving, the torque available at low speeds equals the holding torque minus two times the detent torque (because the motor has to work against the detent torque)."

The running torque mentioned above is actually called pullout torque. It is the torque that the motor can deliver to a load at any given speed. As speed increases, the pullout torque decreases. Like this (from:

Exact behavior of stepper pullout torque is a function of the driver characteristics and applied voltage, but the trend is for the pullout torque (the useful kind) to drop as speed increases. Servomotor torque is the continuous torque that the motor delivers at specified maximum operating temperature. At lower temperatures, and intermittently, it can deliver more torque.

servo motor speed-torque curves
This is typical servomotor torque vs speed behavior. Note that peak torque is much higher than the continuous torque. 
iHSV42-40-07-24 speed-torque curve
This is the nearly useless speed/torque curve of the servomotor I used, taken from the motor manual. Notice relatively low, but constant torque right up to 3000 rpm. 0.185 Nm is about 1890 g-cm, or 26.2 oz-in which is about the same as the holding torque of a small stepper.

There's some interesting information about selecting a servomotor for any given application based on the speed/torque curve here:

One thing near the end of that page has proved to be important in The Spice Must Flow: "A servo motor’s maximum torque is limited primarily by heating (due to the amount of current required to produce high torque), while its maximum speed is limited by the motor’s back EMF (voltage produced as a result of motor rotation, which opposes the supply voltage and reduces motor speed). It’s important to note that the application’s maximum torque and maximum speed must fall within the intermittent duty zone. If either value exceeds the motor’s intermittent curve, damage to the motor or drive could occur."

In all the testing I've done so far, the motors haven't even warmed up. I did run into the back-EMF issue when running speed and acceleration tests on The Spice Must Flow, as you'll see later.

So, in summary, a stepper's torque spec, holding torque, is the most torque you can ever expect to get out of it, and torque while it is running will be lower the faster the motor spins. Servo motor torque spec represents the average torque, and it can deliver much more torque on demand, at least intermittently.


How much acceleration might a measly 0.185 Nm torque be able to produce? Some basic physics helps here. Isaac Newton determined that Force = mass * acceleration. The motors I used produce a constant torque of 0.185 Nm (and should produce higher peak torque). I use a 16 tooth pulley to drive the mechanism, the radius of which is about 5.5 mm or 0.0055m so the force available to drive the mechanism is 0.185 Nm/0.0055m = 33.6 N The mass of the X axis, including the belt, pulleys, magnet and carriage is somewhere between 0.5 kg- 1 kg. Plugging 1 kg into F=M*a gives a = 33.6N/1kg = 33.6 m/sec^2. The acceleration of objects near the earth's surface due to gravity is 9.8 m/sec^2, so the acceleration available to the mechanism is 33.6/9.8 = 3.4 G. All this ignores the motor's inertia, hard-to-estimate losses like stiction, friction, and drag/inertia of the sand, so the real value will probably be a bit below 3.4 G, but even if it's only 1/2 of that value, it's still higher than the sand table should need and 17x more than was available from the stepper motors.

The ball is coupled to the sand table's XY mechanism by a magnetic field. Ball movement is resisted by its own inertia and by the sand. At some level of acceleration and/or speed, the inertia of the ball and/or the resistance of the sand will cause the ball to be left behind (or thrown!) by the magnet. That value of acceleration will vary a lot with ball diameter/mass and sand depth/density, and strength of the magnet, so the actual acceleration used has to be determined experimentally. I was using acceleration of 1000 mm/sec^2 with the steppers because I found that the mechanism tended to stall out on some patterns at and above 2000 mm/sec^2.

What does all that mean? It means acceleration is more likely to be limited by the ball and sand than the servomotors. In my tests I have pushed acceleration as high as 20,000 mm/sec^2 at which point the power supplies sometimes reset because the motors try to draw too much current. With higher current power supplies, I'm pretty sure the servomotors would be happy to deliver even more acceleration.


My speed goal for the table is "soft". Most sand tables are smaller than mine, and run at speeds <100 mm/sec to keep them as quiet as possible, or because the speed is limited by the motors, drivers, or structure of the mechanism. Even though they run slowly, the small size of the table means that patterns will finish reasonably quickly.

The Spice Must Flow is a large table, and I like to run detailed patterns, so if I run it slowly, it takes a long time to finish each pattern. That may be OK under some circumstances, like if it's sitting in my living room and I don't want it to hear it running, but I take the table to Maker Faires and other public events (at least I did pre COVID). People don't want to watch a pattern being generated slowly. They want to see speed! Noise doesn't matter, or even enhances the experience. Screaming motors and sand flying around is fun and exciting! A table that's capable of running fast is also capable of running slow, so if it's built to run fast, it's more versatile.

In practical terms, there are three limits to be concerned about- the speed limits of the sand table, the controller, and the motor. When there were steppers in the machine, they defined the maximum speed because of their limited performance. Based on my experience, 500 mm/sec seems to be the upper end of the speed range for drawing the patterns and still having enough detail that they look nice. Of course, the Duet2 controller applies acceleration and deceleration to all the motion, so if the speed is set to 500 mm/sec, it will only actually be reached if the acceleration setting is high enough, and the line length is long enough to allow it. If the ball runs much faster than that, it starts throwing the sand around and some of it ends up stuck to the underside of the polycarbonate top cover and starts interfering with the view of the pattern. I don't want to have to keep cleaning the top off, so the next iteration of the table design will have a glass top located higher above the sand. At some too-high combo of speed and acceleration the magnet will either leave the ball behind or throw it.

As for the motors, with 16 tooth drive pulleys, the magnet/ball moves 32 mm/rev. Moving at 500 mm/sec will require the motor to spin at 500 mm/sec / 32 mm/rev = 15.625 rev/sec which is 937.5 rpm. That wouldn't work with a stepper, but is well below the 3k rpm upper limit of the servomotor.

At 32 mm/rev, if the motors run at their maximum specced speed, 3000 rpm, the ball will move at 1600 mm/sec - far beyond what is possible when trying to leave a nice pattern in the sand, or maybe even leave the sand and ball on the table, depending on the ball size and depth of the sand.

The Duet2 WiFi controller can only produce so many (120k) step pulses per second. The motor driver (on the motor) can be jumpered for different steps/rev just like a stepper driver. The lowest steps/rev setting available is 800. If I were to run at 120,000 pps, and drive the motors at 800 steps per rev, that would put an upper limit of 150 revs per sec = 9000 rpm- far beyond the motor's limit of 3000 rpm. So the Duet2 controller's 120k pps limit isn't going to limit the sand table speed.

The motor specs show constant torque up to 3k rpm. As we learned from, the upper speed of the motor is limited by the back EMF the motor generates. For the iHSV motor I used, exceeding 3k rpm will cause the motor to generate voltage higher than the supply voltage which could potentially damage the driver (and Duet controller). Later we'll see that I did drive the motor fast enough for the Duet2 board to report "overvoltage condition".

So the limiting factors for speed are, in order from most to least important, the behavior of the ball and sand on the table, the motors, and the Duet2 WiFi controller.


If the target speed is 937.5 rpm (= 15.625 revs/sec) to run the table at 500 mm/sec, and using the maximum 120k pps from the Duet2 board, 120,000/15.625 = 7,680 steps/rev. So any setting of 7,680 steps/rev or less should allow the table to hit the target speed of 500 mm/sec.

Sand is not a high resolution medium, especially not at 500 mm/sec or more. Let's say we used the 7,680 steps/rev calculated above. Since one motor rev moves the ball 32 mm, that 7,680 steps/rev translates to 7,680 steps/rev / 32 mm /rev = 240 steps/mm. That resolution is 2 orders of magnitude higher than needed in a sand table and 1 order of magnitude beyond what's needed in a 3D printer. More realistically, the sand table probably doesn't need more that 1 step per mm resolution.

The minimum settable steps/rev value of the motor is 800. 800/32 = 25 steps per mm, still far more resolution than needed in the sand table. At 800 steps/rev, the controller will have to generate 800 steps/rev x 15.625 rev/sec = 12,500 pulses per second- a very leisurely pace for the Duet2 controller board. Any steps/rev setting in the motors between 800 and 7,680 will provide more than enough resolution and allow top speeds of at least 500 mm/sec.

The motors have 1000 line encoders to monitor the rotor position, so I have been using them set for 1000 steps/rev. At 1000 steps/rev, the Duet should be able to drive the motors well beyond their 3k rpm limit, meaning more than 1600 mm/sec.

Yet Another Redesign of the Sand Table Mechanism

I started at the motor mounts and worked my way through all the other parts. I changed the pulleys to larger diameter, stacked F625 bearings with printed flanges to try to eliminate the squeaky noises that the 3D printer pulleys with the tiny bearings were making. Changing the pulleys required redesign and printing of the corner pulley blocks and the Y axis bearing blocks. I kept the magnet carriage as-is and designed the other parts' pulley spacing to try to keep the belts parallel to the guides.

Corner Pulley Blocks

New corner pulley block
One of two corner pulley blocks. Pulleys are stacked F625zz bearings with printed flanges (green) and orange TPU "tires". These are much quieter and longer lasting than the 3D printer pulleys with tiny bearings I used to use. The blocks are printed in four pieces, the base, top cover, and two cylindrical spacers. Pulley axles are 5mm diameter steel pins that are captured in holes in the top and bottom of the block. The block is held in place with two t-nuts.

The bases are screwed to the table's frame with screws and t-nuts, then the pulley shafts, pulleys, washers, and spacers are added, and finally the top cover is screwed down.

Motor Mounts

I designed the motor mounts the usual way - start with a solid block and carve away just enough material to allow everything to fit properly. The result is a very solid design that doesn't flex perceptably under belt tension even though it is made of plastic. The motor mounts are designed to fit the inside of the t-slot rails just like the old mounts, only now, with the low torque but high speed servomotors, I'm using 16 tooth drive pulleys to maximize the force available to move the mechanism. One change I made was to add F625 bearings to the motor mounts to support the ends of the motor shafts against the belt tension. Testing found runout in the motor shafts and the bearing made it a little noisy, so I ended up not using the extra bearings.

The mounts are designed so that the vertical spacing between the belts will be 4 mm using the centerline of the t-slot as the reference for positioning the pulleys. That 4mm spacing between the belts is maintained throughout the mechanism.

One of the new motor mounts
One of the new motor mounts. I ultimately removed the bearing from the housing because the motors had a bit of runout in the shafts and the bearing made it noisy.

As in the original and all subsequent designs, the motor mounts have tangs that fit into the t-slot and are held in place with screws and t-nuts. The belts are tensioned by sliding the motors in the slots until the belts are tight, then tightening the screws to hold them in place.

I printed the motor mounts and all the other parts using ABS with 30% triangular infill. The motor mounts print with bed-surface-only support material supporting the underside of the t-slot tangs. I used modifiers in PrusaSlicer to make the two main mounting holes solid under the screw heads for maximum strength and resistance to being crushed by the screws.

Assembly is easy- put the drive pulley on the motor shaft with a drop of loctite on the set screws, loop the belt around the pulley, then screw the motor to the mount. Add the mounting screws and t-nuts and it's done. Once the rest of the mechanism is installed and belts have been routed, the motors are positioned to tension the belts and square the X and Y axes. Finally, the optical endstop mounts are glued to the motor mounts.

A motor
A-motor, cables, and optical endstop. The 6 yellow wires carry the step/direction/enable signals from the Duet2 expansion board. The heavier green and red twisted pair provides 24VDC to the motor/driver. The DIP switches under the power cable set the steps/rev of the motor, currently set to 1000, and a few other things that I haven't played with yet.

B motor
B-motor, cables, and optical endstop. The yellow part (upper left) with pulleys is one of the Y axis bearing blocks.

one of the Y axis pulley blocks
One of two Y-axis bearing blocks. This block is printed as a single piece. You can see the UHMW bearing in the t-slot, just behind the belts. The outer belt twists to ensure that only smooth belt surfaces touch pulleys (except the drive pulleys, of course).


Using external motor drivers with the Duet2 controller board is most reliably accomplished by adding an expansion board that cost about $30. It has multiple ports with buffered differential step/direction/enable outputs to connect to external motor drivers.

I installed the Duet expansion board in the sand table, and made cables to connect the step, direction, and enable lines from the expansion board to the motors, and power cables for the motors. Wiring was straightforward- I simply connected all six leads from the expansion board port (step + and -, direction + and -, and enable + and -) to the matching inputs on the motors.

I started out with one, 150W power supply powering the table because that's what I used for the steppers. I quickly discovered that servomotors motors will suck a lot of current from the power supply to try to keep up with the input signals. Trying to use too high acceleration, jerk, or speed during a few tests caused the power supply to self-protect which caused the Duet2 board to reset itself.

I replaced the 150W power supply that was originally in the sand table with one that was good for 200 W (the next biggest size I had handy), but too high jerk and acceleration settings still pulled the power supply down. I finally connected both 24V power supplies- the 150W supply powers one motor and the 200W supply powers the other motor, the controller board, and the LED lighting.

I added optical endstops of the same type I used in UMMD so I wouldn't have to hear the switches clicking when the machine homes itself.

sand table wiring diagram
The wiring diagram of the sand table as built.

Configure the Motors... or Don't

Servo motors use pretty complicated drivers that require configuration in order to optimize the motor/controller system's performance in any specific application. The drivers have some automatic configuration procedures built in that will apply different signals to the motor and make measurements and try to arrive at an optimal setting. The settings in the drivers are changed by connecting to the drivers via a serial port and running some manufacturer provided software. I haven't run any of that optimization yet- just used the default factory settings so far.

Ugreen USB to RS232 adapter cable
This Ugreen USB to RS-232 adapter cable is the sort of thing you need to let your computer talk to the motors.  It uses a PL2303 chip to provide the necessary RS-232 voltage swings.  These sell for about $10 on

Configuring the Duet2 controller board

I had some problems when I first installed the servomotors- I was getting inconsistent motion- I'd tell it to move 100 mm and it would move somewhere between 80 and 120 mm or so. I had to tweak the timing of the drive signals coming from the Duet2 board a little to make it work reliably.

iHSV servomotor timing diagram
Timing diagram for iHSV motor driver. Use this information to set controller pulse timing parameters in M569 statement in the config.g file

Here are the necessary tweaks to the config.g file (this applies to reprap firmware only- if you use some other firmware, you may have to do something different)

M584 X5 Y6  ; remaps the X and Y motor drives to the Duet expansion board
M569 P5 S1 R1 T4.0:5.0:6.0:11.0 ; sets the timing parameters for the X motor servo drive signals
M569 P6 S1 R1 T4.0:5.0:6.0:11.0 ; sets the timing parameters for the Y motor servo drive signals
M92: X31.25 Y31.25 ; sets steps/mm for motors using 16 tooth drive pulley and 1000 steps/rev
M350 X1 Y1 ; sets Duet to output full steps (microstepping is handled by the servomotor drivers)
M201 X20000 Y20000 ; set maximum acceleration limits for each axis
M204 T10000 ; set travel move acceleration (applies to all moves in the sand table except homing)
M566 X200 Y200 ; set maximum jerk speed for each axis
M203 X1600 Y1600 ; set maximum speeds for each axis

I set the motors for 1000 steps/rev because the motors have 1000 line encoders and it seemed like a good idea. In a sand table that doesn't require high accuracy or precision, it probably doesn't really matter.

When testing for maximum speed, I used M203 X3000 Y3000 both beyond the motor rpm spec limit. After testing was done, I set M203 to X1600 Y1600 to ensure the machine couldn't exceed the 3k rpm spec limit of the motors. Speed of any given pattern is set in the pattern file with a G01 FXXX statement at the top of the file. For speed testing purposes, I used G01 F500 or F1000 to set the speed at 500 or 1000 mm/sec in the pattern files, then used the speed % slider on the Duet Web Control page to adjust the speed up to 300%=3000 mm/sec. Also for testing, I used the M204 command to set different accelerations while patterns were running on the table. In the sand table, all movement looks to the controller like travel moves- there are no "printing" moves because there's no extruder. If I were going to make a plotter that set a pen up or down, or started and stopped an airbrush, I'd probably set up the pen servo or paint valve as an extruder, so then I'd need to set a printing move speed in the M204 command.

If, for some reason, 1600 mm/sec isn't fast enough for what you want to do, you can always put larger pulleys on the motors. I chose 16 tooth pulleys because they have the smallest available radius which meant that they'd deliver maximum force to the mechanism to move it. I was concerned about the low torque spec of the motors. Now I know better. 20 tooth drive pulleys would allow a maximum speed of 2000 mm/sec, and 32 tooth drive pulley would allow 3200 mm/sec without exceeding the motor's maximum rpm spec.

Here is a test of the mechanism running a pattern with acceleration set to 10,000 mm/sec^2, speed set to 2000 mm/sec (which exceeds the 3k rpm spec limit of the motors), and jerk speed set to 30 mm/sec.

Once it was working reliably, I got an idea to try something different... The mechanism can go much faster than it will ever need to go to draw in sand, but there may be other uses for that high speed motion. I put an LED and coin cell battery into the magnet carriage, turned the whole table on its side, set up the camera, and did some "light painting":

LED and coin cell for light painting

The light painting "brush"- a modified blue LED and coin cell inserted into a piece of packing foam stuck into the magnet holder. The LED had a lens that narrowed the beam. I clipped it off so it would look bright to the camera at all positions on the sand table.

light painted pattern
Light painted pattern took about 3 minutes to complete. I pointed the camera at the table and focused, then put the lens cap on, homed the table, opened the shutter, removed the lens cap and started the pattern. When the pattern was finished, I replaced the lens cap and closed the shutter. The stray light in the lower left is from the power supply, controller board and motor LEDs.

light painted pattern
It looks like I need to do a better job of connecting the LED to the coin cell...

light painted pattern

These patterns took 3-5 minutes each to complete with speed set to 2000mm/sec, acceleration set to 10k mm/sec^2, and jerk set to 200 mm/sec. This could make a nice display if one were to move a UV LED over the surface of a glow-in the dark sheet of plastic or paper. It could also be used with an airbrush to paint a pattern on a piece of paper, wall, or floor.

Back to drawing patterns in sand...

After playing with the new setup for a while it was time to put the sandbox back onto the table and try drawing some patterns. At the old settings- speed 500, acceleration 1k, and jerk 20, the table ran pretty quietly- quieter than it did with steppers, even at 256:1 ustepping. Part of the noise reduction came from the pulley replacement- much less clattering and no more squeaking. There wasn't any motor vibration noise. The remaining noise seems to be from two main sources - the magnet sliding on the bottom of the table and the X axis clanking when the magnet carriage reverses direction.

I have fixes for both of those noise sources in mind- I'm going to be rebuilding the table with a thinner bottom (currently 1/2" thick plywood) which should allow me to put an air space between the magnet and the bottom of the table. The X axis problem will be solved by spring loading one or both of the Y axis bearings to keep both ends of the X axis firmly in contact with the Y axis frame rails.

I ran some of my previously generated patterns on the table - I was lucky- the newly designed pulley blocks and motor mounts left me with the same drawable dimensions as the old parts so I didn't have to regenerate the patterns. I started playing with the jerk and acceleration settings. The Duet2 controller is nice because it allows me to tweak all those settings on-the-fly while testing. I was quite surprised to find that the table could run patterns with acceleration set to 10k, which sped things up considerably, but also reduced quality of the final pattern because at high acceleration, the ball throws sand at the start of each segment, partially burying previously laid down lines.10k acceleration is definitely not for detailed patterns, but might be good for erase patterns, or patterns with a lot of spacing between lines.

Compare these two photos to see what happens as you increase acceleration and drawing speed.

This pattern was drawn at 500 mm/sec with 1k acceleration. Most of the short segments probably never got much over 100 mm/sec at that low acceleration. Lots of detail is visible.

The same pattern drawn at 1500 mm/sec with 10k acceleration. In this case most segments probably were drawn at >1k mm/sec. Note loss of detail due to sand being thrown around at high acceleration.

I was surprised that 10k acceleration didn't just leave the ball behind on the table. I tried cranking the speed up, too, to see how high I could make it run. Here's a pattern running at high and increasing speeds and accelerations:

I ran more tests at different speeds and accelerations. I found that at very high speeds, the ball throws the sand so much that the bottom of the table actually gets exposed in the lines that the ball leaves behind. Also, the ball tends to wobble a lot right after a direction change, similar to ringing in a 3D printer so lines that are supposed to be straight are wiggly with sand piled along the areas where the ball wobbled. Also, at very high speeds, the track left in the sand by the ball gets even wider than the diameter of the ball. Definitely not good for fine detail in patterns.

Drawn using stepper motors at 1 or 2k acceleration and 500 mm/sec speed.

Wide lines, loss of detail due to excessive acceleration and speed (10k and 1500 mm/sec).

After running a pattern on the table at "normal" speed and acceleration to make sure everything was working reliably, I started experimenting with speed and acceleration settings of an erase pattern. At 15k acceleration, when I set the speed to 2000 mm/sec I start seeing messages from the controller about "overvoltage condition". At 2000 mm/sec, the motors are spinning at 3750 rpm, well above the spec limit of 3000 rpm. I suspect the motor(s) are generating back EMF that exceeds the supply voltage. I made one attempt to run the ball at 3000 mm/sec and the ball flew away from the magnet at the end of a line and then the controller reset, probably due to the overvoltage.

Here's an erase pattern running at 2000 mm/sec:

Now when I generate patterns using Sandify, I use the start custom gcode block to home the machine and set appropriate speed and accelerations for the pattern. I also put an M84 (disable motors) command in the custom end gcode section. Disabling the motors stops the whiny squeaky sounds that come from the motor drivers while the motors are stopped. I may be able to eliminate that noise by tweaking the motor driver parameters.


The stepper motors were always running right at the limits of their performance and I had to run many patterns to figure out "safe" settings for the acceleration, jerk, and speed. Installing the servomotors eliminates any concerns about the motors being able to keep up with any settings for speed, jerk, and acceleration I might care to use when drawing patterns in the sand, or any physical changes I make to the mechanism. That makes the whole mechanism more reliable and opens up many new possibilities with regard to using the mechanism to do things besides drawing patterns in sand.

That said, if you build a small table, and/or you're content to run patterns at lower speeds, there's no reason to go to the trouble and expense of using servomotors.

I'll probably run the table at acceleration of 3-5k and set the speed to 400-500 mm/sec most of the time. It will slow things down a bit but still deliver detailed patterns. If I am going to demo the table at a Maker Faire (will there be any more of those?) I can run a few super fast patterns for the amusement of show goers.

I am planning one more redesign to use a glass top mounted higher above the sand to minimize thrown sand from sticking to it, quieter operation by finally fixing the X axis problem, and a slightly smaller size that will make it easier to transport and to use as a piece of furniture.

At some point in the not too distant future, I will probably try the servomotors out in UMMD, my corexy 3D printer. More posts to follow...


 I added a sprung bearing to one of the Y axis bearing blocks and eliminated the clunking noise it was making when the X motion reversed direction: