Understanding Scheduling Timers

#21

I have bent over backwards to help, and you have dismissed everything I have said, and made no changes to your code whatsoever.

I can only talk to a wall for so long before I wander off…

#22

Here you go:

image
image.png1178×661 71.6 KB

#23

*sighs*

Ten hours worth of conversation, and not a single thing I mentioned is in your piston…

#24

If you don’t want to help that’s fine … it seems strange you’re getting defensive. All I am focused on is the specific problem in my post.

Thanks!

#25

I want to help, or I would not have invested this much time with you. But when you ignore every single thing I say, and do not follow any of my advice, I loose interest in wasting any more time.

No hard feelings

#26

I dont think you have actually tried to run the piston or you would not be off on tangents. There is a specific issue I am bringing up here.

I welcome others you may have expertise that can offer some pointers. This is a specific detail that you may not be familiar with, but thanks for taking the time!

James

#27

Your first import code was corrupt. This new one came thru. Testing now

#28

ok thanks! Not sure what I did wrong posting it :slight_smile:

#29

My freetime is almost up for today, but a few observations after a bunch of testing.

(1) Your variable {changeCount} is never reset. It has to be manually reset when it hits 5, or any other tests will fail

(2) It loops 5 times (as expected), changes {timerTmp} 5 times (as expected) but only sets a schedule for the most recent one. (also as expected)

(3) The internal IF is ignored on the first 5 loops (as expected)

(4) When the first wakeup happens, it runs thru another 5 loops, changes {timerTmp} 5 times again, but this time it does match the internal IF all 5 times (this surprised me, but I guess there is a tiny window, since it all happens in under a second). It then sets a schedule for the most recent time like before.

(For anyone else reading this, do yourself a favor and keep IF Triggers outside of other IF Triggers. James got lucky because it fires 5 times in under a second, but it will usually cause much grey hair and frustration)

(5) This entire process runs top to bottom 5 times, meaning the loop is happening 25 times. (the internal IF happens 20 times)

I imported your piston, and did nothing to it except add more logging.

Here is the piston I tested:

temp
temp.jpg546×647 59.6 KB

and here is the resulting log in chronological order, with the first action at the top, and the last action at the very bottom:

12/21/2018, 3:29:01 AM +893ms  <-- FIRST RUN AFTER PUSHING TEST
+113ms 	║Piston began at 3:29:01 AM
+144ms 	║Before loop on 3:29:02 AM
+168ms 	║Inside loop on 3:29:02 AM
+208ms 	║timerTmp is 3:29:22 AM  <-- This is the one that actually schedules
+266ms 	║Inside loop on 3:29:02 AM
+306ms 	║timerTmp is 3:29:37 AM
+342ms 	║Inside loop on 3:29:02 AM
+382ms 	║timerTmp is 3:29:52 AM
+416ms 	║Inside loop on 3:29:02 AM
+456ms 	║timerTmp is 3:30:07 AM
+488ms 	║Inside loop on 3:29:02 AM
+531ms 	║timerTmp is 3:30:22 AM
+559ms 	║changeCount is 0
+584ms 	║changeCount changed to 1


12/21/2018, 3:29:21 AM +105ms
 +511ms 	║Piston began at 3:29:21 AM
 +535ms 	║Before loop on 3:29:21 AM
 +557ms 	║Inside loop on 3:29:21 AM
 +594ms 	║timerTmp is 3:29:41 AM  <-- This is the one that actually schedules
 +632ms 	║Internal IF on 3:29:21 AM
 +653ms 	║Inside loop on 3:29:21 AM
 +691ms 	║timerTmp is 3:29:56 AM
 +730ms 	║Internal IF on 3:29:21 AM
 +753ms 	║Inside loop on 3:29:21 AM
 +791ms 	║timerTmp is 3:30:11 AM
 +818ms 	║Internal IF on 3:29:21 AM
 +839ms 	║Inside loop on 3:29:21 AM
 +877ms 	║timerTmp is 3:30:26 AM
 +903ms 	║Internal IF on 3:29:21 AM
 +924ms 	║Inside loop on 3:29:22 AM
 +967ms 	║timerTmp is 3:30:42 AM
+1012ms 	║Internal IF on 3:29:22 AM
+1041ms 	║changeCount is 1
+1079ms 	║changeCount changed to 2


12/21/2018, 3:29:41 AM +131ms
+100ms 	║Piston began at 3:29:41 AM
+125ms 	║Before loop on 3:29:41 AM
+147ms 	║Inside loop on 3:29:41 AM
+186ms 	║timerTmp is 3:30:01 AM  <-- This is the one that actually schedules
+223ms 	║Internal IF on 3:29:41 AM
+245ms 	║Inside loop on 3:29:41 AM
+282ms 	║timerTmp is 3:30:16 AM
+312ms 	║Internal IF on 3:29:41 AM
+333ms 	║Inside loop on 3:29:41 AM
+372ms 	║timerTmp is 3:30:31 AM
+397ms 	║Internal IF on 3:29:41 AM
+418ms 	║Inside loop on 3:29:41 AM
+456ms 	║timerTmp is 3:30:46 AM
+481ms 	║Internal IF on 3:29:41 AM
+502ms 	║Inside loop on 3:29:41 AM
+539ms 	║timerTmp is 3:31:01 AM
+564ms 	║Internal IF on 3:29:41 AM
+580ms 	║changeCount is 2
+603ms 	║changeCount changed to 3


12/21/2018, 3:30:00 AM +389ms
 +486ms 	║Piston began at 3:30:00 AM
 +520ms 	║Before loop on 3:30:00 AM
 +543ms 	║Inside loop on 3:30:00 AM
 +587ms 	║timerTmp is 3:30:20 AM  <-- This is the one that actually schedules
 +621ms 	║Internal IF on 3:30:01 AM
 +646ms 	║Inside loop on 3:30:01 AM
 +687ms 	║timerTmp is 3:30:36 AM
 +936ms 	║Internal IF on 3:30:01 AM
 +959ms 	║Inside loop on 3:30:01 AM
+1000ms 	║timerTmp is 3:30:51 AM
+1031ms 	║Internal IF on 3:30:01 AM
+1053ms 	║Inside loop on 3:30:01 AM
+1093ms 	║timerTmp is 3:31:06 AM
+1120ms 	║Internal IF on 3:30:01 AM
+1144ms 	║Inside loop on 3:30:01 AM
+1183ms 	║timerTmp is 3:31:21 AM
+1211ms 	║Internal IF on 3:30:01 AM
+1229ms 	║changeCount is 3
+1255ms 	║changeCount changed to 4


12/21/2018, 3:30:20 AM +172ms
 +537ms 	║Piston began at 3:30:20 AM
 +564ms 	║Before loop on 3:30:20 AM
 +587ms 	║Inside loop on 3:30:20 AM
 +630ms 	║timerTmp is 3:30:40 AM  <-- This is the one that actually schedules
 +690ms 	║Internal IF on 3:30:20 AM
 +714ms 	║Inside loop on 3:30:20 AM
 +755ms 	║timerTmp is 3:30:55 AM
 +945ms 	║Internal IF on 3:30:21 AM
 +972ms 	║Inside loop on 3:30:21 AM
+1021ms 	║timerTmp is 3:31:11 AM
+1051ms 	║Internal IF on 3:30:21 AM
+1074ms 	║Inside loop on 3:30:21 AM
+1122ms 	║timerTmp is 3:31:26 AM
+1150ms 	║Internal IF on 3:30:21 AM
+1176ms 	║Inside loop on 3:30:21 AM
+1215ms 	║timerTmp is 3:31:41 AM
+1242ms 	║Internal IF on 3:30:21 AM
+1259ms 	║changeCount is 4
+1283ms 	║changeCount changed to 5


12/21/2018, 3:30:40 AM +117ms
+261ms 	║Piston began at 3:30:40 AM  <-- Nothing more can happen because {changeCount} = 5

I also did a FULL log to verify that exactly one schedule was set each cycle of 5 loops. (5 schedules in total during the 1m 40s duration) The full log was too much data to post here. The log above is set to MINIMAL

Hopefully these observations will encourage you to rethink your logic flow in this piston.

#30

Thanks WC … clearly there is something wrong in the scheduling of timers in the case of a For Loop … as I said I’ve moved on to a queue based systems that is 100% reliable.

The changeCount works exactly as designed. It is used to make sure the timer loop is only executed one time. You didn’t set NextChange to 1 as I mentioned in my first reply to my post. That is why it attempted to set 25 timers.

Why do you say “it only sets a schedule for the most recent one.” In other cases, it always queues as jobs the next timers (this is the crux of my entire post)…

Sorry you went down a rabbit hole on the changeCount … that is a method I use often in testing to ensure a piece of code is only executed once. :slight_smile:

Hopefully we’ll have some webcore experts take a look - its probably a undocumented limitation.

James

#31

No, the scheduling is working as intended. It is the funky code that you were clinging to causing any unexpected issues.

You are right, we covered so much, I forgot that note. If it was set to one, the entire piston would loop top to bottom 4 times… the loop would cycle 20 times… and the internal IF would happen 15 times

I have never seen a double schedule for a single trigger, but again, I’d love to see an example if you have one. (I try to learn something new every day)

Your choice of wording in your piston forces this to happen. If you had listened to any of my advice, you would be all good to go by now.

It’s like you are asking me, “Why is my car not going when I push this pedal on the left?” I reply, “Try pushing the pedal on the right”… and around in circles we go… LOL

#32

Not sure why you are taking such an antagonistic approach to helping to understand how things work. Its really not helpful in the least.

If the scheduling works as intended then its odd that there are other cases where it does queue additional timers. I dont really think you know much about the case I’m talking about.

Thanks for spending time, I’ll look for other more productive input :slight_smile:

James

#33

By the way, just to close this, what “advice” do you have to schedule N number of arbitrary timers that cause a Piston to execute from the top? You didnt offer any advice on my main point.

#34

Sorry if I offended you in anyway. I guess it just bothers me when I invest so much of my freetime to help someone, and they ignore every word I say. I guess I am an idiot for sticking around as long as I did, but I was really trying to reach you.

Please show me this!! I want to learn!!

Way too late for me to go into details, but I will sleep on it :sunglasses:

#35

Get some sleep :slight_smile:

#36

I absolutely love rabbit holes. No need to feel bad if the journey was eye opening…

If you need more details, I can rephrase in different words tomorrow, but I suspect it revolves around this:

webCoRE does not know what is going to happen until that code is actually ran.
(it knows it’s next command, and when that is executed, it’ll know what to do next)
In other words, I don’t think webCoRE plans out it’s next 5 steps in advance.

If you keep that in mind when coding, I think your final piston could be a masterpiece!

#37

Thanks that was really helpful :slight_smile:

#38

Ok, to close this issue and to help anyone else who stumbles on this thread in the future, here are my findings regarding setting timers in for loops (and other places):

  1. When you use a “IF Time happens” construction, there can be only one timer associated with that specific line of code. Every time you execute that “IF Time Happens” it will update its timer to the new value. This is why when it is used in a for-loop only the last value is set (it has nothing to do with being farthest out in time, it is simply the last value set, in fact it will set it for tomorrow if that time has past.

  2. You can have as many timers as you want for a piston. Every timer set gets put on the Scheduling queue and the one that is closest in time will show “Scheduled job for…” and if there are others it will show “and N pending jobs” (I haven’t found a way to see what timer jobs are in the queue)

  3. You can put the “If timer happens” deep within nested ifs, but it may not be set until that code is executed. I say may not, because timers in the code are evaluated on initialization and some are set, but depending on the logic, they may not be encountered.

  4. Of course, obviously you can never have nested IFs with two different triggers since the piston only deals with one “trigger” each execution and the second trigger will never be seen. However, if all you are trying to do is set up another timer to schedule the Piston to run, you can have “If Time Happens” nested as deep as you want (good luck trying to understand the code though :slight_smile: Each case of IF will establish a new timer.

So to wrap up, in order to do what I set out to, which is manage a set of arbitrary timers, I did that manually in the code by using a Timer List array that holds all of my desired timers. When a timer triggers the next timer in chronological order is set up - and it works great. The main thing to keep in mind with the timers is that the Piston always starts at the top (ignoring Waits) and any timer you set deep within the code will cause the Piston to run but it wont necessarily execute the code associated with that timer (it depends on the logic of course)

Hope that helps some weary soul who is struggling with timers :slight_smile: