Bank Account Protection Circuit for Servo/Stepper Motors

Update 6/11/22

The parts I ordered from Mouser finally arrived, after 6 months of delays in getting the connectors. Here's one of the boards, fully assembled, using the 1W wirewound resistors and including the connector:

If you decide to build some of these circuits, you can skip the connectors and just solder the power in and out wires to the board.

Now back to the original post...

Prologue:

I wrote most of this post a couple months ago but didn't publish it because I was waiting for the connectors I ordered from Mouser Electronics. When I first ordered them, one piece was out of stock and due to be back in stock in a couple weeks. In a couple weeks I got an email informing me that the back ordered parts wouldn't be in for another month. A month went by and I got notice that the backordered parts were in stock but one of the other pieces was now out of stock. They're telling me that the parts should be in stock at the end of May. 

I decided to try using the servomotors in my corexy 3D printer, Ultra MegaMax Dominator and wanted to have protection for the controller board and all the other stuff that connects to the power supplies that power the XY motors, so I went ahead and wired in the protection circuits without the In/Out connectors.

Next time I order parts, I guess I'll have them ship as they arrive in stock instead of holding shipment until all parts are available.

Why Does My Bank Account Require Protection?

A while back, when I was working on the Arrakis sand table, I discovered that one really needs to take some special precautions when driving servomotors (or steppers) at high speed and acceleration. I had a Duet controller board, a couple buck converters to power LED strips, and servomotor, all connected to a single 200W 24V power supply. I made the mistake of driving the mechanism into the end of an axis at 1500 mm/sec. The sudden stop caused the motor's kinetic energy to be converted to electrical energy which ended up on the power supply line, blowing up the controller board, power supply, and buck converters, about $200 worth of electronics, hence the title of this post.

Motors generate voltage that opposes the voltage trying to make them turn. Under certain conditions, they can generate more voltage than the driving voltage. Those conditions include driving them at excessive speed, manually turning them (such as when sliding around the extruder in a 3D printer by hand), and slamming into physical stops while they are moving at high speed (like I did). In the Arrakis sand table, a simple error in generating the pattern file that's a little bigger than the actual table dimensions (combined with an incorrect axis maximum definition in the config file) can cause such a sudden stop. In servomotors like the iHSV series parts I used in Arrakis, the specified maximum rotational speed, 3,000 rpm, is limited by the self-generated voltage. When generating a pattern file for Arrakis, it's easy to make a mistake that will drive the motor beyond the 3,000 rpm limit.

Protection can take different forms. In Arrakis, which runs RepRap firmware on a Duet WiFi 3D printer controller board, I can program speed, acceleration, and travel limits in the Duet's configuration files. In theory, the fault condition should never occur. However, all that assumes that the controller hasn't lost its mind, that there are no mechanical failures, and that the dumbass (specifically, me) experimenting with the mechanism remembers to set the correct software limits in the controller.

What is really needed is a device that will protect my bank account from my stupidity, an insane controller board, or a mechanical failure in the mechanism. Preferably it will be a circuit that will sense a fault condition and keep it from damaging the electronics that might be sharing a power supply with the motor.

Someone on a web forum pointed out a protection circuit in an app note from Gecko Drives, a company that makes stepper and servo motor drivers. 

The circuit is pretty simple- the 1,000uF cap absorbs small current spikes that may occur under normal operation of the motor. Normally, motor current from the power supply goes through the diode to the integrated motor/driver. In the event of a sudden motor stop due to hitting the limit of an axis, or a bearing seizing up, or some object blocking the motion, the motor will put a reverse current spike on its power line. That will cause the voltage on the capacitor to rise above the power supply voltage, reverse biasing the diode (switching it off) which will turn on the transistor, dumping the current coming from the motor to ground via the 33 Ohm resistor. The power supply and anything else connected to it will never see the voltage/current spike from the motor.

I ran a simple simulation in LTSpice to see how it works. The voltage source on the left is the 24V power supply and the current source on the right stands in for the motor.

It's not much of a model, but it roughly demonstrates what happens in the circuit:

The green trace is the current in the motor. It starts at -3.4A, which represents the loaded motor current supplied by the 24V power supply (V1). When the current reverses direction (the fault condition) the voltage across the motor (blue trace) rises. Current through R3 (33 Ohms) starts at about zero because the transistor is off. When the voltage across the motor rises above 24V, the transistor turns on and current through R3 (red trace) rises. The power supply voltage is the light blue trace- notice it barely moves.

I decided I needed to build some of these circuits as I have 4 more of the motors waiting for projects (in addition to the two that are in Arrakis). I thought about hay wiring them, but it didn't seem like a good idea, so I needed a printed circuit board. I asked around the makerspace and a couple people recommended KiCAD, so I gave it a try.

Parts Selection

When you lay out a PCB, you need to know exactly which parts you're going to use in order to select appropriate footprints. The app note doesn't say too much about the parts so I made some calculations of basic specs then went shopping. I decided to use through-hole mounting for all the parts because they're easy to handle and solder.

The motor current normally flows through the diode so it has to be rated to handle it. The data sheet on the motors seems to indicate that the nominal load current for the motor is 3.4A  (3.4A x 24V=81.6W, and the motor is advertised as a 78W motor, so the current seems about right) and that the driver will alarm (and hopefully shut down?) at 300% of that. 300% of 3.4A is 10.2A, so I chose a 15A 100V Schottkey diode (SMC 15SQ100). In normal operation, with 3.4A going through the diode and voltage drop of 0.5V, the diode will have to dissipate about 1.7W, so it's going to get warm/hot (assuming the motor is loaded and drawing full current).

In the "Arrakis Incident" the motors were brought to an abrupt stop which is what caused the voltage/current spike that blew up the power supply and other electronics. If there had been a protection circuit like the one here, after the stop and current spike, the motor might have started up again (the power supply wouldn't have been dead) and run until it slammed into another hard stop. And it might have kept going, over and over. Hopefully, I'll be there watching it and will shut off power before the repeated slamming around does any damage.

The iHSV motor's integrated drivers appear to monitor the motor speed and/or supply voltage and will shut down the motor/driver if you try to drive it so fast that the self generated voltage exceeds the power supply voltage by some unknown amount. Other motor and driver combos may not do that.

If you try to drive a motor beyond it's spec rpm limit, the voltage at the motor will rise, Q1 will shut off, and the motor will slow down or stop until Q1 turns off again, and then the motor speeds up again repeating the cycle (again, the iHSV motors don't seem to do this). In some mechanisms it might keep doing that until someone notices that something is wrong and shuts down the machine. That means R1, R2, R3, and Q1 will all be working to dissipate energy from the motor on a repeated basis.

I point out the different types of faults because it affects the component selection. When Q1 is off, the normal state, R1 and R2 have very tiny current passing through them. In a fault condition, the current goes up and depends on the magnitude of the voltage/current spike produced by the motor. A 20V rise will cause 20 mA to go through R1 and R2. A 76V rise (which puts us up to 100V, the rating of capacitor C1) will drive 76 mA through them. 20 mA will dissipate 0.4W and 76 mA will dissipate 5.8W. Unfortunately, I can't really predict how the iHSV motors behave. There's no way to know what the voltage/current spike will look like under different fault conditions, and I'm not prepared to risk destroying a motor to find out. I chose to use 1W resistors for R1 and R2 and hope that will be sufficient. I used wire wound resistors because they can tolerate power surges better than other types. The ones I used are good for 10x their rated power (=10W) for 5 sec.

The app note specifies a TIP147 Darlington PNP transistor, so I chose one in a TO-220 package. Does it need a heatsink? This also depends on the magnitude and duration of the fault. I think it will only operate for a few seconds at a time under fault conditions, so I think it is safe to dispense with a heatsink.

This is a relatively high current circuit, so I chose a 4 pin Molex MegaFit connector rated for 23A per pin. I also ordered crimp terminals and shell for the plug that mates with J1.

I put together a BoM with part numbers from Mouser and Digikey here. You can make all sorts of substitutions and find the same or similar parts from other dealers. Prices in the BoM are approximate, of course. 

Designing the PCB

I watched a few youtube tutorials on using KiCAD, and dove in. One thing I found out is that if you're going to have PCBs made by OshPark or other board maker, it's best to set up the board maker's design rules before starting the board layout. 

I went to the OshPark website and looked up their design rules and checked them against the defaults in KiCAD. It turns out there were no issues so I didn't really have to change anything. A more complex board or using surface mount parts might require some of the changes.

Next I drew the schematic diagram:

Once the schematic was entered, I selected footprints for the parts. I checked data sheets for part dimensions and selected appropriate footprints from the KiCAD libraries. Then I just dragged the parts into position, paying attention to the net connections, defined the outline of the board, placed mounting holes, and started putting down traces. I used a filled area on the top of the board for a ground plane and put the rest of the wiring on the bottom of the board.

I had to change the connections to the connector a few times before arriving at the final pinout. Some pinouts led to difficult arrangement of the components on the PCB that required jumpers, etc. I found that by playing with the connector pinout I could create a very simple layout for the board.

The diode will carry the full motor current under normal operation, so the metal traces on the board need to be pretty wide to ensure low resistance and heating. There are a bunch of on-line PCB trace width calculators that will give a pretty good idea of the required trace width for any given current, trace length, and temperature rise. I used this one. I put the diode very close to the connector pins to minimize the high current trace lengths and used 10mm wide, filled areas for those connections for the same reason. They should be able to handle the fully loaded motor current and even the peak current without burning up, even with 1 oz copper.

The capacitor and transistor CE loop are the only other places that are likely to see much current so I used wider traces for those to minimize resistance/heating.

The final steps before ordering the board are to run a design rule check, fix any problems that it reveals, and then export Gerber and drill files.

This is the final layout which I have named REDump for "returned energy dump":

The board layout just before design rule check. The outline of the connector extended beyond the edge of the board so I had to edit it back to pass DRC.

The board is relatively large, 60 x 65 mm, due to the large sizes of the capacitor, 33 Ohm resistor and the connector. I used 4 mm mounting holes set at 50 and 55 mm spacing. I kept the edges of the board clear so that it could be mounted in slots in the walls of a case instead of using the screw holes.

I deliberately hung the connector beyond the edge of the board so that if I print a case for it the connector can protrude through the wall and the wall will mechanically support the connector. This overhang was flagged during the design rule check so I edited the footprint silkscreen layers so they wouldn't be drawn beyond the edge of the board.

I ordered a prototype run of 3 of the boards for about $30 from OshPark.

You can download the gerber and drill files in a zipped archive here if you just want to order boards, or the entire set of KiCAD project files is here if you want to do some editing for other parts/footprints.

And here it is:

I probably should have used bigger holes, pads, and pad spacing for the diode and the 1K resistors. When I order more boards I will make the changes to the files.

Assembly

There are no tricks- just put the leads through the holes and solder them down. Pay attention to polarity of the diode and capacitor, and make sure you put the transistor in the right way- the heatsink tab should be toward the connector. 

Note- the 1W resistors and connector are all still back-ordered after about 4 months, so I built it using 1/2 watt resistors and no connectors.

Testing

I did some static tests to verify operation- first just applying supply voltage to the input and making sure it appeared at the output with a resistor substituting for the motor. Then I applied a voltage to the output to make sure sure the diode turned off and the transistor turned on. 

Finally, as I was preparing to install the servomotors in UMMD, I made a test video that indicates the protection circuit will indeed protect the power supply and other circuits from a voltage spike generated by the servomotor.

Installation

When you connect potentially high current wires it's best to avoid ground loops. That means each ground wire should go all the way back to the power supply. That's how I wired this into UMMD. The REDump board ground has a wire back to the power supply ground, and the ground from the motor goes back to the supply ground, not to the REDump board ground.

That means a 3 wire cable is required at the REDump connector. The crimp terminals listed in the BoM are for the plug that fits the jack on the PCB, and are for 14 or 16 gauge wire. If you're going to use some other gauge you'll need to order a different part number for the crimp terminals.

It's also a good idea to twist high current wire pairs, so when I installed the REDump boards in UMMD, I twisted the ground and supply leads from the REDump board back to the power supply, and twisted the motor ground lead around the supply wire from the REDump board together, then continued twisting the ground lead from the motor around the ground and supply leads from the REDump board back to the power supply.

In the future I'll be installing these boards in Arrakis so I can start experimenting with really high speed drawing without having to worry about what might happen if there's a mechanical failure.

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.

Here's What Happened When I Swapped Servomotors For Steppers In My 3D Printer

A little while ago, I replaced the steppers in The Spice Must Flow sand table with iHSV42-40-07-24 servomotors. The results were so impressive, I just had to try them in my coreXY 3D printer, UMMD.

Even though both use coreXY mechanisms, the sand table and 3D printer are two different animals. The sand table needs high speed and quiet operation over positioning precision and accuracy because sand is a very low resolution medium. The 3D printer doesn't need to be so fast, but does need to position precisely or print quality will suffer. 

It turned out that servos worked much better than steppers in the sand table. It was time to see if they would deliver similar or any performance improvements in a 3D printer.

Why would the servos have any advantage over steppers in a 3D printer? 

They run smoother and quieter since the motors don't have the detents that a stepper has. The particular servos I used are 78W motors, so can deliver much higher acceleration and jerk than the steppers can - much more than is necessary. The thing I mostly wanted to see was if they could deliver the kind of precision and accuracy that the steppers did, and that would show up in the print quality.

UMMD BS (Before Servos)

UMMD used two 64 oz-in, 400 step/rev, NEMA-17 motors to drive the XY mechanism. I ran them with 256:1 interpolated microstepping to keep them quiet. I typically ran the printer at acceleration of 2000 mm/sec^2, jerk speed of 30 mm/sec, and print speeds of around 80 mm/sec. Print quality was generally excellent, though some recent experimenting with non linear extrusion and pressure advance has it over extruding on top solid infill a bit- the tweaking never ends- sigh...

Installing Servos

The servomotors are also NEMA-17 size and have integrated encoders and drivers and accept step/direction/enable signals just like stepper drivers, so installing them in the printer was a pretty easy process, much easier than replacing steppers in the sand table.  All I had to do was remove the steppers and bolt in the servos, add the Duet expansion board to the controller, and connect the power supply and step/direction/enable lines, then tweak the config file for the Duet controller board.

I also added another 24V power supply to power one of the servomotors because I discovered in the sand table that the motors can draw a lot of current when accelerating and I didn't want the power supplies to limit the performance of the servomotors.

Setting the Motor Steps/Rev

The drive pulleys are 20 tooth*2 mm pitch, so move the mechanism 40 mm/rev. I want to be able to drive the mechanism up to 200 mm/sec with the servos, so 5 revs/sec = 300 rpm. The Duet can deliver 120,000 steps/sec. 120,000 step/sec / 5 rev/sec = 24,000 steps/rev. So jumpering the motors for anything less than 24000 steps/rev will allow the print speed over 200 mm/sec. 

I jumpered the motors for 20,000 steps/rev. which should give a top speed of 120,000 step/sec / 20,000 step/rev = 6 revs/sec. 6 revs/sec * 40 mm/rev = 240 mm/sec. 

Configuring the Duet Controller

20,000 steps/rev / 40 mm/rev = 500 steps/mm, which is more than an order of magnitude beyond the resolution needed in a 3D printer.

I set the Duet to drive X and Y with full steps, set steps/mm to 500, and left acceleration and speed settings as they were with the steppers. I also set the timing parameters to drive the servos as I did in the sand table.

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: X500 Y500  ; sets steps/mm for motors using 20 tooth drive pulley and 20,000 steps/rev
M350 X1 Y1 ; sets Duet to output full steps (microstepping is handled by the servomotor drivers)
M201 X10000 Y10000 ; set maximum acceleration limits for each axis
M204 P2000 T2000 ; set print and travel move acceleration
M566 X20 Y20  ; set maximum jerk speed for each axis
M203 X240 Y240 ; set maximum speeds for each axis

Configuring the Servomotor Drivers

Maximizing positional accuracy using the servomotors requires tuning the driver parameters for that purpose. I dug into some information on tuning servo motors and poured over the manual for the motors to glean what I could about the available parameters and their effects on positional accuracy.  

The first step in the process was to get my computer to talk to the motors. The motors need RS-232, not serial TTL, so look for a USB to RS-232 adapter based on a PL2303 chipset. It will provide real RS-232 voltage swings between +3.3V and -3.3V.  I ordered one of these.  This adapter has a male DB9 connector which is fine for some uses, but the motors have spring terminal connections, so I cut up an old serial cable that had a DB9 female connector at one end. I cut the male connector off the other end and stripped the Tx, Rx, and Gnd wires and connected them to the motor.

USB to RS-232 converter using PL2303 chip. I connected an old serial cable to the DB9 connector and used only the Tx, Rx, and ground wires to connect to the motors.

The manual says the default modbus speed of the motors is 9600 bps, but the RS-232 speed default is 57,600 bps, even parity, 1 stop bit. I'm not entirely sure what a modbus is in the context of these motors, but it doesn't matter- RS-232 is what you use to configure the drivers.

I was able to read all the factory setting for the parameters which I immediately saved to a file in case I did something wrong later and needed to get back to the defaults.

The next page of the manual has the settings for autotuning the motor:

I ultimately used the built-in autotune function to tune the parameters automatically, while the motors were driving the printer mechanism. 

First Test Results

I knew before testing that the servos can run at much higher acceleration and jerk than the steppers, but I also knew that high acceleration and jerk lead to noisy operation as the mechanism will make a banging noise (and shake the printer) each time the movement direction changes. My first comparative tests kept the acceleration, jerk, and speed at the nominal stepper settings so I could compare noise levels and print quality.

Before I installed the servomotors, I ran a test print using the nominal settings I normally use in the printer. Specifically, acceleration 3k, jerk 20, and print speed 50 mm/sec.

 

After the servos were installed and the Duet was configured, I ran the same test print STL file at the same acceleration, jerk, and speed settings I had used for the test print with the steppers. Here are some photos and video of the two prints. I haven't done anything to alter the volume in the videos- what you hear is what I got.

First layer of print with servomotor.  It does not look promising!

First attempt to print with the servomotors. Poor quality with 'salmon skin" effect at all 45 degree corners of the print.

Test print made with the stepper motors. Some ringing due to the relatively high acceleration (3k), but otherwise good quality.

Servo print.

Stepper print.

Servo print.

Stepper print.

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.

This is a 28 oz-in NEMA-17 stepper motor. It is 34 mm long.

Now compare that motor's length to the servomotor:

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: https://www.motioncontroltips.com/faq-whats-the-difference-between-detent-torque-and-holding-torque/

"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: https://www.orientalmotor.com/stepper-motors/technology/speed-torque-curves-for-stepper-motors.html)

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.

This is typical servomotor torque vs speed behavior. Note that peak torque is much higher than the continuous torque. 

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: https://www.linearmotiontips.com/how-to-use-torque-speed-curve-to-select-servo-motor/

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.

Acceleration

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.

Speed

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 lineramotiontips.com, 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.

Resolution

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

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. 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, 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, cables, and optical endstop. The yellow part (upper left) with pulleys is one of the Y axis bearing 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).

Wiring

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.

This is the wiring I used to connect the Duet 2 expansion board to the servos (upper half of the diagram- the lower half is for wiring alarms which I did not do). This was taken from page 42 of the motor manual.

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.

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.

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 amazon.com

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.

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":

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 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.

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

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.

Conclusion

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...

Update:

 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: