Category: MillDroid


(Originally written in Sept. of 2014, this entry has been re-written and updated to reflect current changes)

A little history first….


I’m purely a hobbyist when it comes to metalworking. Coming from an editing and visual effects background as I do computers are a very natural tool for me. Programming them is second nature. I’ve been writing code for over 40 years be it flipping toggle switches on a breadboard or typing it into a text editor. When I decided to get into metalworking it was only natural to apply my computer skills. I bought a Sherline mill and played with it for several months to understand the processes involved. I bought some stepper motors and a Gecko G540 driver and built my own controller to run it. The ‘standard’ out in the world seemed to be Mach3 for software control so I purchased it and started making chips.


After spending the better part of the several months writing code for Mach 3 on my Sherline CNC Mill and making small parts threw my hands up in frustration. I’m sure that plenty of people are able to work with the antiquated Mach3 software and do fine work. Those same people might not mind the frequent freezes and crashes. Perhaps they don’t write a lot of customized code so it works for them. Perhaps they are fine running on an operating system or machine that is very old. Perhaps they are also fine with the integrated, incredibly buggy and horrible excuse for a “macro” programming language that is Cypress Basic.


I am not one of those people.


Bad user-interface designs and choices are among my pet peeves, especially when they are never improved upon for “legacy excuses” such as “people are accustomed to it”. I’ve seen and used (and written) a lot of bad software over the years and consider myself an expert on the subject. If it is buggy or badly designed, I fix it.

I also got tired of waiting for the long-promised, improved version of Mach4 from Newfangled Solutions. I’ve been hearing about this updated version for YEARS and how it was “right around the corner” (their words, not mine). It was going to support VB, a much better alternative to Cypress Basic and LUA, a poor choice of a scripting language in my opinion. Why ANYONE writing an application today would chose something other than or Python (if they require multi-OS support) is beyond me. When Mach4 announced that it would only support LUA I decided I’d had enough of them. It was time for a better and more flexible CNC application for me. As of this writing they have announced a Pre-Release, PreBuy Hobby Version that has no motion control still. Right.


I had already built a stepper motor controller system based around parallel port output to a Gecko G540, a fine device. I decided to augment it and move away from the computer’s parallel port connection at the same time to allow for more modern hardware options such as USB. I discovered Dynomotion’s KFlop boards online and began researching them.


I will say that rarely have I encountered a company with as good support as Dynomotion. Tom at Dynomotion read and answered my many emails for information in a timely fashion. Best of all, the software for the KFlop board that they sell, written in C++, included a Dot Net library for access by modern managed programming languages such as VB.Net and C#. Net. I purchased a KFlop and began experimenting. I was now able to use a modern computer and USB to communicate with the KFlop, which spoke to the Gecko G540 to drive my stepper motors for the mill.


There have been a lot of good things said online about the KFlop and how smoothly it manages steppers and I agree with them 100%. Motor control is much faster (too fast, in some cases but easily adjusted) and smoother. It even “feels” better and that isn’t something I can easily describe–the motors movement feels less choppy. The KFlop system is not without some issues. Documentation is the weakest part of the KFlop system and Dynomotion seems aware of this. The docs are a bit “spread out” and searching for something can be a bit difficult. The .Net library documentation is a bit rudimentary (example code should exist in the documentation) and adding more example projects would help a lot. There are a few C#.Net and VB.Net example programs and they help, but they address only the basics. Despite this the overall value of the hardware is fantastic.

If you are going to program the KFlop, the main example program is an application in C++ called KMotionCNC which serves as a pseudo-replacement for Mach3 running GCode. If you program much of the system is understandable but it takes some time to figure it all out. If you are not a programmer you have a lot to learn. The hardware initially requires using C++ code that you then compile and download to the hardware to set motor preferences and settings but I later figured out how to bypass this with 100% managed code. Once I was over the initial hurdle of understanding the system and getting motors moving, I set about designing my own custom CNC software.

Phase 1 was to learn the KFLOP hardware itself. I breadboarded the KFlop to my Gecko G540 to make it easier to figure out the IO lines of the board and make changes as I attempted to control my Gecko G540. I then built an enclosure for the KFlop. Done.

Phase 2 was to attempt motor control with the KMotionCNC software of my Gecko and Mill, despite the fact that I didn’t intend to use KMotionCNC. This took a little doing.

Phase 3 was to dive into the code for the new application. Here’s where the fun begins. My end goals were

  • A multiple window, modern user interface that was configurable and persistent.
  • A robust preferences system.
  • Extensive error trapping/correction including intelligent saving of parameters in case of a crash.
  • A DRO module that allowed for “undo-able” changes.
  • A Jog/Manual module for the mouse, including keyboard and potential external hardware devices.
  • The ability to load, save, edit and run GCode files.
  • A CustomTool module for easily adding code and custom milling. This would be my “plug-in” system.
  • Preparation for Backplotting options later by using existing code from my SubSpace 3D digitizing application.

Thanks to Tom’s support at Dynomotion, answers to my questions were never more than a day away. It took about a couple months of spare time to write the code and get it all running. As I write this in August of 2014 I’ve milled several pieces successfully and only broken one end mill because of a bug! But, hey, at least I can fix my bugs! (Note, it is now 4 years later and Dynomotion’s support continues to be great).

I approached the writing of the application by breaking it into the modules I knew I would need. I began with my Skeleton Framework code that I’ve used as the foundation for all my applications over the last 15 years. This foundation gives me a non-modal UI with all the library code I’ve written over the years including:

  • Advanced Generic Collections
  • Application and User Interface persistence
  • Common string parsing and handling
  • Process and Threading classes
  • Form handling
  • History and Undo management classes
  • Hot Key management
  • My MScript scripting language for startup parameters

Using my existing Skeleton Framework as a starting point lets me skip all the mundane code and jump directly into the fun stuff. It provides the foundation for most of the applications I write for work and home.

Update: Originally titles MillDroid because it was specifically for my Mill, I’ve since added a Lathe. Now the software can control both my Mill and my Lathe, switching between them with a button press. I have updated all the images in this blog entry to reflect updates I’ve made to the application over the last few years.

I blocked out the User Interface into the following modules and began building them:


First, the Tool Form, from which all other windows are launched. This is the center point or hub for the entire UI.


After the Tool Form, every form can be made visible or not and positioned anywhere on the screen and persisted.

The DRO form to display location data and allow changes to the data. It also provides functions for quick navigation and movement on the Mill and Lathe. Both my mill and lathe now have magnetic tachometers that provide pulses for the system.


This is the GCode Form for editing and running already prepared GCode. This allows me to edit GCode manually and contains a recording mechanism for auto-creation of GCode. I can jog the mill around manually and add key frames at any time, recording everything or only changes in certain axes depending on my needs.




The Jog Form, for mouse and button manual control of the mill and lathe. All the buttons in this form can be accessed by hot-keys such as the cursor buttons, or an external device on a USB port. I added a few macros for my rotary table control for functions I find myself using often. All jog or step speeds can be changed as well.



Between the DRO and Jog Forms there are plenty of ways to move the axes manually, but what about when I make a mistake? Ever move an axes then realize that you shouldn’t have? Now you have to figure out how far you’ve moved off course That’s what this History Form is about–it records every change you make anywhere in the application and displays it for you. A true Undo would be far too dangerous on a motion control device, so this lets you see what you did, then copy and paste the old value where you might need it in the DRO. Much more flexible than Undo/Redo functions would be.



A Locations Form to allow quick movement and recall of positions on the mill and lathe. I can record current positions of the mill for any or all axes, then move between any of those stored positions quickly at rapid or cutting speeds. Notes can be added to each location to help when human memory fails.


The Message Form provides feedback from the application. This is where general message, warning or errors are presented so they can be logged, without bringing up an application-halting dialog box. It’s proven handy for later review of debugging issues also.


The Preferences Form for the default settings on the application. Every setting in the application can be changed here. The most complex is the Motor Tuning/Motion Params tab. Since multiple preferences can be save/loaded, I have some very fast motion settings for testing and everyday settings I use with safer motor speeds that are more appropriate for a mill/lathe of my sizes. It’s nice to be able to switch quickly between them.




This is the Macro Form.  A folder is parsed at startup and a macro “button” is shown for each script. This allows quick additions of little GCode Snippets that can be accessed quickly.




The CustomTool buttons presents options for my “plugins”. There is a Base CustomTool Class, which is inherited by each of my custom tools. It takes only minutes now to write a new CustomTool and I have several. CustomTools give me the option of starting anywhere in their cycle in case I need to redo something. Each has an accompanying help file. They can also output their commands to a GCode file log for later perusal. A Last Pass Alert plays a tone (and voice) and shows a Dialog box awaiting a continue order before a finish pass is made (if desired). This lets me decide if I want to increase the spindle speed or decrease the table speed for the finish pass–very useful when flycutting or performing other finish cuts. I often like to add a little cutting fluid and increase the spindle speed for a better finish on the last pass and this keeps me from “missing” the chance on a long-running operation. I can also chose to repeat the last pass as many times as I like. All CustomTool setting can be saved as a file for later use.

You will notice that some of my CustomTools, such a PeckDrill, perform operations that can also be done with GCode. Sometime I write my own custom tool just because I want to understand the process better; other times just because I wanted some added flexibility or control.


All CustomTools have an accompanying ProgressForm. It allows modification of the functions all CustomTools have in common, along with starting/restarting and monitoring of passes, their elapsed time and prediction of completion.



The Thread Maker CustomTool allows me to mill threads using my rotary table as a fourth axis on the mill. This is now pretty obsolete, as I have added an optical encoder to my Lathe and am now working on writing some threading code.



SlotXZ cuts adjustable length slots


The ProfileRepeater takes an existing GCode file and repeats it over multiple depths. Handy for cutting a complex shape into thick stock.




PeckDrill perform a drill pecking operation, preventing the bit from clogging. I was tire of cranking the z-axis up and down and up and down…..




InterpHole drills interpolated holes using end mills or any size. I had fun working out the math for this one….




I used the alpha and beta phases of my MillDroid software to create a bunch of additional tools for my mill and bandsaw. Like most of my code writing projects I’m continuously adding features and the apps become dynamic projects, evolving over time as my needs change. Now that the code has matured past the release phase, I can use it daily, confident in its stability.

I now have over 30 CustomTools written for the application.


The Camera Form shows the output from a small microscope camera that I can point at the cutting operations. Much easier than holding a magnifying glass close to dangerous operations.


A CalculatorForm allows for quick calculations with a memory for checking later. It is the little things like this that make things easier.


This one was fun. The VisualizerForm provides a graphical representation of the Mill positions relative to the stock and table. I’m working on making this a 3D perspective view and adding Lathe functionality as well. I was able to re-purpose some of my older graphics code from my SubSpace projects. Never throw anything away.




CurvesCustomTool started as a quick drawing tool for milling directly from a drawing. It snowballed into a curve-based CAD application that I now call Pathfinder. You can find it in the Projects section of this blog, but here’s a snapshot:



Here is a pic of the KFlop Motion Controller I built for the application:



MillDroid continues to grow. People have asked a few questions, for which I have answers:

Q: Will MillDroid work with controllers other than the Dynomotion KFlop?

A: No. The application is built very tightly around the KFlop and it’s libraries.

Q: Is MillDroid for sale?

A: No. I’ve sold software in the past and the limited user base for which MillDroid would appeal does not justify the work that would go into maintaining it for others and support.

Q:Is MillDroid’s source code available or Open Source.

A: No. I wrote this code for my use, to solve very specific goals I had, in the manner in which I like to write code. It’s limited user base, specific hardware needs and programming language (mainly VB.Net and some C/C#) make it a very niche application.