A little history first….


I’m purely a hobbiest 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 nearly 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 I gave up. I’m sure that plenty of people are able to work with the antiquated Mach3 software and do fine work. Perhaps they don’t 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 those people are 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. I’ve seen and used (and written) a lot of bad software over the years and consider myself an expert on the subject.

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 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. 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 DotNet 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 dotnet 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.

The main example program is an application in C++ called KMotionCNC which serves as a basic 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 endmill because of a bug! But, hey, at least I can fix my bugs!

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 persistance
  • Common string parsing and handling
  • Process and Threading classes
  • Form handling
  • History and Undo management classes
  • HotKey management
  • My MScript scripting language for startup parameters

Using my existing SkeletonFramework as a starting point lets me skip all the mundane code and jump directly into the fun stuff.


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 centerpoint or hub for the entire UI.



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

The DRO form to display mill data and allow changes:



The GCode form to run already prepared GCode. This allows me to edit gcode manually and contains a recording mechanism. I can jog the mill around manually and add keyframes 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. 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? Every move an axes then realize that you shouldn’t have? Now you have to figure out how far you 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. 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.




Message form for 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.


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 of my size. 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, but not from the beginning. 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 show a Dialog box awaiting a continue order before a finish pass is made. This lets me decide if I want to increase the spindle speed or decrease the table speed for the finish pass–very useful when facemill or flycutting. 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.


The ThreadMaker CustomTool allows me to mill threads using my rotary table as a fourth axis on the mill:



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. This one was fun working out the math….




So far I’ve 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.


I’ve started adding functionality to the code for a potential lathe purchase. First I have to decide on a Lathe.