I'm not sure about the speed change after stopping. I'll have another look at that.
That would mean there would be no stop button, only a reverse direction button.
I think that might have been a test where I realized there are only 2 interrupts. It might be good to add the other button back in and only check if !go. It would be a good place for the change direction so that it does not happed when the motor is running.
I'm not sure about the speed change after stopping. I'll have another look at that.
That would mean there would be no stop button, only a reverse direction button.
I think that might have been a test where I realized there are only 2 interrupts. It might be good to add the other button back in and only check if !go. It would be a good place for the change direction so that it does not happed when the motor is running.
I thought the first press while it's running would execute the if(go) section which would set g=false causing the motor to stop running (i.e. go = false) which would shut down all movement in the loop.
The second press would enter the else section of the test which would reverse direction and resume operation. So it would be a sort of stop/start action but switching direction when restarting. But it would require this second press to resume.
Am I missing something ?
Anything seems possible when you don't know what you're talking about.
I thought the first press while it's running would execute the if(go) section which would set g=false causing the motor to stop running (i.e. go = false) which would shut down all movement in the loop.
The second press would enter the else section of the test which would reverse direction and resume operation. So it would be a sort of stop/start action but switching direction when restarting. But it would require this second press to resume.
Am I missing something ?
It would work but how does he stop it? I think I did it that way so that it would be a stop function and when it was not in use be a reverse direction. But it was not intended to go at that point. The only reason I am mentioning adding back the other button is just in case of an accidental double press and it reveres when stopped without noticing.
I guess it is fine. It would be one less button click. I'm not sure how good the denouncing is right now so that is why I have some reservations about it. In fact, I don't think there is any.
I think it's safer having a button that stops it to not have the ability to turn it back on. But if he is aware of that and is ok with it, it will work.
The first push of the button sets go=false, that stops it dead until the forward, backward or stop button is pushed again, then it resumes rotation.
I think that the interrupts lead to relatively bounce-free operation (as long as you don't lean on them), but I wouldn't trust the shield buttons unless they're specified in the documentation.
I think we could do without the LEFT_PIN since RIGHT_PIN followed by a double STOP_PIN can change the direction as required.
Actually, following the "principle of least astonishment" the left and right buttons should only be available when the motor is NOT running and the stop button should not affect direction at all, but just start and stop movement.
I think on the final version a dead-man switch or at least an emergency stop should be a mandatory part of the device for safety reasons.
A few moments Googling has disillusioned me about boundless interrupts 🙁 Looks like a switch bounce can last 50-100 ms which could wreak havoc !
Anything seems possible when you don't know what you're talking about.
So you are saying that 1 button be a stop/go function and the other be direction and not accessible in go? That sounds good but that still leads to a possible stop and restart accidentally being triggered. I think it's up to @Voltage if he wants 3 dedicated buttons. It might be nice just having go, stop and direction. no confusion.
#defineBUTTONTEST50boolbuttonDown(intpinNo){if(digitalRead(pinNo)==LOW){// If button pushedunsignedlongin=millis();// Entry timewhile((millis()-in)<BUTTONTEST){// Still within time limitstepper.runSpeed();// Handle stepper movementreturn(digitalRead(pinNo)==LOW);// Isbutton still down ?}returnfalse;// No valid button press}
That would allow us to wait out 50 ms (or whatever we need) while still making sure that the stepper gets a regular call.
The calls would need to be moved into the loop.
Anything seems possible when you don't know what you're talking about.
So you are saying that 1 button be a stop/go function and the other be direction and not accessible in go? That sounds good but that still leads to a possible stop and restart accidentally being triggered. I think it's up to @Voltage if he wants 3 dedicated buttons. It might be nice just having go, stop and direction. no confusion.
Yeah, POLA says that each button should have one function which can be determined by the label.
We can either relabel the stop button as stop/start or introduce a new button called start which only starts up after the system is stopped. Then the stop button will be totally unambiguous as well. That would prevent an accidental double-press too.
Ideally though, I think we should have the left and right buttons only work when the stepper is stopped and direction will be reversed when the stepper restarts after that. Swapping directions in mid-step seems like a severe no-no for the stepper.
So:
- stop does nothing unless the stepper is running in which case it shuts the stepper down.
- go does nothing unless the stepper is stopped in which case it restarts the stepper stepping.
- left does nothing unless the stepper is stopped and then it sets direction left when restarted.
- right does nothing unless the stepper is stopped and then it sets direction right when restarted.
Anything seems possible when you don't know what you're talking about.
So you are saying that 1 button be a stop/go function and the other be direction and not accessible in go? That sounds good but that still leads to a possible stop and restart accidentally being triggered. I think it's up to @Voltage if he wants 3 dedicated buttons. It might be nice just having go, stop and direction. no confusion.
Yeah, POLA says that each button should have one function which can be determined by the label.
We can either relabel the stop button as stop/start or introduce a new button called start which only starts up after the system is stopped. Then the stop button will be totally unambiguous as well. That would prevent an accidental double-press too.
Ideally though, I think we should have the left and right buttons only work when the stepper is stopped and direction will be reversed when the stepper restarts after that. Swapping directions in mid-step seems like a severe no-no for the stepper.
So:
- stop does nothing unless the stepper is running in which case it shuts the stepper down.
- go does nothing unless the stepper is stopped in which case it restarts the stepper stepping.
- left does nothing unless the stepper is stopped and then it sets direction left when restarted.
- right does nothing unless the stepper is stopped and then it sets direction right when restarted.
That would work But I just wanted to let you know how the original was setup but I also know with the AccelStepper it may not be able to be set like the guy did using the Stepper library. It had 3 buttons and a potentiometer. A CW (Clockwise Button), a CCW (CounterClockwise Button), and a STOP button. The CW and the CCW would start it and of course the STOP button would stop it. And if you pressed the CCW when it was running Clockwise it would just change direction. Probably doesn't hurt the stepper but the end user (Me) would know better than to test that on purpose although if it happened here and there it wouldn't hurt it. Ok, back to my workout...
That would work But I just wanted to let you know how the original was setup but I also know with the AccelStepper it may not be able to be set like the guy did using the Stepper library. It had 3 buttons and a potentiometer. A CW (Clockwise Button), a CCW (CounterClockwise Button), and a STOP button. The CW and the CCW would start it and of course the STOP button would stop it. And if you pressed the CCW when it was running Clockwise it would just change direction. Probably doesn't hurt the stepper but the end user (Me) would know better than to test that on purpose although if it happened here and there it wouldn't hurt it. Ok, back to my workout...
OK, looks like we're constrained to three buttons as it seems somewhat senseless to change the interface to something the control panel isn't designed for. By-bye POLA ... 🙂
So, it looks like we're looking at a hardwired stop, left and right button.
1) STOP - does it make sense to everybody to use the stop button to start and stop rotation ? To address madmisha's valid concern about double-pressing the stop button and thus restarting it immediately, we could disable it for a short period. That is, when the stop button is first pressed to stop rotation the button is disabled for a period of 1, 2 or 5 seconds before it can be used to re-start rotation, thus preventing accidental re-triggering.
I, personally dislike the idea of the stop button changing direction, I think that the LEFT and RIGHT buttons should be used for that purpose and the STOP button can only start and stop operation.
2) LEFT/RIGHT buttons only operates when the machine (is stopped ? and) the new direction is different from the current direction. If the button should be active even when it's operating then we should stop the stepper, change the direction and then restart the stepper in code.
My concern is that simply swapping the speed to its negative will result in a huge load on the stepper, gear trains and chain and may damage the stepper. Making it stop and then start rotating splits the inertial load in half.
No offence Voltage, but we should make the system as safe as possible to avoid damage to the stepper and to the operator. We know you wouldn't do anything stupid yourself, but we need to take into consideration accidents like brushing a switch with a piece of stock or leaning on the control panel while tightening the chuck to visitors saying "What does this one do?".
Comments, suggestions ?
Anything seems possible when you don't know what you're talking about.
That would work But I just wanted to let you know how the original was setup but I also know with the AccelStepper it may not be able to be set like the guy did using the Stepper library. It had 3 buttons and a potentiometer. A CW (Clockwise Button), a CCW (CounterClockwise Button), and a STOP button. The CW and the CCW would start it and of course the STOP button would stop it. And if you pressed the CCW when it was running Clockwise it would just change direction. Probably doesn't hurt the stepper but the end user (Me) would know better than to test that on purpose although if it happened here and there it wouldn't hurt it. Ok, back to my workout...
I want to make sure we don't get too far ahead of ourselves. So for clarification:
Do you need the same arrangement for buttons because you are using the same case? Or are you making it to what you have when complete?
I think the second option Will listed is doable. Left and right makes it go in that direction but would only be able to access when !go in the loop. I would keep the stop button as an interrupt. This would also make bounce a lot easier to deal with. No need for direction at all. If needed, a 2 button system could work too, as we have seen. It is really up to you.
My concern is that simply swapping the speed to its negative will result in a huge load on the stepper, gear trains and chain and may damage the stepper. Making it stop and then start rotating splits the inertial load in half.
With the directions local to the loop, that wouldn't be that much of a problem. I agree that it is better to make it stop than allow it to happen.
How long does it take to stop when using the stepper.stop()? I did write a stop where it added a delay that is the speed and multiplied by a number so that when it is faster it will take longer before break. This won't work in the interrupt directly but having a cooldown in the main loop in the !go section that is triggered with the off command. The if statement in the start/stop interrupt could be (!go && countdown == 0). The actions after it would be swapped. It's just an idea.
I still want to see if the shield buttons works. As well as the screen update function. If that design works out fine, all you would need is that screen.
As for the main sketch, the last one I saw was Mod-5. There are a few things to clean up. Extra interrupt can go away. I would rename some things to make more sense. I kept previous names and nothing really matches naming wise and it is confusing. There are a few things that I regret.
I should have a few hours tomorrow with you but not long. But if you can, post the last iteration at the end of the day so I can catch up.
That would work But I just wanted to let you know how the original was setup but I also know with the AccelStepper it may not be able to be set like the guy did using the Stepper library. It had 3 buttons and a potentiometer. A CW (Clockwise Button), a CCW (CounterClockwise Button), and a STOP button. The CW and the CCW would start it and of course the STOP button would stop it. And if you pressed the CCW when it was running Clockwise it would just change direction. Probably doesn't hurt the stepper but the end user (Me) would know better than to test that on purpose although if it happened here and there it wouldn't hurt it. Ok, back to my workout...
OK, looks like we're constrained to three buttons as it seems somewhat senseless to change the interface to something the control panel isn't designed for. By-bye POLA ... 🙂
So, it looks like we're looking at a hardwired stop, left and right button.
1) STOP - does it make sense to everybody to use the stop button to start and stop rotation ? To address madmisha's valid concern about double-pressing the stop button and thus restarting it immediately, we could disable it for a short period. That is, when the stop button is first pressed to stop rotation the button is disabled for a period of 1, 2 or 5 seconds before it can be used to re-start rotation, thus preventing accidental re-triggering.
I, personally dislike the idea of the stop button changing direction, I think that the LEFT and RIGHT buttons should be used for that purpose and the STOP button can only start and stop operation.
2) LEFT/RIGHT buttons only operates when the machine (is stopped ? and) the new direction is different from the current direction. If the button should be active even when it's operating then we should stop the stepper, change the direction and then restart the stepper in code.
My concern is that simply swapping the speed to its negative will result in a huge load on the stepper, gear trains and chain and may damage the stepper. Making it stop and then start rotating splits the inertial load in half.
No offence Voltage, but we should make the system as safe as possible to avoid damage to the stepper and to the operator. We know you wouldn't do anything stupid yourself, but we need to take into consideration accidents like brushing a switch with a piece of stock or leaning on the control panel while tightening the chuck to visitors saying "What does this one do?".
Safety is great. I like being safe so I'm in on safety. Keep in mind though that as long as it works it does not have to be like the original. I was just pointing that out in case it made sense.
1. Sounds fine to me, but the left and right buttons sound s good too. Whatever is easy to implement, be safe, and work without adding other issues.
2. I don't want to break or stress anything so keeping it from doing that is fine. I just know that so far I haven't broke anything yet but I use it with small stuff. Stepper motor demos or examples switch directions but maybe that is just for examples.
Safety is great. Who wants to get hurt or ruin good equipment. I agree as there is always the possibility somebody else pushes the buttons. 🙂
I will check back in tomorrow. My schedule:
Walk dog while doing computer backups.
Get home and finish all backups like I do every Sunday while waiting for breakfast.
That would work But I just wanted to let you know how the original was setup but I also know with the AccelStepper it may not be able to be set like the guy did using the Stepper library. It had 3 buttons and a potentiometer. A CW (Clockwise Button), a CCW (CounterClockwise Button), and a STOP button. The CW and the CCW would start it and of course the STOP button would stop it. And if you pressed the CCW when it was running Clockwise it would just change direction. Probably doesn't hurt the stepper but the end user (Me) would know better than to test that on purpose although if it happened here and there it wouldn't hurt it. Ok, back to my workout...
I want to make sure we don't get too far ahead of ourselves. So for clarification:
Do you need the same arrangement for buttons because you are using the same case? Or are you making it to what you have when complete?
I think the second option Will listed is doable. Left and right makes it go in that direction but would only be able to access when !go in the loop. I would keep the stop button as an interrupt. This would also make bounce a lot easier to deal with. No need for direction at all. If needed, a 2 button system could work too, as we have seen. It is really up to you.
My concern is that simply swapping the speed to its negative will result in a huge load on the stepper, gear trains and chain and may damage the stepper. Making it stop and then start rotating splits the inertial load in half.
With the directions local to the loop, that wouldn't be that much of a problem. I agree that it is better to make it stop than allow it to happen.
How long does it take to stop when using the stepper.stop()? I did write a stop where it added a delay that is the speed and multiplied by a number so that when it is faster it will take longer before break. This won't work in the interrupt directly but having a cooldown in the main loop in the !go section that is triggered with the off command. The if statement in the start/stop interrupt could be (!go AND countdown == 0). The actions after it would be swapped. It's just an idea.
I still want to see if the shield buttons works. As well as the screen update function. If that design works out fine, all you would need is that screen.
As for the main sketch, the last one I saw was Mod-5. There are a few things to clean up. Extra interrupt can go away. I would rename some things to make more sense. I kept previous names and nothing really matches naming wise and it is confusing. There are a few things that I regret.
I should have a few hours tomorrow with you but not long. But if you can, post the last iteration at the end of the day so I can catch up.
Madmisha:
The buttons can be whatever as I am going to build a new control enclosure.
The LCD shield would have to be wired for the button pushes if used as that would not be available through the cover of the enclosure but I think you know that. 🙂
I will be reading the forum after 9:30 AM CST but will be doing backups and eating breakfast until 11:30 and be ready to rumble at 12:00 Noon CST.
The buttons can be whatever as I am going to build a new control enclosure.
The LCD shield would have to be wired for the button pushes if used as that would not be available through the cover of the enclosure but I think you know that. 🙂
I will be reading the forum after 9:30 AM CST but will be doing backups and eating breakfast until 11:30 and be ready to rumble at 12:00 Noon CST.
Thanks Madmisha!
🙂
If we agree that LEFT and RIGHT will only work when the machine is stopped, then we won't need a start button. Stop will just stop the machine and the operator will use the LEFT or RIGHT button to start it running in the desired direction.
@madmisha, I'm wondering, if we have such crisp meanings for each button, will we really need to de-bounce the switches ? I mean, if we sense the STOP button pushed we're just going to stop, we don't have to worry about it bouncing on and off. Similarly if the machine is stopped and somebody pushes a direction button - we're just going to start moving that direction whether the switch bounces or not.
We could "slow to a stop" after the button is pushed by gradually decreasing the stepper speed. In a similar way we could "ramp up" to start by gradually increasing the stepper speed from 0 to the calculated rate. Both of these could take place over a second or two each and should take a good amount of stress off the stepper.
The slow down could be incorporated into the STOP button code and the ramp up could be built into the LEFT & RIGHT button code.
Does this sum everything up correctly ? Use Voltage's custom enclosure (to be designed), use shield buttons if possible wired to enclosure buttons, STOP just stops, LEFT and RIGHT only work when machine stopped and will start up in desired direction, Stop may involve gradual reduction in speed to zero, LEFT, RIGHT may involve gradual spin-up to pot indicated speed.
Just so we all start with the same vision and assumptions 🙂
Anything seems possible when you don't know what you're talking about.
One other question Voltage while I think of it, would you prefer using a potentiometer to dial in diameter or would you prefer using buttons to do so ?
Anything seems possible when you don't know what you're talking about.
We use cookies on the DroneBot Workshop Forums to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
