Arrakis: "This is part of the weirding way that we will teach you."

The Spice Must Flow (referred to hereafter as TSMF) sand table was a fun and interesting project that went through many changes to the mechanism, electronics, and software. I made several posts about the changes made.

TSMF had three main problems - it was too big to use at home, a little too noisy, and didn't look like furniture that would be acceptable in my living room. I decided to build a new, smaller table, with a more presentable finish, that I could use as a coffee table. It would have to be the right size, the right height, and as quiet as a mouse. I think I succeeded, though you may not care too much for the finish...

The result is "Arrakis", named for the sand covered planet in the Dune novels by Frank Herbert.

Arrakis, in all her glory! I gave her a haircut after this photo was taken, trimming off the fur peeking out from under the glass top inside the box.

Here's what I did that is different from TSMF.

The Mechanism

The Arrakis mechanism is smaller, and closer to the floor to make it more usable as a coffee table. 

TSMF's mechanism had a couple problems. The 45 mm square t-slot frame was a little flexible. I found that the belt tension was sufficient to cause the Y axis frame rails to bow outward. When X direction motion reversed, especially near the center of the table, the entire X axis would shift in the Y rails and make a clunking noise. I made a partial fix by bracing the frame with crossbar made of wood that helped prevent the rails from bowing, but it was still a problem.

I wanted a definitive fix for that problem in Arrakis so I spring loaded one of the Y axis bearings so that the X axis couldn't move back and forth between the Y axis rails, even if they bowed outward. I had also had a failure of one of the Y axis blocks due to poor design (the X axis tube was tight fit to the blocks and tended to split the printed layers apart). The new block design was made in two pieces, with screws that clamped it together over the X axis guide tube.

Here's the bearing/pulley block that has the sprung bearing. The light orange part is a PTFE bearing that fits in the t-slot of the XY mechanism's frame. The block at the other end of the X axis is identical, except the PTFE bearing is screwed to the block instead of sliding on pins.

The right side Y axis bearing/pulley block that has the sprung bearing as seen in the video, above. The three screws hold the two printed pieces together, clamping the X axis guide tube (black). One screw passes through holes drilled in the X axis guide tube. The pulleys are made from stacked F625 bearings and held in place with 5mm steel pins (you can see one pin sticking up a bit at the top).

This is the left side Y axis pulley/bearing block. In this one, the PTFE bearing that fits into the t-slot is screwed to the block. There's a flag for the Y axis opto endstop glued to the top of the block.

Another view of the right side Y axis bearing/pulley block.

TSMF's magnet carriage was also a problem. The magnet fit into a square hole with a light spring that kept the magnet pressed against the bottom of the sandbox. Dragging the magnet against the wood was noisy (and created dust under the table). It got even noisier when the motion changed direction. The magnet would rattle in its hole in the carriage and against the bottom surface of the sandbox.

In Arrakis, I wanted the quietest possible operation, so I redesigned the magnet carriage. Now the magnet is glued to the carriage so it can't rattle, and it is separated from the bottom of the sandbox by an air gap. 

The magnet carriage. The screws that hold it together also help anchor the belts. The belts are folded over the screws and clamped against themselves with teeth interlocked in narrow slots. You can just see the PTFE bearings contacting the X axis guide tube. There are four such bearings and their contact pressure on the guide tube is adjusted using shims made from soda cans.

The magnet is glued to the top of the carriage using silicone glue. The "blade" is the flag for the X axis optical endstop. In order to home the X axis, the Y axis must be homed first. 

This video shows how the pieces of the magnet carriage go together. There are four screws that hold the printed pieces together at the corners and serve as part of the belt clamping system. The blue parts are PTFE blocks that act as bearings to allow the part to slide on the X axis guide tube. I used shims made from soda cans to adjust the pressure that the bearings apply to the X axis guide tube.

Here is a video of the mechanism running at 200 mm/sec with plenty of close-ups of all the parts:

The Electronics

When I switched from steppers to servomotors in TSMF, I used two power supplies- one 150W supply powered one motor and a 200W supply powered the other motor, the controller board, and the LEDs (the LEDs had two buck converters to step the 24V down to 12V).

The schematic is the same as TSMF, except that I added a separate power supply (not shown) for the Duet controller board:

As I was working on the Arrakis mechanism I learned something about servomotors the hard way. I had finished putting the mechanism together and wanted to test the motion so I loaded a TSMF pattern file and started it up. I didn't consider what might happen running a large pattern on a smaller table. The magnet took off and quickly slammed into the end of one of the axes, coming to a loud and abrupt halt. The machine stopped dead and wouldn't respond to commands.

I did some research and found that that is a well known/understood problem among people who use servomotors. The problem is the kinetic energy of the system gets turned into electrical energy when the mechanism is blocked. That causes a voltage spike on the power supply line which, in this case, killed a power supply and the Duet WiFi controller board. Shortly after this, the small buck converters that were powering the LEDs from the same power supply also failed. I was lucky that the voltage spike didn't also kill the integrated driver in the motor.

I replaced the power supply, Duet WiFi board, and the buck converters (this time using higher power units), and added a separate power supply for the Duet board.

I found a protection circuit that will prevent power line spikes coming from the motor from doing that sort of damage, and have all the parts in hand, but need to come up with a circuit board for it. Watch for a blog post on the circuit board. In the meantime, I have provided the controller board with its own power supply to keep it separate from the motor.

Protective circuit for servomotors. If the voltage at the motor gets higher than the voltage from the power supply, the transistor turns on and shunts the voltage to the 33 Ohm resistor. When the motor voltage drops back to the supply voltage the transistor shuts off and everything operates normally.

In TSMF the electronics were mounted in a box that was attached to one of the table's legs. In Arrakis I mounted all the electronics on an aluminum plate screwed to the mechanism's frame. I used a Duet WiFi controller board so I wouldn't have to have a control panel on the table. Power on/off is controlled with a foot switch on the line cord. I used a white line cord because the table is best viewed in the dark and I didn't want to be tripping on the cord in a dimly lit room.

Electronics mounted on aluminum panel that's bolted to the t-slot frame. Left to right, 150W 24V power supply, Duet expansion board, Duet WiFi controller board, 200W 24V power supply. The other side of the plate has a small 24V supply for the controller board and two buck converters to power the LED strips in the sand box.

CAD rendering for positioning electronics.

Expansion board (left) that provides step/dir/enable to servomotors, Duet WiFi controller board, and 200W 24V power supply. 

The Sandbox

TSMF's sand box was made with 1 x 8" pine sides and a 1/2" plywood bottom. Pine isn't very good for much besides coffins, and is too soft- it will show every little bump. I wanted a different look for Arrakis so I ordered some red and blue fur that matches the LED lighting inside the table. I also wanted to use a thinner bottom panel so I could put an air gap between the magnet and the box to reduce noise.

I found that running TSMF at high speed would throw the sand with some of it sticking to the cover because the cover was too close to the sand. I had to open it up to clean the cover frequently. I designed Arrakis with the mechanism close to the floor and the glass cover about 230 mm above it, at coffee table height, to minimize cover cleaning.

As you may have seen in some of my photos and videos, I have a cat. She has one bad habit- she likes to chew on wires. I designed Arrakis so the sandbox would come down very close to the floor to keep Ms. Kitty away from wires and belts. If you build something like this you might also want to design it to keep pets or little kids away from wires, belts, pulleys, and motors.

The sides of the sandbox are made of 1/2" Baltic birch plywood. The corners are held together using aluminum corners of the type used to make musical instrument cases, and rivets. That's one decision I regret for reasons I'll explain below. 

The bottom of the box is made of 1/4" Baltic birch plywood. That allowed me to put the air gap between the magnet and the bottom of the box which reduced noise. During construction and testing the mechanism with the unfinished sandbox in place I noticed that the steel ball rolling on the plywood bottom of the sandbox made quite a bit of noise. I wanted to try to reduce ALL noise, so I did some experiments and found that a rubber coated steel mouse ball was very quiet (unfortunately, large diameter). Then I tried a steel ball rolling on a rubber sheet- also very quiet. 

I ended up gluing a sheet of black EPDM rubber roofing membrane to the bottom of the sandbox. That created another problem- it caused the plywood to warp. Eventually I got that under control and it went into the sandbox without any problems. The corners of the sandbox and the bottom edges are sealed with black silicone and the inside of the box is painted with matte black paint. 

Gluing the rubber sheet to the plywood caused the wood to warp! The PVC pipe was used to roll out bubbles trapped under the rubber. I later added staples to the edges of the rubber sheet, in case the glue ever lets go. I was able to get the warp out by putting a couple pieces of wood under the ends of the board and standing on it a few times.  It also seems to have settled a bit with time.

The outside of the sandbox was finished by gluing on pieces of high density 1/2" upholstery foam covered with blue and red striped fur cloth to match the LEDs that light up the table. The cloth was folded over/under the side walls and stapled to the plywood. The seams were hidden by cutting the cloth on the red/blue lines and carefully matching them up before stapling. As each piece was mounted, I glued the edges of the cloth to the foam, then carefully matched up the red-blue lines on the cloth so there would be no break in the pattern all the way around the table.

One corner of the sandbox showing the aluminum extrusion, rivets, printed spacers.

The sandbox was assembled on the granite counter top so the edges would all be in the same plane. The narrow strips are the supports for the plywood bottom of the box.

Installing the fur cloth. I painted the inside of the box black (well, more like charcoal grey), then cemented high density upholstery foam on the sides using a spray foam adhesive, then cut four pieces of the fur cloth (note the fuzz on the floor and in the sandbox), then stapled the cloth to the wood. You can see some printed neoprene spacers (red) that lift the box just enough to create the air gap between the magnet and the bottom of the box. The neoprene spacers were later replaced with printed TPU parts.

The box with the bottom in place and the cloth stapled down. LED strips are not yet mounted. I cut each piece of cloth along the red/blue lines and glued the edges to the foam so that there would be no visible seams where the different pieces of cloth meet. The fur hides the seams perfectly and I have a difficult time finding them even though I know they are there.

The top of the table is a piece of tempered glass that I bought for $6 via Craigslist. I made a frame for it out of oak by cutting the boards to length, milling in 1/2 lap joints at the corners, gluing them together, rounding the corners, sanding, staining, and finally finishing with oil based polyurethane. There is a black painted pine subframe that supports the glass. Eventually, I'll seal the glass to the top with silicone so that if some dope (probably me) spills a drink on the table it won't end up in the sandbox.

Staining the frame. The wood is 1"x4" oak cut to length and sanded smooth, with half-lap joints at the corners. The corners were rounded with a couple cuts with a pull saw and then sanded. After staining, I applied a few coats of oil based polyurethane, then added a sub frame to support the glass top. 

The LEDs are the same strips used in TSMF, cut shorter. The printed plastic clips to hold the LED strips in contact with the aluminum L channel heatsink did not inspire confidence, so I drilled a bunch of holes at every third LED and used zip ties to hold the LED strips down. They are covered with some black painted polystyrene trim boards that hide the aluminum heatsinks and prevent direct view of the LEDs.

I discovered that the black paint didn't stick to the aluminum corners of the box very well and quickly chipped the paint when installing the LED strips. I touched up the paint afterward, but I expect it will probably start peeling soon. I may need to put some sort of primer on aluminum when it's time to fix the paint again.

CAD File

You can access a STEP file of the Arrakis table here. I can't promise that everything is perfect in the file, so study it well before you try to duplicate anything based on it.

Mistakes made during this project:

1. cutting fur cloth with scissors- next time (?) cut from the back with a razor knife instead, and keep the vacuum cleaner close by.
2. aluminum corners for the sandbox, and the rivets used to hold them- paint doesn't stick well and the rivets take a lot of space. I think it would have been better to use 2x2 wood pieces and screws.
3. black EPDM rubber on the bottom of the sandbox- should have used white, and maybe faux leather instead of EPDM. Contact cement would have probably been better and caused less warping of the 1/4" plywood, too.
4. LED wiring- I need to put more effort into creating contacts on the sandbox and frame mechanism to connect LED strips just by dropping the sandbox into position on the frame. Maybe adapt some battery contacts...

A New Post-Processor to Speed Sand Table Pattern Drawing

Update October 17, 23:

Changes have been made to Sandify that required changes to dual_speedify.pl described below. I have updated dual_speedify.pl to a new version called dual_speedify_v2.pl to work with the newest version of Sandify. You can download dual_speedify_v2.pl here.

The new version looks for G1 statements, not G01 statements, and input speeds are in mm/sec instead of mm/min (output filenames still show mm/min speeds).

Now back to the original post:

A little history

Back when I worked on The Spice Must Flow sand table, I found an undesirable characteristic in Sandify, the software that generates the pattern files. For some patterns, it created a lot of excess motion along the edges of the table that drastically increased the drawing time and was boring to watch. I wrote a crude Perl program that would post-process Sandify pattern files to eliminate most of the excess edge motion, often reducing the pattern drawing time by 50% and reducing boredom by about 90%. Shortly after that, a better implementation of that function was written into Sandify by one of the Sandify programmers, where it now works very well on every pattern generated.

So what's the problem now?

The Arrakis sand table is now working and I've turned my eye toward improvements. Arrakis can run up to 2000 mm/sec at high acceleration (up to 2 g!) thanks to servomotors. It's impressive to watch it moving like that, and throwing sand all over the place, but the sand throwing wipes out some of the detail in the patterns. Sometimes it's nice to run it slowly so the pattern finishes with all its most intricate detail intact. 

I normally set the speed for each pattern in Sandify by using the "program start code" box when I export the pattern. That speed value is applied to all motion in the pattern except homing which is set in the table's controller board firmware. If I want to see a lot of detail in the pattern and don't mind it taking a long time to finish, I set the speed to 100 mm/sec using a G01 F6000 statement. If I want it to run fast, I set the speed to 1000 mm/sec using a G01 F60000 statement.

This is how I set speed in Sandify. G01 F60000 sets the speed to 1000 mm/sec.

And that's the problem. Run the pattern slow, and you get lots of detail, but the motion along the edges, that doesn't contribute to the pattern, also runs slowly. 

Some patterns have a LOT of edge motion and running them slowly can get pretty boring to watch. It would be really nice if there were a way to speed up the edge motion while leaving the drawing motion at a low speed to preserve detail. 

Sandify Pattern File Structure

Sandify pattern files are plain text files that start with a series of comments about the parameters used to generate the pattern contained in the file. Then the "program start gcode" statements, followed by a bunch of G01 statements that define the pattern itself, and finally a few more lines from the "Program end gcode" box in Sandify.

The gcode interpreter in the controller firmware uses each G01 as an instruction to go from the last coordinate specified in the last G01 statement to the new coordinate in the next G01 statement. In gcode, the speed is "modal" which means setting it once applies until you set it to a different value. So when I set the pattern speed to 1000 mm/sec using G01 F60000, as in the example above, that speed is applied to all motion. Sandify doesn't allow for speed changes within the pattern file but gcode does. In fact, gcode allows setting speed on each and every segment described by a sequence of G01 statements. For example,

G01 X112.000 Y554.260 F6000

tells the controller to move the ball from wherever it is to (112,554.26) at a speed of 6000 mm/min (100 mm/sec).

I tested the idea of bumping up the edge speed by manually editing a pattern file so that the edge motion runs at 1000 mm/sec while the drawing speed is 100 mm/sec. First I generated a pattern in Sandify. Then I used notepad++ to search for and mark all gcode statements that include a point on the edge of the table. Then I went through the file and looked for all the edge to edge movement and appended F60000 to those statements. Since speed is modal, I had to append F6000 to the statements that return to drawing on the table so they'd draw at 100 mm/sec to preserve pattern detail. 

Here's a portion of the manually edited file (right) compared to the original file (left). I added speed changes highlighted in orange. It took me about 15 minutes to manually make the edits on this relatively small pattern file.

The video below shows the results of the test- the first is run at 100 mm/sec for all motion, and about half way through the video it switches to the same pattern run at 100 mm/sec for drawing and edge motion increased to 1000 mm/sec. Acceleration is set to 5000 mm/sec^2 for both. The 100 mm/sec pattern took 25:42 to complete and the dual speed version took only 15:13, shaving 10:29 (and a lot of boredom) off the completion time.

This test convinced me that it was worth the effort to try to automate the dual speed process.

Time to program again...

Each G01 line in the Sandify pattern file specifies a point somewhere on the table. Every time the controller board reads a new line of the pattern file, it figures out how to move the motors to go from the previous point to the new point, and applies whatever speed has been specified (subject to acceleration set in the controller's firmware).

I want to specify two speeds, one for the drawing, and one for the edge motion. That will allow me to use a low speed for the drawing that will preserve the fine detail in the pattern and a high speed for the edge motion so that the pattern will finish drawing faster.

Each segment (any two sequential points specified in the pattern file) either draws a line on the table or moves the ball around the edges of the table. The program has to figure out which is which and then apply the low or high speed appropriately.

The first step in figuring out whether a segment specifies drawing on the table or moving along the edge is to figure out where the two end points are among nine possible locations- the four corners, the four edges, or on the table.

The nine possible locations for any single point in the pattern file.

But how do you know the location of a given point? You read the minimum and maximum values of X and Y out of the original file. A is at (minx, miny), B is at (minx, maxy), etc. A point on the left edge is at the minimum X value, but not minimum or maximum Y value (those specify the corners A and B).

Once you know the two positions, it's simple logic to determine if the the segment draws on the table or moves the ball along an edge. Actually, the locations are intermediate values that are not entirely necessary to use. One could just compare X and Y values of the two points and use them to decide the speed, but the locations make it a little easier to understand the logic of the program, to write it, debug it, and to maintain it.

If you know the locations of the two points, you know if that segment draws a line on the table. For example, if the first point is at corner A and the second point is at T, TE, C, or RE, the segment will draw a line on the table, so it should happen at the lower speed. If the second point is anywhere else, it will be edge motion at high speed. If the first point is at TE and the second point is either B or C, the segment is along the edge and movement should happen at the high speed. If the second point is anywhere else, the motion will draw a line on the table so it should happen at the lower speed.

The program I wrote does just what is described above. It compares locations of points specified in sequential G01 lines, determines whether the segment draws a line or moves along the edges and appends the appropriate speed designator to each line.

This program was a lot easier to write than the one I had previously written to remove excess edge motion, but this was a much simpler problem to solve.

The Result

I wrote the post-processor program, dual_speedify.pl, in Perl. Input to the program is the drawing speed, edge speed, and Sandify pattern file name and coordinates of the home point. Output is an edited pattern file using the input file name with the low and high speeds appended. It scans a Sandify pattern file line by line, locates edge motion and sets it to run fast while setting all other motion (that actually draws the pattern) to run slowly to maintain detail. The speed values entered can be the same value if you don't want the speed to change during a pattern.

The Perl program, dual_speedify.pl, can be downloaded here. There are lots of comments so it should be pretty easy to understand it and make changes if you want.

You'll need to have Perl on your computer to run this program. It was written using Perl 5.32 in Windows, but it doesn't use any exotic stuff that may have changed, so it will probably work on older versions of Perl, too.

To run the program, open a command line console, type "perl -w dual_speedify.pl" and then follow instructions:

As it states, there's no error trapping, so type carefully and open the output file to check it before you try to run it on your table. Remember- speeds are specified in mm/min, NOT mm/sec!

Here's a short video of a pattern that was processed with dual_speedify.pl running on Arrakis.

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.