History of the EMC-project

This project has been around for almost as long as I have. We’ve started over numerous times over the years but every time the project grew, gained new goals and improved in every aspect.

This is more of a story of my childhood and it sheds some light to the environment where I grew up in and how I gained my love to programming and electronics.

The beginning in the eighties

It all began in the late eighties when I began to understand written text. I don’t remember exactly how old I was, maybe six or eight. First version, early alpha, was constructed of Lego Technic blocks, two motors and Commodore 64 with software written in basic.

The motors were coordinated only by time. The trajectory only a list of times how long the motor should be on. It was capable of drawing lines in X-, Y-direction or in 45 degree angles.

The Commodore 64 version was later enhanced to drive servos which we got from R/C airplane. Still the software was as primitive but the electronics were a little bit more complicated.

But here culminated everything what happened in the following years. We had software controlling motors with our own electronics and code. I was writing the code and dad was soldering the wires.

Serious programming

More serious versions came when I learned Pascal and I had an Amstrad PC. It was fun to have such powerful tools at hand compared to Commodore 64.

Soon we realized that even Pascal wasn’t powerful enough. It was a high-level language, and we needed to control hardwre in very low level. It was possible to control registers, memory and interrupts in Pascal but it wasn’t meant to do that.

I switched to more powerful C language. With C I had the possibility of writing lowlevel code accessing the hardware directly. It was early nineties and I was nine years old.

This line of the project went so far that we had working software which was capable of driving straight lines with stepper motors. Finally it was all about positioning in length units compared to the earlier time-based positioning.

We used hardware interrupts to synchronise the production of pulses out of the LPT-port of the PC. Everything was controlled from the PC. The electronics were there only to amplify the signal for the motors.

It was quite fancy little system. I even wrote text-based windowing UI library for it at later time. It had menu bar at the top of the screen, dialogs, floating document windows and mouse pointer.

And the trajectory file was now real G-code, not some my own syntax. We could write the paths in CAD application and export as G-code and read it to my system.

But then we hit into major problems. I didn’t understand anything about the mathematics needed to calculate arcs, circles and other complex trajectories. You know, I was twelve years old at the time. In retrospect I would have needed the understanding of vectors and complex numbers. So this line of the project was put on hold as “good enough”. Nonetheless, it was working and we used to drill holes to PCB boards with it successfully.

Understanding of electronics

Around the time when I was at junior high school, I started to understand electronics more deeply. What was going on inside those little black boxes that are called microchips, or ICs.

It opened up totally whole new world for me. At last I knew how computers really work. What happens when I change some registers in the CPU, what are hardware interrupts, and what happens inside the motor when it is moving. Before I was only using them like the manual says.

We started working on microcontrollers. At first with PIC but then we moved to Atmel AVR family.

As we played with electronics, most of these projects had nothing to do with the CNC systems so I’ll skip few years.

Rise of the Enhanced Machine Controller

The CNC project found new way when I found out about Enhanced Machine Controller. It was just a source released by NIST and community began continuing its development.

When the LinuxCNC community took the code repository under its wings they started working on a second generation. The version 2 software was more modular and it has superior realtime system compared to the old one. This is still in use in all of our machines.

At first we used EMC to drive stepper motors just like previously. The hardware was the same, we just replaced my software with EMC. We used printer port to interface with the motor drivers and PC. It always had one significant problem: it is really slow. Also it takes huge amounts of work from the computer to calculate and form the stepper signal. It seems like a easy task but on a multitasking computer it isn’t.

To fix that problem we moved the pulse generation to a microcontroller which communicated with the PC thru the printer port. I designed the driver for EMC, the protocol, and the firmware for the AVR ATmega128 microcontroller. It worked pretty smoothly.

There were a lot of variations of that design. Different motor drivers, rotary sensors, absolute sensors, relays etc. It was really fun to learn and experiment with all those chips. And to design and create the PCB boards. Plus there still always was the PC in the system also. We had the EMC doing all trajectory calculations and the stuff that are always the same in all machines. It gave us freedom to concentrate in machine specific interfaces.

Unleashing of the PCI bus

The real breakthrouh came when we started experimenting with FPGA chips.

At first we used them as IO-chips alongside the AVR microcontroller but then at one point we got a really crazy idea: how about if we put the FPGE chip to communicate with the PCI bus directly.

It blew the whole project to new hights. We weren’t restricted by the printer port anymore. We could do anything. It was November 2006 when I started working on this idea.

It was a huge task to switch from communicating thru the printer port to PCI bus interface. I really needed to study and learn new things.

First was Linux kernel driver development. That turned out to be quite easy. There are tons of material, documentation and examples in the internet.

The second thing was more troublesome. I wanted to create the PCI interface from scratch without using any ready-made solutions. The protocols and the speed of the interface was something totally different from what I had used before. I started by reading the book PCI system architecture cover to cover couple of times. Biggest problem still was the speed and nature of the electrical layer of the interface. I had no good tools to get any measurements what happened there. And the bus is used by other pheriphereals at the same time so whenever I put wrong bit to a wrong state at a wrong time I froze the whole machine. And every time I feared I broke the thing.

I had created working PCI bus interface firmware and I could switch one LED on and off. It was really awesome.

In January 2007 the PCI card was in such a state that we used it to run real hardware for the first time.

The home-made PCB was abandoned when we got it working. It would have been too much work to do all error checking, registers, Plug’n’Play and other required things in the PCI specification. For me it was enough to see the system working.

We started to use 5I20 board from Mesanet which has Xilinx Spartan FPGA chip and PCI to local bus bridge chip by PLX. It was much easier to write the firmware to the Xilinx FPGA when I didn’t have to work directly with the PCI bus. Still I needed to know how the protocol worked, all the registers etc, but it was much easier.

This system is still in everyday use in several machines.