For me, this is a very valuable video because it shows me how to code part of my project that I know quite a bit about but didn't know how to even begin to implement the up/down ramps. Actually, I think I can package his code into my support code verbatim. This is an excellent presentation with really clean and consice code. This engineer really knows his trade! You, Sir, will be saving me many hours of grief and constipation. Thank you so very, very much...... FWIW: 45+ yrs ago, I was the senior electronics design engineer in a small company that was developing a product that relied heavily on the performance of a stepping motor to slew and position a print head on a highly advanced dot matrix printer. Too often in testing, the stepper would 'lose sync' when starting or changing direction. It could lose one or two steps or totally lose it and chatter/vibrate like the dickens. A few lost steps resulted in fuzy characters being printed. The software weenies blamed my Z80 hardware design, but my cohort in crime explained to me what was happening and educated me on the need to 'ramp' stepper motors. Charley had Been-There-Done-That years before in a previous job. Along with becoming a lifelong personal friend, Charley was a very good and experienced engineer with many talents. When I diplomatically explained the situation to the software iguneers, they balked, told me to mind my own business, and complained to the owner that I was interfering with their work. The boss called me in and said I needed to leave the 'kids' alone. Later, the 'kids' convinced the boss that they were working with bad motors and an inferior Z80 hardware design that was losing interrupts, which of course was my fault. He asked the manufacturer/supplier to come up and help identify our hardware problems. The supplier evaluated our hardware design and motor control microcode and said nothing was wrong with the hardware but that the microcode was really lacking and really bad. As they briefed a bunch of us on their findings, a small smile creeped across my face, but our boss never looked at me. I think he was embarrassed. Four weeks later, we had a new software team leader, 2 of the original 4 'kids' were laid off, and I was appointed as project engineer with oversight over the entire project. BTW : I think those 2 kids should have been fired. The other two were good guys who knew their stuff, and one of them picked up where the two losers left off and fixed the code to perfection. Anyways, as the almighty stepper motor god in the back room sais, 'Don't ever forget your ramps, your job may depend on it'.......
Fantastic Video and explanation, but I wonder what the formula would be for the number of steps for deaccelerating to stop using the linear algorithm. Thank you!
Thank you for posting the files. I'm trying to utilize ConstantAcceleratioStepper2 and I need a bit of help. Are you available to answer a couple of questions? Thanks very much. Regards
Couldn't you do something like: for (stepperDelay = 3000; stepperDelay >= 700; stepperDelay = stepperDelay*.99) and achieve similar results? I mean, unless I am not understanding something, I was lost on the explanation of angular and linear acceleration, it seems as what you are looking for is acceleration that is proportional so that the speed ramps up in a straight line instead of curving.
in your for loop, instead of incrementing delay, if you increment the frequency then calculate the corresponding delay, the acceleration will be linear, right?
Timestamp(Num_Step)=(sqrt(2)*(ALPHA/STEP_MODE))/ACCELERATION*(sqrt(Num_Step+1)-sqrt(Num_Step)) Calcul de l'intégrale sous la droite de vitesse en considérant une accélération constante ACCELERATION in step/s/s ALPHA = unit/s^-1 = 1000000 (for µs) STEP_MODE = number of precision steps / real step = 1 by default (maybe 1/2/8/16/...) Note : ((sqrt(2)*(ALPHA/STEP_MODE))/ACCELERATION) is a fixed value and could be calculated one time per stepper acceleration to freed up some CPU time
very interesting, i typed your code and tried it for myself, i couldnt find the link to the github, i guess to make drive a robot arm you will update the code so that you can drive from a possition to an other while accelerating and keeping a stady max speed and deselerating before you reash the end possition. Is this about right or you have something else in mind? I'm also in the prosses of building a robot arm, i would love to see more videos from you.
Yeah progress has been a little slow, hopefully I will be working on it a bit more soon. Your description is correct, that's how I plan to drive it. I'll add the link for the github right now
this is called (s curve motion ) and using TMCStepper library is better with TMC drivers because they have the ability to do so in the code beside holding stepper position at the movement end
Nice thought But I am bit confuse about your for loop. You are decreasing pulse width/delay and giving it to motor. So acceleration you are giving to one micro step of motor. Or Acceleration to one complete rotation of motor ?
Hi Sichun Xu, I love your presentation. I would like to know if I can stop the stepper motor in one spot indefinitely , then when I switch off my machine the stepper motor reverses to original position
What is the context for this? That is false without a specific context. If you look up low side switching, you can see that many applications disconnect the ground.
@@MarcelRobitaille The context is that when you have other things like serial cables and what not connected to other equipment, disconnecting the GND is a bad thing to do. It will cause other connected things voltages to spike or float at wrong levels.
Thank you. This will be a valuable asset in coding for Stepper Motors, as in some cases, the motor won't start at high speeds without problems. Thanks
Great explination. Thank you Sir
For me, this is a very valuable video because it shows me how to code part of my project that I know quite a bit about but didn't know how to even begin to implement the up/down ramps.
Actually, I think I can package his code into my support code verbatim.
This is an excellent presentation with really clean and consice code. This engineer really knows his trade!
You, Sir, will be saving me many hours of grief and constipation.
Thank you so very, very much......
FWIW: 45+ yrs ago, I was the senior electronics design engineer in a small company that was developing a product that relied heavily on the performance of a stepping motor to slew and position a print head on a highly advanced dot matrix printer.
Too often in testing, the stepper would 'lose sync' when starting or changing direction. It could lose one or two steps or totally lose it and chatter/vibrate like the dickens. A few lost steps resulted in fuzy characters being printed.
The software weenies blamed my Z80 hardware design, but my cohort in crime explained to me what was happening and educated me on the need to 'ramp' stepper motors.
Charley had Been-There-Done-That years before in a previous job. Along with becoming a lifelong personal friend, Charley was a very good and experienced engineer with many talents.
When I diplomatically explained the situation to the software iguneers, they balked, told me to mind my own business, and complained to the owner that I was interfering with their work.
The boss called me in and said I needed to leave the 'kids' alone.
Later, the 'kids' convinced the boss that they were working with bad motors and an inferior Z80 hardware design that was losing interrupts, which of course was my fault.
He asked the manufacturer/supplier to come up and help identify our hardware problems.
The supplier evaluated our hardware design and motor control microcode and said nothing was wrong with the hardware but that the microcode was really lacking and really bad.
As they briefed a bunch of us on their findings, a small smile creeped across my face, but our boss never looked at me. I think he was embarrassed.
Four weeks later, we had a new software team leader, 2 of the original 4 'kids' were laid off, and I was appointed as project engineer with oversight over the entire project.
BTW : I think those 2 kids should have been fired. The other two were good guys who knew their stuff, and one of them picked up where the two losers left off and fixed the code to perfection.
Anyways, as the almighty stepper motor god in the back room sais, 'Don't ever forget your ramps, your job may depend on it'.......
great stuff ! I would love to see more about the arm project.
Nice men, you're a crack, actually I'm planning to make a robot arm too, so these explanations can help a lot for future. Great job!
Good luck!
Thank you. I'm going to look around your channel to see if you added interrupts for my motors
Fantastic Video and explanation, but I wonder what the formula would be for the number of steps for deaccelerating to stop using the linear algorithm. Thank you!
use AccelStepper Library, more simple with max speed and acceleration variables!!
Good explanation. Keep it up 👍
Thanks 🙂
it's a pity that you stopped posting new video, it would be awesome to see the finall roboproject.
Thank you for posting the files. I'm trying to utilize ConstantAcceleratioStepper2 and I need a bit of help. Are you available to answer a couple of questions? Thanks very much. Regards
HOW DO YOU MAINTAIN A REQUIRED SMOOTHNESS OF COORDINATED MOTION AMONG STEPPERS?
Do you know the name of an integrated circuit that gradually increases the frequency, which means acceleration?
Couldn't you do something like:
for (stepperDelay = 3000; stepperDelay >= 700; stepperDelay = stepperDelay*.99)
and achieve similar results? I mean, unless I am not understanding something, I was lost on the explanation of angular and linear acceleration, it seems as what you are looking for is acceleration that is proportional so that the speed ramps up in a straight line instead of curving.
in your for loop, instead of incrementing delay, if you increment the frequency then calculate the corresponding delay, the acceleration will be linear, right?
please can you explain to me why there is no delay after digitalWrite(stepPin, LOW)?
Timestamp(Num_Step)=(sqrt(2)*(ALPHA/STEP_MODE))/ACCELERATION*(sqrt(Num_Step+1)-sqrt(Num_Step))
Calcul de l'intégrale sous la droite de vitesse en considérant une accélération constante
ACCELERATION in step/s/s
ALPHA = unit/s^-1 = 1000000 (for µs)
STEP_MODE = number of precision steps / real step = 1 by default (maybe 1/2/8/16/...)
Note : ((sqrt(2)*(ALPHA/STEP_MODE))/ACCELERATION) is a fixed value and could be calculated one time per stepper acceleration to freed up some CPU time
very interesting, i typed your code and tried it for myself, i couldnt find the link to the github, i guess to make drive a robot arm you will update the code so that you can drive from a possition to an other while accelerating and keeping a stady max speed and deselerating before you reash the end possition. Is this about right or you have something else in mind? I'm also in the prosses of building a robot arm, i would love to see more videos from you.
Yeah progress has been a little slow, hopefully I will be working on it a bit more soon. Your description is correct, that's how I plan to drive it. I'll add the link for the github right now
this is called (s curve motion ) and using TMCStepper library is better with TMC drivers because they have the ability to do so in the code beside holding stepper position at the movement end
Nice thought
But I am bit confuse about your for loop.
You are decreasing pulse width/delay and giving it to motor.
So acceleration you are giving to one micro step of motor.
Or
Acceleration to one complete rotation of motor ?
Thanks
Bravo 👏 👏 merci
thnx a lot that's helped me
Hi Sichun Xu, I love your presentation. I would like to know if I can stop the stepper motor in one spot indefinitely , then when I switch off my machine the stepper motor reverses to original position
You NEVER want to disconnect the ground. You always disconnect the +
What is the context for this? That is false without a specific context. If you look up low side switching, you can see that many applications disconnect the ground.
@@MarcelRobitaille The context is that when you have other things like serial cables and what not connected to other equipment, disconnecting the GND is a bad thing to do. It will cause other connected things voltages to spike or float at wrong levels.