The problem mentioned in the post 17 has not been resolved.
Nope I solved it you should check it (post#18)and it is working
Look - the line
never be reached if the condition
is false. And it could be false if somebody lower the car after the signal.
In this case the buzzer still sound forever
There are other logic errors in your code as well. For example, your code will turn on the buzzer and light again and again after the first turn on, because you change the buzzerState only after the interval has elapsed, but you need BEFORE.
For that I have added the noTone(buzzer) in else statement also
Also I tested my code here
ok
Keep in mind that all your edits are visible .
Oh yeah but you can check the time I edited
I edited it before your reply 
@amitf which is to say… don't edit your previous posts to make subsequent responses meaningless. Or make the respondent look like idiots, which they are not.
a7
However with the buzzerState flag you still don't work optimally. In fact, you don't use it.
I also think so.
But I am not a programmer I'm a high school student and have no idea how to improve that
@amitf thank you for using the wokwi simulator so we can see how your program works, or doesn't.
And thanks for helping the OP. In the future, please get your code fully working in the wokwi before you post it on a world-wide forum and get a bunch a people to help you fix it.
As you have seen, there is no excuse for posting code you haven't tested and fixed.
a7
sorry
I should note that I did not test my code in the post above before posting it on the forum ...
If there are mistakes, somebody will point it out, this is part of the communication.
1 Like
I just ran it and it does not work.
Unless you start with distance < 10, you get no tone.
If you start with distance < 10, you get one tone blast. Never again hear tone.
Back to the drawing board.
a7
Well your code didn't work, but I did have to guess how to put it into the OP's wokwi.
So... as well as testing, another good idea is to always post a complete-it-compiles sketch that we can try for ourselves.
I understand that errors get out of captivity and many eyes here are a blessing, but if you (all) are trying to help the OP, posting untested code and/or snippets is not. Helping.
a7
Is it about the code from post 18?
I don't see why the code won't work if the initial distance is more than 10
#define trigPin 13
#define echoPin 12
#define led 11
#define rele 10
#define buzzer 9
int buzzerState = 0;
unsigned long currentMillis;
unsigned long previousMillis = 0;
const long interval = 5000;
void setup() {
Serial.begin (9600);
pinMode(trigPin, OUTPUT);
pinMode(echoPin, INPUT);
pinMode(led, OUTPUT);
pinMode(buzzer, OUTPUT);
pinMode(rele, OUTPUT);
}
void loop() {
long duration, distance;
digitalWrite(trigPin, LOW);
delayMicroseconds(2);
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);
digitalWrite(trigPin, LOW);
duration = pulseIn(echoPin, HIGH);
distance = (duration / 2) / 29.1;
if (distance < 10)
{ digitalWrite(led, HIGH);
if (buzzerState == 0)
{
currentMillis = millis();
tone(buzzer, 2500);
}
if (currentMillis - previousMillis >= interval)
{
previousMillis = currentMillis;
noTone(buzzer);
buzzerState = 1;
}
digitalWrite(rele, LOW);
}
else {
digitalWrite(led, LOW);
noTone(buzzer);
buzzerState = 0;
digitalWrite(rele, HIGH);
}
Serial.print(distance);
Serial.println(" cm");
delay(500);
}
now it works
Edit:- although it still have some bugs
@alto777 can you improve it instead giving us lecture
By the way, I would not exaggerate the value of testing. Very often the wrong code "works" for some time.
Understanding the logic of the code usually gives more than tests, especially for small codes.
The relativity of testing is confirmed by the analogy with a traffic light - from the fact that someone once successfully drove through a red light, it does not follow that it "works"
Not sure what you mean.
I would not underestimate the value of testing.
In all the cases where the various code posted here doesn't work, it was either reading it and knowing that it obvsly wouldn't, or 10 seconds of testing to see.
At worst, a few minutes to take any complete code into the wokwi, and then 10 seconds of testing to see flaws.
a7
I'm talking about those cases when the author claims that his code is fully tested and works for a year without problems, but you see obvious errors in the code - I don't believe in tests 
In general I agreed with you and think that it will be better for me to delete my post with untested code.
But we have moved away from OP problem, this is already offtopic.
ok this last code...i tested it and sometimes it works and sometimes not....a bit strange
Welcome to computer programming. The nice thing about it, and especially when using the simulator, is that it is highly probable (an almost virtual certainty) that the code is doing what you wrote, not necessarily what you meant.
So put your finger on your code and follow the logic. Add some Serial.print/println statements to check the value of key variables and the flow through the code.
You must be getting quite close to working out how to do the OP's required process.
In simple programs like this, it helps (me) to have a full design that doesn't involve any real code - pseudo-code or flowchart or even scribbling on the back of the proverbial envelope.
By the time I am writing actual code, there is no more to do than write the code. When we are working with other ppls' code, then it becomes a matter of fixing flaws, which as you have seen is fraught. It is easy to spot flaws and patch them, but seems inevitably to initiate a series of patches and new errors and so on.
I say again the wokwi is a game-changer. Without any of the OP's hardware you have it all working (or not!) in captivity, free of all hardware issues and issues ariding from physical circumstances.
Which no doubt will be the OP's next set of challenges once some simple code is sorted.
a7