CNC Router

So I lied. My next post is not going to be about more 3d printing and other microcontroller cnc control platforms… I’ll have to get back to that a bit later.

I got the idea in my head that I needed a CNC router. This would let me make, among other things, cabinet doors, bracketry and other misc attachments for other machines, and anything else really I can think of.

Started discussing the idea with my father, who is a mechanical engineer (Some of his exploits at and by chance he happened to have a bit of a problem buying good deals on linear actuators and rails on ebay. He managed to get a pair of 1560mm Schneeberger 35mm linear roller rails (rollers instead of balls inside the carriages), and a pair of 920mm THK 30mm regular rails. These sizes happen to line up perfectly to do a 2’x4′ (610mmx1220mm)router with about 300mm of carriage on each. We started researching into the rails, and figured out that if we built the frame sufficiently robust, such a machine should be able to do aluminum, and maybe even steel!

Enter my own 3d CAD experiences. I’ve fiddled around with cad in the past, but I’ve always been a software/electronics kinda guy. I decided this would be a good thing to play around with modeling, so I started drawing things up. Wound up with this:


a 2×4 router, with 300mm of Z. The design is centered around 4″x4″ square tubing, which is available for fairly cheap from local vendors. These would be bolted and pinned together to avoid any movement, and then self-leveling epoxy would be poured on top to give a flat surface and allow both rails to be parallel at least on the surface.

This seemed all good and well… but then I started to price out the materials, and thought to myself… if 2×4 is good, then 4×8 would be even better?

I managed across a pair of 2680mm THK 30mm rails (identical to the 920’s) for fairly cheap… the documentation states that I can butt the rails against each other, giving me 3600mm total length one way, and 1560mm the other. Easily a 4x10ft router, with room for a tool changer and a hefty carriage. Thus was born the second design:


Remarkably similar to the first… but the flat sheet in the middle is 4’x8′, and it weighs twice as much. The self-leveling epoxy idea would still work here, just require a lot more epoxy. I’ll have to call around to a couple of places and find out recommended practices and procedures for this sort of thing.

The design still needs more work, I’m going to make the gantry significantly beefier, make a table underneath (whole thing weighs in at around 1400lbs so far… needs quite a table!) and design the motion system (I have some really cool ideas!) but I think that this will be quite the interesting project, and hopefully at the end I’ll have the equivalent to a $25,000 router, for about tenth of the price.

More Printing, Linux style!

So I wrote this post with the intention to post it quite a few months ago… and never actually got around to finishing it up for posting. Oops. Quite a lot has been going on since then, so I’ll hopefully make another post soon after this one with more information.

My last printer post I mentioned I had gotten a to play around with, and in the past few months I’ve gotten it up and running on my BeagleBoneblack. I ran into a couple of issues and gotchas that I had to work through, which I’ll hopefully be able to detail out in this post to help others that are interested in running the 432 with their printer.

The board itself seems to be well laid out, it breaks everything out to the sides, and leaves room for accessing the BBB ports. It does not have any mosfets/relays, but the I/O has enough current to run any mosfet or SSR that you would want.

It has two 26pin IDC connectors for hooking to your standard IDC to DB25 parallel port connector, which I do, and plug directly into a G540.

It also conveniently has 4 analog inputs, preset with 4.7k resistors which allow it to be easily used with the standard 100k 3dprinter thermistors. The 4.7kohm resistor is replaceable without soldering if a different resistance is required, but 4.7kohm worked fine for me.

Let’s talk a little about the I/O. I’ve added the PMDX-432 I/O in the beagleboneblack-pinmux document here, and this details what GPIO numbers match to what pins on the PMDX-432

The step/direction for all 4 steppers run out the J1 connector, and are set up such that you can plug the DB25 directly into a G540 and be pinned correctly for step/direction. I’ve not used the extra I/O on the G540, but rather am running my solid state relays direct off the PMDX-432.

I have two DC solid state relays running my heatbed and hotend, both at 24v rather than the normal 12v. This lets me pwm 60-70%, and get more power out of the heaters. The bed and hotend both heat up significantly faster now than they did running on a 12v system.

To run the temperature control, I use the BeBoPr++’s file, and point it to the proper analog inputs for the PMDX-432. Pipe that into a PID for the hotend, and one for the bed, outputting direct into the pwmgen for each. I’ve set the pwmgen to only run at 5hz, since the solid state relays are a bit slow to turn on and off, and really I don’t need super high frequency pwm. Thus far I’ve not worked out how to tie M commands into the HAL file, so I have to manually set the temperature with halcmd each time I want to print, and then turn it off once the print is finished.

To slice my STL’s, I use simplify3d, which is an amazing piece of software. It turns out much higher quality prints than slicing with either slic3r or kisslicer. It’s a bit costly, but well worth the money. The one downside is that I do have to do some post processing on the gcode. I convert the E’s to A’s, remove all M commands, and add a G64 P0.150 to set my path following tolerance (the key benefit that made me switch to LinuxCNC).

All in all it prints amazing, however I’ve been going back and forth about continuing to use LinuxCNC to run the printer. It’s really not *intended* to run a printer so it doesn’t quite do proper extruder control which leads to some odd print artifacts. I’ve started playing with a few other options, including Smoothie, GRBL, and TinyG, which run on a couple different microcontroller platforms. I’ll detail that out in the next post.

Qt and cross compiling

So for a while now I’ve been cross compiling Qt from Linux, for Windows. I use this on my build server to allow me to build binaries of several applications I develop. Every time I go to set up a new build server, or upgrade Qt libraries I always run into an issue ( which has since been closed as a duplicate, however the replacement issue is not the same. The error I would get is “No target to build mocinclude.tmp” Edit: The error may actually be “No rule to make target mocinclude.tmp”, I may have mis-remembered. Regardless, it’s a very vauge error, but after some searching I discovered a bit more about mocinclude.tmp.

The whole purpose behind mocinclude.tmp is a fix for Windows XP and before, where the command line had a rather small limit to how long a single command could be. This means if you had a large number of include paths (40+) then you would not be able to fit it all on a single command. Qt’s solution to this, was to stick all the includes inside a mocinclude.tmp file, and include that file on the command line. This is all good and well, but if you actually trigger it, it does not work! (It hasn’t since Qt 4.6, and as of Qt 5.2 it still does not). As I keep stumbling across this issue, and keep having to fix it, I figured I would document it here so I don’t have to frantically google whenever it happens and I’ve conveniently forgotten the fix since the last time.

Inside the moc.prf file (Which by default is at QTDIR/mkspecs/features/moc.prf) is the logic for generating mocinclude.tmp. Partway down the file is a chunk that looks sort of like this:

build_pass|isEmpty(BUILDS) { = $$INCLUDETEMP
mocinclude.commands = $$RET

This tells the makefile to create a dependancy for $$INCLUDETEMP (which is the absolute path to the mocinclude.tmp file). The problem being, all the other includes use RELATIVE paths to the mocinclude.tmp file, so make is unable to find the dependancy. Simply adding a relative_path to that, is enough to fix it:

build_pass|isEmpty(BUILDS) { = $$relative_path($$INCLUDETEMP,.)
mocinclude.commands = $$RET

This lets the dependency be named by the relative path, which is the same name that other files link to. Problem solved, it’s a shame that this same issue has been closed several times ( as unable to reproduce.

At least I’m up and running now, hopefully this can help someone else with the same issue.

3D Printing, Rev 2

So I was using my 3d printer for about a year, and I decided that I wanted to print parts in ABS. One of the key differences that ABS has, is its higher glass transition temperature. This means it doesn’t start to get soft (and deform under pressure) until it reaches a much higher temperature than PLA, 100C+ vs 60C.

So to improve the chances of a successful 3d print using ABS, I wrapped my printer in cardboard in order to emulate a heated enclosure. In this case, the enclosure is heated by the waste heat from the heated bed. This went decent for a print or two, until I noticed I started to have some axis creep, where the head was slowly moving in one direction. As the prints progressed I found out it was doing this because the x carriage was starting to melt! A couple more prints later, and both the X Carriage and the extruder had destroyed themselves and were no longer usable.


My father, in the meantime had been building a XYZ table for a drag engraver. He was using really nice linear rails that he had purchased off ebay. He found himself another small CNC machine that made his XYZ table obsolete, and I managed to convince him to donate the table to the cause, and thus my ABS printer was born!


DSCN1338 DSCN1336 DSCN1500 DSCN1494

The X and Z axis are 6mm pitch ballscrews, powered by NEMA17 style steppers. They have encoders on the back, but I am not using the encoders at this time.

The Y axis (table), is a 10mm pitch ballscrew, powered by a NEMA23. I was initially driving all three steppers from the Sanguinololu board with pololu stepper drivers.

After everything was installed and wired up, I fired it up and got started running some simple movement tests. Figured out that 600mm/s^2 is a decent acceleration, it’s not super quick, but running the pololu’s at 1 amp it keeps it from skipping steps. I can likely crank this up once I get more power for them.

Doing speed tests, I was able to get up over 100mm/second running back and forth, but I quickly noticed I was having some odd resonance issues with the X axis. Around 60, and again at 80mm/second, it made some quite loud noises, and would occasionally stall for a moment.I did some digging and research, and found out that they DO make stepper drivers to prevent this, but the $10 pololu’s won’t. For the time being, I limited my speed to 40mm/second.

Tried a few test prints and I was having extruder jamming issues, very weird issues. Fiddled around for a few more hours and discovered some…. issues with the extruder itself. Tore it apart, widened some of the the holes, put in a j-head slot plate and put it all back together. No more jamming filament, no more slipping hotend!


At this point, I was up and running! I had my ABS printer, it did alright for smaller prints. For larger prints, I started having delamination issues from the lack of a heated environment, as you can see below. This is really a major issue on large parts, but shows up as corner warping on smaller parts.


So I made an attempt at a heated enclosure….

DSCN1343 DSCN1344 DSCN1345

More on my experiments with that, including a proper frame later :)

I started noticing that certain prints would cause missed steps during rapid small infill. Lowering my acceleration values didn’t have any effect at all, so I started looking into exactly what parameters managed this. Turns out it was something that reprap calls “JERK”. Anyone familiar with motion control knows what jerk is, but in this case it is entirely literal. Jerk is the maximum velocity change the printer is willing to do instantaneously. Sure, instantaneous acceleration isn’t possible but it tries really hard to do it anyway. If I disable this feature, then the printer goes from point to point, acceleration and deceleration, coming to a stop between points. Totally unusable.

So my options were, turn down the speed REALLY far for the whole print so it’s not an issue, or live with it. I chose to find a different controller.

Enter; LinuxCNC. My dad had a spare G540 stepper driver that he said I could play with so I put LinuxCNC on a liveCD, loaded it on a spare CarPC that I had laying around which happened to have a parallel port. I had to cut all the connections to the stepper connectors I had, and solder them into some DB9 connectors to plug into the G540, but I got all that finished fairly quickly. I plugged it in, started linuxCNC, and got fiddling with GCode to get it to work.

DSCN1506 DSCN1505 DSCN1504

A couple key differences between Reprap and LinuxCNC gcode. Reprap is primarily G1 commands for movement, with M commands interspersed for extruder/bed temperature and the like. Simply commenting out all M codes, and changing all E references for extruder to A for the 4th LinuxCNC axis is all that needs to be done for the GCode file to be loadable by LinuxCNC.

Because I don’t yet have a way to run the bed/hotend from LinuxCNC, I kept them hooked up to the Sanguinololu, and used my own utility to turn them on and off, but I do need to have that controlled by LinuxCNC at some point,

Once I was able to load the GCode, I set my home positions, got the hotend and hotbed hot, and then hit Go. It printed magnificantly! Way more smooth, way quieter with the G540 stepper drivers, able to go faster due to the anti-resonance characteristics of the G540. I was limited however to only 70mm/second, since the PC I was using wasn’t great in terms of jitter, but it prints at 60mm/second beautifully with no issues.

DSCN1350 DSCN1349 DSCN1348 DSCN1347 DSCN1346

So right now I have a spare CarPC connected to a loaned G540 plugged into my stepper drivers, with a Sanguinololu connected to my hotend/hotbed. It’s quite a contraption as you can see below but it is a very good proof of concept!

DSCN1503 DSCN1502 DSCN1501 DSCN1496 DSCN1494

Next step will be to figure out what stepper driver I want to go with (G540, or as an alternative MX3660 would work as well), and figure out how I will be getting a faster step clock. My PC is running with a 33uS step clock, which is only fast enough to get up to 70mm/second with the G540 10 microstepping. The 3660 would allow me to drop to 1/4 microstepping, increasing my maximum speed to 140mm/second, and switching to a beaglebone would reduce my step clock to <10uS, increasing my potential speed well beyond what I am looking for.

Just a couple of weeks ago I got my hands on a PMDX-432 (, which allows me to truly do a standalone beaglebone/linuxcnc based solution. More on that in the next post…

3D Printing

Wow, it’s been almost a year since I’ve updated this. I really need to dedicate more time to documenting my various hacks. I have a few written up in drafts, but never published because I didn’t have the time to finish them. Well this is an attempt to start that. I will also be integrating Facebook comments, hopefully so as to curb the amount of spam comments that I have to weed out (100 or so a day) to get any real comments (3 a year? if that?).


So anyway, I’ve gotten to add a new tag, 3d printing!

I’ve been looking at 3d printers for a bit over a year now, kind of skirting the edge of the hobby. I’ve wanted to jump into it but never really had motivation to actually spend the money on it. My father, who is an engraver/cncer/metalworker, also happens to be into steampunk. He’s decided that he wants to build a paper towel holder, which would be an absolute nightmare to to machine… enter 3d printing!. His paper towel holder is modeled after two DC motor end-pieces on either side, with the paper towel holder in the middle. This is primarily because the end pieces look cool. You can purchase the motor ends rather than trying to machine them, but they cost several hundred dollars. Somehow I’ve managed to convince him to spend MORE than a couple hundred of dollars on a 3d printer which would be capable of printing the pieces he needs.


So a couple of months ago I purchased a half completed 3d printer along with my father. We spend a couple of weeks (well, a couple of sundays) fiddling with it and getting it assembled. Finally got it running, and was getting kind of crappy prints out of it.


I did some searching, and found out that the hotend that we were using was kind of a home-made deal, so I went and purchased a J-Head ( The owner lives about an hour north of me, so I stopped by his shop and bought one. Got a chance to hang out with him for an hour or so, really cool guy, awesome little machine shop he has. Got the j-head installed on the machine and it was printing WAY better. Printed a PCB holder for the control board, added a couple fans to the machine to help cool the part, and it just kept getting better. I brought the printer to my house, got it all set up,and started printing more improvements. Printed a power supply mounting bracket, printed different Y axis rail holders, Y axis plate mounts, and installed the heated bed. Before the heated bed, I was using blue painters tape wiped down with acetone before every print, to make the part stick.


Below is a gallery with some pictures of my adventures. As I take more, I’ll continue to make updates. There are a couple test prints, some tool holders for my father (He’s doing the majority of the 3d work), and a Jaguar ECU enclosure that I designed myself (Woohoo! first real design!)

Jaguar A3 Part 2

Managed to scrounge up some solder, so I did some more :). I got everything done that I had components for. I’m missing 3-4 components, so I’m going to have to make a mouser order for that stuff later anyway. Gallery attached of the rest of the build.

Jaguar A3

In my last post I commented about something I had recently discovered, FreeEMS as a potential solution to my Camaro problem. Today I received my copy of Jaguar A3, which is revision 3 (still alpha) of a FreeEMS compatible ECU.

Soldering it together wasn’t difficult at all especially since there is a really awesome how-to for Jaguar, put together by Preson, with help from DeuceEFI (mastermind behind Jaguar). These instructions cover from assembly, all the way through to testing. I’ve got it about halfway done, and I ran out of Solder, as well as discovered that I am missing one or two required components. In a month or so I’ll put in another mouser order and hopefully get it completed. Gallery attached for your viewing pleasure. I am well aware that I suck at soldering… I’m a code guy yanno :)


It has been a while since my last post, and I apologize for that. Between buying a house, and traveling for work, I’ve not had much time for silly things like updating my blog :). As a few people are aware, I have a 1987 Camaro that has been nonfunctional for about 4 years now. It’s gotten to the point where I’m just sick and tired of looking at it, so I’ve lately embarked on a project to build my own ECU for it. Lucky for me, there is a FOSS Do-It-Yourself EFI as it were . In talking to the lead developer, it seems that they don’t really have any decent tuning client to assist with tuning the already very runnable codebase. This is where I saw a niche that I could fill. Enter: EMStudio. C++ Qt based tuner for the FreeEMS ecu. Thus far it has a fairly small feature list, it can open/edit ram data on the device, either via hex edit, or 2d table view , and display live data in a table or on gauges. All in all I’m very proud of how far it’s come and what it can do in such a short amount of time.

I just wanted to give a small update as to what I’m working on. I’m not dead or gone, I’m just busy.

Visit to

So for the past month I’ve been on travel for work in Arizona. Yesterday I was on my way home, and happened to be in Phoenix. As it turns out,’s HQ is located in Phoenix so I dropped by for a visit. I had not initially realized how large of a staff they have on site, but a good number of them took time out of their day to talk to me and I really appreciate that. I actually wound up being there for several hours. Between discussions over CAN network and sitting in the Chevy Sonic I had rented to decode a variety of CAN messages using their can sniffer, it was a very eventful and interesting day.

Initially we got into discussions about CAN based OBD2 messaging, specifically the meanings of the different identifiers in 11bit vs 29bit. It seems that there were a few different modes of CAN That I was confused about the OBDLink MX’s return values for. There are a few different CAN modes that the OBDLink MX supports, the main differencing factors are 11vs29bit, and 15765 vs 11898 protocols. 15765 has an extra byte in the return for PCI, or Protocol Control Information field, defined here. This was of course, throwing my software through a loop since I wasn’t handling this, and this made for an extra byte on top of everything else. 11898 CAN does not have this identifier, since it is just RAW can values. The OBDLink does not actually return what is listed in the wikipedia article on CAN_Bus, adding even more confusion. The underlying CAN hardware internal to the OBDLink MX strips out start-of-frame, the RTR/IDE bits, and the DLC (unless otherwise requested to show it via ATD1 if I remember correctly).

Armed with this new information, we moved into a conference room, set up one of their wonderful OBD2 simulators, a Y cable, and a second laptop/tool to attempt to try out my new CAN Parser software to sniff what a CAN datatool is doing. Of course, as with anything technology we ran into a few issues. The first of which was the fact that I was running linux. When connecting over rfcomm using a bluetooth adapter on linux, you have to manually bind the rfcomm channel on your device to access /dev/rfcomm0. This is a bit of a hassle, since upon power cycling the device, or disconnecting screen from that particular pty, it breaks the connection and you have to unbind and rebind, which doesn’t seem to work 100% of the time. This is not an issue with the Obdlink MX, this is a linux issue since windows has no issues keeping the com port connected and active even under device powercycles. I will have to investigate more thoroughly if there is a method for easy connecting under linux.

The few times we actually got it to work, I realized that there were a lot of contingencies I did not actually plan for in the writing of my CanParse application. So after some mad random coding, and a bit of pizza and soda (thanks guys!), we moved out into the car. Jason, from what I can tell (forgive me if I get this wrong), one of the hardware guys hooked up his can sniffer to the Chevy Sonic, while I hooked up the OBDLink MX via Y-cable. Couple of weird things happened, including the rpm dial flickering up and down and random dingings of the door alarm, even when the door was closed. We figured this was just his can sniffer doing something weird, and moved on. Unfortunately I did learn that my CanParse application is missing a few key usefulness features that will be required before it is used in such a fashion to actually decode what is happening on the CAN bus. I will be detailing these in a later post as I write them into the code. Using Jason’s scan sniffer application, we were able to decode several things over the course of about two hours, including how to control the radio from the steering wheel controls, and how to identify when the lock/unlock and blinkers went on and off. We were unable to control the blinkers or locks, possibly due to a gateway node on the CAN network blocking our traffic, or us just not seeing the proper commands and only viewing notifications. Not entirely sure, but it was still very cool information to have. Just an example, but one could write a piece of hardware that monitors the CAN network, and logs lock-unlock events, turn signals, speed, rpm, a whole bunch of values to identify if someone is driving the car appropriately, or dangerously. I can think of a couple companies which could benefit from this, a couple who would want this, and a couple who NEED this :).

Couple of other key things to note that came out of this meeting. There is an asynchronous communications mode that is eventually planned (ATMA mode with bidirectional communication), however logistically it’s not simple, so it may not happen very soon. It is definitely on their minds though, which is a huge bonus to the CAN crowd. I know that pretty much anyone with a MX and a CAN car would benefit from this, so I can only hope that they implement it soon.

The other thing had to do with CAN masks, I’ll go over that in my next post along with ATMA/STMA/STM differences.

Couple of pictures.


Their offices, they have cubicles

This is the back side of the cubicles. They’re not too large. There is a little white fan looking thing to the left of the paper cutter. It is a Wimshurst Electrostatic Generator. And let me tell you, even through 4-5 people, it still hurts.

This is the lab, they have cool workbenches for assembling stuff ESD safe-like.

And last but not least, me standing with the guys who took so much time out of their days to talk to me and deal with all my questions. From left to right, Joe, Jason, Me, Vitaliy, Vitaliy. That’s right, there are two of them. And I thought it was a unique name :). Thanks again guys!

OBD2 CAN Parsing

So I’ve been on travel for a few weeks, and the rental vehicle I got is a Chevy Sonic. Ignoring the fact that it’s a brand new shitbox, I noticed that it has GMLan. I fortunately brought my OBDLink MX along with me so I can plug in and play with the car. Upon playing around a little with a terminal I found that messages go by so fast, that it’s really not practical to use a terminal at all for monitoring CAN messages. I put together a little CanParser application to assist in the process, and this lead me to try and figure out exactly how to parse CAN messages.

For all intents and purposes in the automotive world you can break down CAN messages into 11bit, and 29bit. This is how many bits are in the header of each message. The Sonic uses both, however predominantly 29bit so that is where I focused my efforts. Let’s take a long at some messages.

10 30 40 58 C0 9A 01
10 22 00 40 00 00 00 00 0F FD 00 00
10 30 80 60 C0 9A 01
10 22 E0 40 00 1B EC C3 C0 49 0A C6

10 30 40 is the header for the first message, and the rest is the actual message. The header can be broken apart into priority, param, and source IDs. The priority is bits 4,5, and 6 of the first byte, so that would be a priority of 4. Param is split between the first three bytes. Two bits of the first, the entire second, and third. Source is then the 4th byte This may seem a bit confusing, so I’ll break it down bit by bit. Say we have the message:

10 0A C0 97 82 08 01 FF D4
The header is 10 0A C0 97
  1  |   0  |   0  |   A  |   C  |   0  |   9  |   7
0001 | 0000 | 0000 | 1010 | 1100 | 0000 | 1001 | 0111
Written another way:
000 | 100 | 00000010100110 | 0000010010111
0     4         56               97

Skip 3 bytes in the front, then the next 3 is the priority, b100, or 0x04.
The next 14 are the paramID, 0x56, and the last 13 are the source ID, 0x97. then the rest of the message, 82 08 01 FF D4 is the packet that we want to play with. Unfortunately this is as far as I have gotten. I’ve not been able to figure out what any of the messages on the vehicle mean yet, but I’m slowly working on it.

I also have not yet been able to figure out how to parse 11bit CAN headers, with any luck that will be next.