The servo has a maximum speed. If the pulsing stops before the position is reached, the servo stays where where it got the last pulse.
What I'm a bit surprised that there is no pin initialization. I would expect something like
pinMode(A0, "output"); A0.reset();
at the beginning. May be it is not needed because the first digitalPulse() takes care of it in its own way. The module works as follows:
every 20ms (50 times in a second) a pulse is sent
the rising flank of the pulse starts on some servo internal single pulse generator a pulse
the servo internal pulse length is defined by the position of the shaft converted into a resistance / voltage divider by a potentiometer which turns with the shaft.
for the pulse length differences of the servo internal pulse and the externally applied pulse the servo motor is given power in either forward or reverse direction to close the gap between the pulse lengths.
pulses have to be sent until the servo has closed the gap (internal pulse matches externally applied pulse) and with that servo has reached commanded position.
Therefore, depending on the speed of the servo, it may take one servo more pulses to get to a particular position than another one, and if not given enough pulses at all, the servo never can close the gap... and never gets to the commanded position.
This is the logic the module applies. Since you can control the time from the outside, you may give not enough time - not enough pulses - and the servo can not 'get there'. In a wrapper around the module invocation you may calculate the minimum time - depending on the position difference and the maximum speed (angle speed = positions per time unit) - you have to 'give' in the move command so that the servo has enough time 'to go there'. As a module builder, I would have anyway an accelerating and decelerating profile with a ramp up, a max speed and a ramp down... or at least a few extra pulses when theoretically having 'arrived' at commanded position. The module calculates the difference but does not apply them when in an E-psilon (Math.) range, at which the difference is considered not existing anymore. When reached that point, a few pulses with the final value would have to be applied.
With processor we can stop sending pulses - and avoid jitter / unnecessary power consumption. In (old) RC model control, the pulses would keep coming and differences are constantly corrected. This has of course power consumption ramification... and if the pulse length and the internal pulse generation are not highly stable, the servo never comes to rest. It keeps jittering/shivering, which raises serious concerns / power usage.
*** EDIT / ADDENDUM ***
More recent / modern servos have now different ways to 'measure' the position / angle of the shaft / arm...
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
The servo has a maximum speed. If the pulsing stops before the position is reached, the servo stays where where it got the last pulse.
What I'm a bit surprised that there is no pin initialization. I would expect something like
at the beginning. May be it is not needed because the first
digitalPulse()
takes care of it in its own way. The module works as follows:Therefore, depending on the speed of the servo, it may take one servo more pulses to get to a particular position than another one, and if not given enough pulses at all, the servo never can close the gap... and never gets to the commanded position.
This is the logic the module applies. Since you can control the time from the outside, you may give not enough time - not enough pulses - and the servo can not 'get there'. In a wrapper around the module invocation you may calculate the minimum time - depending on the position difference and the maximum speed (angle speed = positions per time unit) - you have to 'give' in the move command so that the servo has enough time 'to go there'. As a module builder, I would have anyway an accelerating and decelerating profile with a ramp up, a max speed and a ramp down... or at least a few extra pulses when theoretically having 'arrived' at commanded position. The module calculates the difference but does not apply them when in an E-psilon (Math.) range, at which the difference is considered not existing anymore. When reached that point, a few pulses with the final value would have to be applied.
With processor we can stop sending pulses - and avoid jitter / unnecessary power consumption. In (old) RC model control, the pulses would keep coming and differences are constantly corrected. This has of course power consumption ramification... and if the pulse length and the internal pulse generation are not highly stable, the servo never comes to rest. It keeps jittering/shivering, which raises serious concerns / power usage.
*** EDIT / ADDENDUM ***
More recent / modern servos have now different ways to 'measure' the position / angle of the shaft / arm...