Large Stepper Code does not work

Hi @will and @ralphxyz,

   Looks like your having some fun.

• The spec for the controller says the quickest rate it can cope with is in the range 13kHz to 20kHz, depending upon the mark/space ratio of the pulse fed to it. If I understand the microstep game correctly, the flick switches on the controller determine how many pulses are needed for one physical step of the motor. So setting the number of microsteps per physical step changes the maximum rotation speed... if you reduce this factor, the motor will spin faster. Producing pulses with software in the way both my and Will's program does is slowed down by the time it takes for the software instructions - this effect usually is negligible below 1kHz, but becomes increasingly noticeable as the frequency is increased above that. Other methods are possible, including using PWM outputs to genrate the pulses, but require a bit more effort to program. I have never done it, but my guess is an Arduino can be persuaded to achieve the fastest speed the controller can cope with, but may need some more effort. The fun bit may be programming an acceleration and deceleration profile if you wish to move smoothly and quickly.

• Ralph, I think you, possibly aided by your daughter, need to start  mapping out what the motor is going to be required to do. Personally, I would start with regarding the physical step size of the motor .. say 1.8 degrees if it is a 200 steps per rotation, as the basic 'unit' of travel. When you have got some numbers for that, it should be easier to choose a microstep setting.

Best wishes, Dave

Posted by: @ralphxyz FYI @davee

This should be a new thread.

I have a 8 TPI (Threads Per Inch) leadscrew on the Z axis of my lathe.

There is a 10 TPI leadscrew on my X axis.

I am going to try to match SFM (Surface Feet per Minute) to the chart on this page.

Or other similar pages on the web.

Of course for the X axis ounce I get to threading and turning I will only be moving the leadscrew

.001" - .005". so the motor will not even make a full revolution.

Math is probable my worse thing so I will be looking for help. 

All of the calculations are simple arithetic.

If you have an 8 TPI lead screw, then it takes 8 complete revolutions to move it 1" (in either direction). If your stepper driver micro stepping is set to 1 and your motor requires 200 steps per rotation then 1" of travel equals:

A) 8 revs = 1" so 1 rev = 1/8" (=.125")

200 steps/rev X 8 revolutions = 1600 steps = 1 inch so

B) 1" = 1600 steps

C) 1 step = 1/1600 inches.

From B) we can calculate that

.001" = 1600 steps/inch X .001" =1600/1000 = 1.6 steps

.005" = 1600 steps/inch X .005" = 1600/200 = 8 steps

The definition of speed is distance/time; so, if we have a turn rate of, say 20 RPM

distance = 20 revs X .125 (from A above) = 2.5 "

time = 60 seconds (one minute)

speed = 2.5" / 60 sec =.042 its (inches per second)

We can calculate the turn rate in steps as ...

(20 revs X 200 steps/rev)/(60 sec) = 4000 steps/60 sec = (appx) 66.667 steps/second.

@will I was talking about multiple other programs I have downloaded.

Bill's sketch is now working but it did not work when I first tried.

Ralph

@will Thank you so much. That is one of the best explanation I have seen.

I am going to copy it to keep as a ready reference.

Ralph

@will How would one get "(20 revs X 200 steps/rev)/(60 sec) = 4000 steps/60 sec = (appx) 66.667 steps/second." 66.667 steps

or for .001" 1.6 steps? I have thought of motorizing a rotary table but never could figure out how to control the stepper motor to get accurate °. I have seen people claim they could do 

.5° or even .25° but never explained how they did it.

Ralph

@ralphxyz 

Those calculations were based on your stepper driver being set for unit multi stepping, that is 200 steps/revolution. Try redoing the above calculations with multi stepping set to 32, i.e. using 200*32 = 6400 steps/revolution and note the improved resolution.

For example

8 revs = 1" = 8 X 6400 steps (multi stepping 32) = 51200 steps

so 1 step = 1/51200 = (appx) .00000195"

Then

.001" = 51200*.001 = 51.2 steps

At no multi stepping 360 degrees = 200 steps so 1 step = 1.8 degrees but when multi stepping is set higher, like to 32, then

360 degrees = 200*32 = 6400 steps

so 1 degree = 6400/360 = (appx) 17.78 steps

so 1 step = 360/6400 = .05625 degrees (3.375 seconds of arc)

@will So are people reporting .5° accuracy just rounding their numbers and going for close enough? So if I wanted 1° I would just do 17 steps using 32 microsteps.

It seems if I wanted to do 360 divisions the rounding would catchup and cause bigger error at the end.

This is a conversation I have wanted to have for a lot of years.

Ralph

@ralphxyz 

You have to keep the machine's capability in mind when you plan this kind of thing, because it has no capacity to do anything but what you tell it to do.

If, for instance, you rounded off the 17.78 to 18 and told it ...

int steps=0, delta=18;

for (int degrees-0;degrees<360;degrees++) {

   ... do something here

   steps = steps + delta;

}

then you would indeed wind up with an error over 80 steps which is why ...

NEVER DO LIKE THIS !!!!   -  Bad programmer - NO BISCUIT !!!

What you do instead is ...

float stepsPerDegree = 6400./360.;  // Lets computer set value as accurately as it can

int steps = 0;

for (int degrees-0;degrees<360;degrees++) {

   steps = degrees*stepsPerDegree;  // Calculate steps using degrees and factor

   ... do something here

}

This structure will allow the machine to form the conversion factor to the most precise capable and will recalculate the "steps" value as precisely as possible. The final value should be off by less than a single step.

I can't comment directly on claims of angular precision because I haven't seen any (and wouldn't put any credence on them anyway). They may, in fact, be talking about other brands or models of stepper motors.

Hi @will & @ralphxyz,

  Will is kindly providing lots of good advice.

I have a couple of comments which might be helpful at some stage, but if they are a bit confusing at the moment, don't worry about them.

Integer versus Floating point arithmetic

Computers usually deal with numbers as either 'integer' or 'floating point' ... both types have the advantages and their problems...

Integers

• The numbers you will have taught as 'whole numbers' ... -3  -2 -1  0  1  2  3 ..

• These are 'exact'
  • ... You can add, multiply and subtract them with no 'errors' creeping in.This is good for operations like moving around your work piece, because if you make a sequence of positive and negative moves (in one direction), which add up to zero, then you are exactly back at the start point
  • Divide is more tricky e.g. 8/3    is somewhere between 2 and 3, and a computer would typically say 8/3 = 2.
    • Hence you might expect (8/3)*3 to be equal to 8, but the computer could say 6

• Integer numbers on a computer usually have a fixed maximum and minimum value because the larger the magnitude of an integer, the more data bits it requires - so the programmer has to choose a size which can hold the largest magnitude
  • e.g. 16-bit integer ... range -32768..32767 
  •        32-bit integer ... range (roughly)   -2,000,000,000 .. 2000,000,000
• using integers 'risks' getting crazy results ... e.g with 16-bit integer, (32767+1) = -32768

Floating point numbers

• Numbers are (in general) 'approximate' ... it is easy to do simple arithmetic and get answers with small errors e.g 3.0 * (2.0 / 3.0) might be reported as 1.999999
  • Of course a small error is better than the integer equivalent (3*(2/3)) = 0, since 2/3 will probably be regarded as zero.
•  However,
  • Even addition and subtraction can show similar 'approximation' effects. In many circumstances the difference is negligible, but you can easily come unstuck.
  • Imagine a machine programmed to make a batch of 20 widgets. Counting in 'float' might cause it to make 21, as it the 20th one 'counted' as 19.999999, which is less than 20, and it made another one 'for luck'! This would not have happened if counting as an integer.
•  
•  The main advantage is they can deal with much larger numbers without giving 'crazy' results...
  • e.g. 32-bit floating point range is roughly -340,000,000,000,000,000,000,000,000,000,000,000,000  to 340,000,000,000,000,000,000,000,000,000,000,000,000   (compare to 32-bit integer above)

------------------------

So in applications like 'navigating' around your work area, you have (at least) two 'choices'

1. Use floating point for everything, with the hope that the 'rounding errors' are too small to make a 'real difference.  This may be true, but the analysis to determine it is true is tricky
2. Use a mixture of floating point and integer. e.g. you might use floating point to determine the number of steps in each direction for a given set of moves. At the same time use an integer calculation to actually count the number of steps for that operation. At the end of the operation, move back to the start point, using the integer counters to move to the 0, 0 position

--------------------------------------------------

Considering the 'microstepping' is a second 'art' of this kind of system. The motor itself has a fixed number of poles, and hence 'full step' positions ... maybe 200 if it is a 1.8 degree/step motor

The microstepping involves driving the magnetic fields to subdivide the angle between any two adjacent pole positions into a number of intermediate positions ... the controllers can apparently attempt to subdivide that small angle of (say) 1.8 degrees into a large number of intermediate positions .. the accuracy to which the motor rotor can achieve these intermediate positions is a dfferent matter.

However, providing the motor is not driven too quickly, this subdividing should not cause a large cumulative error as the cumulative errors should cancel to zero, every time the rotor moves to a 'pole' position.

Thus, providing your motor is not driven so quickly that it 'skips' a pole, the angle error should always be less than the 'whole' step angle. Of course, this does not include any other errors in the system, such as backlash in any gears, etc.

---------

I hope the above is understandable ... it is only my understanding of the 'physics' and 'maths' ... I have no direct experience, so there maybe a 'gotcha' or two I have overlooked.

Best wishes,

Dave

Another format is binary coded decimal numbers.

With stepper motors I just use the number of physical steps instead of degrees. You can always convert from physical steps to degrees for display purposes but the actual unit of measure can be whatever you like so why not choose the actual number of physical steps in a single rotation to measure the angular change?

@robotbuilder The problem  we were discussing is getting .78 steps.

"so 1 degree = 6400/360 = (appx) 17.78 steps"

Ralph

Hi @ralphxyz,

The problem we were discussing is getting .78 steps.

"so 1 degree = 6400/360 = (appx) 17.78 steps"

and ...

This is a conversation I have wanted to have for a lot of years.

So, in an attempt to put a little background to your requests...

The trick is to avoid, or at least minimise the effect of, the "approx 17.78 steps" type of number

Choices to consider include:

• Only work in integers ...
  • e.g. 360 degrees per rotation is not a fundamental mathematical number ... it is just a 'convenient' number that is widely recognised ...  a quick Google suggested it came from Babylonian times, and may be related to the number of days in a year, as apparently their calendar year had 360 days ... Personally, I am too young to verify this origin, but I take it as sign that I can ignore it when it is inconvenient.
  •  
  • Working in degrees may be convenient for a geometrical problem, but in your case, you need to specify the amount of movement in a straight line, along the length of the threaded rod, which does not need to consider any circular geometry.
  •  
  • So, if it takes 6400 microsteps to make one complete revolution, then use this relationship directly and pretend the 360 degrees definition never existed.
    •  
    • If 1 turn = 0.125 inches (linear movement), consider thinking in micro-inches ... 1 turn = 125000 micro-inches    
    • Then 1 microstep = (125000 / 6400) = 1250/64 = 625/32  micro-inches
    • With care "625/32" can be used in subsequent integer calculations, without rounding approximations, etc. That is, don't  replace 625/32 with 19.53125 .... keep it as 625/32 in the final calculation sum.
      • As an aside, note 1 microstep corresponds to 32/625 = 0.0512 micro-inches, or 51.2 nano-inches! How accurate do you need the calculation to be? 🤔 🤔 
  •  
• Limit the use of the approximations to situations in which errors cannot accumulate.
  • e.g. Say, the calculation says you need to move 5704.64 microsteps from the 'origin' 0 position
    • The motor is instructed to move micro 5705 steps ( (as the nearest available choice)
    • The calculation for the next move is made, knowing the motor is 5705 microsteps away from the origin
    • and so on
  • Thus the motor is always within 0.5 of a step of the 'ideal position
  •  
• Use high precision floating point numbers
  • Floating point calculations are (in general) approximate, but that does not mean they are inaccurate, merely that misusing the 'calculator' might produce an inaccurate number. There are  standardised definitions of floating point precision, e.g. 32-bit, 64-bit and 80-bit, each of which refer to the number of binary bits required to hold one number, with 32-bit commonly being associated with 'single' precision. Obviously the more bits, the higher the precision.
  •  
  • Using higher precision has downsides .. processor/software has more work to do, takes more time, more memory, may not be available and so on. Usually fine on a PC/MAC but maybe difficult/impossible on a small microcontroller, such as 'low end' Arduino.
  •  
  • A quick check of Arduino docs, shows that Arduinos generally only support 'single precision' floating point calculations, with the type 'double' being treated as 'single', unless you are using the Due, which supports double. (ref https://www.arduino.cc/reference/en/language/variables/data-types/double/)
  •  
  • The programmer's task includes understanding the effect of the precision limits. If the maximum calculation error of  your CNC router is less than 0.1 nanometre, then it should be fine, since this is less than the size of an atom.... But of course, if it was 1 mm (~1/25th inch), you may be disappointed.
  •  
  • So if you use floating point, you need to establish the likely magnitude of the errors. If they are too small to matter, problem solved .... if they could affect your result, change the method in some way.
  •  
• It's a computer .... it doesn't usually mind a few decimal places ... 😀 😀 
  • Most of us hate dealing with numbers with lots of different digits .. we tend to look at the first 2 or 3 digits, then worry about the decimal point, so we might look at  23.45678901234 and think about 23.5, as we can't really cope with the rest without a lot of effort. However, computers are just as happy remembering and calculating with the whole number, providing it fits in to the number format (single, double, etc.) . So providing we do NOT tell the computer to round the number, very often it will work with a lot more significant figures than we would ever do if forced to use pen and paper. So, whilst your concern is valid, it might be less of a problem than you think.
    • A consequence is that we sometimes find the computer calculated number has too many digits to readily understand, so we tell it to print a 'rounded' value. This is fine, provided any subsequent calculations use the original 'complicated' value, not the rounded value which has been over simplified.

So, sorry, this is a rather long and tricky discussion, but it is intended to give some idea of how to approach such problems. I am sorry if it seems abstract and tricky ... The above options should be regarded as tools, all of which can be used together as required to produce the optimal result.

Best wishes, Dave

@ralphxyz 

If I understand the problem correctly your issue is linear distance travelled per step.
So you know the required linear distance which may be in floating point numbers for accuracy.

int desiredPosition;  // in steps

int currentPosition;  // current position in steps

float linearDistance;  // accurate desired position in float

desiredPosition = int(round(linearDistance * K));  //where K is some constant
stepsToMove = currentPosition - desiredPosition;  // moves clockwise or counter clockwise depending on sign

I started talking about movement of my leadscrews (linear distance travelled per step). .001" and .005". Will was answering those question. 

But when the answers got to talking about degrees it started me wondering how a motorized Rotary Table works.

They need to turn to a exact degree.

"so 1 degree = 6400/360 = (appx) 17.78 steps" how does one account for the .78 step?

Probable somewhere in the great input I have received is the answer on what to do

it just has not sunk in yet.

Ralph

How do I mark my original question "Solved"? While the thread is continuing with some great/informative discussions my original question has been answered.

Ralph