As Irving says, it's a matter of knowing how far the system will travel for each step of a stepper motor, but there are some other little bits you need. I'm not sure to what level you're at, so just in case, I'll start fairly basic (also in case anyone else joins in).

A stepper motor driver will use two primary signals - "step" and "direction".

- Direction says whether it's clockwise or anticlockwise - so something like 0V = clockwise, 5V = anticlockwise (but it could easily be the other way around).
- Step will pulse each time the stepper needs to move onto the next step. It's normally "edge triggered", which means that the step pulse needs to either rise from 0V to 5V (rising edge), or fall from 5V to 0V (falling edge).

Note that it doesn't necessarily need to be 5V.

In the G-code interpreter, you'd know where you currently are, and where you need to be. For a one-dimensional movement, it's fairly simple. I'll assume that the stepper motors move 0.01mm each step for this.

If you were at (0, 0, 0), and you wanted to move to (10, 0, 0), then it's +10mm in the X-axis. This needs 10/0.01 pulses, or 1000 pulses. So the controller would set the direction to clockwise/anticlockwise (depending on what a positive movement is), and then feed it 1000 pulses.

This is conceptually fairly easy - except you need to take three things into consideration: acceleration, feed rate (maximum speed) and deceleration.

If the feed rate is 0.6m/min (100mm/sec), then in theory it would send those 1000 pulses in 0.1 seconds (10KHz). However, the machine generally wants to be accelerated up to that speed, and decelerated towards the end - otherwise it will either stall, jump or wobble about a bit (my first implementation didn't do acceleration, and I saw all three).

So, the first few pulses would start off slowly, and then speed up to get to the feed rate. But then it would slow down the rate of pulses towards the end so that the stop isn't abrupt.

This means that the overall time to move that will be longer - how much longer depends on what rate of acceleration/deceleration your machine can cope with, and that would depend on the torque of the motor, and the physical construction.

If you wanted to get into moving in more dimensions, then it becomes more complex.

If you were moving from (0, 0, 0) to (10, 5, 8), then the X-axis moves 1000 pulses, the Y-axis 500 and the Z-axis 800. In order to make it linear, you would need to send those pulses during the same time period.

So the X-axis would be 10KHz, the Y-axis 5KHz and the Z-axis 8KHz.

However, you also need to apply acceleration/deceleration to each of these, and also the overall feed rate. This means that there's a bit more maths to do. The maths itself isn't terribly difficult; just a lot of it.

You can also do some optimisation - for example, if you were drawing a path from (0, 0, 0) to (10, 0, 0) to (20, 1, 0), then you don't need to decelerate much as you get to (10, 0, 0), because the next location is in a similar direction. In G-code, you can even specify tightness of such steps - EMC2, in its default state, will make a 90 degree change more of a curve (this caught me out a few times). I use G61 to disable this in EMC2 (http://linuxcnc.org/docs/html/gcode_...1,-G61.1,-G64:).

Hope that's useful.