What is the Meaning of Color Coded "Execution Bars"


#1

I’m confused about the meaning of the color coded “execution bars” that are visible in various piston code blocks when Trace is turned on. I cannot find any documentation about them. It seems obvious that a red bar means that the section of code was not executed the last time (or maybe will not be executed in the next scheduled job.

The green bar indicates the code WAS executed last time or will be executed in the next scheduled job.

I’m not clear on what the blue bar indicates. Also, frequently a block of code has no color bar at all - what does that signify?


#2

I would love a detailed explanation as well…

Especially how can this be red:
temp
and this be green:
temp
when the code is identical…

Does webCoRE pull a fresh random number on each line of code??


#3

Thanks. Excellent point and I should have pointed that self-inconsistency out. It is ridiculous, isn’t it? The paucity of documentation is a real barrier to getting more out of WC.


#4

Well, to defend webCoRE for a moment, it is important to keep this in mind…

Any new technology / programing language that is always pushing the boundaries (such as webCoRE) will always have the challenge of keeping the “owner’s manual” up to date. Especially since new features are coded, but not announced until a bunch of us have tested it.

Personally, if I had to choose between a 100% complete manual versus an innovative product, I will choose innovation every time.

Another way to say this is that every minute spent adding to the manual is a minute not spent improving webCoRE.

For the record, last I heard there was a call to the community (us) to add to the wiki as we are able. I have even seen some really good threads here converted into the wiki. One of the challenges is, because of webCoRE’s power, there are so many ways to accomplish a goal, each with their own pros & cons. This makes it tough to write a “blanket statement” that covers all scenarios. (which is why most of my posts are quite long & detailed)

As a summary, I agree, it would be nice to have everything all nicely written in one document, but at least we have this forum to fall back on. (and it is rare that a question goes unanswered here)


#5

WC is an amazing project. It is staggering that it is free, too. So it’s easy to understand why documentation is sparse.

As an occasional user, it always takes a lot of fumbling around to figure out how things work (or don’t). I can’t thank you enough for all your assistance on mastering this tool!


#6

I honestly think the best documentation (beyond the basics in the wiki) is this very forum. There are some amazing gems here!

If all the documentation was all in one spot, we would only get one point of view, and it would likely either be abbreviated, or overwhelming.

Alternatively, using this forum, we get to hear from multiple perspectives, and we can all bring different strengths & experience to the table. Plus, we only tackle one thing at a time, so it might be easier to digest for the newcomers.


I admit though, my left brain would like a nice bullet list showcasing all the functions, examples and best use cases.

Since many of the gems here are buried in scattered posts, I have often wondered if the wiki could implement that bullet list idea, with each bullet linking to single posts from the forum. I think it would be a great way to “round up” the data into an easier to digest format. Especially if each bullet could have multiple links showcasing alternative approaches.

This would also take the burden off of one person to test & write the entire wiki.

Just an idea if any of the @webCoRE_Minions feel inspired.
I am sure many of us here would contribute to it…


Anyways, sorry to get off topic, @OldPro.
Hopefully someone can answer your original question.


#7

green and red conditions that have been evaluated in last run of the piston and found to be either true or false respectively.

blue indicates part of the code that was last executed.

no color generally indicates that block of code has not been executed yet. like in this case there is a wait preceding the blocks that have not been executed yet.