How does controller control motors?

Maybe I can do some reading... but since I am lazy, let me just ask people here. LOL

Let's say the extruder on my printer can move X or Y direction by 0.1 mm increment - not sure what the actual "step" is, but for the simplicity of this discussion...

And, I want to draw a diagonal line, which is of length 14.14 mm - meaning the extruder will have to travel by 10 mm on each direction.

What does the control do to achieve this? I can think of a few different ways:

1. It tells the X motor to move 0.1 mm, and tells the Y motor to move 0.1 mm, then tells the X motor to move another 0.1 mm, and so on. So, the controller will end up sending total of 200 separate instructions, hopefully in a speed fast enough for the motors will look like moving continously.

2. It tells the X motor to move 0.1 mm and the Y motor to move 0.1 mm at the same time (in one instruction). It repeats this 100 more times. Again, it does this so fast and it looks like the motors are moving the whole 10 mm continuosly.

3. It tells the X motor to move 10 mm and the Y motor to move 10 mm at the same time (in one instruction).

4. It tells the X motor to move 10 mm. And in the very next tick/cycle, it tells the Y motor to move 10 mm. The instruction cycle is so short that it would look like both motors started moving at the same time, but in reality X motor started moving hair early.

5. It tells the X motor to move 0.1 mm, and then tells the Y motor to move 0.1 mm. It repeats this process. This is very similar with #1, but the key difference is that in #1 the controller moves each motor one at a time, while in this case the controller just sends out a sequence of instructions as fast as it could, so the Y motor may have started moving 0.1 mm while the X motor has not completed its move yet. In other words, case #5 is actually more like case #4, but moving the motor in the smallest step.

6. ?


Does anyone know? My printer has two Z motors (Prusa i3), and they are actually driven by one Pololus. And these motors are smaller (shorter) than the other motors, so I guess they are not as powerful. But then again, since there are two motors I believe it's okay to have less powerful motors. Also, it may not be good idea to use regular size motors when both motors are driven by one Pololus.

I was thinking (just thinking).. what if I replace these Z motors with larger ones? Since I got more torque, I can probably increase the speed of Z move. However, I would probably need another Pololus so that each motor has its own.

Now, I am wondering... Are these Z motors still going to spin in the perfect unison? Or, will one be ever so slightly lagging behind the other one, but the delay will be so small that it can be neglected? Or, do I have a problem now that Z movement will be in zig-zag?

For the Z question, bigger motor does not always mean it is faster. Low torque motors will do fine in Z axis, as you usually cannot even drive the bigger motors to their full potential because of the limitations in stepper driver (current). If you want to use two controllers for Z, make a slave board to get instructions from the Pololu connections on your driver board, and then distribute them to each stepper controller. The instructions are digital, so you could theoretically add as many steppers as you like, in parallel.

The instructions are sent to the printer in gcode, and in gcode you can specify multiple coordinates. If you want to go from (0,0,0) to (100,100,50), just use for example "G1 X100. Y100. Z50. F3000".

The printer receives and interprets the instructions. The motors get pulsed simultaneously, as AVRs have dedicated hardware for making PWM signals. Of course the hardware gets its instructions in separate clock cycles, but it does not really matter because the CPU frequency is so high.

Thank you for the reply.

So,from the controller (i.e. RAMPS) to the hardware (motors), it really is a series of individual instructions, chopped down to the lowest movement level, but since the CPU clock is so fast in reality it's just as good as all the motors are moving simultaneously, right?

In other words, it's like case #5, which is actually what I have expected - there is no such thing as two simultaneous tasks in the digital world; it's usually two tasks are performed separately but since the separation is so small they are as if performed at the same time...

Then, I guess the controller must know how long it should/would take for the motors to perform the micro instruction that it sends out to? Otherwise, it may end up in a situation like telling a motor to spin CW 1.8 degree, which it is still in the middle of spinning CCW 1.8 degree from the previous instruction.

Or, there are some sort of feedback signal coming back from the stepper motor? Well, I don't know much about stepper motors... all I know is that it moves in steps, and there are four wires, two of which I think is for the current spinning the motor and the others carrying control signal (I'm guess here).


Anyway, about having two controllers for Z motors... when you said to add another slave board, did you mean adding another Pololu and connecting this new Pololu to the same pins/connectors which the existing Z motor Pololu are connected to?

Would adding another Pololu to my RAMPS and connecting that to one of the the motors be an option, too? There's a space to add another Pololu on my board. I guess some firmware modification may be needed with this approach, unless there already is a way to send instructions to this "unknown" motor driver - in which case gcode modification would be needed..



jkoljo Wrote:
-------------------------------------------------------
> For the Z question, bigger motor does not always
> mean it is faster. Low torque motors will do fine
> in Z axis, as you usually cannot even drive the
> bigger motors to their full potential because of
> the limitations in stepper driver (current). If
> you want to use two controllers for Z, make a
> slave board to get instructions from the Pololu
> connections on your driver board, and then
> distribute them to each stepper controller. The
> instructions are digital, so you could
> theoretically add as many steppers as you like, in
> parallel.
>
> The instructions are sent to the printer in gcode,
> and in gcode you can specify multiple coordinates.
> If you want to go from (0,0,0) to (100,100,50),
> just use for example "G1 X100. Y100. Z50. F3000".
>
> The printer receives and interprets the
> instructions. The motors get pulsed
> simultaneously, as AVRs have dedicated hardware
> for making PWM signals. Of course the hardware
> gets its instructions in separate clock cycles,
> but it does not really matter because the CPU
> frequency is so high.

It's not really sending "instructions" to the motor. It's at a lower level than that, for each single step, the uController sets a data line, (one of the pins on the chip) low and then after a short delay high or viceversa. The stepper driver uses this signal to indicate that it should move the motor and changes the output current on the coils in the motor.

In terms of speed, the GCode command specifies how fast the motor should move, and the uController will send the pulses to the driver at the requested rate.
Because you could send pulses much faster than the motor could move, there is a maximum allowed value in the firmware which limits this, and because you can't instantaneously change speed, the firmware also implements acceleration, so although you request that the move happens at 3000 mm/minute it will in fact start at a slower speed, accelerate to the requested speed if the move is long enough and decelerate at the end of the move.

---

___________________________________________________________________________

My blog [3dprinterhell.blogspot.com]