You may need to revisit your mechanical setup for ringing a bell with a servo. Servos move slowly, which may require a mechanical setup different from what you have to be successful. 

The bell rings just fine - it's just this darned delay I want to eliminate.

Any ideas?

Not really, as you talk of code that doesn't work for you without explaining what you are actually trying to do. If you are using "hobby" servos, I've never seen one containing worm gears. Having a servo strain against a spring might not be a good idea unless the spring is used as a counter balance for some type of a load. You should also describe what function a delay in your code serves.

Sorry.

If I don't include a delay after each instruction to the servo, the servo doesn't move. It doesn't seem to have time to complete the task required of it and the arduino seems to continue onin the loop and forget the command to the servo. If I include a delay the servo moves.

The delay after a command to move to Microseconds(2300) is manageable. It's the delay after Microseconds(600) that I'm keen to eliminate because this is encountered ALL the time in my sketch.

I had hoped to be able to use "detach" to return the servo to a default position given that the bell cord is lightly sprung.

Basically my  servo pulls a string which is attached to and thus rings a bell. It's important that for the bell to ring just once per request that the back and forth movement of the servo arm is conflated into one as far as the bell is concerned.

I can attach a YouTube video if this is still unclear.

(the servo arm is connected to a spring so the power of the (now) unresisted spring should enable a return).

Not a good idea. The servo normally goes through a worm gear and it is not a good idea to try and drive those backwards.

Oh? I thought it was possible to move a servo manually through its range of rotation (for example to test its limits)? Didn't realise it was damaging...

Any ideas?

Use the blink without delay method to write your program.

OK...was hoping to avoid that as it's going to be quite complicated for my sketch.

This is an excerpt from my loop. I would prefer to have as few as possible uses of delay in my sketch. I would prefer to "detach" the servo to cause it to return to its original position (the servo arm is connected to a spring so the power of the (now) unresisted spring should enable a return). However, this doesn't seem to work.

Code:

if (bedroomVoltsRead < 100)
  {
    if (currentMillis-bedroomTriggeredTime > debounce) 
    {
      bedroomTriggeredTime = currentMillis;

      if (bedroomState == OFF)
      {
        bedroomState = ON;
        if (bedroomLEDState == OFF)
        {
          bedroomLEDState = ON;
          if(value3) 
          {
            BellControlServo.attach(6);
            BellControlServo.writeMicroseconds(2300);
            delay(200);              // wait for a bit
          }
          bedroomLEDTimeStamp1 = currentMillis;
          Serial.println();
        }
        else if (bedroomLEDState == ON)
        {

          bedroomLEDState = FLASH;
          if(value3) 
          {
            BellControlServo.attach(6);
            BellControlServo.writeMicroseconds(2300);
            delay(200);              // wait for a bit
          }
          bedroomLEDTimeStamp1 = currentMillis;
        }
      }
    }
    else
    {
      bedroomState = OFF;
      BellControlServo.attach(6);
      BellControlServo.writeMicroseconds(600);
      delay(200);              // wait for a bit
      BellControlServo.detach();
    }
  }
  if (bedroomLEDTimeStamp1 + LEDOnDuration < currentMillis)
  {
    bedroomLEDState = OFF;
  }
 

In particular I understand each time the arduino goes through the loop this bit is executed. So I have a delay of 1.2seconds every time the loop is executed even if nothing is happening because I have six of these in my loop. If something is happening the delay is potentially 7.2 seconds!

Code:

    else
    {
      bedroomState = OFF;
      BellControlServo.attach(6);
      BellControlServo.writeMicroseconds(600);
      delay(200);              // wait for a bit
      BellControlServo.detach();
    }

Any ideas?

Thanks!

so it sounds like there is another issue with another part of your code, then.

Maybe I put your snippet in the wrong place?

Code:

long switchPinsWaitTime = 30000; //30 seconds

Code:

  static unsigned long switch_timestamp1 = 0;

  if(value2 && switch_timestamp1 && (millis() - switch_timestamp1) >= switchPinsWaitTime)   
  {
    //    playTone(100, 1000);
    //    playTone(100, 3000);
    //    playTone(100, 1000);
    //    playTone(100, 3000);
    switch_timestamp1 += 60000;
  }

  else if (!switch_timestamp1 && value2)   
  {
    //The !switch_timestamp1 is to make sure we don't refresh the timer if the switch remained on.
    //The pin just changed to on, start the timer
    switch_timestamp1 = millis();
  }
  else if(!value2 && switch_timestamp1)   
  {
    //Switch went off, while timer was running, disable the timer
    switch_timestamp1 = 0;
  }

Code:

switch_timestamp = millis() + ( 6000 );

What this means (assuming timestamp isn't changed), is that after 6 seconds, the timestamp will will be equal to the current time, so that means overall, it will run again 6 + interval seconds. If you want it to run every minute, then you simply need to add 1 minute to what the current timestamp is:

Code:

switch_timestamp += 60000;

Hmmm - tried that - it didn't do the trick either. Thanks though!

One "hack" you could do to get this working fast, is every time you play the tone, reset the switchPin1TriggeredTime back to the current system clock.

Like so:

Code:

  if(switch_state && switch_timestamp && (millis() - switch_timestamp) >= switchPin1TriggeredTime)   {
  //play a short alert tone every minute
     playWarningTone();
     switch_timestamp = millis() + ( 6000 );  //Re-fire the event every minute after the first 2 minute warning.
    }
 

Thank you for this hack, it seems to have a lot of potential. However when using it, I've found that what happens is that the warning tone is re-fired after switchPin1TriggeredTime - not every minute. Would you mind seeing if there's something simple to address to get it working? I've had a play myself to no avail :-)

THANKS AGAIN

How the relay circuit is wired:

How the relay interfaces with the Arduino and the phone cable.


I'm just surprised because I had understood that the switched pole was isolated electrically from the relay/arduino/PSU.

Yes, very good. But what about the error when I remove the line you suggested?

In my non-working example,

Code:

const int relay = 4;

is changed to

Code:

const int relay = 10;

Sorry, I had explained this in my original "first post" - which I then contrived to wipe!

Hi!

I'm trying to switch one of the three internal wires which run to a phone in my house.
When I do this with a mechanical switch and simply introduce a break in the wire, attach one side to one pin of the switch and the other side of the break to the other pin, things work as unexpected.

If I use an Arduino controlled relay, I get the most awful deep hum on the line (ground loop?).

I had understood that the switched connectors on a relay were independent from the rest of the circuit, being controlled by an electromagnet which I had supposed didn’t actually touch.

Does anyone know how I might be able to be rid the hum, or if it’s for some reason part and parcel?

Thanks

I also find this strangely confusing

Sorry - that'll be an error I introduced when stripping back my code. Of course it has to be and should be done but it's one of the reasons I was keen to strip as little possible. Please note I'm not trying to start an argument - just explaining the anomoly. I've amended the code.

Because you have declared the pin to be an output pin, reading from it returns the last value written to the pin. Output pins are, by default, LOW, so it is not surprising that the pin always reads LOW.

Hi Paul - actually the reverse appears to be true. In its current state (posted above) the sketch works. But I'm confused as to why. If I remove the 'relay' output assignation it ceases to work.

I find it hard to believe that 186 lines is the smallest code which would display this fault.

I'm not sure I care whether that is rude or not.

You were right, I could and have stripped it down more than I already had. I have now stripped it down to the bare bones. The rest I didn't do this earlier is because in this reduced state the sketch won't "do" anything, but the logic is still there.

This wasn't rude either - not even close. However - to not care whether something might be rude is in itself rude.

Not to be rude... but stripping your code out of what doesn't matter for this doubt of yours so we wouldn't have to parse through all the program would be nice.

As it turns out you're not at all rude, but presumptuous because I did exactly that. My actual code is 943 lines long, the above stripped version 187.

Thanks

"The logic looks quite convoluted"
"I suggest you do some major simplification on your control logic"
"shouldn't need that much complexity".

Hi Peter

I didn't think my logic was that convoluted or complex - are you talking about the where I posted the code for the entire project?

I think what I'll do is include a millis-debounce check to only run the if ( Udp.parsePacket() ) if it hasn't been run in the last 25 minutes.