Archive for the 'Software' Category

ESP32: Step Pulse Experiments with Timers

(Edit: Also check out my better “RMT” way to send the pulse)

I have been playing with the ESP32 microcontroller to see how well it would perform as a small scale CNC controller. The low cost and high performance as well as the built in Wifi and Bluetooth make it very attractive.

One of the challenges is step pulse timing. Most stepper drivers work with a direction signal and step signal. The step signals are a short pulse for each step. If they are too short, the driver will not detect them. If they are too long, it limits the rate at which you can send them.

You first set the direction signal high or low depending on the direction you want the motors to spin. You then send the step pulse. The direction signal has to be stable for a short period of time before the step signal is sent. The process is…

  1. Set direction
  2. Wait a bit (if it changed)
  3. Turn on the step pulse signal.
  4. Wait a bit
  5. Turn off the step pulse signal.

The timing is critical and varies by motor driver. Here is a typical spec.

Here are the specs for a few of the stepper drivers I regularly use.

 Allegro A4988TI DRV8825Toshiba TB6600
Direction Delay200ns650ns?
Step Pulse Delay1us1.9us2.2us

Test Firmware

Typically the firmware motion planner determines when to take a step, then sets an interrupt to occur at that time in the future. This allows the firmware to do other things like interacting with the user and planning future moves while it is waiting for the interrupt.

To simulate a stream of pulses, I created a timer interrupt that would case steps to occur at a constant 5kHz rate. That is onStepperDriverTimer() in the code.

In that interrupt service routine I first set the direction pin. Normally you only need to set it when the direction changes, but it will be easier to see this on a logic analyzer if I change it every time for this test. I then need to wait a little time before setting the step pulse pin. I could use another interrupt to do this, but the time is so short at about 750ns, that it is better to just waste a few cycles. In the CNC software I will only need to do this when the direction changes. That will be at the few beginning of the acceleration when the step rate is the slowest. I do this delay with a few NOP()s. The are “no operations”.

I then setup the the interrupt to end the pulse. That is onStepPulseOffTimer() in the code. I set the step pin after this because those instructions take clock cycles too. I can use those as part of my delay.

When that interrupt occurs, I turn off the step pulse signal. I also turn off the direction in this example. I am only doing it here so I can see that change on the logic analyzer. Normal CNC frmware would just leave it alone because there are typically thousands of steps before the direction is likely to change.

I wrote a program to simulate some CNC firmware so I could play with step pulse timing.

// create the hardware timers */
hw_timer_t * stepperDriverTimer = NULL;  // The main stepper driver timer
hw_timer_t * stepPulseOffTimer = NULL;  // This turns the step pulse off after xx uSeconds

// define the gpio pins
#define STEP_PIN 17
#define DIR_PIN 16

// the step pulse interrupt service routine. 
void IRAM_ATTR onStepperDriverTimer()
  // if ... the direction changed from last time (not in this demo)
  digitalWrite(DIR_PIN, HIGH);  // in actual CNC firmware this will go high or low
  for(uint8_t i=0; i<10; i++)
    NOP();  // do nothing for one cycle
  // end if

  // setup the pulse off timer
  timerWrite(stepPulseOffTimer, 0);
  timerAlarmWrite(stepPulseOffTimer, 22, false);  // the alarm point is found by looking at logic analyzer
  digitalWrite(STEP_PIN, HIGH); // put it after the timer setup to include the timeto do that

void IRAM_ATTR onStepPulseOffTimer()
  digitalWrite(STEP_PIN, LOW); // end step pulse 
  digitalWrite(DIR_PIN, LOW); // only here for dem program CNC firmware would leave this until direction change

void setup() {  

 pinMode(DIR_PIN, OUTPUT);

 stepperDriverTimer = timerBegin(0, 4, true); // 80Mhz / 4  = 20Mhz// setup stepper timer interrupt ... this will simulate a flow of steps
 stepPulseOffTimer = timerBegin(1, 1, true); // 

 // attach the interrupts
 timerAttachInterrupt(stepperDriverTimer, &onStepperDriverTimer, true);// attach the interrupttimerAttachInterrupt(directionDelayTimer, &onDirectionDelayTimer, true);// attach the interrupt
 timerAttachInterrupt(stepPulseOffTimer, &onStepPulseOffTimer, true);// attach the interrupt
// setup the time for the 
 timerAlarmWrite(stepperDriverTimer, 4000, true);  // 20Mhz / 4000 = 5kHz rate ... this is the only one that auto repeats  

void loop() {
  // no loop code required.:


Here is a picture of my setup.

This is screen shot of what the logic analyzer captured. The upper line is the step signal and the lower line is the direction signal. The direction signal comes on first and then the step pulse signal comes on 0.75us later. The step pulse then lasts for about 2.5us before turning off.

Next Steps

  • I’ll go forward this method to see how well it works in actual CNC firmware.
  • I have been programming in the Arduino-ESP32 environment. This is an easy way to learn about the peripherals and do some quick tests. I may switch to the ESP-IDF  in the future.
  • I would like to investigate the RMT features of the ESP32. It is designed for Remote Controls, but I have heard it is quite flexible and might help with pulse generation.


If you want to be notified of future blog posts, please subscribe.

Using the HC-05 Bluetooth Module

In a previous post I showed how to use the HC-06 Bluetooth module. In this post we will be using the HC-05. They are very similar, but the HC-05 has more features. The ability to be a master is the main feature. A master can create a connection with other Bluetooth devices. In this post we will only being using it as a slave.

The basic module looks like this.

It is typically purchased soldered to carrier PCB with some additional electronics. The HC-05 typically has a 6 pin header, rather than the 4 pin HC-06 header. The two extra pins are state and enable (en). State gives the state of the Bluetooth connection and enable can power down the module by turning off the power regulator. I will not be using the enable. I will use the state to allow programming of the Arduino via Bluetooth.


Here is a schematic of the carrier board. Not all carrier boards are the same, though.

The parts on the carrier PCB are pretty basic

  • 3.3V Low Dropout Regulator, which allows you to power it from 3.6V to 6V.
  • An LED to show the mode.
    • Fast Blink = Waiting for Bluetooth connection3.6
    • Slow Blink = In AT command mode
    • Double Blink = Connected via Bluetooth
  • A button to enter AT Command Mode
  • A diode, probably for reverse voltage protection.
  • Various Pull Up/Down resistors and bypass capacitors.

Configuring the HC-05

Like the HC-06, the HC-05 has a AT command mode, but the commands are a little different. The HC-05 is put in the AT command mode by holding in the switch while applying power. It will do a slow blink when in AT mode. AT Mode accepts commands at 38400 baud , N,8,1 using the Rx and Tx pins. You should level shift the Tx out of your Arduino to 3.3V using a resistor divider. Commands are sent with line feed and carriage return appended to the end. Most serial monitors can do this for you including the Arduino Serial Monitor.

Any command that sets a parameter can also get it.

  • Set commands are in this format “AT+CMD=PARAM” like … AT+NAME=FRED to set the name to FRED. Some commands have multiple parameters that are separated by commas.
  • Get commands are in this format AT+CMD?” like AT+PSWD? to get the password. Weirdly, they all seem to work except AT+NAME?.

Here are the commands you needs for slave mode. Remember, each is followed by a line feed and carriage return.

  • AT (This is just a way to test the connection. It will respond “OK”)
  • AT+VERSION? (This returns firmware version info)
  • AT+ROLE=x (for x use 0 =Slave role, 1 = Master role, 2 = Slave-Loop role default = 0)
  • AT+NAME=xxxxx (to change name to xxxxx default=HC-05″)
  • AT+PSWD=nnnn (to change password to 4 digit nnnn default = 1234″)
  • AT+UART=nnnn,s,p (nnnn=Baud, s=stop bits (0=1, 1=2), p=parity (0=None, 1=Odd, 2=Even) Example AT+UART=115200,0,0
  • AT+POLAR=a,b (a=PIO8 (LED), b=PIO9 for both 0=low turn on, 1 = high turn on. (see below for how we use this)
  • AT+ORGL (reset all parameters to defaults)
  • AT+RESET (restarts the HC-05. Will not be in AT mode afterward unless button held”)

Using an Arduino to program the HC-05

We need some hardware to talk to the HC-05. An Arduino will easily do that. Here is a diagram and sketch to do this using an Arduino UNO.

This is the hardware diagram. I show an UNO, but virtually any hardware (Nano, Mega, etc) will work. The HC-05 is a 3.3V device so we need to level shift the Arduino 5V Tx signal down to 3.3V.  The diagram uses a resistor divider to do this. The Arduino should have no trouble reading the 3.3V Tx signal from the HC-05, so we don’t need to shift that.

The State connection through the capacitor is optional. This will force a reboot of the Arduino when a Bluetooth connection is made. More on that later.

BTW: A lot of people don’t bother to level shift and it appears to work fine, at least in the short term 🙂

The Arduino Sketch

Here is the sketch I use. We will be setting up 2 serial links. One link will be from the PC to the Arduino to send the commands from the keyboard over USB.  We also need a serial connection from the Arduino the HC-05. We will use a software serial port for this and can use any remaining pins to do this. HC-05 uses 38400 baud for AT commands, regardless of the what you set it to for Bluetooth operation.  I used 115200 for the PC to Arduino connection. Set the Serial monitor like this.

You can then type AT commands in the Sereial Monitor.

Here is the sketch…

#include <SoftwareSerial.h>

#define SOFT_RX 11
#define SOFT_TX 12

SoftwareSerial hcSerial(SOFT_RX, SOFT_TX); // RX, TX

String fromPC = "";

void setup() { 
  Serial.begin(115200); // hardware serial for the USB-PC
  hcSerial.begin(38400);  // software serial Arduino to HC-06 (38400 is default)

  // print instructions
  Serial.println("HC-05 AT Command Programmer V1.2");

  Serial.print("For Arduino Rx use pin ");
  Serial.print("For Arduino Tx use pin ");
  Serial.println(" -- Command Reference ---");
  Serial.println("To Read use '?', Like AT+PSWD?");
  Serial.println("AT (simply checks connection)");
  Serial.println("AT+VERSION (requests the firmware verison)");
  Serial.println("AT+ROLE=x (0 =Slave role, 1 =  Master role, 2 = Slave-Loop role  default = 0)");
  Serial.println("AT+NAME=xxxxx (to change name to xxxxx default=HC-05");
  Serial.println("AT+PSWD=nnnn (to change password to 4 digit nnnn default = 1234");
  Serial.println("AT+UART=nnnn,s,p (nnnn=Baud, s=stop bits (0=1, 1=2), p=parity (0=None, 1=Odd, 2=Even)");
  Serial.println("AT+POLAR=a,b (a=PIO8 (LED), b=PIO9 for both 0=low turn on, 1 = high turn on.");  
  Serial.println("AT+ORGL (reset all parameters to defaults)");
  Serial.println("AT+RESET (restarts the HC-05. Will not be in AT mode afterward unless button held");

void loop() {
  // Read from HC-05
  if (hcSerial.available()) {
    while(hcSerial.available()) { // While there is more to be read, keep reading.
      Serial.print((char); // send it to the PC
  // Read from PC
  if (Serial.available()){
    delay(10); //     
    fromPC = (char);    
      hcSerial.print(fromPC); // show the HC-05 responce
      Serial.print(fromPC); // echo it back to the PC

Arduino Programming over Bluetooth.

Arduinos are programmed over serial via a bootloader. A bootloader is program that runs for a few seconds whenever the Arduino is started. It looks for someone trying to program it. It runs in one part of the Arduino’s memory. If it does not detect an attempt to program the Arduino it switches to the part of memory where the last program (sketch) resides. If it does detect an attempt to program the Arduino, it reads the incoming program instructions over the serial port and writes them to that other part of memory where normal programs (sketches) reside. Once the upload is complete it switches to that program and runs it.

Therefore, in order to program the Arduino over a serial connection, you need to trigger a reboot. The Arduino USB creates a full RS232 connection. In addition to Rx and Tx is has other control lines like DTR (Data Terminal Ready). The Arduino uses the DTR signal to force a reset. To reset an Arduino you pull the reset line to ground. The DTR signal out of the USB chip is high when there is no connection and low (ground) when there is a connection.

If we directly connect DTR to the reset pin, the Arduino will be stuck in permanent reset mode whenever a serial connection is open. To correct that, a capacitor is inserted in the circuit. Capacitors block a continuous signal, but pass a quick transition. Therefore the the change from high to low will look like a quick pulse to ground at the reset pin. That pulse is exactly what is needed to reboot run the bootloader.

Here is what that circuit looks likes on an Arduino Nano schematic. The length of the pulse depend on the value of the capacitor and characteristics of the high to low transition.

The HC-05 state pin will work for this. In its normal mode it is high during a connection. We need that to be low (ground). Fortunately the HC-05 has the Polar command. That allows you to flip that logic. AT+POLAR=1,0 will do the trick. The first parameter is for the LED. We leave that at 1. The second parameter is the state and we switch that from the default of 1 to 0.

I found that the typical 0.1uF capacitor would not generate an adequate pulse to ground, so I bumped it up to 1.0uF. It occasionally does not work when uploading. I think a little less capacitance might be better. The Arduino uses the hardware serial connections for programming, so you use those pins. When programming the Arduino use the virtual serial port you got when pairing the Bluetooth. Do not use Bluetooth and the USB serial port at the same time. Both would be connected to the hardware Rx and Tx and conflict with each other and possibly cause damage.


Other Reset Features

You may not care about uploading code over Bluetooth, but some of your applications may expect that reboot on connect behavior. I have found this with some GCode senders. They open the serial port and expect to see the text Grbl spits out at startup. Without seeing this text, the program wrongly assumes there is a problem and closes the connection.


Useful Links


If you want to be notified of future blog posts, please subscribe.

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.




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.


Hobby/RC Servo Control in PSoC



The PSoC family is my go to line of processors for prototyping.  It is like having a breadboard full of digital and analog circuits that you can wire up on the fly. I have been doing some stuff with hobby servos lately so I needed to figure out how to do it on the PSoC.

Hobby Servos


From Wikipedia


Image from Adafruit


Hobby servos set their rotation based on the length or a repeating pulse. The pulse should be 1ms to 2ms long and repeat every 20ms.  One end of the rotation is at 1ms and the other is at 2ms.

The PSoC PWM  Component


The PWM component is perfect for this job.  The PWM component can be setup to have a period and an on time.  The period should be 20ms and the on time would be between 1ms and 2ms.  The component uses a clock and two counter values.  The component will count on every clock pulse.  It resets the counters after the period count has been reached and the CMP value determines how long the pulse is logic high.

The PWM output goes to the servo control line.  Here is the configuration dialog box for the PWM component. The graph at the top is a good reference for what the output will look like.


The goal is to have a pretty decent resolution to set the 1ms to 2ms pulse.  I chose a 2MHz clock.  I picked the fastest clock that would still fit within the 16bit (65535) limit of the control.  PSoC clocks are derived from system clocks, so you need to pick values easily divided down from them.  The IDE helps with creation of these clocks.  At 2Mhz the period (repeat rate) should be set to 40,000.  The equation is the clock * period(in second) = period counts (2,000,000 counts/sec * 0.02 secs = 40,000 counts).

The CMP Value is how many counts the high pulse should last.  The equation is the same. For 1ms the count would be (2,000,000 cnts/sec * 0.001secs =  2,000 counts) and for 2ms the counts would be 4,000.  The range is 2,000 to 4,000 (2,000 count resolution).  This is better than most hobby servos can do.

The Code

The IDE will generate a bunch of functions, a custom API, for each component used when the application is built. There are two PWM Component functions we need to use for this application .

  • PWM_Servo_Start() This will initialize the component and get it running. This is called once at the beginning of the program.
  • PWM_Servo_WriteCompare(val) This sets the CMP Value that will be used to set the pulse length.

I also wrote a function the can set the value by degrees.

void setServo(float degrees)
unsigned int val;
// convert degrees to compare value
// 2000 to 4000 = 0 to 180
// value is
val = (degrees / 180.0 * 2000.0) + 2000;


The Results

Here is a screen shot of my logic analyzer. The output was set for 1/2 rotation. The pulse is 1.51ms and the period is 20.14ms.  That is close enough for me.  It is likely the clock speed is different between the PSoC and  and the analyzer.



Typically you will have to tune the to the actual servos used.  Just tweak the endpoint values until you get the rotation you want.

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.


The Delta Router + 4th Axis



Every year I make a new thing for ORD Camp.  This year I made a delta router.  The ORD contraptions I make, have one primary function; to spark conversation.  This means they have to be interesting, a little whimsical and a little cool looking.  They are generally rather small for portability and to keep the costs down. Practicality and suitability are way down the list, so go ahead and snark away.  If you do, you are missing the point.

This year there happened to be a session on creativity with constraints.  The question we debated for an hour was, do constraints help or hurt the creative process. Constraints can move you out of your comfort zone and maybe that is a big part of creativity.  The topic was perfect for me because I had intentionally challenged myself with a few constraints on this project.

  • Use non captive stepper motors. Not a lot of people have seen these in use, they are cool to watch and they simplify the design.
  • Limit myself to 3 unique fabicated parts.  People keep thinking deltas are more complicated than .  This was to demonstrate the simplicity.  Go ahead, design a Cartesian machine with only 3 unique fabricated parts.  All other parts had to be commonly available parts.
  • Use stock reprap software.  I could only touch the configuration files.


I met all the constraints except for one.  I designed a common top and bottom bulkhead, but at machining time I decided it was silly to to spend the time to add holes only used on the top to the bottom and the same with the top.  So the four unique fabricated parts are the top, the bottom, the carriages and the end effector.  The top and bottom are 3/4 inch Baltic birch.  The other fabricated parts are 3mm carbon fiber.  All parts were setup and cut in less than 30 minutes on my homemade CNC router.  A 3D STEP of my design is here.


The vertical rails are MakerSlide.  I used steel V wheels because I had them laying around.  The rest of the mechanical parts are Actobotics parts from Servo City.  I thought they were an awesome discovery and then the next day I saw that Sparkfun started to sell them.  They really worked out great.  My only complaint is that they are imperial thread based parts.  I prefer all metric on my designs.

The non captive stepper motors are really cool.  The thread is a 2 start 8mm trapoidal, so it moves 4mm per rev.  They are quite fast and strong.  I custom ordered them at Robot Digg.  The only drawback is you cannot move them by hand.  You can’t spin the rod or the motor.  In this design they are a little vulnerable too.  If they get banged hard they could bend.

The linkages are Acrobotics heavy duty ball ends attached to some standoffs I got at McMaster.


I used some mini arcade style switches for the limit switches.  They are pretty nice snap acting switches, but probably a little less accurate than microswitches.  I chose them because they would be super simple to mount without adding mounting brackets.


The controller is my favorite reprap controller; the Azteeg X3.



The spindle is a brushless DC hobby motor.  It is a Turnigy Trackstar.  The speed controller is a Turnigy Plush 30.  The shaft is 1/8″.  I used a simple shaft coupler to mount the bit.  This added a lot of vibration so the motor could not run at full speed, but that was OK becuase the full speed is close to 30,000 RPM and 550Watts!.  I eventually manually balanced the coupler and it runs a lot smoother now.  I did it by drilling through the existing set screw holes to the other side with a small bit.  I enlarged that hole until it was balanced.





4th Axis


Later when I got home, I thought it would be cool to add a rotary axis to it.  The challenge was going to be using the extruder motor logic for the rotary axis.  I had this attachment laying around that was bought from eBay a few months ago.  A typical 4 axis machine simply disables one of the axes while using the rotary.  That is not possible with a delta, so all 4 axes need to run at the same time.  It is quite fun to watch.



It was perfect because it was so small.  It has a 6:1 reduction gear inside.  I made a simple base for it that would allow it to be quickly mounted to the router.



Firmware Changes.

The firmware changes to Repetier were pretty simple.  Extruders use millimeters as the feed unit, so I just converted that to degrees.  The motor is 200 steps/rev with 16x microstepping plus 6: 1 gear reduction.  This yielded 53.333 steps per degree.   I changed the safe extruding temperature to a very low value and then just wired a 100k resistor across the thermistor pins so it read a constant value above the safe temperature.

 CAM Software

I don’t have any high end CAM software that does anything really cool on a rotary.  I did have an evaluation copy of DeskProto, but that timed out.  I did have Vectric V Carve that does have a wrapped rotary feature.  That would be good enough to do my Hello World project.  I had to write a post processor for it.  I basically hacked the Mach3 wrapped rotary post processor.  I had to make it really simple and tell it convert “A” moves to “E” moves.  There were a couple other changes too. The post processor is here.


Changes and Issues

  • I really need a tail stock to support the stock and help set up the job level.


  • The feed rate on rotary axes are tricky because millimeters per minute is quite different than degrees per minute and there is no way to deal with that in GCode.  The actual feed rate through the material depends on the radius (Z).  Programs like Mach3 can compensate for it.   I could really hack the firmware or maybe write a post post processor to compensate the speed based on the Z.
  • I need to get some real software to some interesting carving with this thing.


First Job Video

Go Deltas!





Camera Slider Controller Hack


I have been having fun with my camera slider controller.  It is a cool, little, general purpose motion and camera controller that will soon to go on sale at Inventables. Taking a picture is very easy.  You just plug the camera into it and run the takePicture() function.  It has a lot of spare I/O pins that can be used for some cool hacks.

I always thought it would be cool to take a time lapse movie of a 3D print, but do it exactly one layer per frame and have the picture be taken at the exact same location every time so the print appears to grow out of thin air.  I know people have done this before, and I could probably hack the circuit right onto the printer controller, but camera slider controller was ready to go with the circuit and connectors all ready to go.  With less than ten minutes of coding and making a cable, I was ready to go.

GCode Hacking

The first task was hacking the GCode to output a a signal I could read remotely.  Kisslicer has a feature where you can add a few lines of Gcode every “N” layers.  I added the following GCode.  Note the “1” in the layers box.  This means do it every layer.




G1 X0 Y0 means move to 0,0

G4 P500 means dwell for 500 milliseconds.  This was added because the next command was happening before the move completed.  I think this has to do with the way commands are buffered.  I think there is a more elegant fix for this, but adding a little delay here was a quick fix.

M42 P11 S255 means set I/O pin 11 to full on (255  is max).  Pin 11 is the first of the “servo” pins on my RAMPS controller.  This three pin connector would map directly to the servo connector on the camera controller.

G4 P1000 is a 1 second delay.  I had my DSLR on “auto” so it would need to focus for each shot, so I gave a little extra time.

M42 P11 S0 turns pin 11 off.

I ran a few test layers with my volt meter hooked up to the connector and it looked great.

Camera Slider Controller Hacking

The controller has 2 servo connectors that are intended to be used for hobby servos in a pan and tilt arrangement.  The signal pin on the connector can also be used as and input.  The code is simply going to watch for that pin to go high.  When it does it will display the next layer number and take the picture


Arduino Code

In the setup() section you need to make the PIN_SERVO_1 pin an input because that is connected to the printer controller.

pinMode(PIN_SERVO_1, INPUT);

The loop() section looks for the PIN_SERVO_1 pin to go high. When it does the layer number is incrememented the picture is taken and the LCD is updated. The camSignalRead flag is set so we don’t go read the same pulse more than once. The flag is cleared as soon as the signal

void loop() {

   if (digitalRead(PIN_SERVO_1) == HIGH) {
     if (!camSignalRead) { // make sure we read once per pulse
       camSignalRead = true; // 

       lcd.cursorTo(2, 0);
       sprintf(sVal, "Layer %d", layerNumber);


   else {
     camSignalRead = false; //reset this. the pulse is over 



Simply connect the signal pin (D11) on the servo 1 connector of the printer controller to the signal pin on the servo 1 (J7) connector of the camera slider controller. You also need to connect together a ground pin on each controller.






Camera Setup

I setup my DSLR on fully automatic and disabled the flash. I am sure the movie would have been better if I manually focused and locked the speed and aperture settings, but I just wanted a quick result. The controller first sends a focus signal and then a shutter signal. The focus signal acts like the half button push you do to focus most cameras.

The Print

The printing was done on the Quantum Delta printer.  I used my CNC Ninja Squirrel as the test print. It was scaled to 50mm tall. At at 0.25mm layer height, that gave 200 layers. The print took about 45 minutes with the added delays. It was run in a busy room at Pumping Station One so there was a lot of activity in the background and some light level changes.



The Result

Click here if the video is not displayed below.