Servo problems with VarSpeedServo.h


I have problems with servo control on a Arduino Nano for manually switching turnouts on a analog model railway.

After power on, pressing one of the buttons, that servo goes with reduced speed as it should be.

Pressing another button, that servo goes high speed to endpoint, high speed to midpoint, and finally slow speed to endpoint.

That first high speed gives a short on the layout due to the frogrelay which should go on or off at midpoint.

ServoSpeed.h was made by user Korman.
I alse found another version dated 2013, but that one has the same issues with the speed.

Regards, Martin.

// servo test

#include <VarSpeedServo.h>

#define NrServos sizeof(ServoMap)
#define NrFrogs  sizeof(FrogMap)

VarSpeedServo myservo;

const byte ServoMap[] = {9, 7, 5, 3};
const byte FrogMap[] = {10, 8, 6, 4};
byte ServoPos[] = {0,0,0,0};
const byte LedArduino = 13;
const int BeginPos = 45;
const int MidPos = 90;
const int EndPos = 135;
int Switchnr;

// ************************************************
void setup() {

    //setup the LED
    pinMode(LedArduino, OUTPUT);
    digitalWrite(LedArduino, LOW);

    // setup frog pins
    for (byte i = 0; i < NrFrogs; i++) {
       pinMode(FrogMap[i], OUTPUT);
       digitalWrite(FrogMap[i], LOW);
    // setup servo pins 
    for (byte i = 0; i < NrServos; i++) {
       pinMode(ServoMap[i], OUTPUT);
       digitalWrite(ServoMap[i], LOW);
} // end setup
// ************************************************
void loop() {
  if (Switchnr < 8) {
      Switchnr = Switchnr / 2;
      digitalWrite(LedArduino, HIGH);
      if (ServoPos[Switchnr] == 1) {
        myservo.slowmove(MidPos, 30);
        delay(1000);                 //wait for servo
        digitalWrite(FrogMap[Switchnr], HIGH);
        myservo.slowmove(BeginPos, 30);
        ServoPos[Switchnr] = 0;
       else {
         myservo.slowmove(MidPos, 30);
         digitalWrite(FrogMap[Switchnr], LOW);
         ServoPos[Switchnr] = 1;
       delay(1500);   // wait for servo
       digitalWrite(LedArduino, LOW);

}  // end loop
// ************************************************
void GetSwitch()  {
   int sensorValue;
    sensorValue = analogRead(A6);
    if (sensorValue < 1000) {         // switch pressed?
        Switchnr = map(sensorValue, 0, 1023, 0, 9);
    else  {
      Switchnr = 9;
    while (sensorValue < 1000){        // wait for switch release
      delay (20);                      // give a-d converter some time
      sensorValue = analogRead(A6);

I've never used .slowmove() which I believe is only in there for compatibility with old code.

Have you tried it with the preferred .write(angle, speed, wait) version which has the "wait until finished" option?


Yes I did, and that makes no difference at all.

In this sketch I use the delay to wait for the servo to complete.

Because of the servo shoot away when power is applied, I added a 4k7 resistor between the signal and the +5V on each servo. Now they stay where they are.
Servo's are SG90 and SG92R - both working the same.


The only thing that looks odd to me is the way you keep attaching and detaching the servos. It may not be the problem but detaching does leave the servo with no control signal so it can potentially float about and then attaching again causes the library send an initialise signal which I think is done at full speed. In my (non-railway) use of servos I've always just attached them all in setup() and left them.

But I'm a little confused. Are you saying that the code you posted now works?


Hi Steve,

I've tried both ways - yes or no detach. Does not make any difference.
The code in the first post is the current code.

But why the highspeed? It also happens after a few minutes of not switching. That high speed of the servo's is random between the servo's.


Just to check, is this the version of the library that you're using?

I was guessing that it was something to do with using a single servo object and switching it back and forth between different pins all the time which is not a very normal way to use the library. But I've tried a few simple tests like that and I can't get anything odd to happen. And now you say it happens randomly it's even more confusing.

We could go through the usual "Is the power supply adequate?", "All the grounds connected together?", "Show me a full circuit diagram" etc. but none of those sort of things seem to fit the symptoms and I have a feeling you probably have them under control.

I think you've beaten me. Sorry. I hope someone else can help.


On reattaching the servo, it may be going to default position of 90 degrees if you have not allowed for that. No experience with VarSpeedServo though.
Please post a link to the library you are using.

I keep re-reading the thread, but I cannot see a clear description of what you are trying to do, and what actually happens.

Your original post stated that pushing buttons gives a certain sequence of moves.
But somewhere along the way a short happens.

Is the servo moving as you intend, or is there some difference between the servo movement you intend and the actual servo movement?

Is the short created because of unexpected servo behavior?

There are 2 versions of the library: one made by a user called Korman (Kornan?) dated 2009 and another extended one from 2013 to which you refer in the link.
I've used both libraries, and find no difference in how the servo's react.
Currently I use the 2013 version.

Each pushbutton should move a servo - 4 buttons for 4 servo's. Pressing a button must move that servo from 45 to 135 degrees and vice-versa with a stop at 90 degrees to allow the frogpin to switch a relay.

Hardware: mounted the Nano, servo connectors and pushbuttons on a testprint. Power is a 5V/2A adapter giving power to the testprint. From there power goes to the Nano - both 5V and gnd.


Good. A better description of what you intend for the application to do.
Does it do it? I might have missed it, but I do not see a description of where the actual behavior differs from your intended behavior.
Can you elaborate?

To elaborate:

Why is a servo moving HIGH SPEED all the way to the other end (either 45 or 135 degrees) ?
Why is it moving HIGH SPEED back to the midpoint?
Why is it moving SLOW SPEED to that same end?

I hope this is clear.

Otherwise the sketch is functioning as I wanted it.

In other words why does it seem that VarSpeedServo is sometimes ignoring the speed part of .write(angle, speed) or .slowmove(angle, speed) where speed is always 30, i.e. slow? The servos always move to the correct places but sometimes at full speed not slow speed. Is that correct?


Yes, that's the case.

( remark: the Nano has the Optiboot loader).


Can you write a simple bit of code that just tries out these various commands with ONE servo and two buttons.

Have you got a bit of code like that, you should have as you developed your code, before you went to arrays to give you multi servo operation.

Get a simple bit of code working for ONE servo, then develop it for more., forget arrays at the moment, they only cloud the code.
A simple code will be easier to debug and see what is happening.
You may have to try a different strategy to get your sweep, pause, sweep and speed control.

It sounds like you need to come to terms with the library, so do this first please.
It may sound long and laborious, but it will result in less bugs and a better understanding of how the library functions work.

Thanks.. Tom... :slight_smile:


Sorry, but that's of no use.
Pressing a button over and over again will cause that servo slowly move back and forth, just how I want it.

Testing over and over again I found another strange thing: pressing a button an even number (2, 4, 6, etc) before switching to another button results in all 4 servo's going with low speed.

Pressing a button an odd number, I will have that high speed problem again.


The only thing I see suspicious is as pointed out earlier, detaching and attaching the servo possibly creating a full speed move to whatever the default initial position is.

Why not follow the norm and keep the servos attached and remove the doubt? Attach in the setup and never detach.

And a link to where the download for your library would help too (also as mentioned earlier).

The servo.detach was already removed by me.

The link to the library was already given in post #5, but here it is again:

What MartinAP doesn’t specifically mention is that he needs the attach() because he’s using just a single Servo object and in the code is then attach()ing it to different pins for his different servos. That’s certainly not how Servo.h is normally used.

So that’s the bit that makes me uncomfortable but I haven’t managed to get it to fail here.



Sorry, but that’s of no use.
Pressing a button over and over again will cause that servo slowly move back and forth, just how I want it.

Testing over and over again I found another strange thing: pressing a button an even number (2, 4, 6, etc) before switching to another button results in all 4 servo’s going with low speed.

Pressing a button an odd number, I will have that high speed problem again.


Okay, so cut your code down to an array to control ONLY two servos and test.
Completely physically remove the unused servos.
Then add the third and test.
Then the fourth and test.
The minute you add a servo and the problem appears, check it with the previous code.

Are you monitoring your servo power supply voltage while you are troubleshooting?
How are you powering the servos and the nano?

Can you please post a copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png?

Please add some serial print statements to check if the button you are pressing is the button being detected, I see that you are using the analog potential divider method of button selection.

Tom… :slight_smile:

The servo.detach was already removed by me.

Cool. Can you post the latest version of your code that we are all working from?

The link to the library was already given in post #5, but here it is again:

Cool. I saw Steve post the ling but as a question. Good to know this is the one.
As a side comment, I see that this library was modified 2 hours ago. I wonder if getting a new version might fix some problems.