How EMC2 works, I think.
07 Jan 2011 13:31 - 08 Jan 2011 18:18 #6511
by chiefgeek
How EMC2 works, I think. was created by chiefgeek
I spent come time over xmas break tinkering with EMC2 and this is the short version of what I've learned.
Basic Architecture and Timing:
Using a PC to control a CNC machine is really overkill. Any modern Pentium chip has the computing power control a zillion axis machine. The challenge is to focus the CPU's efforts on what we want it to do (read g-code files, plan tool trajectories, and send control signals to the motor drives). Time is the key factor. If we just wanted to move our machines, cutting an inch or two a minute, almost any software and hardware will work. The problem is we'd all be bored to death waiting for parts to be finished.
Time is the key factor. The CNC controller has to read the g-code files, calculate what motions are needed by which axis motors, actually command the motors, and make sure the motors are actually getting there. The Pentium chip can do it, but without proper software planning, it will be too distracted by other things like talking to the network and refreshing the display.
The most basic thing the CPU does is run the operating system, which in this case is the Ubuntu flavor of linux. The problem is that all of the operating systems that I've worked with don't allow programs to run routines on a very fast, precise time schedule. Getting a program to respond tens of times per second is easy, but CNC machines need operations to happen hundreds or thousands of times per second, every second, no matter what.
To solve this timing problem, the version of Ubuntu/linux on the EMC2 liveCD has been tuned up with some black magic called "real-time kernel". The real-time kernel can grab control of the CPU thousands of times per second on a precise schedule, putting linux on hold until the real-time routines are finished. I have no idea how this real time thing works, but EMC2 isolates us from needing to know how and I've decided to trust that the people who made it are way smarter than me.
Some events, like reading encoder positions (if you have any) and outputting motion commands to the motor drives must be executed at an extraordinary speed, something like 20,000 times a second (50 nanoseconds). Other events like trajectory planning and closing servo loops must happen fast, but not that fast, often 1,000 times a second (1 millisecond) seems to be a favorite speed.
EMC handles this difference by creating 2 "threads" for the real-time kernel to run. A "thread" is a list of software routines that are executed before the CPU is turned back over to linux. By default EMC2 creates 2 real-time threads, the base thread and the servo thread.
The base thread is the fast one so I'm running that one with a period of 0.000,000,050 seconds (50 nanosec) on my 10 year old Dell 1GHz Pentium PC. Since I'm using the parallel port for connection to the outside world that means that every 50 nanosec. EMC2 inspects the inputs and sets the outputs. If an input pulses faster than the base thread period, it might turn on and off in between inspections and will be missed. Fortunately, it isn't easy to make anything happen at that speed in the real world so I'm blissfully ignorant of any problems with this plan.
The servo thread is the slower one that I'm running with a period of 0.001 second (1 millisec). This where the motion planing and servo loop closure are happening. This "lower" speed thread is fast enough because even the fastest CNC machines don't move very far in 1 msec. Doing motion planning and perhaps course correction at this rate still keeps the cutter from going off course in any measurable way.
The final breakdown of timing works like this:
- Base Thread, super fast cycle time, doesn't do any deep thinking, just monitor inputs and sending output signals
- Servo Thread, g-code interpretation, trajectory planning, and servo loop closure, i.e. all of the hard math.
- the user interface/display events as well as disk reads happen in "linux-time", which is the processors spare time and is still much quicker than I can see by eye.
Picture 1 is how I see the timing of EMC/real-time kernel/linux working. This is horribly out of scale, but you get the idea.
Making stuff move, intentionally
My machine will be regular 3 axis gantry style router. Since I only have one "real" stepper motor and driver combination the other two axis will have to be built up from salvaged parts. Also, since I didn't want to blow up my only PC/EMC-to-real world interface, the parallel port, I added opto isolation between the parallel port and the rest of the larger electrical world.
There are many other cards and interfaces that can be added to the PC to provide addition, faster, smarter inputs and outputs (I/O), but since my goals are modest and most every PC has one, I'm sticking to the parallel port.
Parallel port interface
I learned the basics of working with the parallel port from the EMC manuals and how to opto-isolate the PC from www.pminmo.com and this page in particular: pminmo.com/4axisopto/4axisDIYopto.htm
I didn't buy this board, I just stole the schematic. There is nothing wrong with the board, but I didn't like being locked into step/direction style drives and I wanted to isolate my PC's input pins as well. Finally, this board gets power for the PC side of the optos from a USB cable. There is nothing wrong with this plan, but I'm getting my PC side 5v power directly from a spare hard drive connector in the PC.
The goal of the opto-isolated parallel port interface circuitry is to create an electrical wall around my PC. If you don't know what opto-isolators are, just think of an LED and photocell facing each other inside a microchip package. The LED is wired to one set of electronics and the photocell is wired to the other. There are no electrical connections between the two sides, the only thing that crosses between are the photons. I think a lightning strike will kill everything on both sides, but "normal" stuff like my wiring mistakes will only kill one side and the opto chip. The other side of the chip will be fine.
An important detail is that you can't use any other power supply for the PC side of the optos, you have to use the same 5v and 0v circuits that power your PC's motherboard. Hence my obsession with opto isolation.
After buying a half a dozen HCPL2630 dual channel high speed opto isolation chips, the tinkering began. As it turns out, this is pretty straight forward.
The PC's 25 pin parallel port has 17 pins that do useful things, the other 8 are just connections to PC ground. Of the 17 useful pins, 4 are outputs, 5 are inputs, and 8 can be configured as a group to be either inputs or outputs. By default, the group of 8 are set as outputs and that is the only way I've used them. So, I have 12 outputs and 5 inputs available, all told. Picture 2 is what I've printed and hung on the wall to remind me which pins are what. Don't worry about the names like D0 and S4, just think of the yellow pins as outputs, and the cyan pins as inputs.
Picture 3 is my little rig to get the parallel port conncected to my prototyping board without alot of annoying soldering. The DB25 to ribbon cable is from an old pc that had a 25 pin serial port installed in a card slot hole. The 0.1" IDC connector to breadboard connector is one I've soldered together from a 2x13 pin header and 2 1x13 pin 90 degree pin headers.
Outputs: The way the parallel port output pins seem to work electrically is that when the pin is commanded to be "off" the pin won't conduct any current and will likely drift up to 5 volts. When the pin is commanded "on" the PC connects the pin to ground and will certainly show nearly 0 volts relative to PC ground.
One annoying thing is that the PC must have, what I guess are, tiny transistors on the output pins because they can only flow a few milliamps of current before the voltage drop between the pin and ground starts to rise quickly. This is where the HCPL2630 chips are handy, they require very little current flow to signal an "on".
Like the PMinMO schematic shows, the positive side of the HCPL2630 opto LEDs (pins 1 and 4) is connected to PC5v (5 volt power from the PC itself) and the negative side of the opto LED (pins 2 and 3) is connected to the parallel port output pin via a current limiting resistor. I've always used 470 ohm resistors and life has been good. When EMC commands the output pin "on", current flows through the parallel port pin to ground, and in the end, the output side of the opto chip energizes. Yeay. Pictures 4 and 5 show my generic output pin schematic and my breadboard wiring. Best I can tell, the reason we need the 2.2 kohm pull up resistor is to ensure that when the output turns off, the opto's LED goes out immediately.
Inputs: Since I didn't want a wiring mistake to blow up my PC motherboard, I tinkered around with the the parallel port inputs so I could use an opto isolator between them and the outside world.
When naked, the input pins will measure 4 or 5 volts compared to PC0v (PC ground). When left naked or pulled up to 5v via a resistor (I always use 1 kohm), the PC will recognize this as "high" or "off". If we short the pin to PC0v, the PC sees this as "low" or "on".
So, if we connect the parallel port input pin to the "output" pin of the HCPL2630 (pins 6 or 7) the input pin will stay near 5v until the opto is energized. When it is, the input pin will be shorted to ground.
I don't think it matters much which opto chip you use but the HCPL2630s work (when oriented the right way). I had some ILQ2 chips and found out they work too, although they don't switch as fast as the HCPLs but for things like home and limit switches or touch probes, I can't believe the few microsecond speed difference matters. Perhaps if your using an encoder on your spindle the pulses might be so fast that the ILQ2 start getting lost.
Picture 6 and 7 shows my generic input pin schematic and my prototype board setup. In my system, this is as far as power and signals to/from the PC go, everything on the other side of the optos are powered by other things. So far I've blown up a couple of opto chips, but my PC remains unaware of my mistakes.
Control: How EMC reads and writes to the parallel port pins, I don't know, but clearly EMC can do this very, very quickly. I think the only portions of EMC that can read the inputs and set the outputs directly are executed in the 2 real time threads and usually only from the super fast base thread.
We'll be able to setup EMC so we can push a button on the screen and turn output pin #1 on to turn the spindle on but this isn't a direct software connection, there is a software layer in between. EMC insulates us from the gory details of working with the PC hardware with this thing called HAL, the Hardware Abstraction Layer. I've just taken the connection between the HAL and the hardware pins as black magic that works.
The rest of the electronic hardware is not defined yet but now we have a robust, safe, and high performance interface between the PC and the outside world. More specifically, I've described how I understand the
... not done yet ...
Basic Architecture and Timing:
Using a PC to control a CNC machine is really overkill. Any modern Pentium chip has the computing power control a zillion axis machine. The challenge is to focus the CPU's efforts on what we want it to do (read g-code files, plan tool trajectories, and send control signals to the motor drives). Time is the key factor. If we just wanted to move our machines, cutting an inch or two a minute, almost any software and hardware will work. The problem is we'd all be bored to death waiting for parts to be finished.
Time is the key factor. The CNC controller has to read the g-code files, calculate what motions are needed by which axis motors, actually command the motors, and make sure the motors are actually getting there. The Pentium chip can do it, but without proper software planning, it will be too distracted by other things like talking to the network and refreshing the display.
The most basic thing the CPU does is run the operating system, which in this case is the Ubuntu flavor of linux. The problem is that all of the operating systems that I've worked with don't allow programs to run routines on a very fast, precise time schedule. Getting a program to respond tens of times per second is easy, but CNC machines need operations to happen hundreds or thousands of times per second, every second, no matter what.
To solve this timing problem, the version of Ubuntu/linux on the EMC2 liveCD has been tuned up with some black magic called "real-time kernel". The real-time kernel can grab control of the CPU thousands of times per second on a precise schedule, putting linux on hold until the real-time routines are finished. I have no idea how this real time thing works, but EMC2 isolates us from needing to know how and I've decided to trust that the people who made it are way smarter than me.
Some events, like reading encoder positions (if you have any) and outputting motion commands to the motor drives must be executed at an extraordinary speed, something like 20,000 times a second (50 nanoseconds). Other events like trajectory planning and closing servo loops must happen fast, but not that fast, often 1,000 times a second (1 millisecond) seems to be a favorite speed.
EMC handles this difference by creating 2 "threads" for the real-time kernel to run. A "thread" is a list of software routines that are executed before the CPU is turned back over to linux. By default EMC2 creates 2 real-time threads, the base thread and the servo thread.
The base thread is the fast one so I'm running that one with a period of 0.000,000,050 seconds (50 nanosec) on my 10 year old Dell 1GHz Pentium PC. Since I'm using the parallel port for connection to the outside world that means that every 50 nanosec. EMC2 inspects the inputs and sets the outputs. If an input pulses faster than the base thread period, it might turn on and off in between inspections and will be missed. Fortunately, it isn't easy to make anything happen at that speed in the real world so I'm blissfully ignorant of any problems with this plan.
The servo thread is the slower one that I'm running with a period of 0.001 second (1 millisec). This where the motion planing and servo loop closure are happening. This "lower" speed thread is fast enough because even the fastest CNC machines don't move very far in 1 msec. Doing motion planning and perhaps course correction at this rate still keeps the cutter from going off course in any measurable way.
The final breakdown of timing works like this:
- Base Thread, super fast cycle time, doesn't do any deep thinking, just monitor inputs and sending output signals
- Servo Thread, g-code interpretation, trajectory planning, and servo loop closure, i.e. all of the hard math.
- the user interface/display events as well as disk reads happen in "linux-time", which is the processors spare time and is still much quicker than I can see by eye.
Picture 1 is how I see the timing of EMC/real-time kernel/linux working. This is horribly out of scale, but you get the idea.
Making stuff move, intentionally
My machine will be regular 3 axis gantry style router. Since I only have one "real" stepper motor and driver combination the other two axis will have to be built up from salvaged parts. Also, since I didn't want to blow up my only PC/EMC-to-real world interface, the parallel port, I added opto isolation between the parallel port and the rest of the larger electrical world.
There are many other cards and interfaces that can be added to the PC to provide addition, faster, smarter inputs and outputs (I/O), but since my goals are modest and most every PC has one, I'm sticking to the parallel port.
Parallel port interface
I learned the basics of working with the parallel port from the EMC manuals and how to opto-isolate the PC from www.pminmo.com and this page in particular: pminmo.com/4axisopto/4axisDIYopto.htm
I didn't buy this board, I just stole the schematic. There is nothing wrong with the board, but I didn't like being locked into step/direction style drives and I wanted to isolate my PC's input pins as well. Finally, this board gets power for the PC side of the optos from a USB cable. There is nothing wrong with this plan, but I'm getting my PC side 5v power directly from a spare hard drive connector in the PC.
The goal of the opto-isolated parallel port interface circuitry is to create an electrical wall around my PC. If you don't know what opto-isolators are, just think of an LED and photocell facing each other inside a microchip package. The LED is wired to one set of electronics and the photocell is wired to the other. There are no electrical connections between the two sides, the only thing that crosses between are the photons. I think a lightning strike will kill everything on both sides, but "normal" stuff like my wiring mistakes will only kill one side and the opto chip. The other side of the chip will be fine.
An important detail is that you can't use any other power supply for the PC side of the optos, you have to use the same 5v and 0v circuits that power your PC's motherboard. Hence my obsession with opto isolation.
After buying a half a dozen HCPL2630 dual channel high speed opto isolation chips, the tinkering began. As it turns out, this is pretty straight forward.
The PC's 25 pin parallel port has 17 pins that do useful things, the other 8 are just connections to PC ground. Of the 17 useful pins, 4 are outputs, 5 are inputs, and 8 can be configured as a group to be either inputs or outputs. By default, the group of 8 are set as outputs and that is the only way I've used them. So, I have 12 outputs and 5 inputs available, all told. Picture 2 is what I've printed and hung on the wall to remind me which pins are what. Don't worry about the names like D0 and S4, just think of the yellow pins as outputs, and the cyan pins as inputs.
Picture 3 is my little rig to get the parallel port conncected to my prototyping board without alot of annoying soldering. The DB25 to ribbon cable is from an old pc that had a 25 pin serial port installed in a card slot hole. The 0.1" IDC connector to breadboard connector is one I've soldered together from a 2x13 pin header and 2 1x13 pin 90 degree pin headers.
Outputs: The way the parallel port output pins seem to work electrically is that when the pin is commanded to be "off" the pin won't conduct any current and will likely drift up to 5 volts. When the pin is commanded "on" the PC connects the pin to ground and will certainly show nearly 0 volts relative to PC ground.
One annoying thing is that the PC must have, what I guess are, tiny transistors on the output pins because they can only flow a few milliamps of current before the voltage drop between the pin and ground starts to rise quickly. This is where the HCPL2630 chips are handy, they require very little current flow to signal an "on".
Like the PMinMO schematic shows, the positive side of the HCPL2630 opto LEDs (pins 1 and 4) is connected to PC5v (5 volt power from the PC itself) and the negative side of the opto LED (pins 2 and 3) is connected to the parallel port output pin via a current limiting resistor. I've always used 470 ohm resistors and life has been good. When EMC commands the output pin "on", current flows through the parallel port pin to ground, and in the end, the output side of the opto chip energizes. Yeay. Pictures 4 and 5 show my generic output pin schematic and my breadboard wiring. Best I can tell, the reason we need the 2.2 kohm pull up resistor is to ensure that when the output turns off, the opto's LED goes out immediately.
Inputs: Since I didn't want a wiring mistake to blow up my PC motherboard, I tinkered around with the the parallel port inputs so I could use an opto isolator between them and the outside world.
When naked, the input pins will measure 4 or 5 volts compared to PC0v (PC ground). When left naked or pulled up to 5v via a resistor (I always use 1 kohm), the PC will recognize this as "high" or "off". If we short the pin to PC0v, the PC sees this as "low" or "on".
So, if we connect the parallel port input pin to the "output" pin of the HCPL2630 (pins 6 or 7) the input pin will stay near 5v until the opto is energized. When it is, the input pin will be shorted to ground.
I don't think it matters much which opto chip you use but the HCPL2630s work (when oriented the right way). I had some ILQ2 chips and found out they work too, although they don't switch as fast as the HCPLs but for things like home and limit switches or touch probes, I can't believe the few microsecond speed difference matters. Perhaps if your using an encoder on your spindle the pulses might be so fast that the ILQ2 start getting lost.
Picture 6 and 7 shows my generic input pin schematic and my prototype board setup. In my system, this is as far as power and signals to/from the PC go, everything on the other side of the optos are powered by other things. So far I've blown up a couple of opto chips, but my PC remains unaware of my mistakes.
Control: How EMC reads and writes to the parallel port pins, I don't know, but clearly EMC can do this very, very quickly. I think the only portions of EMC that can read the inputs and set the outputs directly are executed in the 2 real time threads and usually only from the super fast base thread.
We'll be able to setup EMC so we can push a button on the screen and turn output pin #1 on to turn the spindle on but this isn't a direct software connection, there is a software layer in between. EMC insulates us from the gory details of working with the PC hardware with this thing called HAL, the Hardware Abstraction Layer. I've just taken the connection between the HAL and the hardware pins as black magic that works.
The rest of the electronic hardware is not defined yet but now we have a robust, safe, and high performance interface between the PC and the outside world. More specifically, I've described how I understand the
... not done yet ...
Please Log in or Create an account to join the conversation.
Moderators: HansU
Time to create page: 0.100 seconds