Archive for the 'CNC' Category

The Polar Coaster – A Drink Coaster Drawing Machine

I designed this machine to draw custom, round drink coasters. I already have a laser cutter for square coasters and I wanted to try something unique for round coaster.

The Base

The base of the machine has two stacked 5mm bearings in the center for the bed to rotate on. There are (3) 3mm bearings on the bed perimeter that provide support and keep it level. They have little shafts that snap into the base.

The Bed

The bed is  a 156 tooth GT2 pulley. It has little springy fingers that grip the coaster when it is on the bed. The bed connects to the motor pulley with a closed loop belt.

The Radial Arm.

This is a belt driven, cantilevered arm that uses 6mm shafts and linear bearings. The belt is a cut pieces with the ends clamped at the carriage. It has a slotted mounting hole that lets the arm rotate. The pen must be adjustable to get to the exact center of the coaster or the drawing will be distorted. There is a limit switch on the top.  This is the only axis that needs to be homed. To setup the machine you home it and jog the pen until it is exactly over the center of the bed. You then set the work zero for X (Gcode: “G10 L20 P0 X0”). This only needs to be done once. If you use different types of pens, the center should be rechecked.

The Z Axis

The Z axis uses a micro servo and a cam to control the height of the pen. The firmware is setup to only have (2) Z positions, pen up and pen down. It uses 3mm rods and tiny little 3mm linear bearings.  There is a compression spring on one of the rods that applies a little pressure to the pen, and allows the pen to float a little on uneven coasters.

The Controller

I used my Grbl HAT controller. It is a bit overkill for this project but works perfectly.  It is attached to a Raspberry Pi in this photo, but I have not been using the Pi in this project yet. I just connect directly via USB.

Kinematics and Pre-Processin

See this blog post on how it was done. The pre-processor is written in C#, but it is rather simple and you could probably read the source file and convert if you cannot deal with C# on Windows.


I use a modified version of Grbl 1.1f.  Grbl does not support servos, so I needed to hack that in.  I used the PWM that is normally used for the spindle speed to control the servo. I turned off the variable speed spindle option and streamlined the spindle functions to the bare minimum I thought Grbl needed.  I adjusted the PWM parameters for use with a servo and added pen_up() and pen_down() functions. I tried to put as much of the custom code into one file spindle_control.c. I had to add a few lines in stepper.c to look at the current machine Z height and apply the correct pen up/down function.


You can use anything to generate the gcode that works with Grbl. The pen will go up when the Z is above zero and down when it is below zero. Therefore, you want the Z movement as short as possible to speed up the drawing and not have the pen dwell on the material and bleed.  I make the depth of cut 1mm and the z clearance 3mm.

CAD Files.

The design was done using PTC CREO 3.0.  A STEP version of the design is linked at the end of the post.


It does a great job. Here a recent coaster. This was done from a rasterized bitmap image found online (searched: circular Celtic braid).

Here is a Fat Tire beer themed coaster.

Coasters are made to be super absorbent, so larger tipped felt pens tend to bleed a little too much. I like to sketch with Micron pens and the thinner ones really work well on this machine.

Build You Own?

The build is not difficult, but covers a lot of areas. You should know how to work with STEP files and compile firmware.

The design is open source with no commercial restrictions, so feel free to use any part of my work. I found most of the parts on Amazon and eBay. I bought the belt from Stock Drive Products. The polar motor pulley is 36 tooth and the arm pulley is 20 tooth.  Cutting the shafts requires an abrasive cutoff wheel.

Please post any questions in the comments section and I will try to address them.







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)



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.




Coasty Update

Here is a quick update on Coasty. Several people have asked if I am releasing the source files or selling a kit. I am adjusting the design to make that more viable.  The original version was made with parts I had laying about and not necessarily the best design choices for an open source project.

X Axis.

Originally I used an TR8-8 ACME thread lead screw. It was mounted to the motor by drilling a hole in the lead screw and epoxying it to the motor shaft. This worked well, but you needed a lathe to drill the hole and a special low backlash nut. The axis was also a little loud with and all metal design.

I changed to use a GT2 open belt cut to length.  Belts and pulley are really easy to get and don’t cost too much.


Need to shorten some wires after testing.

There were some issues with the EleksMaker electronics that I did not like. The laser circuit did not appear to have a pull down on the signal and it tended to fire if the Arduino was not pulling it low. This would happen during reboot and other scary times. The wiring was also quite a pain. There were no connectors for the limit switches so you had to directly solder to the Arduino Nano.

I changed to use a custom PCB that is the entire rear panel. This contains all of the circuits including the limit switches. Building a Coasty was a little like building a ship in a bottle. Now the bottle has no bottom and there are less parts inside.

Front Door.

The front door now has a window. This makes the machine more fun to watch and no glasses are required.

Next Steps.

I have one build and am testing it for a while. If all goes well, I will release the source files and consider a kit.


PSoC 5 Daughter Card for XCC

I finished a PSoC 5 daughter card design for X-Controller-Controller project.  10 boards should arrive in about a week. This will clean up all the wiring from the breadboard testing I have been doing. My goal is to have a clean development platform for me and possibly others to work with.

The design has the following features.

  • Mounts CY8CKIT-059 dev board directly
  • Mates directly to the X-controller-Controller
  • Independent control of 4 axes.
  • Connector for X-Controller button panel
  • Connector for  X-Controller power supply PCB
  • Connector for a Serial LCD panel (Itead Studio Nextion style)
  • PSoC controlled stepper motor current.
  • PCoC controlled idle current.

Here is an image of the CYC8CKIT-059 development board.  The CPU is a PSoC 5LP.  The price is only about $10.  It comes with a built in programmer, debugger, and USB/UART. This can be snapped off.  To fit into the X-Controller, I snap off the programmer and mount it in another location.  The connections are made on the PCB.  I plan to use stackable headers so all of the pins are still easily accessible.


Please subscribe to me on YouTube or follow me on Twitter.


Step Pulse Extender – PSoC Style

The TB6600 stepper drivers I have in the X-Controller have a “Torque” feature.  You set the motor current with a reference voltage and the torque feature allows you to easily switch between that current and 1/3 third of it. This is typically used for an idle current reduction feature at the system level.


Why Idle Reduction?

Stepper motors have a lot of hold torque, but that torque quickly falls off with speed.   Therefore you typically size a stepper motor and set the current for your maximum cut or rapid speed.  This means your motors will have excess torque when idle and will tend to run hottest at idle.  You basically the the current as high as possible until the motors get too hot.  If you could reduce the current at idle, you would reduce the temperature and could set the current higher than normal when spinning.

This is great, but the machine will never be in idle during a long job.  At least one of the motors should always be running. If you could figure out when each individual motor was idle, you handle each motor independently.  That is not easy in firmware, but there are tricks to do it in hardware.  You could tie the feature to the step pulse.  Whenever the step pulse is active, the full torque could be active.  That has two problems. The step pulse is extremely short, in the range of a few microseconds.  The other is you might want the current high for a a short bit after the motor goes idle just to make sure the machine is stable in the new position.

The trick is to use the step pulse, but extend it to the desired duration.  It should stay on through all the step pulses and extend the last pulse.

Discrete Hardware Solution

The X-Controller uses a discrete logic chip to do this. It uses a retriggerable monostable vibrator (74HC123D).  The R/C circuit on the right of the schematic snippet sets the duration. It works great, but this adds a lot of parts and things are locked down and not easily adjustable. If you needed to override this function, you have to break out the soldering iron.

PSoC Solution

With PSoC, when you hear “discrete logic” you should know there is probably a good way to do it on the chip. In this case I designed a custom component using verilog.

The verilog code is quite simple.  The best part is none of this is done on the CPU, so there is no impact on the motion control performance. What the video to see the details.


X-Controller-Controller (X-Controller minus controller)


I am very happy with the X-Controller.  It packs everything you need to run Grbl into a clean little package.  It is super easy to hook up and move between machines. With that said, I had a quite a bit different idea in mind when I began the design.

The X-Controller was designed to be the motion controller for the X-Carve. The “X” in X-Carve was meant to signify that it was sold through a configurator and there were a lot of options. The X-controller was going to follow the same concept. It would support Grbl, Beaglebone Machinekit, Smoothy, and others. Additionally, alternate stepper driver PCBs might be developed.

To enable the configurability, the stepper driver section would be separated from the controller section. Every feature the stepper drivers supported would be available to the controller. The plug in controller PCB would control the features via firmware or jumpers and pots, depending on the power of the controller. The current X-controller has 4 stepper drivers, but (2) are wired together. In the split concept the controller card would decide how that was done.

At the time Easel was starting to get some real traction and Easel only supports the Grbl protocol. We decided that it was best to pick the easiest solution for our customers and make the X-Controller Grbl only.

My experiments in Beaglebone and PSoC have been such tangled messes of wires. I always wished I had that disconnected stepper PCB. I finally decided to make one.


The XCC Stepper Driver PCB uses the same Toshiba TB6600 drivers as the X-Controller. It fits in the X-controller just like a stock PCB, but it is quite a bit shorter.  The interface side of the PCB has (1) 2×5 right angle header connector for each axis. Brought out the the connector are…

  • Step
  • Direction
  • Torque  (high=full current, low=1/3 current)
  • Enable
  • Micro-stepping selection
  • VRef (sets the motor current)
  • Ground and VMot



For this version, I put a current selection pot and micro step selection jumpers for each axis to simply testing.  These function should be on the controller board, so most of these will be built without those installed.   The PCB also needs 12VDC to 40VDC power for the motors.  Each driver has a small 5VDC supply built in, so an external source is not needed.


Here is a snapshot of the schematic.  This is just 1 of the 4 identical sections.



Here is snapshot of the layout. I was able to get everything on 2 layers.



It fits into the X-Controller great.  I used a small piece of black acrylic to fit the gap due to the shorter length.  It is working perfectly.  I have been testing it with my PSoC port manually wired in.  A PSoC5 controller will probably be the first controller card I will have made.






Yet Another Way to do the Kinematics


Paul Kaplan, originator of the Easel project, came up with another way to do the kinematics for the Line-us Clone. My method used intersecting circles. His method uses the Law of Cosines.

The Law of Cosines relates the lengths of the sides of a triangle to the cosine of one of its angles.




This can be used to find the angles of the servo arms.

(Click on the images if you want a larger view)

The Goal


The goal is to find the two angles, A1 and A2, of the servo arms

Known Values

  • Px is the desired X location of the pen
  • Py is the desired Y location of the pen
  • L1 is the length of the upper servo arm (50mm)
  • L2 is the length of the end of the Pen Arm (50mm)

Step 1

Find the distance “D” of the pen to hub using the Pythagorean Theroem and the angle T1 using arctangent.

Px2 + Py2 = D2

rewritten … D = Sqrt(Px2 + Py2)



T1 can be found using the arctangent or inverse tangent formula. Note: When programming use the atan2(x,y) function to preserve the quadtrant.

T1 = atan2(Py,Px)

Step 2



Find T2 using the Law of Cosines

L12 + D2 – L22 = 2 * L1 * D *cos(T2)

rewritten …  T2 = acos( (L12 + D2 – L22) / (2 * L1 * D))

Step 3



Find T3 using the Law of Cosines. We want the left one of the two T3 angles, but since the linkages form a parallelogram that same angle shows occurs in several places.  We will use the right one and the dimensions associated with it.

L12 + L22 – D2 = 2 * L1 * L3 * cos(T3)

rewritten … T3 = acos( (L12 + L22 – D2) / (2 * L1 * L2))

Step 4



Determine A1 and A2 from the angles we figured out.

A1 = T1 + T2

A2 = A1 + T3


I think I will switch the code to use this method. I think I can optimize it better in C code. The speed of the code is important.  The faster it runs, the most times per second we can run it.  The more often we run it, the smoother it will run.


PSoC 5 Port Of the Grbl 1.1 CNC Controller

Image from Cypress

Image from Cypress


Grbl Logo 250px


Grbl is a high performance CNC controller.  It is used on a lot of small scale CNC machines and is the motion control code behind a lot of 3D printers.  It was originally targeted at the Arduino 328p hardware (UNO). It is developed  by Sungeun “Sonny” Jeon. He is a good friend.  He is always very helpful and this port would not have been possible without the quality of his code and his advice.

PSoC Mixed Signal Controller

I love working with the PSoC (Programmable System on Chip) family of micro controllers.  You can configure them on the fly with many analog and digital components.  The analog components are not basic ADCs and DACs, you have OpAmps, PGAs,  filters, MUXs and more.  The digital blocks includes basic logic gates, all the way up to FPGA like components you program yourself in Verilog..  There are over 200 ready to use components you can wire together on the chip.

I have always used them for small prototype projects, but wanted to test my skills by porting a major project like Grbl.  At the same time I wanted to take advantage of the features of the PSoC. The dev board I used was the CY8CKIT-059.  This has ARM Cortex M3 processor a lot of I/O and costs less than $10! It has a built in programmer and debugger.


PSoC Advantages

Here is a comparison between the the ATMega 328p (Arduino UNO) and the PSOC5

PSoc 5

ATMega328p (UNO)


32 bit

(ARM Cortex M3)

8 bit


Up to 80MHz

16MHz Typ.

Flash (program size)










up to 62



Grbl’s flexibility allows you to tailor it to your hardware.  With a few limitations, you can move the pins around and change things like whether switches are active low or high.  This is all done using #define values in configuration files.  That is great, but the code gets a little messy every time you access hardware. It has to do a little logic gymnastics each time.

With PSoC you can do all of that in a visual schematic and pin wiring feature.  Here is a PDF of my schematic.  Have you ever swapped transmit and receive on a UART? In PSoC you can just swap the pins on the schematic.

Here is an example of the difference in firmware code.

Grbl on 328p

uint8_t limits_get_state()
 uint8_t limit_state = 0;
 uint8_t pin = (LIMIT_PIN & LIMIT_MASK);

 if (bit_isfalse(settings.flags,BITFLAG_INVERT_LIMIT_PINS)) { pin ^= LIMIT_MASK; }

 if (pin) {  
   uint8_t idx;
   for (idx=0; idx<N_AXIS; idx++) {
     if (pin & get_limit_pin_mask(idx)) { limit_state |= (1 << idx); }

Grbl on PSoC

uint8_t limits_get_state(){  
 return Status_Limit_Read();


Special Hardware Usage

I used some special features to move functions out of code and onto the hardware.  One of them was the step pulse.  Stepper drivers typically require a pulse of a minimum length to take a step.  In normal hardware you have to raise the pin, then figure out a way to turn it off after a given period of time.  This is typically done via an interrupt.  It works fine, but the code is messy and interrupts can cause timing issues.  PSoC  control registers have a pulse feature that automates this. You attach a clock and the clock determines the length of the pulse.  The code sets it and the hardware clears it.  It looks like this on the schematic.



Another feature I used was hardware switch debouncing.  This can be done completely in hardware.  See the image below.  The clock sets the debounce time.  The debouncers are all fed into a status register where they are read  as a single value.  There are digital “nots” after the debouncers because my switches close to ground.  The firmware could invert the logic, but it is so much easier to read on the schematic. It then feeds an interrupt.



If you would rather do this with an analog filter, you can design custom filters in the hardware.  You could fine tune the filter right from your keyboard.



PSoC has a built in character LCD Component that makes using and LCD  very easy.  The code for the LCD is in the main loop and not an interrupt.  This allows the time critical  stuff to have higher priority.  I used an interrupt to just set a flag so the LCD does not update every time through the main loop.  I found the LCD to be an awesome debugging tool.  I could display stuff while the code is running.



I also used a hardware Quadrature Decoder for the LCD rotary knob. This works great to monitor the encoder in hardware.  I just need to read the value in the LCD update routine.  The clock feature on the QuadDec is a debouncer, which helped debounce my mechanical encoder.


Next Steps

I have been testing for a while and so far it is working great. I also have some plans to use the extra power on some cool projects.

Here is the code on GitHub

Here is a picture of my test setup.