Loops driving me loopy

#1

1) Give a description of the problem
I have a real basic piston. If switch is on, log once every second.
I have tried using a WHILE loop as well as a REPEAT loop with the same results.

2) What is the expected behavior?
Log should write one line every second while the switch is on

3) What is happening/not happening?
It works great 10 times in a row, and then there is a 3.5 second delay, then works ten times in a row, then a 3.5 second delay… Can anyone please shed some light why there is a hiccup after every ten seconds??
(and more importantly, how to bypass that issue)

4) The variables below are just to make troubleshooting easy

temp
temp.jpeg408×582 43.3 KB

5) The log below was left running for over 30 seconds straight

temp2
temp2.jpeg216×791 49.8 KB

Notice the highlighted pauses being MUCH more than they should have been.

Is there a workaround for this, or should I file a bug report?

Lights Flash when Ring Motion Detected
Piezo beep (Entry/Exit delay). Strange behavior
#2

Upon analyzing my FULL log, I notice a pattern.

At the end of the 10th log (the last in the cluster) it schedules a wake up for 1 second in the future. But for some reason, in the next cluster, there is an extra delay of more than 2 seconds. This is the EXACT delay that is impacting this piston.

Here is an example focused on the last few lines of one cluster, and the first few lines of the next one.
(Sorted chronological, not the way it displays in webCoRE)

temp

This extra delay repeats every ten seconds, and is the likely culprit.

Any idea why the 6:27:35 wake up did not happen until 6:27:37?

#3

Semaphore? Maybe a built in delay to prevent a runaway piston from bringing down the servers?

What happens when you increase the delay to 5/10/15 30 seconds. Still the same hiccup?

#4

In none of my testing did I see a semaphore delay while the piston was running.
(although occasionally I saw one at the very end when cancelling the piston)

I just re-tested using a 5 seconds delay, and it still hiccups.
The main difference is it now hiccups EVERY single time, because after each log command, the next one gets rescheduled as a wake up.

By the way, for the record, I realize that spamming once per second is not a good habit, but this is a unique piston, that will only run for 20 seconds twice a day, so I am making an exception this time. :sunglasses:

Maybe one of the @webCoRE_Minions can share some wisdom on how to bypass the scheduled wake up. (which really shouldn’t be happening since the delay is so short)

If we cannot bypass it, then maybe someone can shed some light on why it never continues at the proper time.

#5

dont remember the exact code off hand … but wC forces a wake up when there is less than 10 seconds of the 20 second timeout ST enforces for any app execution.

till those first 10 seconds are over the waits are handled by pausing the app and then switches to a wake up on the next wait because it crosses the 10 seconds boundary.

#6

Are you saying that there will always be a 2-3 second delay each time there is a wake up command? (like in my original post)

#7

almost always because ST scheduling methods like runIn(…) or schedule(…) are not precise to the seconds.

#8

Ahh thank you.
I’m disappointed, but at least I won’t waste any more time trying to make it happen. I never noticed it before, but then again, I have never tried to repeat a command so quickly before either.