Specification of values for ramp (one more time)
(update) I've changed the name of the post in an attempt to be more accurate. I don't (think I need) another definition of what servo ramping is, rather a specification of how the parm values change the ramping behavior of the PSC....
I'm starting this as a new thread even though there have been some other posts, since the ones I'm looking at haven't produced an answer·for me and have begun to wander a bit.
The ramp value for a PSC affects how the pulsewidth is changed from its current value to the value specified in the set servo position command, right?
For example, if I've got a servo set at a position value of 500 and I issue a command to set it to 1000, instead of it changing from a position of 500 to 1000 immediately (I realize that these are not pulsewidth values but increments of 2us), the values are "ramped", i.e. interim values are sent so that the actual pulsewidth is changed over a series of increments over time.
My question is: To what·do the values (1-63) correspond, exactly? The only information I see in the doc is that a ramp value of 0 causes the change to be immediate, a ramp value of 1 corresponds to .75 seconds to change from existing to target pulsewidth (if the existing-target is the full range of motion), and a ramp value of 63 corresponds to 60 seconds to go from 250 to 1000.
It would be very useful to know to what the other values correspond, and how they work for travel distances less than the full range of motion.
I did some tests (I don't have a scope so I had to use servos), and it wasn't patently obvious. Is the time between .75 and 60 seconds parceled up in equal increments? Does a ramp value of 2 correspond to two times the ramp value of 1? (goes from current to target over a period of 1.5 seconds?)
I see that this has been fiddled with by looking at the release notes in the doc, and it's easy to program for a flexible definition of ramp in case it gets changed again, but knowing how it's implemented would be quite helpful in my application.
Thanks
-r
Post Edited (Rick K) : 6/13/2005 5:50:29 PM GMT
I'm starting this as a new thread even though there have been some other posts, since the ones I'm looking at haven't produced an answer·for me and have begun to wander a bit.
The ramp value for a PSC affects how the pulsewidth is changed from its current value to the value specified in the set servo position command, right?
For example, if I've got a servo set at a position value of 500 and I issue a command to set it to 1000, instead of it changing from a position of 500 to 1000 immediately (I realize that these are not pulsewidth values but increments of 2us), the values are "ramped", i.e. interim values are sent so that the actual pulsewidth is changed over a series of increments over time.
My question is: To what·do the values (1-63) correspond, exactly? The only information I see in the doc is that a ramp value of 0 causes the change to be immediate, a ramp value of 1 corresponds to .75 seconds to change from existing to target pulsewidth (if the existing-target is the full range of motion), and a ramp value of 63 corresponds to 60 seconds to go from 250 to 1000.
It would be very useful to know to what the other values correspond, and how they work for travel distances less than the full range of motion.
I did some tests (I don't have a scope so I had to use servos), and it wasn't patently obvious. Is the time between .75 and 60 seconds parceled up in equal increments? Does a ramp value of 2 correspond to two times the ramp value of 1? (goes from current to target over a period of 1.5 seconds?)
I see that this has been fiddled with by looking at the release notes in the doc, and it's easy to program for a flexible definition of ramp in case it gets changed again, but knowing how it's implemented would be quite helpful in my application.
Thanks
-r
Post Edited (Rick K) : 6/13/2005 5:50:29 PM GMT
Comments
For months and months now I've wanted to measure and plot the ramp values of several PSCs to arrive at a useful and postable average plot for everyone to use, but alas my duties have recently trippled and I haven't the time. (If some ambitious customer were to do this for me, it would certainly be worth a measure of free Parallax products! Contact me directly first to arrange this: jbarrowman@parallax.com)
The reason that a single equation was not given to describe the rate of movement for wach speed is that there are two algorthyms in place to facillitate the movement.
For speeds 1-7 there is one algorthym, and for speeds 8 - 63 there is another. Each alogrythm should be linear, but I seriously doubt that their respective graphs would be parallel. I hope this information helps, and I really hope someone takes my offer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John Barrowman
Engineering
Parallax, Inc.
Two non-parallel linear algorithms is actually not bad. Unfortunately (for me) I think you'd need some equipment to do this properly that I don't currently possess.
In order to reach a near-term milestone, I'll need to do some (probably very) rough work, and I'll post whatever I come up with in the interim even if it's a partial workaround.
Can you post the logic on which the algorithms are based so that we can have some intuition or create some expected results for testing purposes?