Without looking in more detail at the Gary Liming site I can't think what GearRatio1top can be but I suggest that you set it to 1, as also the "front end gearing".

The answer is probably a lemon because my copy of Gary's code (version 2.3) already defaults to Fast.

The gear ratio settings don't effect motor speed; Gary just allows for common rotary table ratios like 90:1 and 40:1. The two main parameters that do are:

• Line 45: #define DefaultMotorSpeed 0 // zero here means fast, as in no delay
• Line 73: #define pulsewidth 2 // length of time for one step pulse

The main thing slowing the motor down is the number of microsteps per revolution, probably set to 8. Setting the motor to 4 microsteps would double the speed and halve the accuracy. Probably don't want to mess with microsteps because the accuracy of your rotary table depends on them. It's at

Line 27: #define Microsteps 8

A few things you might try:

Gary updates the display after every step in moveangle and movesteps modes, which slows the motor down. Try disabling the display by altering the movemotor() function at about line 546, to cut out a section of code with an #if defined(DO_UPDATE) and #endif block thus:

The code between #if and #endif will be ignored when the sketch is recompiled, and not having to wait while the display is altered should speed the motor up. Noticeable improvement rather than gee whizz, and of course the display is disabled.

And/or try setting Line 73 to #define pulsewidth 1

The latter might not be satisfactory because how fast the motor can spin is limited by your power supply. 48V or more if the controller can cope please. Unfortunately the motor will skip steps If the power supply can't react fast with enough amps, so there's a limit to how quickly the software can issue pulses and have the motor keep up.

Ask again if #define pulsewidth 1 performs OK with the table carrying a load because delay() can be replaced by delayMicros() to give sub-millisecond stepping, which might be worth trying. I doubt it because stepping quickly takes the motor into unreliable 'here be dragons' territory.

Dave

It is possible that the wiring is picking up electrical noise giving spurious inputs. Assuming that the switch function is "switch pulls down", i.e. puts a short to ground on the relevant Arduino pin, quite likely the pin is set for "pinmode_pullup" which activates a relatively weak internal pullup (~20k ohms) – this means the pin is a rather high impedance and more prone to picking up noise. An easy fix, IF the switch does short to ground, is to wire an external resistor the input with a lower value, 4k7 would be a good choice.

However, you may still have problems with "bouncing" of the microswitch contacts – this ought to have been fixed in the software anyway. It might cause occasional spurious increment of the indexer.