Visually, when all running together, the timing does not appear correct. It should be faster. I am guessing someone is going to suggest I use millis timing instead what I am using now.
Here is code and video of the setup:
int led1 = 9;
int led2 = 8;
int led3 = 7;
int led4 = 6;
// the setup routine runs once when you press reset:
void setup() {
// initialize the digital pin as an output.
pinMode(led1, OUTPUT);
pinMode(led2, OUTPUT);
pinMode(led3, OUTPUT);
pinMode(led4, OUTPUT);
}
// the loop routine runs over and over again forever:
void loop() {
digitalWrite(led1, HIGH);
delay(100);
digitalWrite(led1, LOW);
delay(20);
digitalWrite(led1, HIGH);
delay(100);
digitalWrite(led1, LOW);
digitalWrite(led3, HIGH);
delay(250);
digitalWrite(led3, LOW);
delay(0);
digitalWrite(led2, HIGH);
delay(100);
digitalWrite(led2, LOW);
delay(20);
digitalWrite(led2, HIGH);
delay(100);
digitalWrite(led2, LOW);
digitalWrite(led4, HIGH);
delay(250);
digitalWrite(led4, LOW);
delay(0);
}
As best I can tell from the video the LEDs do exactly what the program suggests they should do. However, it's hard to tell because I don't know which LED is which and the flashing is too fast.
I suggest you increase all the delays by 10 times and check again.
In the video, LEDs 1 and 2 (alternating double flash on each one) are on the left and LEDs 3 and 4 (alternating single flash on each one) are on the right.
The simulation should be faithful. The only thing that might happen is that it gets bogged down doing the simulation, and runs slow with respect to real time.
Can you please post a link to your wokwi simulation so it can be fairly judged as to whether it is a, or the, problem here?
I was going to suggest that you add printing, in particular printing the value of millis() at various pints will allow the Arduino to time its own activities; it is quite likely that your code is and always has been behaving exactly to plan.
Not to me! We were able to run the video and the simulation at the same time as well, there it looked quite like they were very similar. Single step the video and watch, it takes 28 frames for the loop to loop.
I added timing to your sketch in the simulation you linked (thanks!) and it reports that each pass of the loop takes 940 or 941 milliseconds, which is the sum of all the delays.
28 frames at 30 fps is 933 milliseconds. Since I am eyeballling this, that's the same time as the sim.
You can get a better sense of it if you just watch one LED. The video of about 7 seconds allowed the one I was watching to blink about 7 times...
So we can leave the wokwi boys asleep on this matter.
Yeth. TBH I'd be happier if it just ran at one speed no matter it be slow but did not deviate.
One sad fact is that no matter how slow a simulation, any RTC will keep perfect real time. I feel this makes it worth somewhat less. Other than that, everything happens in the same order, and there's a "real time" ticker along with the percent of real time achieved, so most development can proceed. For some things you just slow you brain down to match.
LEDs are handled but anything visual effects orientated has to be tested IRL.
My tablet is so slow it's useless, even if using it on a tablet weren't already PITA.
My big rig gives 99 - 100 percent on the kinds of things I throw at it.
Whatever you did, it's wrong. You need a long enough time during the "LOW" time, or the electronics will not react, or your eyes will not see the blink.
