Electronic Dividing Head using the Arduino

[tjwal]

I was thinking of putting an electric brake on a rotary table/ dividing head for gear cutting. A car AC compressor has an electric clutch that might work. Unfortunately they are too pricy at the local wreckers. YMMV

 

[Captain_Obvious]

I have a few broken car AC compressors but I'm not sure if the clutches work on those. For a rotary table these would work fine, but my dividing head spindle has a 20mm bore so I can feed long bar stock through the whole thing. I suppose I could still use an AC clutch with some modifications, but for now it just seems like too much work.

 

[Captain_Obvious]

Sorry for the long post again, but even at the risk of slight thread-jacking, I'll post my progress here... or lack thereof. It's officially not funny anymore, ladies and gentlemen. Yesterday I tried to engrave a graduation on a small rotary table. I wanted to have a longer line every 10 degrees and shorter lines every one degree. So, confident that my lathe dividing head finally works, I first used used four divisions, so every 90° I drew a line on the side of the table. Great, seemed to work fine. Then I divided by 36... fail. I was visibly off the mark. I couldn't believe it.

Today I did some testing and the results are strange to say the least. Every division from 2 to 33 is spot on. from 34 to 39 they're all off. All even tens, 30, 40, 50, 60 are spot on. I didn't go through every number of divisions from 2 to 65, but I picked random divisions and tried them. Here are my results:

These are dead on:

2-33
40
43
48
50
60
64

These are off:

34-39
46
49
51
61
65

The results are consistent, so if I go back from say 51 to 40, the results do not vary. 40 is still dead on. Microstepping doesn't change anything, so no matter if I use 8 or 10 or whatever, nothing changes.I even told the software that my stepper motor had 400 steps instead of 200, no change.

I can't think of any other reason for this than a rounding "error" in the maths. Since my timing belt ratio is only 6:1, it's not enough to compensate for the error. On a rotary table with a reduction of something like 90:1 you probably wouldn't even notice this but in my system you certainly do. Am I off to a gearbox shop or can you think of another solution? Software tweak maybe? Different pulley ratio?

 

[rodw]

Are you still using my script?

What happens if you enter an angle rather than the number of divisions? (eg 10 degrees = 36 divisions)

 

[Captain_Obvious]

Hello rodw, yes I'm still using your script.

5° is off
8° is off
10° is off
20° is OK
36° is OK

These are the ones I tried so far.

 

[Foozer]

From Chuck Fellows RT program:
"laststep = round(stepsDiv * lastPosition);
nextstep = round(stepsDiv * currentPosition);
divSteps = abs(nextstep - laststep);"

Now to make simple, complicated. Best as my math challenged mind can figure, seems to recalculate each future move taking into account any error from the last move, adding a step here and there to spread the margin of error out over the whole. Say 65 divisions - 6:1 @ 400 steps - 2400 steps / 65 - 36.9 something, near a step short each move. That 65 by .9, well it's not gonna end up where it started

 

[Captain_Obvious]

I think I found the problem. It's seems the issue is mechanical, not software or electronics. My belt tensioning system just simply sucks. Still, not having a whole lot of experience in belt drive systems, I can't really figure out how I was getting such consistent results with the errors I was having.

Now if I go through the step program a few times before I start, the belt tension has time to settle and after that I get an even division. When I was testing the system I didn't do this and it seems this is why I was getting the error. Lesson learned once again. Next I will probably ditch the separate tensioner wheel and just build a mechanism that moves the stepper motor up and down, thus tensioning and loosening the belt when needed.

These are my findings so far. I'm almost willing to bet I'm wrong again, though... I think I'll finish my second dividing head to some degree next week and that one doesn't have a separate tensioner, and the belt will stay on for all eternity as far as I care. This one will also have a shorter polyurethane belt, so I hope this setup will confirm the problem with my lathe is indeed the stupid tensioner thingy.

Oh boy, where's my dunce hat again?

 

[rodw]

I think software can account for some of the error. I developed this on a 90:1 table with 18,000 steps per rev. I think your table is 1200 steps per rev.

The base unit I use is seconds of a degree so there are 1,296,000 of them in a circle. Angles are entered as degrees, minutes and seconds but internally, it is converted and stored as the number of seconds. Integer maths is used for the conversion so there is no risk of rounding errors. A division on the other hand is converted to an angle (in seconds) so there is an additional mathematical step.

In either case, the angle in seconds (gAngle in the code) is sent to goDivide where it is used to calculate the number of steps per division in this code:

 stepsPerDiv = (long)(tmpSTEPS_PER_REV *((float)gAngle/(float)MINUTES_IN_CIRCLE));
   divisions = (long)((float) MINUTES_IN_CIRCLE / (float) gAngle);

When I looked at your example for 36 divisions, I made you were moving 200 x 6 = 1200 steps per rev. which is 33.3333 steps per division. The code drops the 0.33 and give you 33.0 steps per division. So by the end of the exercise, 36 x 0.3333 = 12 stepper steps of error per revolution.

12/1200 * 360 = 3.6 degrees

so your last division should be at 356.4 degrees

So I'll take this as a bug!

What I should be doing is to accumulate the 0.3333 error and when it is >= 1.0, add one step to the number of divisions. The subtract 1 from the error so any residual error is carried forward for the next one. This would mean that every third division, I would add 1 step to that division so the missing 12 steps were spread around so they were never noticed.

I'll see if I can post an updated goDivide() procedure for you to test in the next day or so

 

[Captain_Obvious]

Excellent, thanks a lot for the effort!

I've been trying to eliminate my own goofs the whole day. I'm just trying to find the ideal settings for optimal stepper motor performance so I can be as certain as possible that I'm not losing steps. I already replaced the idler with a larger HTD pulley. The old idler was smooth and pushed the belt inwards but now the larger toothed pulley pushes it outwards. I don't understand why this would make any difference as long as the belt is at a reasonable tension but I guess it's worth a try. I also had an issue with a stubborn set screw that kept coming loose, but I got that sorted now, so I'm pretty sure the mechanical side is in order now. Yesterday's results can't be considered valid since I only noticed the set screw issue today, so that probably became a factor at some point during the test.

Today I found that no matter what microstepping and software settings I'm using I get the same results. Right now the settings are 25 microsteps, min 2000Hz max 5000Hz and these settings seem to work just fine, very smooth and quiet operation.

I have a piece of printer paper glued to a 120mm cast iron backplate on the lathe spindle and I'm using a small carbide needle on the tool holder to poke holes on the paper and checking alignment that way. I've been using a hole circle diameter of about 110-115mm which would be pretty much the largest piece I could ever have on this lathe. I set the software to 74 divisions, as I noticed this was giving me misalignment of about 0.2mm. I tried several microstepping and frequency settings, no change. The same amount of misalignment every time. Then I tried 81 divisions. Same thing, roughly the same amount of misalignment. I changed the setting to 80 divisions, perfect alignment. 60 divisions, perfect alignment. 61 divisions, about 0.2mm error. 36 divisions, perfect alignment. So yes indeed right now it seems the error is in the maths after all.

I will keep experimenting the rest of the day and I'll let you know if I find something strange (which honestly seems more than likely at this point).

 

[rodw]

If its bang on one setting, and off on another, it is most likely my bug but you should be able to calculate the error and compare your result. You should find where its bang on, the divisions will have a whole number of steps.

You could also try Chucks script as I think he moves up or down one step on alternate steps or something.

I have to think about it but I think that a better algorithm might be to decide how many divisions cause a full step of error (3 in the example) and add a an extra step every third division (for this example) so we are not using floating point any more than we need to.

 

[Captain_Obvious]

If its bang on one setting, and off on another, it is most likely my bug but you should be able to calculate the error and compare your result. You should find where its bang on, the divisions will have a whole number of steps.

You could also try Chucks script as I think he moves up or down one step on alternate steps or something.

I have to think about it but I think that a better algorithm might be to decide how many divisions cause a full step of error (3 in the example) and add a an extra step every third division (for this example) so we are not using floating point any more than we need to.

Lazy me hasn't even read the whole thread and I didn't realize Chuck had written his own script...

I tried Chuck's script and I'm not getting the error. I tried divisions 33, 74, 81 and 80. Basically ones that were giving me trouble with your script and the 80, which works in both scripts. All were bang on using Chuck's script. The only trouble was that the script kept misinterpreting keystrokes, so I assume it's a debounce issue, maybe? I was pressing the same button forward and sometimes the speed would change and sometimes it would even move backwards, but the division was still bang on every time.

I hope this helps debugging your script, as I really like it otherwise and I would prefer it for its versatility.

 

[Captain_Obvious]

I know this is starting to look like a monologue, but bear with me, this actually may be useful to others as well (I hope). I was messing around with Chuck's script and I modified it slightly to get the buttons to work reasonably well. It's not perfect, but good enough for testing.

I tested the script with 2 microsteps at first. I did a 360 division program with a hole circle diameter of about 120mm. In other words I poked a hole in the paper every one degree. Looking through an eye loupe something didn't seem right but I went through the whole 360° program and the needle lined up perfectly with the first hole. I took the paper off the backplate and had a closer look... the holes were not evenly spaced. So the steps lined up but the holes were not at every 1 degree so this would be no good for engraving a graduation for example. I jacked up the microstepping to 10 microsteps, so in my case 30000 steps per spindle revolution in the software, and now there is no visible error even under my microscope.

The red arrow in the picture shows the most obvious division error.

Also added a picture of the rotary table engraving I just finished using Chuck's script. It worked just fine.

 

[Foozer]

Chucks script is 'centered at these values: 0, 144, 329, 504, 741' Sainsmart shield buttons are voltage divided. If your buttons soldered to perboard have resistor values removed from the Sainsmart could see where the sketch might misinterpret the button press . . .
VCC-- 2K // 330 // 620 //1K // 3.3K //

 

[rodw]

Foozer and Captain_Obvious. I have revised my goDivide() procedure in an attempt to fix this bug. Please check this thread
http://www.homemodelenginemachinist.com/showthread.php?p=294834#post294834
for an updated goDivide() procedure which hopefully fixes this problem. Tye cutting and pasting it into your existing script to repalce the current buggy procedure.
Please report your findings on the other thread.

 

[Fossilbones]

http://www.liming.org/millindex/

 

[cfellows]

I think my positioning algorithm is accurate because I recalculate the position from zero (home) each time the forward or reverse button is pushed, rather than use an incremental number of motor steps. This takes care of proper rounding and always assures that you wind up at the right position.

Chuck

 

[rodw]

I think my positioning algorithm is accurate because I recalculate the position from zero (home) each time the forward or reverse button is pushed, rather than use an incremental number of motor steps. This takes care of proper rounding and always assures that you wind up at the right position.

Chuck

I think that is a good approach. What is clear is that you need a strategy to deal with possible inaccuracies due to being out a step per division due to rounding errors. This is imperceptible on hardware with a large number of steps per revolution (18,000 in my case). But on hardware with coarse resolution, it becomes noticeable. So many people have written their own sketches to drive a rotary table, often with very little knowledge of coding. That is great to see as people are making an effort to get conversant with new technology. I wonder how many of these people have made this same mistake? Lucky we are not building rocketships!

 

[rodw]

http://www.liming.org/millindex/

Hmm, I think if Captain_Obvious applied his testing procedures to this script, it would also fail at coarse resolution.

There must be many more bugs out there masked by 40:1 or 90:1 gearing ratios.

 

[Captain_Obvious]

I haven't done any proper testing with the Liming script with my new hardware, so I couldn't say for sure what the issue was. I was having so many problems with the whole setup that I really can't blame the script. I know for a fact that I had two dodgy stepper drivers, so that may have been the cause for all the issues. Right now I don't have the parts to put together another controller, and I won't take my finished control box apart unless I really really really have to. I'm afraid someone else has to do the testing. The Liming script is not bad, but I did have some button debounce issues with it. I wasn't able to find a really good setting for it, but it worked reasonably well. I did get the odd misinterpreted keystroke, but it was still OK-ish. The major issue I had was that sometimes when I pressed the forward button, the script would add another step in the program = ruined parts.

I had no issues with Chuck's script other than a few keystroke issues here and there, but I'm sure it's just a matter of tweaking the code slightly. I already got it working well enough for testing purposes. I'm using rodw's script now and it also works perfectly as far as I can tell.

I've taken some time off for a few weeks, but I'm about to build the milling machine dividing unit soon. I just need to fabricate a spindle housing and assemble it. This unit will have a 4:1 physical ratio while my lathe unit has 6:1 ratio. I'll post pictures once it's finished.

 

[rodw]

I was having so many problems with the whole setup that I really can't blame the script.

But your enquiring mind and rigorous testing did identify bugs in my script that has been out there for a number of years. I did like Limings suggestions for hardware.

The sorry fact is that about 70-80% of code is taken up with the user interface. Key bounce is always an issue. There are some debouncing libraries for the Arduino, so it would not be hard to modify a script to solve the debounce problem.