My Arduino is delaying functions

Hello, I uploaded to my Arduino mega 2560 a program that connects to ultra sonic HC-SR04 rangefinder
sensor and debugs on the serial monitor the range it detects.
I have run this on a dry run without the sensor yet but in either case my arduino reads 0 as it should be but the delay between each read is way more than it should be, it suppose to delay it by roughly 50 ms but in practice, it delays it like 1 second.
There is the code I used:

void op1(){
  
   pinMode(trig, OUTPUT);
   digitalWrite(trig, LOW);
   delayMicroseconds(2);
   digitalWrite(trig, HIGH);
   delayMicroseconds(10);
   digitalWrite(trig, LOW);
   pinMode(echo, INPUT);
   dist = pulseIn(echo, HIGH);
   Serial.println(distance(dist));
   delay(50);
}

Does somebody know why is that?
is something wrong with my arduino?

it spends time in function called by the function op1()

And your full code is ??

Also be aware that if you print a lot, the software output buffer used by e.g. Serial.print will fill up and block your code once it's full.

FYI: At 9600 baud, transmission of one character takes roughly 1 ms.

Juraj:
it spends time in function called by the function op1()

sterretje:
And your full code is ??

Also be aware that if you print a lot, the software output buffer used by e.g. Serial.print will fill up and block your code once it's full.

FYI: At 9600 baud, transmission of one character takes roughly 1 ms.

The rest of the code isn't the problem, I tried to delete the op1(); lines and it turned out to work fine.
Is there anything that I can do in order to make the calculations faster or make it work faster?

What is the timeout period of pulseIn?

dindibo4:
The rest of the code isn't the problem, I tried to delete the op1(); lines and it turned out to work fine.

You have an unknown function distance() in there; for all I know you can have a delay in there. I know it's not likely but we can't be sure.

We also don't know how often you call your op1() and you might be filling the serial buffer (as indicated).

dindibo4:
Is there anything that I can do in order to make the calculations faster or make it work faster?

Maybe use of the newping library? No experience with it but as far as I know it can be used non-blocking.

sterretje:
You have an unknown function distance() in there; for all I know you can have a delay in there. I know it's not likely but we can't be sure.

We also don't know how often you call your op1() and you might be filling the serial buffer (as indicated).
Maybe use of the newping library? No experience with it but as far as I know it can be used non-blocking.

Alright so there is the only time I call op1() and distance:

void initialization(){

for(int i = 0;i<=180;i++){
pos.write(i);
// op1();
range = dist;

• delay(initTime);*
• }*
• for(int i = 180;i>=0;i--){*
• pos.write(i);*
  // op1();
  range = avg(range*, dist);*
  * delay(initTime);*
  * }*

}
void op1(){

* pinMode(trig, OUTPUT);*
* digitalWrite(trig, LOW);*
* delayMicroseconds(2);*
* digitalWrite(trig, HIGH);*
* delayMicroseconds(10);*
* digitalWrite(trig, LOW);*
* pinMode(echo, INPUT);*
* dist = pulseIn(echo, HIGH);*
* Serial.println(distance(dist));*
* delay(50);*
}
double distance (double time){
* double v = 0.034029;*
_ return (vtime)/2;
}*
Parameters:
int initTime = 28;
int echo = 12;
int trig = 11;
double dist = 0;
bool initializationCom = false;
const double s = 1000;
double range[180];_

...and that's why we ask you to use code tags.

It's not the serial buffer - the delay(50) gives plenty of time for the output to print.

It's gotta be that pulseIn() is sometimes timing out (ie, not seeing a pulse).

DrAzzy:
It's not the serial buffer - the delay(50) gives plenty of time for the output to print.

That depends on what is printed at which speed; and I know that you know that

This is a flipping long text that can't be send in 50 ms at 9600 baud without delaying the code

DrAzzy:
It's gotta be that pulseIn() is sometimes timing out (ie, not seeing a pulse).

Hence the suggestion that the newping library might be a solution.

sterretje:
That depends on what is printed at which speed; and I know that you know that

Of course, if we didn't know what was being printed, we couldn't make an assertion like that. But we do know what's being printed - a single floating point value followed by a CRLF sequence, each pass through that function.

Ah, I didn't look at the latest code.

In the initial post didn't the OP say the sensor wasn't connected yet?

No sensor presumably means no pulse. So isn't pulsein() going to time out every time? And by a strange coincidence the default timeout is exactly the time he's complaining about (which is what I thought AWOL was trying to tell him before things went off in all sorts of other directions).

Steve