View Full Version : G-Code into stepper driver pulses?

08-01-2010, 11:51 PM
I'm trying to establish some techie info wrt the final leg of the CNC process/chain ....after CAD, G-Code gets generated, this G-Code in turn is fed into a CNC app (like Mach3), which carries out some maths to turn cordinate info into the pulse trains required to drive the stepper motors?

Has anyone a good linky or two which explains this CNC app-> stepper driver board in more detail?

I'm toying with the idea of learning how to do a CNC pickup winder GUI/Program (I've already built a CNC winder & use my own G-Code in conjunction with Mach 3 to drive it)..it might be a handy goal to learn more & also a bit of fun.

09-01-2010, 12:41 AM

At the end of the day all Mach3 etc do is send pulses and direction info to the stepper... for a winder presumably all you need to decide is the speed of rotation and the number of turns... If you know that one turn = 200 steps then the rest is simple math. Wind 500 turns at 10rpm = 500 x 200 = 100,000 steps at 33 steps/second. A purpose made program to do this is very simple. The only tricky bit is getting access to the parallel port under Windows... for that you will need to load a device driver that makes the raw port hardware visible to a Windows program (DLLIOPort is one such utility, I use it to drive a PIC programmer - same technique of sending controlled pulses). What programming languages do you use/know? If you want more info on how its done let me know.

09-01-2010, 09:22 AM
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_main.html#sub:G61,-G61.1,-G64:).

Hope that's useful.

09-01-2010, 09:49 AM
Good explanation tribbles. Of course acceleration will stil apply to Hank's rotational requirement. I am not sure if he has a linear arrangement controlling the wire position on the bobbin, so probably he has 2 degrees of motion whch have to be sync'd. But again that is easy to do - for each rotation of the bobbin, move the wire along 1 wire width. Winding 50swg wire (0.1mm dia I think) would ideally need about 10 steps per rev to get it neat...so a resolution of .01mm, so 2mm pitch screw on full step would be fine. The rest is simple math to work out the step rates needed per second, including acceleration and the maintenance of simple counters to know where we've got to...

In fact this would be a great candidate for a PIC based standalone controller, no PC needed, just a PIC, keypad and display, along the same lines as kwackers rotary table controller (http://www.mycncuk.com/forums/showthread.php?150-CNC-Rotary-table-lathe-head-indexing)...

09-01-2010, 09:55 AM
Ahh - I didn't realise what Hank's machine was doing (but thanks for the words!). That's probably easier - I'd even be tempted to do it in a PIC if a small controller was required.

09-01-2010, 11:55 AM
Ahh - I didn't realise what Hank's machine was doing (but thanks for the words!). That's probably easier - I'd even be tempted to do it in a PIC if a small controller was required.

Thanks very much to you both - as it goes, I have previously written a PIC program to drive a pickup winder, but it only had one stepper (the traverse motor) - a DC motor was used for the main winding motor (which had an encoder disc on it - this kept the two axis 'in sync') but that setup used one simple standalone stepper IC & all the calculations were done on a spreadsheet (eg "after X pulses from encoder disk, pulse traverse stepper") & then input to the PIC at the begiining of each winding session ....a little klunky at best!

I'd much rather have two stepper pickup winder *and* use a commercial stepper driver board & then have a nice custom pickup winder a GUI as the interface.

I'll mull this one over a little while longer!

Thanks once again.