Main Site Documentation



Hello All,

It’s been a long time. How have you been?

I’m working on a CNC mill that is to be controlled by an embedded micro controller (FezDomino), thus continuing a project that I started a year ago.

The link here has the progress with the fez thus far (

I’m using the EasyStepperDriver from the tinyclr wiki and I noticed a major drawback: It cannot do more than 120 RPM on the motor as a result it’s dependency on the Thread.Sleep(1) method.

I’m writing a native CNC control program for the Fezes, based on how game programmers write their games; by using a master control loop. In this control loop timing is an issue. While game programmers can just let the program run at any frame rate that it can, I need to be able to have precise control of the stepping speeds.

I’ve figured that to do this I would have to write the program such that it calculates how long it takes to execute the control loop and then add in a variable amount of wasted time to ensure that the step commands are evenly timed. My method for doing this requires knowledge of how many nano seconds have gone by while the body of the control loop is executing.

The question is: How do you determine the number of nano seconds that have gone by during program execution?


Very cool. I look forward to see your CNC reading Gcode from micro SD card :slight_smile:

Now, CNCs and stepper motors require very accurate timing and real time response. This can be achieved using RLP. You need to write low level stepper motor drivers in RLP and then control that from C# with ease.

I would keep on using C# for everything for testing. Make sure all is functional then switch to RLP for the drivers.


I was planning to write a value to the Fez Parallel port (need documentation on that) to ensure step accuracy. Other than that, your suggestion sounds like a plan.

The goal of this project is to replace the computer and software for DIY CNCing with 1 Fez Device, software included (ironically the Mach3 software cost more than a Fez Cobra)


How about running the said command 1000 times and dividing the answer? That should give you a pretty good approximation. And instead of the thread.sleep(1), how about running an empty loop X amount of times? Working out how many times you need to run it for a certain delay.


@ Xarren, so basically trying to figure out how many cycles can be done within a specified amount of time. That has the drawback in that the GC may interfere with the execution time, and there is no way to stop that. I will, however, try it :slight_smile:


GC doesn’t effect “RLP tasks” that run in kernel mode.


@ Gus, Really! hum that’s good to know :smiley: Technically that would be true, since the GC only cleans up what it can manage.

Note: I got a new driver yesterday.


Video of the new driver in operation as well as further testing on the program.

I just relized that it’s going to take 28 pins to connect the 4 motors; going have to switch to the rhino.


Very cool … I love the “what is that smell” comment


Why is that? Each motor will require a Step and Direction line to the driver. What are the other 24 wires for?


There are also at least 3 pins to set the step size


There are 7 pins per driver: Step, Direction, Sleep, Enable, Mode1 2 and 3. 7 x 4 = 28

Sleep puts the entire driver into low power mode, while enable enables voltage to the FETs

Further, I need 2 more pins for the limit switches per axis; and there are 4 of them. X1, X2, Y and Z for a total of 6 plus 1 for ground = 7

So the minimum pin count is 35, which is more pins than the Domino (and Adrunio) have. In all the pin count confusion only the Step Pins have to be in lock step; and there are 4 of them. I hope to achieve this via the new parallel port feature.


ParallelPort will not help you. All it does is pushes a byte on 8 pins at the same time. You will need Panda, Panda II or use a shift register(s) with Domino.


Correct, and I only need the 4 Step pins to change at the same time. All the other pins such as direction, enable, sleep and mode select don’t need to be synced. That’s the beauty of using the Parallel Port.


Ah right, you are aiming to use the ParallelPort feature to do the syncing, not to magically increase your pin count, as Architect obviously read into your statement, like i did :slight_smile:


:slight_smile: Yea, sometimes my explanations aren’t that coherent.

Another thing. The Fez Pins have Pull up and Pull down resistors on them, so that when you use them as input pins you can keep the default state as either high or low. Since it has the pull up resistor in it already that means that you don’t need any additional external components other than a switch connected to ground to send the pin low.

Is this correct?


pull up and pull down settings on input pins work as you expect. Set pullup mode and then connect to a switch that goes to GND, all good.


Ok, so that part’s clear. Now then, is it possible that pulling one pin to ground could cause them all to go low? Kinda like a brown out?


are you asking because you are seeing that, or just to be sure :slight_smile:

Usual experience should be that they’re totally independent. Brown out should not happen unless you’re severely power depleted


I’m trying to explain a phenomonon I’m seeing. It appears that when I push 1 button, both of them appear to get pushed. However the ZX-01 Switch by inex works flawlessly. I’ll do some more tests.