More Sand Table Updates- Making It Run Quietly

The Spice Must Flow sand table was working well and I liked running it at 500 mm/sec because that speed was fast enough to make it interesting to watch.  The problem was running it at 500 mm/sec was noisy.  Not vacuum cleaner noisy, but loud enough that you wouldn't want to have it running in your living room on a regular basis.

I decided to figure out where the noise was coming from and how to reduce it to an acceptable level.

I identified several sources of noise (in order from loudest to quietest):

1. Motors
2. Belt teeth hitting smooth pulleys
3. Pulley bearings
4. Sliding bearings in X and Y axes

I originally built the table with NEMA-23 motors because I had them on hand.  I tried switching to NEMA-17 motors but they turned out to be only about 1 dB quieter, as measured with a sound meter app running on my phone.

That was when I was driving the motors at 16:1 ustepping using the smoothieboard that was originally installed in the table.

Higher Microstepping Ratios

The next thing I did was switch to a Duet WiFi controller board to use high microstepping ratios to try to quiet the motor noise.  The result was mixed, but I was able to figure out from my tests what needed to be done.

Here's video of the table with the Duet WiFi board driving the NEMA-17 motors.  Notice that at 100 mm/sec, any microstepping ratio above 32:1 is pretty quiet.  In this drive configuration I could only get to 175 mm/sec at 256:1, so I ran it at 128:1 so I could at least get to 350 mm/sec, but it was still noisy.  It occurred to me that at 100 mm/sec, the motors were turning at 1.25 revs per sec and at 350 mm/sec they were turning at almost 4.5 revs/sec.  So the key to quiet motor operation seems to be keep the motors turning slowly even as the mechanism moves fast.



I ordered a set of loop belts and pulleys that would give a 1:5 step up so that when the motors were turning at 1.25 revs/sec, the mechanism would be moving at 500 mm/sec.  Stepping up the speed by 5x divides the torque by the same amount and I found the NEMA-17 motors I had weren't up to the task.  I also found that at high microstepping ratios, the NEMA-17 motors hissed loudly and playing with the driver parameters wouldn't fix it.

I redesigned the motor mounts for the NEMA-23 motors- the hissing noise went away, and now the mechanism was able to run at 500 mm/sec again.

NEMA-23 1:5 motor mount and corexy drive assembly.  There's an 80 tooth pulley on the motor shaft and a 16 tooth pulley on the corexy drive shaft.  The original 40 tooth pulley drives the corexy mechanism.  Two printed green spacers ensure proper position of the 40 tooth pulley for corexy stacked belt configuration.  The motor mount and drive pulley blocks are kept in place using t-nuts.

With the 1:5 step up, I am able to run the motors at 256:1 ustepping to well beyond 500 mm/sec (I took it up to 750 without any issues).  The mechanism ran relatively quietly but there was still a lot of zip-zip sound that seemed to be due to the belt teeth hitting the smooth pulleys.  I redesigned the Y axis pulley blocks and enlarged the belt pass-through holes so I could put a twist in the belts and keep the smooth back sides of the belts against the smooth pulleys.  The zipping noise disappeared completely.

This is the previous Y axis pulley block design with a relatively small belt pass-through hole that would not allow the belt to be twisted.

The new Y axis pulley block (yellow) design with the large belt pass-through hole that allows for a twist in the corexy drive belt.  The other side of the corexy mechanism is identical.

One other change I made was to remove the magnetic endstop switches and replace them with standard type microswitches with levers.  The Duet board motor drivers can detect when a motor stalls, so in theory it should be possible to home the machine without using any endstop switches, but I'll have to get the friction in the mechanism down before I start messing around with that.  I may be running the motors too slowly for stall detection to work.

The Milwaukee MakerFaire was coming up fast so a lot of this work was done in a couple late nights and there was no time to test the mechanism fully assembled with the sand box, so that had to be done at the MakerFaire.  The result was disappointing.  The Y axis moves very easily but there's a lot of friction in the X axis motion.  I tried sanding down the UHMW bearings to give them a little looser fit on the X axis tube, but UHMW doesn't sand well.  I applied some silicone lube to the X axis tube and it worked fine for a few hours, but eventually, the friction came back and the patterns started shifting.

The MakerFaire wasn't really a quiet environment, but most of the noise I heard coming from the assembled table was the quiet grinding sound of the ball moving through the sand (!) so I think I'm finally getting close to the end of the design process.

I'm going to rework the bearings for the X axis and see if I can get the friction down to an acceptable level.  I'm also working on a new design for the sandbox that will have a thinner bottom and will allow an air gap between the magnet and the bottom of the box to minimize any noise that might come from dragging the magnet against it.  That will also reduce friction a bit, which can't hurt.

More on the Duet WiFi Board

I would ultimately like to make this table into a piece of living room acceptable furniture.  One of the things I disliked about using the SmoothieBoard was having the control panel on the table in a place where I could easily (by crawling under the table) access it.  That's great for displaying it at a MakerFaire, but not so great when it's at home.  For a piece of furniture, I want to hide the controller completely and even try to minimize visibility of the power cord.

When I was home working on the mechanism, the Duet WiFi board was perfect.  I was able to tweak all the configuration settings, and generate and wirelessly upload pattern files to run.  However, when I was at the MakerFaire, the wifi at the venue was flaky and I was unable to set the board or even my laptop to communicate on the network.  After some panicked digging around the reprap firmware wiki, I found that the firmware includes an access point mode in which the wifi radio on the Duet board will act as a host and I was able to connect to it with my laptop and get the whole thing up and running.  The only problem with that is that you have to start the access point mode by connecting to the board via USB, so I found myself crawling under the table again to get the thing running.

Fortunately, you only have to connect to the board using USB once to set up access point mode.  The wifi module will remember the settings (SSID, IP address, password) you used and will restart access point mode if you put an M552 S2 command in the config.g file that is run each time the board powers up.  Now when the machine powers up, I can connect my laptop by manually switching it to use the "network" that the Duet board is broadcasting.  No more crawling under the table to connect to the USB port!

Summary

256:1 microstepping, running the motors slowly using 1:5 drive step-up, and twisting the belts all contributed to reduced operating noise of the mechanism.  If you're going to build a sand table, and you want to run it fast, I recommend all the above to keep operation quiet.

Update!  Video, or it didn't happen!

More of The Spice Must Flow from Mark Rehorst on Vimeo.

The Spice Must Flow from Mark Rehorst on Vimeo.

The Spice Must Flow (again) from Mark Rehorst on Vimeo.

SoM Gets a Duet WiFi and PanelDue 5i Controller

A few months ago, the SmoothieBoard in SoM died when I managed to short something while working on the printer, so we installed an MKS Sbase board that one of the MakerSpace members had handy and also runs SmoothieWare.  Unfortunately, it was a piece of crap and didn't reliably read SD cards, and more recently, jogging the Z axis also moved the Y axis for some reason.  It had crappy DRV8825 drivers, too, that I never liked.

I decided to do the only sensible thing and install a Duet board, and since I had experience with the Ethernet version, I decided to try the WiFi board with a PanelDue 5i interface.

My experience with the Duet Ethernet board in UMMD has been mixed.  It has been very reliable, the drivers are really quiet, I like the Panel Due interface.  But I prefer to run printers from SD cards for reliability and not having to connect a computer to the printer.  The Panel Due 7i has a uSD slot along its bottom edge.  Unfortunately, the way the panel is installed in UMMD, I can't readily access the card slot and even if I could, it's a little too far from the controller board (you need to use a short ribbon cable to make the connection).  The Panel Due has the option of rotating the screen 180 degrees, so I could theoretically flip it over and make a hole in the top of the printer to access the uSD card slot, but then I'd have to worry about things falling into the slot and jamming it up.  Even though I have relatively small fingers, and mad hand skillz, handling a uSD card is a lot more difficult than an SD card.  I'm looking into fixes for that - maybe an outboard SD card slot that will plug directly into the Duet board.  With the Ethernet board and Panel Due 7i I found that I needed to keep a computer connected to the printer just to load gcode files.  That feels like a backward step to the bad old days when I was using Arduino/RAMPS and Pronterface to control the printer.  At least it uses a reliable network interface instead of USB with flaky drivers.

Sure, a Duet WiFi controller board would eliminate the need to have the computer physically connected, but if I take the machine to a MakerFaire or other location, I won't always have a reliable wifi connection to use, and I don't like having to waste time debugging flaky wireless connections.

I tested the Duet WiFi in the sand table before I installed it in SoM.  In the sand table the wifi controller is especially nice- I don't have to have any controls on the table which means I don't have to try to hide them.  I have ordered a Duet WiFi board for the sand table and will write a post on that when I get it installed.

Networking a 3D Printer?

Call me a Luddite, but I really don't see a big advantage to having a 3D printer on a network.  I clean the bed and verify that the filament spool that's loaded has enough filament to finish the job before every print.  If I have to go to the machine anyway, why not just plug in a card and start the print while I'm standing there?  The Duet's web server provides some data and control that is still missing from the Panel Due, but a lot of the data isn't particularly useful to me. The missing control capability in Panel Due can easily be added via macros, and I'm hoping that one day the Panel Due firmware will catch up to RepRap Firmware that runs on the Duet board.

Some people go out of their way to add a RPi running octoprint to network their printers.  If I were a baseball fan, I'd probably like staring at my printer while it's printing and enjoy the enormous amount of "stats" octoprint can produce, but I have better things to do I'm not impressed or entertained by data that isn't particularly useful, so I don't care too much for either baseball or octoprint.  I have no desire to try to impress people by starting prints using my phone, though it might be handy to be able to stop them when they fail (pretty rare).  It makes no sense to me to do the slicing on an RPi when I use CAD to design the parts I print on a higher powered, much faster laptop.  Maybe slicing on an RPi is OK for people who just download stl files to print, but I don't know many 3D printing people who remain at that stage for very long.  Sooner or later, almost everyone who gets into 3D printing wants to print their own designs.

Panel Due 5i Enclosure

I decided to try the Duet Wifi board to replace the controller in SoM.  Who knows, maybe I'll be impressed enough to change my mind about using SD cards and wireless networking.  But just in case I don't, I designed and printed an enclosure for the Panel Due 5i that leaves the uSD card slot accessible.  In SoM the Panel Due is close enough to the Duet board that the uSD ribbon cable works, so I have the option of using either the wireless network or the uSD slot to transfer gcode files to the printer.

The enclosure design was based on a GrabCAD model of the Panel Due 5i board.  Kudos to whoever uploaded the Panel Due 5i model because to my pleasant surprise, it was very accurate and my enclosure fit on the first attempt.  Even with the accurate model, I managed to spend far too much time designing the box.

This box was designed to allow easy access to the uSD card slot.

The top of the box has labels for the erase and reset switches that are used when updating the Panel Due's firmware.

The bottom of the box has holes for mounting it on a panel (I'll probably just use velcro tape) and slots that allow the ribbon cable and 4-wire cable (not shown) to pass through the wall of the box.

The circuit board is mounted on the top cover using 4 small plastic anchor screws.  The top cover snaps onto the bottom cover and holds securely.  The bottom cover has bosses that provide mechanical support for the top cover and circuit board.  I have since updated the bottom cover design to include some webbing to give it more rigidity.

The enclosure prints in 2 pieces without any support material.  The board screws to the top cover using 4 small screws, and the two halves snap tightly together and can be pulled apart as needed to access the the board for firmware updates, etc.  The Fusion360 CAD file is here.  It includes the GrabCAD model of the Panel Due 5i.

Installation

Before doing anything else, I updated the firmware in the Panel Due and added my own splash screen.  I used Irfanview to put red text on a green background (to match the color of the box), cropped it to 800 x 480, saved it as a .bmp file, compressed the .bmp file with escher3d.exe, then added it it to the firmware file using a "copy" command per the instructions, here.

I went through the cables in the printer and labeled them (probably should have done that years ago) as I pulled them off the MKS board so they'd be easy to identify and connect to the Duet board.  I replaced a bunch of the connectors with the much better quality ones that came with the Duet board.

I mounted the Duet board in the printer's electronics drawer on of the board mounts I designed and printed for UMMD.

Configuring the Duet Board

I used the online configurator and checked it against UMMD's config file to try to minimize problems.  I mounted the board and started hooking up the various connections, testing them as I went along to make sure they were working right and tweaking the config files as necessary.  It took about an hour getting everything working right, so it was pretty easy.

SoM had a DSP based driver and 32V power supply for the Y axis motor that was used back when it had a ball screw drive.  I did a couple experiments and found that the driver on the Duet board could deliver sufficient current to drive that motor, so I took out the DSP driver and power supply.  Simplification!

I ran into one problem after installing the Duet.  The X axis was making a lot of noise and vibrating.  Maybe it had been doing it for a long time and the noise was masked by the noisy ball screw that used to drive the Y axis.  I didn't pay much attention to it when I put the MKS board in the machine- that was a temporary measure to get it back up and running.  Now that the Duet was in and I was using high microstepping ratios, I expected quiet operation and was bothered by the noise.  I looked closely at test prints and found the vibration in the X axis was causing closely spaced vertical lines in the X parallel sizes of prints.

The problem had nothing to do with the Duet board.  It was a result of some small metal flakes getting into the motor and interfering with the motion of the rotor.  I wrote a separate blog post on that.  That problem was easily fixed, once I knew what was happening, and the X axis now runs quieter than it ever did thanks to the 128:1 ustepping in the Duet board.

Here's the inside of the electronics drawer now that the Duet is in place.  I know, it's ugly, but it's really easy to service, especially now that I have all the wires labeled.  I used this type of label- they are really tough.  I tried using them in a laser printer and found that the fuser heat distorted the labels and they tended to peel apart and even curl off the backing sheet, so I decided to just write on them with a permanent marker instead and had no further problems.  UMMD will get the same type labels the next time I have a reason to open the electronics enclosure.

Inside the drawer- no more 32V supply and DSP driver for the Y axis.  I used a custom splash screen that is displayed for a few seconds every time the printer is powered up.

A Motor "Failure" in a 3D Printer

Troubleshooting 3D Printer Motion Problems

Stepper motors are some of the most reliable machines human beings have ever invented.  And they should be- all they are is some steel, and some magnets spinning on bearings, and some coils of wire.  There are no brushes to wear out, so as long as you don't get it so hot that the insulation burns off the wires or demagnetizes the magnets, a stepper should work for many years, especially in the relatively benign environment of a 3D printer. 

The typical driver chips on 3D printer controller boards don't have enough current drive capability to burn up motor windings of typical motors used in 3D printers, though I suppose it would be possible for one of them to fail shorted and send a lot of current through a motor.  So unless you have a failed driver, it is very unlikely that you have a burned up motor.  If you do have a burned up motor you will be able to tell by its smell, and you will surely have a dead driver chip, too.

What I'm trying to say here is that in general, if you have a motion problem in a 3D printer, the least likely cause is going to be a failed motor.  So look carefully at everything else before you start replacing motors.  Everything else includes cables and connectors (very high failure rates) and driver chips (also high failure rate, especially if you use plug-in driver modules), drive pulleys and couplers, (are the screws tight?) and configuration issues.

If you've ever built a kit-type printer or even read a stepper driver data sheet, you'll have been warned about connecting or disconnecting motors while the printer is powered up.  The problem is that when you connect or disconnect a motor while it's powered, a large voltage spike that can kill the driver chip is generated by the inductance of the motor coils.  Now what do you think happens if you have an intermittent connector or motor cable?  It will connect and disconnect the motor and destroy the driver.  If you have a dead driver, carefully inspect the cable and connectors before you put a new driver in your printer, or you may end up with another dead driver.

An Atypical Failure 

I recently did some long overdue maintenance and mods on SoM which resides at the Milwaukee Makerspace.

I rebuilt the Y axis entirely, eliminating the noisy ball screw and converting back to belt drive.  I also put in a Duet controller and set it up for high microstepping ratio.  That quieted down the Y axis, but then I noticed that the X axis was making a lot of noise that it didn't used to make.  The noise sounded like something was vibrating, and it left closely spaced vertical lines in X axis parallel sides of prints.  Ugh!

This fine pattern was showing up on X-parallel sides of prints because the X axis motor was vibrating.

When I inspected the X axis and noticed some belt dust on the motor mount, I didn't think much of it. The machine has a Gates belt and a standard, cheapo GT2 drive pulley on the motor, both of which have been on there for years.  I disconnected the belt and tried moving the extruder carriage along the linear guide- it was as smooth as could be.  No problem there.

I tried running the motor without the belt and sure enough, it was vibrating.  I verified that the screw terminals and connectors were in good condition and tested the cable with a meter and found no issues.  I thought maybe it's the driver, so I swapped driver on the controller board- nope- the motor kept vibrating.  It had to be the motor itself.

I tried turning the motor shaft with my fingers and found that it took an unusually large amount of force to start it turning.  That's not right!

In SoM, the X axis motor was mounted hanging below the X axis, with shaft and pulley pointing up.  I thought that maybe some of the belt dust I saw got into the top bearing in the motor and was gumming things up.

I replaced the motor with another, pulled from an old stratasys printer mechanism.  It ran almost completely silent again, like it used to, so I did an autopsy on the failed motor.

The failed motor, with belt dust.

Cover removed- pretty simple...  There's very little clearance between the rotor and the stator pole pieces, so it wouldn't take much to jam it up.

All the pieces laid bare. I tried spinning the shaft on the bearings and it spun freely.  So much for the belt-dust-in-the-bearings theory.

I tried spinning the bearings and expected the top one to be sticky.  Nope.  Both spun freely.  Hmmm.  I inspected the rotor and found a couple small ferrous metal flakes (sorry, I didn't take a picture) stuck to the magnetic rotor.  After carefully removing the flakes and inspecting the entire rotor under a microscope, I blew out the inside of the body of the motor with some compressed air and then put the whole thing back together.  It spun freely like it used to, with just the normal, gentle bump-bump of the magnetic detents.  I suspect that metal flakes were getting between the rotor and stators and it was jamming things up.

So where did the metal flakes come from?  Hmm.  I think the bearings are the most likely source.  The motor was industrial surplus when I installed it in the printer about 6 years ago.  There's no telling how much use it had seen before I got it, so maybe the bearings are at end-of-life.  I'll order new ones and install them.

If you ever have an axis that starts vibrating a lot, inspect the motor!

A Coin and Wallet Holder for Prius

About a month ago I was driving down the highway when a pickup just ahead and to the right of me slammed into the barrels at the start of a concrete barrier.  That spun him around and I swerved to the left, but the rear end of the truck caught the right side of my car and tore it up pretty badly.  The driver of the pickup suffered a minor injury when his airbag went off, but I came out unharmed and no airbags blew.

My car was a 2008 Audi TT convertible.  I really liked that car.  Unfortunately, it had a lot of years and miles on it so it wasn't worth much.  The body and most of the frame were made of aluminum.  That means you can't hammer out dents or bend the chassis straight.  Anything that is damaged has to be replaced, and that gets expensive in a hurry.  The result is that the repair costs would have exceeded the value of the car, so the insurance company totaled it, wrote me a check, and I had to find a replacement.

My poor car!

I had been planning to sell the TT at the end of this summer anyway, so my plans got moved up a little.  I replaced the TT with a Prius.  I chose the Prius over the available all-electric options mainly because of its ability to haul stuff, reliability (I had a 2007 Prius and it never needed fixing), and low operating cost.  My next car will be electric, after the wheels fall off this Prius.

Yes, it's a big change!  The two cars are on opposite ends of the performance spectrum, but now I'm getting 60+ mpg, which is pretty satisfying in a different way.  I went for the "limited" version so I'd get heated seats and steering wheel, and a decent audio system.  It's also got adaptive cruise control, lane departure warning/assist, blind spot warning, and even parallel parking assist.  It also has a nice big 11" display for the GPS that I can read without glasses.  It's a huge improvement over the 2007 base model Prius I used to own.

New Car, New Problem

I hate sitting on my wallet, and I hate having to dig in my pockets for coins when I order coffee at a drive-thru, so I needed a place to put my wallet and coins when I drive.  The most obvious place in the Prius is the center console that has a tray that sort of works, but it's pretty easy to spill the tray inside the console, and then you have to dig all the coins out from the dark abyss that is the console's interior.  As the cowboy said in the Big Lebowski, it's "Darker than a black steer's tuchas on a moonless prairie night."

This is the console with the tray full of coins and my wallet.  Yes, that's my wallet- it's made from polyester and kevlar sail cloth, not duct tape.  I chose it to be easy to spot in a dark bag or console in a car.

There's a pocket in the driver's door, but I wouldn't want to take a chance on my wallet falling out when I open or close the car door, and it doesn't seem like a good place for coins.

There are two cup holders up front, but I'd rather keep those available for drinks.

The glove box is too far to reach.

I decided to go with the center console but not the tray that was already in there.  I wanted the coins organized and easy to grab without having to move my wallet out of the way first.

I checked Thingiverse and Youmagine for other people's designs and came up with nothing, so I set about designing it myself.

Designing A Coin and Wallet Holder

Step 1- measure everything.  I looked up US coin specs and got the dimensions and bumped the diameters up by about 0.7 mm so the coins would very easily fit into their slots.  I also measured the tray in the console (130 mm wide) and my wallet.

Step 2- layout.  I wanted the coins stacked vertically so they'd stay put and I wanted to drop my wallet into a vertical slot so it wouldn't take up too much lateral space in the console.  Everything had to be easy to reach and remove, and I didn't want crud to accumulate in the bottom of the wallet slot, so I left it open.  The wallet hangs over the thin back edge of the holder, and I put in a wide enough slot that it can easily hold even George Costanza's wallet.  The coin slots are 40 mm deep, so they'll hold quite a bit of change.

A Fusion360 render of the coin and wallet holder.

Step 3- print it.  This is going to be in a hot car so no PLA!  I printed it in ABS, 15% infill density, 0.2 mm layers, and turned on support material for the tabs at the top.  

Printing on UMMD.  The image is one of a sequence captured at 2 minute intervals using my old cell phone camera to monitor the printing process.  I printed in fluorescent green so it will be very visible in the darkness of the console.

More coins than I'll ever need, but if I ever forget or lose my wallet, enough to get a sandwich or a couple gallons of gas.

When it finished printing I loaded it with about $8.50 in coins and tried it in the car.  You have to rotate it a little to get it past the console's top cover, but once it's in, it's in.

It fits with or without the original tray and holds about $8.50 in coins.

The Fusion360 CAD file for the coin and wallet holder is located here.  You can download and edit the file or just export an STL file to print it as-is.

Update- Already!

After using it for a couple short trips in the car, I found that unless I was very careful lifting the wallet out of the holder, the wallet tended to pinch the holder and lift the whole thing.  It would be easy to spill the coins doing that!  I don't want to have to be careful- I want to just grab the wallet when I get out of the car. 

I added a printed plastic loop to the bottom of the wallet slot to allow me to drop the wallet into the slot and have it lifted high enough that it was easy to grab without lifting the coin holder.

Printed loop added to the wallet slot to lift the wallet a little higher than the coins.

The loop printed in about 20 minutes.  I solvent welded it to the coin holder with a couple drops of acetone.  Perfect!

A couple drops of acetone weld the loop to the coin holder.

Now the wallet stands up above the coins, making it easier to take it back out when I get out of the car.

The wallet fits easily and doesn't interfere with closing the top of the console in the car.

Putting it in this way risks spilling coins if you carelessly remove objects from the console.

Putting it in this way protects the coins from spilling.  They're still easy to take out when you want by sliding the coin holder back a little.

Wait a Minute!

After I designed and printed the coin and wallet holder, it occurred to me that there's no good place to put my sunglasses in the Prius.  Hmmmm.  As we used to say in high school drafting class, "back to the drawing board!"

I'll make another post when I come up with something.