NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.7

First off, yes, it's designed for Arduino 1.0 only. I'm not sure if at this point development for old versions is really required.

Anyway, I have a bit of a problem with your sketch. You use a delay! Really, you should try to avoid using a delay at all cost, and the sketch is built to not need to use it. The entire problem with the other ping/ultrasonic libraries out there is that because they can add up to a second of delay, it breaks your event-driven sketch.

If you want to slow it down, simply change the pingSpeed, that's what it's there for. It appears you want to only do a ping once a second, so set pingSpeed to 1000 and remove the delay. My guess is that your goal is to have both sensors ping as close to the same time as each other, then print the results, and do that once per second. Here's the proper event-driven code to do that:

#include <NewPing.h>

NewPing sonar1(11, 12, 200); // Sensor 1: trigger pin, echo pin, maximum distance in cm
NewPing sonar2(9, 10, 200); // Sensor 2: same stuff

#define pingSpeed 1000 // Ping frequency (in milliseconds), fastest we should ping is about 35ms per sensor
unsigned long pingTimer1, pingTimer2;
int in1, in2;

void setup() {
  Serial.begin(9600); 
  pingTimer1 = millis() + pingSpeed; // Sensor 1 fires after 1 second (pingSpeed)
  pingTimer2 = pingTimer1 + 35; // Sensor 2 fires 35ms later
}

void loop() {
  if (millis() >= pingTimer1) {
    pingTimer1 += pingSpeed; // Make sensor 1 fire again 1 second later (pingSpeed)
    in1 = sonar1.ping_in();
  }
  if (millis() >= pingTimer2) {
    pingTimer2 = pingTimer1 + 35; // Make sensor 2 fire again 35ms after sensor 1 fires
    in2 = sonar2.ping_in();
    // Both sensors pinged, process results here
    Serial.print(in1);
    Serial.print(" - ");
    Serial.println(in2);
  }
  // Do other stuff here, notice how there's no delays in this sketch, so you have processing cycles to do other things :)
}

This code will ping both sensors once per second as close in time to each other as possible, then output the results. It also will never get in a situation where it could have a 2 second delay. It will always fire exactly every 1 second.

Hope that helps better understand the event-driven programming method and why it's so important for real-world applications.

Tim