Friday, January 1, 2016

Focus tuning.

Happy 2016!

Here are the latest changes I’ve made, and their results.

First, when using Eagle and PCBGCODE, I noticed that the script was drawing too many traces around the tracks to isolate them. They can be seen in the picture below:


The isolation lines seemed to be a bit too messy, so I decided to try to make this better and changed some of PCBGCODE parameters. The first one I changed was the Etching Tool Size.


I noticed that this parameter must be smaller than the smallest track separation of your board, or PCBGCODE does not generate the traces, like this:


So I have set it to 0.1mm and tried again, getting my isolation traces back. But I was still getting too many traces around the tracks, which were making the etching messy:



After a few tries, I noticed that if I set the Board Isolation Maximum to zero, I get only one line around each object of the board. This is the parameter I changed:


But after many other attempts the best I could get was a line around each isolation track AND a line around each part of the GND polygon made to connect the circuit GNDs.


I tried, but I could not eliminate the lines around the GND polygons, so I decided to eliminate the GND polygon on my board and connect the grounds using tracks.


And, after running PCBGCODE again, with the new parameters, I got this result on OpenSCAM:


Which is what I was looking for since the beginning. And the pattern generated by the laser was much better:



But I was still having problems with the laser focus. Moving the focus to the Z axis opened up many possibilities for me, showing that the focal depth of the lenses that were shipped with the laser is very deep.

I used to search the laser focus by qualitatively measuring the amount of light that was generated when the laser evaporated the ink, but this method was not reproducible. So I wrote a function on YetAnotherGCodeSender to plot a focus scale, with one trace in each Z depth. Some of the results, follow below.


Under a USB microscope I could see that only two of the traces had almost all the ink removed. The others around had considerable amount of ink left inside the channels. After selecting the a good Z position I got the following results on the PCB:




Now it may be time to tune the ShapeOko2 screws and try to improve its mechanical positioning.

Thanks for reading! Ah, and please leave comments if you believe you can help or have questions.




Tuesday, December 29, 2015

First etching attempts.


I’ve started to work on the chemical etching process to remove the copper from the laser etched paint PCBs. I’ve used the etchant solution described here:

And here are my first results. Macroscopically they look good:



But when I increase the magnification the quality is not enough:


So, there are lots of improvements to work on yet. The etching time may have been too much, the cleaning of the board may not have been so good, or the choice of paint may have been a bad one.


Please send me some feedback. I’d appreciate a lot!

Thanks for reading!

Saturday, December 26, 2015

CNC at work.

Hi. I’m posting today a video of the CNC working to draw a PCB on a black painted copper board with a 0.5W 808nm laser diode assembled as described on earlier posts.

EDIT: Watch this video too:

Friday, December 18, 2015

New laser holder.


I’ve just installed a new support for the 808nm 0.5W diode laser discussed in previous posts. It is a very simple one, using a copper tube and two PVC plumbing parts. Now the focus position can be changed by moving the Z axis.





I’ve also assembled all the electronics in a sealed plastic box, with removable connections to switches and step motors.


Thursday, June 11, 2015

Microscopic pictures of the PCB ink coating that was laser etched


I’m posting here the latest microscopic pictures of a PCB that was covered with black spray ink and illuminated by the 808nm 0.5W laser diode that was installed on my ShapeOko2 CNC. The focal point was moved by the machine to draw an insulating trace around the tracks.

As can be seen, the focal area is not round and the result is not good. I’m trying to find a laser diode with a circular profile to fix this.







Tuesday, June 9, 2015

Latest results

I’m posting the latest results, after disassembling the ShapeOko2 and reassembling it due to a change from one country to another.

A few things have changed:

1- I found an easy way to place and hold limit switches in the machine. See the pictures below for more info.

2 - The YetAnotherGCodeSender program was advanced and now it can be compiled in a Raspberry Pi and in a Mac. Probably on Linux too. The program uses a very crude text based interface and controls quite well the TinyG planner queue, sending commands to the controller only when it is able to process them;

3 - I installed a 808nm laser diode on the machine as I said I would. I tested it against black ink covered PCBs and it could remove the ink where the laser beam hit. Pictures below too;

4 - Instead of using a specific program for generating GCode from GERBER files, I decided to follow the following workflow:

a – Draw the board then export the layers to GERBER format;

b – Open gerbv, installed on a Mac through MacPorts, load the GERBER layer and export it to PNG;

c – Open MeshCAM, load the PNG layer, set the Z thickness to 0.1mm and set black to +Z. Follow the normal procedure and generate a toolpath only with the pencil pass. Save the G-Code to a file;

d – Send the GCode file to your CNC machine. I’ve used my own software here and made it translate the negative z movements to Laser ON and the positive ones to Laser OFF. Incredibly, it worked. The first result can be seen on the last picture below.










Tuesday, December 2, 2014

YetAnotherGCodeSender, a C++ software for TinyG and ShapeOko2.

Hi. I’m working on a C++ program that connects to the TinyG and configures it for the ShapeOko2 machine. It will, soon, also be able to deliver the gcode files to the machine, line by line.

If you are interested, the sources can be found here. They include a Makefile so you should be able to compile them in a linux machine just by typing ‘make’ and <ENTER>. The only required library is libxml2, which is available on most linux distributions and can be installed by conventional package managers:

- apt-get install libxml2 on RaspberryPi, Debian, etc;

- port install libxml2 on Mac OS;

- yum install libxml2 on Fedora, etc;

- cd /usr/ports/textproc/libxml2; make; make install on FreeBSD.

The chances that you have it already installed in your system are very big. Please read your linux distribution manual to learn how to install it if it is not your case.

To download the code you can access the link I gave or checkout it using Mercurial, which is a version control system available on almost all systems (including Raspberry Pi). You can learn how to use Mercurial here or, if you already have it installed in your linux (or MacOS) system, type this in a terminal:

$ mkdir YetAnotherGCodeSender

$ cd YetAnotherGCodeSender

$ hg init

$ hg pull -U

The Mercurial version control system can also be installed using available package managers (yum, apt-get, ports, macports etc) or via an excellent software called SourceTree which is available for Mac and Windows systems. This software handles all the checkouts and updates graphically and can make your life easier if you do not like the command line interface.

For my program (YetAnotherGCodeSender), all the machine configuration parameters are written inside a XML file that is easy to be changed. The parameters include the communications port. The file looks like this:


<attribute key="serial_port_device">/dev/tty.usbserial-DA00XWU7</attribute>

<attribute key="serial_port_data_bits">8</attribute>

<attribute key="serial_port_parity">0</attribute>

<attribute key="serial_port_stop_bits">1</attribute>

<attribute key="serial_port_baud_rate">115200</attribute>

<attribute key="serial_port_flow_control">XONXOFF</attribute>

<!-- Global system settings -->

<!-- Junction acceleration: Global cornering acceleration value -->

<setup key="JUNCTION_ACCELERATION" command="$ja">2000000</setup>

<!-- Chordal tolerance: Sets precision of arc drawing. Trades off precision for max arc draw rate-->

<setup key="CHORDAL_TOLERANCE" command="$ct"></setup>

<!-- Switch type: 0=NO, 1=NC -->

<setup key="SWITCH_TYPE" command="$st">1</setup>

<!-- Motor disable timeout: Number of seconds before motor power is automatically released. Maximum value is 40 million. -->

<setup key="MOTOR_DISABLE_TIMEOUT" command="$mt">10</setup>

<!-- Communications settings -->

<!-- Enable JSON mode: 0=text mode, 1=JSON mode -->

<setup key="ENABLE_JSON_MODE" command="$ej">0</setup>

<!-- JSON verbosity: 0=silent ... 5=verbose (see details) -->

<setup key="JSON_VERBOSITY" command="$jv">3</setup>

<!-- JSON syntax: 0=relaxed, 1=strict -->

<setup key="JSON_SYNTAX" command="$js">0</setup>


<!-- Status report interval: in milliseconds (50 ms minimum interval) -->

<setup key="STATUS_REPORT_INTERVAL_MS" command="$si">50</setup>

<!-- Enable CR on TX: 0=send LF line termination on TX, 1= send both LF and CR termination -->

<setup key="ENABLE_CR_ON_TX" command="$ec">0</setup>

<!-- Enable character echo: 0=off, 1=enabled -->

<setup key="ENABLE_CHARACTER_ECHO" command="$ee">0</setup>

<!-- Enable flow control: 0=off, 1=XON/XOFF enabled, 2=RTS/CTS enabled -->

<setup key="ENABLE_FLOW_CONTROL" command="$ex">1</setup>

<!-- Baud rate: 1=9600, 2=19200, 3=38400, 4=57600, 5=115200, 6=230400. 115200 is default-->

<setup key="BAUD_RATE" command="$baud">5</setup>


<!-- Motor 1 settings --

<!-- Motor mapping to axis: Configures the axis to which this motor is connected (for Cartesian machines) Typically: $1ma=0, $2ma=1, $3ma=2, $4ma=3 to map motors 1-4 to X,Y,Z,A, respectively-->

<setup key="M1_MOTOR_MAP" command="$1ma">0</setup>

<!-- Step angle: Motor parameter indicating the angle traveled per whole step. Typical setting is $1sa=1.8 for 1.8 degrees per step (200 steps per revolution) -->

<setup key="M1_STEP_ANGLE" command="$1sa">1.8</setup>



In principle you just need to run the main program and it will read the XML file, send it to TinyG and configure your machine. More advanced functions will include spindle warm up and other tasks which are not available now.

The current code is able to send the configuration parameters to TinyG with success. I’m working on the functions that read the GCode file and send them line-by-line to the controller, so if an emergency happens (crash, break etc) you can stop the task by killing the program.

I almost forgot this: the program outputs a log file with details of the communication between it and the TinyG. You can find there all the commands and the answers from the controller.



The files are licensed as follows:



* This file is part of YetAnotherGCodeSender

* Copyright (C) 2014 Eduardo Novaes Hering


* YetAnotherGCodeSender is free software: you can redistribute

* it and/or modify it under the terms of the GNU General Public

* License as published by the Free Software Foundation, either

* version 3 of the License, or(at your option) any later version.


* This program is distributed in the hope that it will be useful,

* but WITHOUT ANY WARRANTY; without even the implied warranty of


* GNU General Public License for more details.


* You should have received a copy of the GNU General Public License

* along with this program. If not, see <>



This code is still immature. If you decide to use it, take all the necessary safety precautions before trying. As written in the license, this program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.