A counter for number of Runs

I updated my dynamo to 2.0.1 (from 1.3.1 version). The part that is considered as “second counter” does not work now. In other words, it does not count and the “tCount” is given “null” value at every run. It seems it cannot store values from previous runs anymore.

So, If you run it in Dynamo 1.3.1 the highlighted “Watch” node shows the number of runs, but in 2.0.1 version it does not count and it shows 0.

  • I attached the code here. If you want to test, make sure to have two copy of the code; one for 1.3.1 and one for 2.0.1. (since when the code is updated to a newer version, it cannot be opened by previous ones)
    second counter.dyn (3.3 KB)
1 Like

I think this is related:

try the suggested workaround at the bottom of the thread please.

Hi Michael,
It is not the solution to my problem. But, thanks for your consideration.

FYI @Aparajit_Pratap

Note that your variable is defined outside of the imperative scope. In Dynamo 2.0, you can no longer redefine variables in the same code block in associative mode.

@sobhan.kouhestani, when I’ve wanted to count runs I use python to write a string to a text file, and then read and adjust the text file on each run, have a look at this this code, if your writing imperative hopefully adjusting this python should be fine for you :slight_smile:

@sobhan.kouhestani I do not see any issue with the result of this graph. The expected result will be 0 for tCount returned from the Imperative block. And if you’re returning t0 from the Imperative block, it will be the current time. I see the same output of 0 for tCount returned from the imperative block in 1.3.

@Aparajit_Pratap Thanks for your time. But On my dynamo it works like a charm. please see this GIF:

@adam_bear1 Since writing in an external source need a little bit of RAM and I need every little of it, I think this would be my last bullet in the chamber. However it is a nice solution. Thank you for your contribution.
@Dimitar_Venkov I think this is the painful truth :smiley:. I need to think other ways like saving it into an external source. Thanks for the response.

Just to add an alternative option that doesn’t require saving to an external source (but does have the aforementioned drawback)

1 Like

Oh thanks @awilliams , that’s a nice one!

@sobhan.kouhestani sorry, I didn’t see that you were running in periodic mode. Unfortunately the old behavior in 1.3 will not be reproducible anymore in 2.0.

In 1.3 variables defined in the outer scope could be modified within the inner imperative scope. Therefore variables “t0” and “tCount” would update once written inside the imperative block and every time, “time” changed and the imperative block re-executed, the previously updated values of “t0” and “tCount” would be reused.

However, in 2.0 we changed the behaviour of imperative blocks and made outer variables read-only within them. This means that these variables are now copied and used as if they were local to the imperative block scope. Therefore when “t0” and “tCount” are changed in imperative code, only their local copies are modified and thus their new values do not reflect outside the imperative scope. Subsequently whenever the imperative code re-executes upon change of “time”, “t0” and “tCount” are reset to null (in the outer associative scope), copied and reused in the imperative scope thus overwriting their previous states.

These changes were made to simplify complex associative update semantics between associative and imperative code and to make writing DesignScript in code block nodes more coherent to users. A lot of them do not make use of associative update workflows like in this case.

1 Like