Arduino Rotary Table for Dummies

[billanygard]

I did as been told, swap tm with 1200.
BUT!
Still 1040 steps for 360 degrees

 

[Foozer]

I did as been told, swap tm with 1200.
BUT!
Still 1040 steps for 360 degrees

if your steps are 200 per rev with table ratio of 3:1, 3 revolutions of the stepper is 1 turn [360] of the table or 600 steps. So thinking you wanted to step 1200 steps is 2 turns [720] of the table . Half stepping [400] will give you 1200 at 3:1 for 1 turn.
So whats off? steps per revolution or the table ratio?

const int StepsPerRotation = ?; // Set Steps per rotation of stepper
const int TableRatio = ?; // ratio of rotary table

 

[bmac2]

Hi Olsson. I think Fooser has it. Check the settings on your stepper driver and remember to work that in for the “StepsPerRotation”

 

[bmac2]

Hello all of you!
Sometimes when you see something it says clonk in the head "That should i build".
This was such a thing.
Ordered missed components, draw a nice box and 3d printed it, hooked it up and its working.
BUT!
I use it for my 4th axels thing to my cnc router. 200steps/rot, beltgear 1:3 and it is impossible to get the controller to give the right steps. I need 1200 and get 1040. Fiddeling with numbers in the script only change between 1040 and 1440steps.

Any tips?

I know a few people around here have been asking about 3D printing a box for this project. I know Chuck (chucketn) would like to print one. Any chance you could post your STL file?

 

[bmac2]

Hi Chucketn

Here is a link to amazon. com for the box. Note it took a few weeks to get

https://www.amazon.com/gp/product/B06XSMK61Q/?tag=skimlinks_replacement-20

And here is the link for the power inlet

https://www.amazon.com/gp/product/B00ME5YAPK/?tag=skimlinks_replacement-20

And the power supply

https://www.amazon.com/gp/product/B00UHI3NGS/?tag=skimlinks_replacement-20

Mark T

This is a little off topic but hey it’s my thread. ;D
Mark I think I saw your avatar (http://www.homemodelenginemachinist.com/showthread.php?t=22722) or its cousin in the wild while we were on vacation in BC a couple of weeks ago. My wife takes pictures of the pretty things . . . I’m always looking for the rust!

 

[Foozer]

const int Multiplier = (StepsPerRotation * TableRatio)/360;
Only returns a whole number,

'member trying this script , my numbers were (400 *36)/360
for 40 steps per degree
400 steps per rev @ 36 || 27 || 18 || 9 returns whole steps

i.e. 400 36 14400 40 400 35 14000 38.8888888889 400 34 13600 37.7777777778 400 33 13200 36.6666666667 400 32 12800 35.5555555556 400 31 12400 34.4444444444 400 30 12000 33.3333333333 400 29 11600 32.2222222222 400 28 11200 31.1111111111 400 27 10800 30

The Bride loved the picture . . she wants one . .

 

[dnalot]

Hi

Mark I think I saw your avatar

Nice, thanks for sharing

Mark

 

[billanygard]

Hello again!
I was not clear enough in describing.
Steps/rev for motor = 200 set for halfsteps give 400steps/rev and with 1:3 gear need 1200 / rev.
I can see about those even numbers but dont understand yet how it rounds off in the end.
For now when ask for 360deg i get some 324 and hoping to get closer.

STL
Nema problema, would be happy if someone find them useful.
There are about 2x5hr printing time, print without cooling and with raft and support.
Let stay long on the buildplate for cooling, long things wrap easily.
I use som round 5mm alu pillars for the circuit mount and also for the two caseparts.

View attachment top.stl

View attachment bottom.stl

 

[chucketn]

Thank you for sharing your enclosure, billanygard.

 

[billanygard]

I know what I have done, but do not know what I did!

I was not satisfied about the resulution I get with my 1:3 ratio so I set down and read the script up and down up and down
as I understand what i was reading.
The worst thing that could happen if i changed something would be that is not function so I changed some rows.

032 const int Multiplier = (StepsPerRotation * TableRatio)/360; // 200*90=18000/360 = 50
to
032 float Multiplier = (StepsPerRotation * TableRatio)/3.6; // 200*90=18000/360 = 50

102 ToMove = (Degrees*Multiplier);
to
102 ToMove = (Degrees*(Multiplier/100));

109 ToMove = (Degrees*Multiplier);
to
109 ToMove = (Degrees*(Multiplier/100));

This was an huge change with just a few steps at worst eg 36x10°=1198 instead of correct 1200.

I have read a little in an "sidethread" about another solution but for now that is to heavy for me.

//Olsson

 

[chucketn]

I am printing Olsson's case for my RT controller. I have the bottom half printed, took over 9 hours. Had a problem printing the top half. The external mosfet in the heat bed circuit failed in the on condition. Luckily, I noticed the bed temp climbing and disconnected the wires to the bed. Shortly thereafter, the Y axis hung, causing many missed steps, which and caused a large level shift, ruining the print at 8 hours + . I will attempt the top half again when the replacement mosfet comes in.
For ChuckF, I can't remember now, but was your code based on Bob Pratl's code?

 

[Foozer]

Never Mind - Try it again after some sleep . .

 

[rodw]

I have read a little in an "sidethread" about another solution but for now that is to heavy for me.

//Olsson

The problem is that no matter what you do you end up with a required division that includes a fraction of a step under some circumstances and stepper motors can only move whole steps. You will get errors if your script simply calculates a fixed number of steps per division.

Imagine a rotary table doing 36 divisions around the complete circle and the required number of divisions is 100.333333333 steps per division. So if you just round this to 100 steps, by the time you get right round the circle, you have missed 36 x 0.3333 = 12 steps.

The only way to fix this is to work out a way of distributing those missing steps around the circle. In our imaginary example, if you moved 101 steps every third division, your problem is solved.

Work out how to code that and your problem will go away.

 

[Foozer]

float Multiplier = (StepsPerRotation * TableRatio)/360.00;

From: ToMove = (Degrees*Multiplier);
to: ToMove = round(Degrees * Multiplier);

Should get you close . . . At least
Serial.print("ToMove # Steps = ");
ToMove = round(Degrees * Multiplier),
Serial.println(ToMove);
Degrees = Degrees + 1;
if(Degrees==361)Degrees=0;
delay(500);
shows 360 degrees as 1200 steps . . .

 

[tjwal]

float Multiplier = (StepsPerRotation * TableRatio)/360.00;

From: ToMove = (Degrees*Multiplier);
to: ToMove = round(Degrees * Multiplier);

Should get you close . . . At least
Serial.print("ToMove # Steps = ");
ToMove = round(Degrees * Multiplier),
Serial.println(ToMove);
Degrees = Degrees + 1;
if(Degrees==361)Degrees=0;
delay(500);
shows 360 degrees as 1200 steps . . .

I’m in the process of adding a routine that will allow the steps and table ratio to be input rather than embedded in the code.

While I was going through the code I noticed the issue with “Multiplier” as well. Unless the steps and table ratio give an integer number of steps per degree the controller won’t be accurate. It likely works with most RTs but likely won’t with a timing belt pulley arrangement. There are a number of fixes for this. Changing Multipler to a float is the easiest. I’m going to test a couple things of other methods. I think one of them will also adjust for steps that have been lost through rounding. I’ll post my results and code when I’m done.

 

[rodw]

There are a number of fixes for this. Changing Multipler to a float is the easiest.

Unfortunately, this will not work becasue the float has to be converted back to an integer to determine the number of steps to move. So either you will end up truncating or incrementing the integer value. This will lead to errors if the number of steps per division does not end up being a whole number. You cannot move a fraction of a step.

Consider a mythical example that requires 36 divisions per 360 degrees and each division requires exactly 100.33 steps. to move around a circle, you will need 100.33 * 36 = 3612 steps. But truncating to 100 will result in 100 x 36 = 3600 steps meaning you will be 12 steps short at the end of a 360 degree move. This is a significant error and will be noticeable.

So you must work out a way to distribute the 12 step error across the 36 divisions. The solution is to move 100 steps per division and every third division, move 101 steps. How you code that is up to you but two alternative approaches have been documented in other threads on this forum.

 

[tjwal]

I agree, changing Multiplier to float only addresses one of the issues. It does not fix the accumulated truncation error that you describe. I’ll have to find the other threads you.

If I’m correct, my method will have less than ½ step error at each division. I’ll have to find the discussions you refer to, perhaps it’s the same solution.

In any case my original intent was to allow for steps and table ratios to be an input. At the same time I’m changing to long integers so I can use 16th steps with my 90:1 RT.

 

[rodw]

The approach I took on this thread
http://www.homemodelenginemachinist.com/showthread.php?t=25091&page=3
was to accumulate the fractional error and add a step when it was > 1.0 add another step.

Chuck Fellowes followed another approach. For the start of each division, he tracked how far around the circle he was and calculated how far around the circle he would be after the division, take the difference and move that number of steps.

Ultimately the result is identical. The adjustment algorithm depends a bit on the complete methodology you use to do your divisions.

As far as the data structure goes, using int or long will make no difference unless the number of steps moved exceeds the resolution of the data type. When I did this, I wanted to avoid the use of floats and inevitable rounding errors so I measured angles in the number of seconds of a degree using an unsigned long as there are 1,296,000 seconds in a circle. I wrote routines to input and display this value for angles in degrees, minutes and seconds but internally worked with seconds. Then when actually moving the rotary axis, I implemented a trapezoidal acceleration/deceleration algorithm to maximise torque on startup and overshoot at the end of the move. (You can't do instantaneous accelleration to maximum speed due to the laws of physics).

So what on the surface looks like a simple application becomes amazingly complex, particularly if you use interrupt driven step generation.

 

[tjwal]

Rod
I haven’t examined Chuck’s code but from your description it’s the same method as what I’m incorporating. So far it appears to be an almost trivial change to the code. I have more debug print statements than actual new code.

I’ve just completed my controller and don’t have it connected to a spindle so I can’t directly test the accuracy. The numbers look good though.

It will be a while before I build the spindle so I’ll clean up my code and post it. Perhaps someone can test it out.

I’ve downloaded your code and when I get time will examine your approach.

Cheers
John

 

[tjwal]

I have finished modifying the code so it now allows for finer microstepping and high ratio rotary tables. I've changed it to accumulate steps so there should never be more than 1/2 step error. I can't physically check this as I don't have it connected to an RT, but I've included a debug macro in the code that when enabled prints values to the serial monitor. As best I can tell the code is working. I've included the code and a text file noting the changes I have made. For installation follow the excellent instructions posted by bmac2 at the start of this thread.

View attachment Dummies_Rotary_Table_Control_2017_beta.zip