Polar Pen Machine Kinematics
When you have a round work piece like a drink coaster, it makes sense to have a round work area. A round work area works best with a polar coordinate system. A polar coordinate system uses an angle and a distance from a center point to define a point in 2D.
The problem is that most drawing and CAM programs work in Cartesian (X,Y,Z) coordinate systems. My machine controller firmware, Grbl, also works in normal linear X,Y, and Z. The process of converting one system to another uses Kinematics.
The Firmware
The firmware is side is actually quite easy. I defined the X axis as the distance in mm from the center (the radius). The Y axis will control the angle. The Y axis is setup so that millimeters will equal degrees. If I tell the Y to move 360mm, it will actually rotate the work area by 360°. I could have used radians, but my brain works a lot slower in radians.
The machine will only need to home on the X axis. It needs to know where the exact center of the work area is. The starting angle does not matter because the coaster is a circle.
The conversion from X, Y to polar is probably won’t fit in into the firmware, so the X, Y conversion is done in a preprocessor software program. The X,Y gcode is output from normal CAM programs, then run through a conversion program.
The Conversion Program
The program reads the X,Y gcode, converts any X or Y coordinates into polar coordinates and outputs a new gcode file. The sender simply sends the new files. The math is actually quite simple.
Typical Gcode sends line data by giving the end points of lines. You simply draw from one point to the next, unfortunately this creates a few problems with a non linear machine.
The basic non-linearity problem
If we were trying to draw the green square centered on the work area, the generated gcode would basically send the corner points. Each corner point has an equal radius to the center. Therefore, the pen will never change radius when going to the next point. This will result in a circle. We want the green square, but we get the red circle.
We need to calculate each point along the way to stay on the desired path. The preprocessor divides the line into tiny segments. Each segment has the same problem, but at a scale you won’t be able to see.
The Spiral Problem
If we are drawing a shape that crosses the 0° angle we don’t want the angle to spin the wrong way. If a point is at 350° and the next point is 10° (crosses over 0) we don’t want it to spin backwards from 350° to 10°. We want it to go to 370°. It happens anywhere the angle difference between 2 points is greater than 180°. The program will choose the shortest direction even if that means going above 360° or below 0° degrees.
The Feed Rate Problem
Feed rate, in CNC terms, is the speed of the tool across the material. The CAM software is setting the feed rate as if this were a Cartesian machine. On this machine, if you were drawing a circle, you would simply move 360 units in Y. Without compensating feed rate, the pen would move across the work piece faster for larger diameter circles. I want to do some sort of compensation to help with this. The coasters are very absorbent, so the lines look thicker if the speed is slower. A consistent speed will help the quality of the work.
Since the lines are all very short, the easiest way to compensate for feed rate is to use the current radius. With a simple circle, Grbl thinks the machine moved 360mm. The real distance is easy to to calculate from the perimeter of that circle.
We can compare it to the 360mm (full circle) and apply the ratio to the desired feed rate from the CAM program.
polarFeedrate = cartesianFeedrate * 360 / (2 * pi * radius)
Video
Here is a video of it. The machine is rerunning a file to see the repeatability.
Next Steps.
I would like to automate the preprocessor. I think a Raspberry pi, might be an easy way to do this. It would sit between the sender and the controller.