Tinkering with Gary Liming’s Stepper Motor control sketch

[GreensandsParticipant @greensands]

I have been playing around with a Type 17 stepper motor using the Gary Liming Arduino sketch running with a UNO/Type 6600 Driver but could do with some help with some fairly basic questions regarding tweaking the software. Basically I would like to know how to increase the speed of rotation by say a factor of 2 or 3. Currently the micro-stepping DIP switch is set 8 but what is the significance of 'front end gearing' and the sketch variable GearRatio1top equal to 3? Any assistance on the subject would be much appreciated.

[GreensandsParticipant @greensands]

[John HaineParticipant @johnhaine32865]

A simple thing to do is change the microstep setting from 8 to 2 or 4. You get 200 steps per rev from the "native" stepper motor and the microstepping function in the driver interpolates 8 additional steps in between so the motor will take 1600 steps for one rev, I'm not familiar with the software you mention but I would guess that "front end gearing" refers to any mechanical reduction between the motor shaft and what it's driving. If for example there was a 2:1 reduction this would increase the effective steps per rev to 3200.

Edited By John Haine on 16/08/2021 11:26:47

[John HaineParticipant @johnhaine32865]

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".

[John HaineParticipant @johnhaine32865]

Looking slightly more closely and making a wild guess, I think that originally Gary assumed that there would be a simple reduction gear ratio like 1/4, but then people were saying that their mechanics had ratios like 3/4 – so the parameter "3" would be the numerator (top) and "front end gearing" would be set to 4.

[SillyOldDufferModerator @sillyoldduffer]

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

[GreensandsParticipant @greensands]

I have been experimenting with the original circuit by adding a microswitch connected via a 2 pin plug and socket brought out to the bottom of the front panel as seen in the attached photo. The microswitch is wired in the NO state and connected across the centre tab and outer tab of the rocker switch shown mounted on the RH side of the panel as illustrated in Carl Wilson’s article in MEW No.249, Page64.

The object of the exercise is to activate the Indexer unit by a momentary closing/opening of the microswitch generated by movement of the milling machine table in place of normal hand operation of the rocker. However in practice simply plugging the microswitch into the socket results in read-out instability and the circuit fails to operate in its anticipated way. Unplugging the microswitch followed by switching the unit Off/On does however restore normal working and so I am somewhat confused as to what is going on.

I just wonder if this can be the result of some sort of capacitive loading due to the length/type of wiring used for connecting the microswitch into the circuit. I do hope there is an answer to this problem.

[John HaineParticipant @johnhaine32865]

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.

[SillyOldDufferModerator @sillyoldduffer]

The long wires are picking up mains hum and other electrical noise. Microcontroller inputs being high impedance makes them sensitive, so best to keep wiring short and shielded.

There's a good chance putting a decoupling capacitor across the wires at the arduino end will fix it. 0.1uf is popular, but any value between 0.01 and 0.22uf. Use a ceramic type because they're fast acting and good for decoupling.

Dave

[GreensandsParticipant @greensands]

Perhaps the next thing to try would be to replace the twin flex cabling with a length of screened cable which does needs to be of a certain length to provide for a practical set-up. If the problem still exists will then consider fitting a suitable resistor/capacitor as suggested above.

[GreensandsParticipant @greensands]

Would anyone be able to make the necessary amandments to Gary Liming's Step indexer program Ver 2.3 in order to change the AngleIncrement variable into a run time variable. The program default value is currently set at 5 but it would be useful to be able to make a change without having to reprogram the chip.

[Author]

Posts