Arduino Rotary Table for Dummies

[tjwal]

I put it back to the original 400 and 36 and got a good scope reading. I did set the driver to half step and then hooked it up and it worked. I need to change the ratio to 72 and see if it will still works?

Thanks,

Jeff K.

The version I posted in message #80 uses long integers so it will handle micro-stepping up to where steps * table ratio > 2 million.

My code does rely on the compiler to take care of the conversion rodw refers to. I plan on fixing that but am still waiting on parts for my spindle.
IIRC there are either 1000 or 500 steps per second so a a setup with a large Multiplier will take several minutes per rotation.

 

[jkcab]

That is pretty funny! I was coming here to ask that question. I read Rods reply which was a bit over my head so I did some research. I was wondering if I would be able to use long integers? I am not sure I understand about the compiler conversion though? I guess I need to do more reading.

Thanks,

Jeff K.

 

[Cogsy]

I am not sure I understand about the compiler conversion though?

Type conversions are when a variable type is changed to a different type. For example an integer is a whole number (1, 2, 3, etc.) and a float is a floating point number (basically a decimal 1.23, 10.5, etc.) and they are different things. Now if you let the compiler decide which type you wanted to use it can have unwanted consequences. For example, using floats, 3.0 divided by 2.0 gives a result of 1.5 as a float. If we mix our types though, and divide a float of 3.0 by an integer of 2, without specifying what we want the answer in, we will still most likely get a float of 1.5 but it's not guaranteed and is decided by the compiler - the answer may well be given as exactly 1.

What about if we don't mix types and divide the integer 3 by the integer 2? The result is the integer 1, so 3/2 = 1!! This is how integer division works, where remainders are discarded. In this example, if we let the compiler decide the type of the result, it will return an integer of 1, rather than a float of 1.5 (most likely anyway). From our example above, 3.0/2 is possibly going to return an integer of 1 as well, even though at first glance it looks like we are performing float division rather than integer division. So because of all this potential for problems, we must make sure we don't have any ambiguity by either not mixing variable types, or specifying the types used for calculations and results (it's called type casting).

Lastly, if we take a returned value (let's say a float of 2.99) and attempt to use it where the program is expecting a different type (we'll say an integer) the compiler will do the typecasting for us and likely convert the float from 2.99 to an integer of 2, so we just lost over 30% of the value of our variable. You can see how many problems can arise from this.

When a program is written with typecasting issues like this, it may function perfectly due to the values being used (eg 10/2 = 5, etc.) but then small changes are made, such as needing a ratio change from 10/2 to 11/2 using integer values, and we hit conversion issues.

This was supposed to be a quick explanation but I'm not sure I succeeded...let me know if it's not clear.

 

[rodw]

I think Cogsy has given a fairly good explanation of consequences of getting types wrong. The term is not "type conversion" but "type cast".

eg :

float f:
int i = 13:
f = ((float) i /2.0); // adding brackets around stuff like this is always a good idea.

Mixing types should generate a warning at compile time. You should treat every warning as an error and try and work out why they are happening and change your code to eliminate the warnings totally.

C is very tightly integrated to the CPU and its seen iterations from 8 bit, 16 bit, 32 bit and 64 bit processors so today we can manipulate larger data types than we could and it is quite possible that an int on one CPU is a different size on another.

Now try changing the above to
f = i / 2;
and see what value ends up in f and if you get a compiler warning.

 

[jkcab]

Thanks Guys, That was a great explanation and very easy to follow. Rod's sketch is working for me because the only change I made was to double the ratio for the gearing. His was 36 and mine is 72. I am going to do some more reading and attempt some changes on my own. I will try tjwal's sketch from post #80 also and see how that goes. I will report my results after.

Thanks again for taking the time to explain. I find the tutorials to be a bit confusing. They do not take the time to explain the nomenclature.

Jeff K.

 

[tjwal]

I've quickly gone through the sketch I posted in message #80.
I found 3 instances where there were type conversions that depended on the compiler to resolve. The compiler with Arduino IDE 1.8.2 does resolve these correctly however there is no guarantee that another compiler would do so.
line 152 should be ToMove=(long)((bob/360.0) *(float)( Multiplier + 0.5 - cumSteps));
line 164 should be ToMove=(long)((float)(cumSteps+0.5 - (bob * Multiplier)/360.0));
and line 251 should be Degrees = (float)360/num;

I haven't tested these changes other than making sure the code compiles. When I have an opportunity to do a full test I will re upload it.

 

[jkcab]

tjwal,

In the beginning of your sketch you have user defined variables. I used pin assignments from Rod's original sketch. So I changed those and also the ones for the key pad to what Rod had for rows and columns. I then downloaded the sketch but the key pad was not responsive. What might I be doing incorrectly?

Jeff K.

 

[tjwal]

Without looking at Rods sketch I imagine that my sketch is using one the pins for something else. First thing to do though is test the keypad with his assignments. I'm attaching a short sketch for testing the keypad. It uses the same pin assignments as my indexer sketch. Make your changes to it and see if the keypad works.

View attachment keypad_test.zip

 

[tjwal]

Can you point me to Rod's sketch that you are using? The one I found doesn't use a keypad.

Thanks
John

 

[jkcab]

John,

I,m sorry I was referring to Bob's sketch in this tutorial!

I also made the changes you listed and I got this error for line 164 change "Long was not declared in this scope"?

Thanks for your patience,

Jeff

 

[tjwal]

John,

I,m sorry I was referring to Bob's sketch in this tutorial!

I also made the changes you listed and I got this error for line 164 change "Long was not declared in this scope"?

Thanks for your patience,

Jeff

is "long" all lower case?

I didn't make many changes to the keypad input part of Bob's code, but I do recall having a bit of difficulty getting my keypad to work. As I recall Bob's original keypad was 3x4 and the column-row pinout seemed to be reverse of what mine is. I wrote the keypad_test sketch so I could figure out what was going on. When I pressed the 1 key the sketch was detecting the keypress but reporting a different result to the serial monitor. Then it was just a matter of adjusting the pin assignments to get it to work.

 

[Foozer]

Code from post 17 Arduino_Rotary_Table Rows 11,10,9,8 Col 7,6,5,4
... from post 80 Dummies_Rotary_Table Rows 9,10,11,12 Col 5,6,7,8

Tested 4x4 keypad
byte rowPins[ROWS] = {9,10,11,12};
byte colPins[COLS] = {5,6,7,8};

Reports correct button pushes . .

 

[jkcab]

John,

I typed long with an upper case L and am assuming we are case sensitive? As for the keypad pin out fozzer's description is accurate. I renumbered your sketch to match Bob's as I had already wired it and it was working correctly under Bob's sketch. When trying yours with the numbers changed I got no response to the keypad at all. I then uploaded Bob;s sketch back in and all worked. I will need to take another look to make sure it was typed correctly?

Jeff

 

[Foozer]

While watching Rick & Morty played around with the sketch
Sketch from post 80 has listed

const int stp = 8; // connect pin D8 to step
const int dir = 9;

8 & 9 are used by the keypad, haven't looked thru all the post to see if that was caught, changed them to 3 & 4
Also and this may just be the keypad library on my machine, changed all instances of 'Keypad kpd' to 'Keypad keypad'

To clean up screen
char key = keypad.getKey();
lcd.clear(); <---- added
lcd.print("Enter Selection:");

Buttons and screen working in harmony

Robert

 

[rodw]

John,

I typed long with an upper case L and am assuming we are case sensitive?

Jeff

C is a case sensitive language.

 

[jkcab]

Ok Guys here is my report. I fixed the case sensitive problems and I apparently transposed the numbers for rows and columns. I fixed that also. I am using an 84 ozin nema 17 motor to turn a Sherline rotary table that is 72:1. I changed the steps on the motor driver to 1/8 and in the sketch to 800 and all worked fine. I then tried 1/16 at 1600 and it worked also. The problem is with 1/16 it seams to lack enough torque and is really sloooow! In the end I put it back to 1/2 step and 400. I am using a 20v 3A power supply. I think the only thing else I could do is use a higher voltage supply in hopes that it will increase speed?

Thanks again for the help,

Jeff K.

 

[jkcab]

I have everything finished and hooked up. John's sketch dose some strange things with the maths. I typed in 17 divisions to test an odd number. It reports a move of 21.18 degrees and moves 1694 steps. The next time you hit the button it moves double the steps but reports the correct degrees 42.36. it goes on in odd steps from there. I then uploaded Bob's sketch since I am still at 400 and 1/2 stepping and performed the same test. The only thing wrong there is it dose not report the number of steps to move on the LCD? however it lands right back at the start when you travel the full 17 increments 3 times around.

Jeff K.

 

[kquiggle]

I've been working on a build based on the original post for this topic, and it has been a very useful learning experience. Of course there is a ton of info online about steppers (drinking from the fire-hose, anyone?), but a few things seem to be hard to find. Here are some things I think I learned, which may or may not be correct, so if anyone can confirm or correct these items I would appreciate it. Also, I have not been able to find a really good reference on controller settings (what they are and how best to set them), so if anyone has one please let me know.

Things I learned (?) about stepper motors :

1. Do NOT rotate the stepper motor by hand while connected to the controller – it will generate a voltage which may damage the controller.
2. NEMA motor sizes : These refer to the size of the motor faceplate, not the overall size of the motor. Motors with the same NEMA size can vary in length, rated current, maximum torque, etc.
3. Settings on the controller :
   1. Running current – the current supplied to the motor by the controller. Increasing the running current increases the torque. Do NOT set the running current higher than the rated current for the motor.
   2. Stop – amount of current to supply the motor when stopped; more current = more holding torque. [really not sure about this one]
   3. Excitation – set the motor for stepping or microstepping.
   4. Decay – controls how quickly the current to the motor drops off when stopping (it’s counterintuitive : fast decay = slow stop, quick decay = fast stop).
4. Microstepping – generally speaking, microstepping will reduce torque to about 71% of full stepping.

 

[kquiggle]

I've been working on an electronic indexer based on the original post on this topic, making what I call a "straight-through" design (see picture) with the motor driving an ER32 collet holder. I plan to use this on my mini-mill to make gears and other small items which can be held in an ER32 collet (or mounted on a mandrel in the collet). My goal is to build a simpler (cheaper!) indexer.

Initially I was concerned that the motor might not have enough torque to do the job, but it seems to be working. The design also includes a mechanical rotation lock, so I'm not counting on motor holding torque to keep things stationary while milling.

I'm running the motor at max rated current (1.4A) with microstepping set to 16. Since there is no reduction gearing the collet holder moves quite briskly. This give me a resolution of 0.1125 degrees/step, but I need to make the coding more complicated to make full use of this resolution (working on that).

Here's a link to the build in progress:

https://sites.google.com/site/lagad...ls-etc/build---electronic-indexing-head?pli=1

 

[Foozer]

inserting the change [line 152 should be ToMove=(long)((bob/360.0) *(float)( Multiplier + 0.5 - cumSteps));] from post 126 gives the error - It seems to be adding tomove to itself

'vert back to the original till the 'Why' is solved . . Been punching the A - B with 17 divisions for a while and so far error free . .