Friday, August 16, 2013

Frostruder - XY Plotter Derivative

The XY Plotter now has a frosting extruder mounted in the place of the Sharpie as the "tool".  I used the Frostruder kit originally designed for the MakerBot, which uses two solenoids to control pressurized air to a syringe.  The syringe can be filled with frosting and the air pushes it out at a rate that depends upon the air pressure and the syringe tip size.

I connected the two solenoids through a series of relays to the Arduino microprocessor which is running the whole project.    Two pins control when pressure is applied to the syringe, and when pressure is vented to atmosphere.

The video below shows a proof of concept of the Frostruder in action.  The video is sped up 4x times.  There is still a lot of work to be done in terms of balancing variables to optimize the extrusion process; the variables include air pressure, time delay between when pressure is applied and when tool head motion begins, rate of tool head motion, and the nature of the frosting used.  Still I was very excited when this video was made because it represents a functional piece of equipment!


Unlike the original Frostruder, the syringe is separate from the electronics and solenoids which route the pressure.  Those are mounted to the frame of the 3D printer in a wooden box.  Tubing runs from the box to the syringe, which is mounted into a custom designed and 3D printed part.  The syringe can be easily removed with just an allen wrench.



SolidWorks and STL files for the carriage can be downloaded from the links below.  These parts were 3D printed using a Replicator using 20% fill and 3 shells. 


I have made two major improvements on the software side of the project as well.  I improved the Processing interface, and I took a major stab at correcting the slope change problem seen in the previous post.

Processing Interface Improvements:
  1. I calibrated the machine to determine the relationship between screen pixels in Processing, steps of the stepper motors, and XY distance traveled.    I changed the interface so that the grid shows inches now.  Unfortunately, the grid spacing doesn't work out very nicely.
  2. I added a clear button which removes the "lineLayer" PGraphic without having to restart the program.
  3. I added a slider based on the Control P5 library which controls the presence and size of a "cookie" in the center of the stage.  The cookie is to scale, making it easier to visualize.
  4. I added the ability to load an image which can serve as a template for drawing the lines on the Processing screen which correspond to the places where frosting will be laid down.  Making the template image is easy with the help of a screen shot tool.  Then the template file can be opened and edited in any image processing software, saved, and then loaded from within the Processing sketch window.  The video above was done with the help of a image file which had wordArt added using Powerpoint.



New and Improved Stepper Motor XY Interweave:
A previous post showed that my method to allow the X and Y stepper motors to move at the same time had a flaw.  The issue was essentially that slopes are often non-integer numbers when reduced to a reasonably small integer denominator, while stepper motors cannot take fractions of a step.  My previous algorithm was to reduce the decimal slope to the nearest smaller whole number, then calculate the remainder which was the additional number of steps required to go along the longer axis.  Those steps were taken at the beginning, effectively increasing the slope by 1 for as many iterations as it took to make up the extra steps.

For example, suppose that you wanted to take 28 steps in the Y direction and 23 steps in the X direction.  The slope, dY/dX is 1.217 which is not possible to do directly with stepper motors.  So instead, we have the motors run at slope 2 for five iterations, and then for slope 1 for 18 iterations, where each iterations corresponds to one step along the X axis.  The picture at left shows that this results in a tool path which substantially deviates from the ideal path, because all the remainder steps are taken at the beginning.

The solution is not hard; we need to space out when the remainder steps are taken instead of doing them all at the beginning.  One algorithm which is working for me is discussed below.  Note that this algorithm is not the most efficient, but it seems to be "good enough" in terms of actual performance on the device.

  1. Calculate the slope and round down, as before.  Also determine the number of leftover steps as before.
  2. Divide the number of iterations (equal to the lesser of dX or dY) by the number of leftover steps.  For example, in this case 23/5 = 4.6.  My algorithm rounds this number UP, because otherwise you could do too many steps.  This is the number of steps per iteration.
  3. Figure out how many steps are still leftover.  In this case, doing an extra step every 5th iteration means 4 steps will get done, so there is one more step to do.  This step is done at the beginning (in retrospect, it should be done at the end).  If there are more than two extra steps, the code repeats steps 2-3 one more time.
From the images below, we can see that the code works if it is somewhat convoluted.  I also setup an Excel spreadsheet which helped me to test the algorithm before actually writing the code for it.  I used the same spreadsheet to visualize the tool-path by having the Arduino printout the cumulative steps along both axes after each iteration, and then graphing these.
Two Method Comparison for dY = 40, dX = 25.
Two Method Comparison for dY = 41, dX = 21.
Actual results of both methods done by Arduino microprocessor and
plotted for four different dX,dY combinations.


One interesting note is that the second method is not always better than the first method.  The case where dX = 21 and dY = 41 results in 21 iterations with a leftover of 20 steps.  So if the original method is used, all but one iteration can be done with an extra step, resulting in the original method giving a better trace of the ideal path.  The code I wrote allows the program to chose the better method.

The code which implements the algorithm described above is shown below.

This is a simplified version of the actual code posted on GitHub, but is easier to understand.  The best way to understand the algorithm is to compare the color coding done in the pictures above with the comments written into the code.

Current code is available:
Processing Sketch
Arduino Sketch