When it comes to actual movement, no, no difference at all between 200*16 and 3200 with no multiplier. 3200 with no multiplier will mean the controller can address every single step, and so ultimate resolution is possible, but leaves the chance that the motors will stop on a microstep, rather than always stopping on a full step. I am risk averse, and don't like stopping on microsteps - I think you risk losing a step, and when I've tried it with other drivers, the chip and the motors get pretty hot and cross about it.

The polarshield runs at a fixed 8x microstepping. I really think it's the lack of current control that makes the motorshield v2 a bit jumpy. It certainly seems quite noisy and harsh - I guess the right combination of motor and voltage would get it singing sweetly, but it isn't doing it for me.

(I also couldn't get the servo lift working - did you have any luck with that?)

sn

I've got a few twitches out of the servo, and that's it. I don't have the other set of pins soldered in so can't try them, but I'm sure I tried swapping the pin assignments and didn't have any more luck. The circuit for the servos is absolutely simple, so there's almost nothing electrical to go wrong there... But the code for the servo is _also_ absolutely simple, there's almost no logic to go wrong there 🙂

I was just wondering if I had fried my motor and it was working fine for everyone else. I'll have a closer look and a better test if I get the chance. I'm a bit disinclined to sink a lot of time into this shield - it doesn't seem to be much of an improvement over v1 to be honest.

sn

I should warn that I haven't actually used the uno32 before, myself. I base the recommendation on Brian Schmalz's recommendation (Brian is the designer of the Eibot board, the easydriver, and bigeasydriver amongst other things, though I believe he is also employed by PIC/chipkit).

He's got a couple of videos of the chipkit spinning a load of motors at many kHz, so I think it would remove any CPU bottleneck. That said, it was also driving a standalone stepper driver with serial control lines. I think the bottleneck in the motorshieldv2 is the I2C bus, and the PWM system that the shield uses - I just don't think it's suitable for high-speed stepping. At least, not the kind of speed that you need to use to get 16x microstepping moving at a useful rate.

After thinking about it, I don't think running a faster board would get you faster stepping unless it also ran at a faster I2C bus - I'm not really clear how that all works though, so I could be talking out my hat.

Polarshield is basically the same as RAMPS, but with an LCD header on it (and only three channels instead of five). The microstepping size is a little harder to adjust, but otherwise they both use standard "stepstick" motor drivers, which are controlled by simple pulses to a step pin. This is the same way that easydrivers, bigeasydrivers, and _most_ other drivers are used, and it is usually bottleneck'd by the clock speed of the processor. I run the drivers on the polarshield at 8x microstepping (with a MEGA2560) and have never really wanted for speed - I can't say much more than that. RAMPS can also easily be set to 8x microstepping.

But I think you will find that you won't need such high microstepping (or microstepping at all) if you use a different driver and can tune the power to match the motor.

Also, consider using the standard interleaved (or DOUBLE, or SINGLE), at an extremely low speed (try to match the speed you're getting at the moment), and see if that helps. I kind of think it won't, but you might get a clearer idea of where your judders are coming from (step / bounce / pentip friction etc).

sn