Tips for Arduno software for Rotary Table Controllers

[rodw]

I am sure that it doesnt help that 6 degrees isnt equally divisible by the 0.36 deg /step if I change div /rotation to 1000

It will have much better accuracy as it is using floating point not integers and the numbers used are much larger, thus add to the accuracy.

But you are correct. If you want equal divisions, do it by the numbers! That's why I think it is better not to display the "of 62" when you've entered a degree.

The physical resolution of the stepper is always going to be a limitation.

But if you want to say drill a hole and want one exactly 24 degrees further around the circle, you should be able to do it (or as close as you can get subject to stepper resolution)

 

[rodw]

Just one more comment about using an electronic dividing head. We are viewing the world through a new paradigm. We immediately start thinking about the rotary table with an old world view that was around dividing controlled by dividing plates in discrete steps around a circle.

Moving to the world of electronics, we can break that paradigm and be more flexible and do different things (like pick an arbitrary angle to move). So maybe think of it in terms of:
Doing it by the numbers replicates the dividing plates.
Doing it by degrees replicates winding the rotary table handle an arbitrary amount.

However in all cases, we are constrained by the physical limitations of the number handling in the software code and by the minimum angle a stepper can move.

I wanted to totally avoid floating point maths but found I had to use it otherwise I got rounding errors when using purely integer maths. I therefore just use floating point maths when calculatiing ratios but store results as integer values as that is how the hardware is. That explains the heavy use of C casts to convert from one number type to another in places.

 

[rodw]

Just implemented the 2 changes we have discussed

In enterDegrees change the way divisions is calculated

          divisions = (long)((float) MINUTES_IN_CIRCLE / (float) angleField.value());

So now a 6 degree division will show as 60 degrees. This has no affect on the division code, just fixed the display where it said "of 62" (now says "of 60")

Changed the definition of divfField in the global definitions to use GetIntfield a different data entry routine to support arbitrary divisions by cursoring along left to right.

Form divideForm(lcd);
GetIntField divfField(divideForm, "Divisions", 1000, GETINTFIELD_READ_WRITE);

The other issue raised was difficulty in entering an angle. This was a known feature as opposed to a bug. The correct way to enter an angle has been outlined above. If you want to improve the code, contributions would be accepted. The code resides in the LCD library DegreeField.cpp
in this procedure

int DegreeField::dispatch(int event)

If you are editing a library file, the best way I've found is to use an external code editor so you can edit it directly and then compile in the Arduino IDE. Google "free code editor" and there are heaps. I use Dreamweaver but its not free.

 

[rodw]

Well I have got the Home position and a speed control done now. Need to clean up the code and double check it all before posting it up tomorrow.

I have made the code think in terms of frequency in Herz for speed control. Quite tricky because a high frequency is a short time delay. kinda the inverse
This will make it easy to set the parameters according to a data sheet.

 

[rodw]

Well,

I think this is working. I've had a few dead ends
New features:
1. Sign on Screen moved to setup so it is not in the main menu (displays for 2 seconds)
2. Arbitrary input of # divisions
3. New feature Set/Goto Home
4. New feature Set speed

I've made massive changes to achieve this so there could be bugs
The setup code has changed significantly so study the code before configuring it again to suit your hardware. TIMER_DELAY is unchanged but is now a variable.

#define STEPPER_STEPS_REV 200 // The number of steps per stepper
#define MICRO_STEPS 10        // set to 1 if not not using a microstepper driver, otherwise set to # microsteps
#define DIVIDE_RATIO 90       // The Dividing table ratio (eg 40 or 90)
#define STEPS_PER_REV STEPPER_STEPS_REV * MICRO_STEPS * DIVIDE_RATIO 
#define NUMBER_JOG_STEPS 10L  
#define MAX_STEPPER_HZ  1000 // Maximum frequency for this stepper
#define MIN_STEPPER_HZ   400 // Minimum frequency for this stepper

long TIMER_DELAY = 80;

You can see I have added changes so the stepper speed parameters are defined in Hz.

<Set Speed>
picks a percentage range between

#define MAX_STEPPER_HZ  1000 // Maximum frequency for this stepper
#define MIN_STEPPER_HZ   400 // Minimum frequency for this stepper

and increments/decrements in 5% steps

There are procedures to convert between Hz and microseconds used internally to manage the frequency.

Default speed value (TIMER_DELAY = 80) is 37.5% of the default range I have set in the defaults

long TIMER_DELAY = 80;

So when using speed control for the first time, it will be truncated to 37% and will change. I may change he way this is done so it is aligned with a 5% increment and specify the default in Hz.


<Home>
The code should take the shortest route to the home position as it tests to se if tests to see if the current position is < 180 degrees. (I hope) So it will turn clockwise or anticlockwise to get home the fastest.

The home position defaults to the starttup position so to test, use in conjunction with the jog feature.

Hope I've explained enough. I had a few unexpected compiler issues so it is possible we have a stack overflow but it seems to have settled down now.

I need to get this installed on my rotary table to debug the speed and stepper control as I am uncertain if I've got it done right

View attachment RotaryTableChuck3.zip

 

[canadianhorsepower]

Well,

I think this is working. I've had a few dead ends
New features:
1. Sign on Screen moved to setup so it is not in the main menu (displays for 2 seconds)
2. Arbitrary input of # divisions
3. New feature Set/Goto Home
4. New feature Set speed

I've made massive changes to achieve this so there could be bugs
The setup code has changed significantly so study the code before configuring it again to suit your hardware. TIMER_DELAY is unchanged but is now a variable.

#define STEPPER_STEPS_REV 200 // The number of steps per stepper
#define MICRO_STEPS 10        // set to 1 if not not using a microstepper driver, otherwise set to # microsteps
#define DIVIDE_RATIO 90       // The Dividing table ratio (eg 40 or 90)
#define STEPS_PER_REV STEPPER_STEPS_REV * MICRO_STEPS * DIVIDE_RATIO 
#define NUMBER_JOG_STEPS 10L  
#define MAX_STEPPER_HZ  1000 // Maximum frequency for this stepper
#define MIN_STEPPER_HZ   400 // Minimum frequency for this stepper
 
long TIMER_DELAY = 80;

You can see I have added changes so the stepper speed parameters are defined in Hz.

<Set Speed>
picks a percentage range between

#define MAX_STEPPER_HZ  1000 // Maximum frequency for this stepper
#define MIN_STEPPER_HZ   400 // Minimum frequency for this stepper

and increments/decrements in 5% steps

There are procedures to convert between Hz and microseconds used internally to manage the frequency.

Default speed value (TIMER_DELAY = 80) is 37.5% of the default range I have set in the defaults

long TIMER_DELAY = 80;

So when using speed control for the first time, it will be truncated to 37% and will change. I may change he way this is done so it is aligned with a 5% increment and specify the default in Hz.


<Home>
The code should take the shortest route to the home position as it tests to se if tests to see if the current position is < 180 degrees. (I hope) So it will turn clockwise or anticlockwise to get home the fastest.

The home position defaults to the starttup position so to test, use in conjunction with the jog feature.

Hope I've explained enough. I had a few unexpected compiler issues so it is possible we have a stack overflow but it seems to have settled down now.

I need to get this installed on my rotary table to debug the speed and stepper control as I am uncertain if I've got it done right

thanks for your GRATE integration to this:bow::bow:
At this point is it ready to do a straight download to the arduino board and
work cheers

Luc

 

[rodw]

thanks for your GRATE integration to this:bow::bow:
At this point is it ready to do a straight download to the arduino board and
work cheers

Luc

Luc, I think so. Testing by a few others would be great!

I don't envisage adding any more features to the program. My next job is to mount up a stepper to my rotary table so I can use it and make sure the home and speed controls work OK. I won't be doing any more to it until then.

If I did anything more, it would be to add a Setup page so the parameters could be overwritten and saved to EEPROM without recompiling. That would let you use the one controller with multiple devices.

 

[TorontoBuilder]

Luc, I think so. Testing by a few others would be great!

I don't envisage adding any more features to the program. My next job is to mount up a stepper to my rotary table so I can use it and make sure the home and speed controls work OK. I won't be doing any more to it until then.

If I did anything more, it would be to add a Setup page so the parameters could be overwritten and saved to EEPROM without recompiling. That would let you use the one controller with multiple devices.

I'll test it later tonight.... great work. Seriously. If I ever get to Oz I owe you a beer, but you'd have to come to Sidney to collect

 

[rodw]

I'll test it later tonight.... great work. Seriously. If I ever get to Oz I owe you a beer, but you'd have to come to Sidney to collect

Sounds like a plan.

I'm not that great with drawing stuff but the attached metric drawing should allow you to mount a NEMA23 stepper motor to a Vertex Rotary Table using 4 standoffs with a M5 thread at one end and a M5 hole tapped in the other. Make standoff length to suit your setup. PLate will bolt to Rotary table with M5 bolts and the stepper secured to standoffs using M5 screws.

My Weekend project.

View attachment NEMA23 to Vertex Rotary Table.PDF

 

[TorontoBuilder]

Within my given limitations i.e. no rotary table attached, v3 works for me..

I'm liking it very much.

 

[rodw]

Within my given limitations i.e. no rotary table attached, v3 works for me..

I'm liking it very much.

Cool, is it just me or does it require 2 keystrokes to exit from a procedure? Please let me know.

I have tested it with a rotary table attached and holding the stepper in position by hand and it worked. If it moved off centre, I got missing steps so I need to get it properly mounted up myself to continue.

Just one tip. When you engage and lock the worm, don't rotate it too much before locking it or it can bind. I've read this advice in a few places now, but I learnt the hard way....

 

[TorontoBuilder]

Cool, is it just me or does it require 2 keystrokes to exit from a procedure? Please let me know.

I have tested it with a rotary table attached and holding the stepper in position by hand and it worked. If it moved off centre, I got missing steps so I need to get it properly mounted up myself to continue.

Just one tip. When you engage and lock the worm, don't rotate it too much before locking it or it can bind. I've read this advice in a few places now, but I learnt the hard way....

Yes 2 keystrokes to exit procedure.

Im getting some weird issues when inputting number of divisions. The menu doesnt clear upon switching to the inout screen.

Also, getting very long lag time on the steps

 

[Scott_M]

Rod
Thanks a bunch.
I will hack my 4th axis tomorrow and check it out on my machine. I played with it on the bench and all looks good.
I'll give a full report tomorrow.

Again thanks for all your effort ! Above and beyond.

Scott

 

[rodw]

Yes 2 keystrokes to exit procedure.

Im getting some weird issues when inputting number of divisions. The menu doesnt clear upon switching to the inout screen.

Also, getting very long lag time on the steps

I've had similiar issues with that input screen. It could be my code in the class, or it could be a stack overflow. Still got 1.5k free though which seems heaps. I tried to free up space by moving some form declarations to procedures but it did not like it..

Lag time could be a config error on the time delay. I noticed your micro stepper must be slower than my Gecko As you slowed it down from my original settings to get it working. I'm using a UNO. What board have you got?

 

[TorontoBuilder]

I've had similiar issues with that input screen. It could be my code in the class, or it could be a stack overflow. Still got 1.5k free though which seems heaps. I tried to free up space by moving some form declarations to procedures but it did not like it..

Lag time could be a config error on the time delay. I noticed your micro stepper must be slower than my Gecko As you slowed it down from my original settings to get it working. I'm using a UNO. What board have you got?

I have Uno r3 compatible from sainsmart. Tomorrow I'll load the sketch on my other Uno and see if its has similar response time.

 

[rodw]

Success! Well some anyway!

I have to remake a part for my Rotary table mount as the stepper is misaligned and binding. Something moved and I lost a setup so mustn't have got it in position again. But I did get the stepper mounted well enough to do some tests.

I've seen a couple of the faults TorontoBuilder saw so I will look at that. It seems reentering the <divide #> a second time causes this.

I just had a look at the code in the LCD library and this is interesting and applies to the call to mainForm.show();

 *  Shows the form, or does nothing if the form is already on-screen.
 *
 * When the form is shown, the screen will be cleared and the currentField()
 * will be drawn.
 *
 * If the form was previously hidden, then the field that was previously
 * current will be shown again.  Call defaultField() before show() to reset
 * the form to show the first field instead.

So maybe we should be redawing the screen after a data entry procedure that does not use the form library.

It looks I also left some debugging print statements in the goHome() procedure that can be removed.

The good news is that I set the #divisions to 3 and after 3 steps of 120 degrees, I was exactly back where I started according to the Rotary table dial! Nice!

I have not checked the Go Home feature yet.

The number of steps in a single step jog needs to be a lot higher with a 90:1 stepper. If we can get the speed control sorted out, slow speed, continuous jogging should be all that's needed to position exactly.

 

[rodw]

Sorted the corrupt display. Add this

  divideForm.defaultField();

before

  divideForm.show();

Need to do this for all other forms

 

[rodw]

Well, here is a quick update which fixes a few things.
1. Deleted debug printing statements
2. Fixes corrupt screen in some procedures when selecting them again.
3. Prints messages when going to and setting home so it is more obvious what's going on.

I don't understand why we need to hit select twice to exit a procedure but nobody has complained about it.

View attachment RotaryTableChuck4.zip

 

[rodw]

Oops, missed a bug which meant degrees were wrong when dividing # in the last upload

Change the enterDivisions() code to this

void enterDivisions(void)
{
  long tmpDeg;
  float tmpSteps = (float) STEPPER_STEPS_REV * (float)MICRO_STEPS * (float)DIVIDE_RATIO;
  tmpDeg=(long)((float)MINUTES_IN_CIRCLE / (float)divisions);
  divfField.setValue(divisions);
  divideForm.defaultField();
  divideForm.show();
  while(1){
    int event = lcd.getButton();
    if(event == LCD_BUTTON_SELECT)
      break;
    if (divideForm.dispatch(event) == FORM_CHANGED) {
        if (divideForm.isCurrent(divfField)) {
          // set the number of divisions here
          divisions = divfField.value();        
          tmpDeg=(long)((float)MINUTES_IN_CIRCLE / (float)divisions);
          stepsPerDiv = (long)( tmpSteps *((float) tmpDeg/(float)MINUTES_IN_CIRCLE));
         }
    }
  }
  goDivide(tmpDeg);
}

 

[rodw]

There are still a few bugs in the divisions and angle procedures, I am working on. A few of them got introduced when I changed the configuration data #defines which interfered with the casts between data types. I'll do a bit more checking.