Arduino with Stepper and LiquidCrystal Issue

Posted by: @will

@voltage @madmisha

To help illustrate the calculations I use for converting diameter into RPM, let's use an example with stock diameter 5".

5" diameter gives a circumference of 5 x pi = 15.71 inches (close)

15.71 inches has 15.71 x 8 eight'ths of an inch = 

so there are 125.68 eights of an inch along the circumference of the bar

but the circumference equal 5100 steps (3 x 4.25 x 400)

5100 steps = 125.68 eight'ths of an inch

1 eight'th/second = 5100/125.68 = 40.58 steps/second

40.58 steps/second x 60 seconds per minute = 2434.8 steps/minute

then 2434.8 steps/min = 0.477 RPM

Ok, I compiled and ran the last sketch and I counted 13.75 RPM's with the same setting of 0.50 diameter and 4.76 RPM which is about right on @4.58 after the chain and sprockets. Good job! Yours is most likely more accurate than my finger hitting the flag tape on the output shaft and counting. 😋 Let me think on this overnight and further soak it in but it looks great to me. But my wife will be here shortly to cook supper. 🍺 I appreciate all the work from both of you guys helping me with this.

Don't change anything as it seems correct but I will make a bunch of tests tomorrow and take notes. Earlier the output was less as noted but sometimes we may be talking about the sketch before or after a mod. I have been marking the sketches at the top so I know which one we are using with this format:

sketch_aug06e-Will-Mod-4

That is the current final one for today.

@voltage

Sounds like we have the problem on the run.

I have one more new version which has some slight improvements, but I'll wait until you say you're ready for it tomorrow.

I'd also like @madmisha to check it over as well to see what improvements he can suggest.

Posted by: @will

@voltage

Sounds like we have the problem on the run.

I have one more new version which has some slight improvements, but I'll wait until you say you're ready for it tomorrow.

I'd also like @madmisha to check it over as well to see what improvements he can suggest.

Ok great. All the stuff is put up for today. I appreciate you and madmisha. Take a break for today. I may check in later but won't able to test anything until tomorrow. Thanks again!

@voltage

That's what we're here for.

@voltage @will

That jitter in the pot was why I suggested an encoder before. Store the value as an int and adjust it up and down. If you want to experiment with that then I look into a way of having the move go into a buffer so that we wouldn't miss steps. Or try it without and see how it does. I do not have a spare LCD like that around so I can't test right away.

Now that I know it only has 2 interrupts, my 4 button idea won't work. I really liked that one too.

That error you saw that was like 5000 when it was actually 50 was an update error. I did not clear the last 2 digits when it went down to a 2 digit number. There might be something in the sprint function that can always print it as a 4 digit number. It might be better than if statements. It will still be an issue now though.

Before going any further, I would test out the largest, smallest and heaviest pieces to make sure you get the speeds you need when it has a load. You wouldn't want to have to rework your formulas because you needed more torque.

You could also use and E-Stop button and pass the enable signal through it. That will take care of your stop and start and the 2 interrupts can be up and down speed. Precise and responsive. There would be no need for updating the screen if it wasn't pressed. That would also mean the ability to do more to make the screen better. Direction can be a quick poll of a button or even a toggle switch in an if statement. Instead of go, it can pull the 5V signal looped back from the E-stop. That's where you can check direction before starting and prevent it from reversing while it's going full speed. Many option and configurations.

And/Or, you can always use the 4 buttons on the LCD board. I will have to look up some things on that. I kind of wish I had one so I can see what the delay is if polled once in a loop.

Just some random thoughts.

Posted by: @madmisha

@voltage @will

That jitter in the pot was why I suggested an encoder before. Store the value as an int and adjust it up and down. If you want to experiment with that then I look into a way of having the move go into a buffer so that we wouldn't miss steps. Or try it without and see how it does. I do not have a spare LCD like that around so I can't test right away.

Now that I know it only has 2 interrupts, my 4 button idea won't work. I really liked that one too.

 

That error you saw that was like 5000 when it was actually 50 was an update error. I did not clear the last 2 digits when it went down to a 2 digit number. There might be something in the sprint function that can always print it as a 4 digit number. It might be better than if statements. It will still be an issue now though.

 

Before going any further, I would test out the largest, smallest and heaviest pieces to make sure you get the speeds you need when it has a load. You wouldn't want to have to rework your formulas because you needed more torque.

 

You could also use and E-Stop button and pass the enable signal through it. That will take care of your stop and start and the 2 interrupts can be up and down speed. Precise and responsive. There would be no need for updating the screen if it wasn't pressed. That would also mean the ability to do more to make the screen better. Direction can be a quick poll of a button or even a toggle switch in an if statement. Instead of go, it can pull the 5V signal looped back from the E-stop. That's where you can check direction before starting and prevent it from reversing while it's going full speed. Many option and configurations.

 

And/Or, you can always use the 4 buttons on the LCD board. I will have to look up some things on that. I kind of wish I had one so I can see what the delay is if polled once in a loop.

 

Just some random thoughts.

The jitter bothers me too because it means that the LCD display code will be called even when the pot hasn't been moved. The code, as it stands, will execute irregularly because it won't pass through the loop in the same time every pass. That's because sometimes it will have to read the pot, recalculate and display both the speed and RPM.

That's why I wanted to move those calculations out of the loop and into the stop button, so it could be done external to the loop. Then the loop would always take the same time to execute and the resulting speed would be more steady and reliable (and closer to the calculated speed).

The current code can be improved by declaring a jitter limit and only entering the speed calc when the absolute difference between the current pot reading and the previous pot reading exceeds the limit (e.g. 5). That reduces the time that's wasted in recalculating changes caused by small jittering.

If the speed calculation and display were performed in the "!go" section of the loop then even the pot jitter would have no material effect on loop time, unless the motor was stopped in which case it couldn't be slowed anyway. Unfortunately, loss of the ability to "fine tune" the rotation while it's actually occurring seems like a heavy penalty 🙁

I'm not sure that an encoder would work in this case. The pot value ranges from 0 to 1023 and I think it would be very tedious turning the encoder 1023 clicks get the maximum 🙂

So far I think that the LCD display is working. The pot is now reading a diameter in hundredths of an inch and calculating the steps/second which is sent to the stepper and the RPM. It displays the diameter on the first line and the RPM on the second line. The LCD is wiped with blanks before the next value is displayed and seems to be working satisfactorily from the few tests done.

Preliminary tests seem to indicate that the RPMs reflect a fairly appropriate value for the diameter selected, but a lot more testing is required.

I don't think that a live test will be possible at this point, I believe it's all just loosely wired pieces on his kitchen table 🙂

@madmisha @voltage

Voltage has run preliminary tests on the existing version and everything tested seems to be OK. He said he's going to do more detailed testing and make notes tomorrow.

Unless tomorrow's testing goes badly or unless Voltage feels that the extra buttons for setting the target whatever would be better for him than using a potentiometer, there seems little point in starting over with a brand new sketch.

We'll have to wait for Voltage's decision tomorrow.

Posted by: @madmisha

@voltage @will

That jitter in the pot was why I suggested an encoder before. Store the value as an int and adjust it up and down. If you want to experiment with that then I look into a way of having the move go into a buffer so that we wouldn't miss steps. Or try it without and see how it does. I do not have a spare LCD like that around so I can't test right away.

Now that I know it only has 2 interrupts, my 4 button idea won't work. I really liked that one too.

 

That error you saw that was like 5000 when it was actually 50 was an update error. I did not clear the last 2 digits when it went down to a 2 digit number. There might be something in the sprint function that can always print it as a 4 digit number. It might be better than if statements. It will still be an issue now though.

 

Before going any further, I would test out the largest, smallest and heaviest pieces to make sure you get the speeds you need when it has a load. You wouldn't want to have to rework your formulas because you needed more torque.

 

You could also use and E-Stop button and pass the enable signal through it. That will take care of your stop and start and the 2 interrupts can be up and down speed. Precise and responsive. There would be no need for updating the screen if it wasn't pressed. That would also mean the ability to do more to make the screen better. Direction can be a quick poll of a button or even a toggle switch in an if statement. Instead of go, it can pull the 5V signal looped back from the E-stop. That's where you can check direction before starting and prevent it from reversing while it's going full speed. Many option and configurations.

 

And/Or, you can always use the 4 buttons on the LCD board. I will have to look up some things on that. I kind of wish I had one so I can see what the delay is if polled once in a loop.

 

Just some random thoughts.

Random thoughts have been read. I won't be able to test it for a while in use as it's just a project on the counter based on the one I already built. I am going to build a portable version using this and thought I would start with a new build. I don't mind the idea of other code to test but simple is good and I am just a hobbyist welder so no production issues here. At the moment with the last code the display looks pretty stable and could likely be made better with a multi-turn pot but I have a bunch of new Bourn 10k 280 degree turn pots so I may as well use one. All your ideas sound great but I don't always understand everything you say until I put it to the test. The display at the moment sometimes will display a number after I change directions (like a 22), but I it doesn't look like a buffer overflow. I also noticed with this current code when I unplug and plug back in the usb cable to the laptop, the code runs. More info in the next posts...

Posted by: @will

Posted by: @madmisha

@voltage @will

That jitter in the pot was why I suggested an encoder before. Store the value as an int and adjust it up and down. If you want to experiment with that then I look into a way of having the move go into a buffer so that we wouldn't miss steps. Or try it without and see how it does. I do not have a spare LCD like that around so I can't test right away.

Now that I know it only has 2 interrupts, my 4 button idea won't work. I really liked that one too.

 

That error you saw that was like 5000 when it was actually 50 was an update error. I did not clear the last 2 digits when it went down to a 2 digit number. There might be something in the sprint function that can always print it as a 4 digit number. It might be better than if statements. It will still be an issue now though.

 

Before going any further, I would test out the largest, smallest and heaviest pieces to make sure you get the speeds you need when it has a load. You wouldn't want to have to rework your formulas because you needed more torque.

 

You could also use and E-Stop button and pass the enable signal through it. That will take care of your stop and start and the 2 interrupts can be up and down speed. Precise and responsive. There would be no need for updating the screen if it wasn't pressed. That would also mean the ability to do more to make the screen better. Direction can be a quick poll of a button or even a toggle switch in an if statement. Instead of go, it can pull the 5V signal looped back from the E-stop. That's where you can check direction before starting and prevent it from reversing while it's going full speed. Many option and configurations.

 

And/Or, you can always use the 4 buttons on the LCD board. I will have to look up some things on that. I kind of wish I had one so I can see what the delay is if polled once in a loop.

 

Just some random thoughts.

The jitter bothers me too because it means that the LCD display code will be called even when the pot hasn't been moved. The code, as it stands, will execute irregularly because it won't pass through the loop in the same time every pass. That's because sometimes it will have to read the pot, recalculate and display both the speed and RPM.

That's why I wanted to move those calculations out of the loop and into the stop button, so it could be done external to the loop. Then the loop would always take the same time to execute and the resulting speed would be more steady and reliable (and closer to the calculated speed).

The current code can be improved by declaring a jitter limit and only entering the speed calc when the absolute difference between the current pot reading and the previous pot reading exceeds the limit (e.g. 5). That reduces the time that's wasted in recalculating changes caused by small jittering.

If the speed calculation and display were performed in the "!go" section of the loop then even the pot jitter would have no material effect on loop time, unless the motor was stopped in which case it couldn't be slowed anyway. Unfortunately, loss of the ability to "fine tune" the rotation while it's actually occurring seems like a heavy penalty 🙁

I'm not sure that an encoder would work in this case. The pot value ranges from 0 to 1023 and I think it would be very tedious turning the encoder 1023 clicks get the maximum 🙂

So far I think that the LCD display is working. The pot is now reading a diameter in hundredths of an inch and calculating the steps/second which is sent to the stepper and the RPM. It displays the diameter on the first line and the RPM on the second line. The LCD is wiped with blanks before the next value is displayed and seems to be working satisfactorily from the few tests done.

Preliminary tests seem to indicate that the RPMs reflect a fairly appropriate value for the diameter selected, but a lot more testing is required.

I don't think that a live test will be possible at this point, I believe it's all just loosely wired pieces on his kitchen table 🙂

Some new things to work on. The project is loosely wired on the kitchen counter but I cut a circle close to 3" diameter for testing(I have to make one more accurate this one is 2-7/8"), and when I set it for that diameter is seems the stepper is twice as fast...Yikes. I forgot the 3:1 part in my test. Ok, here are the numbers anyway. In order to get the output shaft on the gearbox to move 1/8" per second, I have to set the diameter to 7.10 and that leaves an output RPM of 0.33 so we should be able to do the math from there. So if we divide that by 3 it equals 0.11 which is close to (.125 or 1/8"). I think I need to do another test. 😋 What would be a good test? Try again with a more accurate circle like 3" and we could do the math from there? This test may be tricky to accomplish.

edit: Maybe easier than I thought. Just mark 3/8 increments on the test wheel as that would end up divided by 3 with the sprockets...Back to the kitchen!

Posted by: @voltage

Some new things to work on. The project is loosely wired on the kitchen counter but I cut a circle close to 3" diameter for testing(I have to make one more accurate this one is 2-7/8"), and when I set it for that diameter is seems the stepper is twice as fast...Yikes. I forgot the 3:1 part in my test. Ok, here are the numbers anyway. In order to get the output shaft on the gearbox to move 1/8" per second, I have to set the diameter to 7.10 and that leaves an output RPM of 0.33 so we should be able to do the math from there. So if we divide that by 3 it equals 0.11 which is close to (.125 or 1/8"). I think I need to do another test. 😋 What would be a good test? Try again with a more accurate circle like 3" and we could do the math from there? This test may be tricky to accomplish.

 

edit: Maybe easier than I thought. Just mark 3/8 increments on the test wheel as that would end up divided by 3 with the sprockets...Back to the kitchen!

To fix the problem of extra digits when you reverse, change the 5 blanks to 6 blanks in the loop where it displays the RPM. (I forgot to add an extra blank for the +/- sign).

For timing, you could also just mark the disk at one point, spin it and count the time it makes to make 1 rev. You know the diameter so you can calculate how many eights of an inch it traveled in that time. Dividing out will give you distance per second.

Posted by: @will

Posted by: @voltage

Some new things to work on. The project is loosely wired on the kitchen counter but I cut a circle close to 3" diameter for testing(I have to make one more accurate this one is 2-7/8"), and when I set it for that diameter is seems the stepper is twice as fast...Yikes. I forgot the 3:1 part in my test. Ok, here are the numbers anyway. In order to get the output shaft on the gearbox to move 1/8" per second, I have to set the diameter to 7.10 and that leaves an output RPM of 0.33 so we should be able to do the math from there. So if we divide that by 3 it equals 0.11 which is close to (.125 or 1/8"). I think I need to do another test. 😋 What would be a good test? Try again with a more accurate circle like 3" and we could do the math from there? This test may be tricky to accomplish.

 

edit: Maybe easier than I thought. Just mark 3/8 increments on the test wheel as that would end up divided by 3 with the sprockets...Back to the kitchen!

To fix the problem of extra digits when you reverse, change the 5 blanks to 6 blanks in the loop where it displays the RPM. (I forgot to add an extra blank for the +/- sign).

For timing, you could also just mark the disk at one point, spin it and count the time it makes to make 1 rev. You know the diameter so you can calculate how many eights of an inch it traveled in that time. Dividing out will give you distance per second.

Good morning Will. I did another test on the rpms and cut a 3" circle and made 3/8" increments and set it to Diameter 3.0 and the RPM showed 0.79. I ran it and tried to look back and forth to the clock on the laptop as I counted and it seemed to be between 10 and 11 increments in 10 seconds. I will try the 1 rev test and see what I get.

edit: 3.0 DIA, 0.79 RPM- 28 seconds for 1 rev

@voltage @madmisha

If you can make a cardboard test circle of 4.76 inches, it should come out to close to 0.5 RPM. So if you mark it on the circumference, you should see the mark back at almost exactly two minutes. That will avoid having to glance back and forth all the time.

Posted by: @will

@voltage @madmisha

If you can make a cardboard test circle of 4.76 inches, it should come out to close to 0.5 RPM. So if you mark it on the circumference, you should see the mark back at almost exactly two minutes. That will avoid having to glance back and forth all the time.

Ok, I will see if I can make one that size and test it. It's easy to glance back and forth on the one rev test. Counting the 1/8 or 3/8" increments a whole different story. Back to the kitchen.

edit: Made approximate 4.76" circle. Display said 4.74-4.76 (flickers a little at first) RPMs 0.49 and for 1 revolution it took 43 seconds and 2 revolutions took 1 min 25 seconds (85 secs).