Announcement

Collapse
No announcement yet.

Why is the timer keeps counting after done bit gets set?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • franji1
    replied
    Unless you have 1000 timers/counters, the impact on your scan time is minimal (even then, it's minimal compared to all the other logic related to 1000 timers)

    Write your code for readability. If your PLC scan is too slow, figure out where the bottle necks are, and optimize those (Pareto principal). Testing the done bit to skip over the accumulator addition is not much more time than just doing the addition (it still costs something to test the .Done bit and jump, and adding that test would affect ALL scans, not just when it is .Done).

    To profile any code to empirically to figure out any scan time bottle necks, use paired MATH instructions with TICKus() method (microsecond counter) (start with STRING functions).
    Take snapshot of TICKus() counter value MATH D100 "TICKus()"
    LOGIC TO PROFILE
    Take the delta of the current TICKus() - D100, and stick the result in D42: MATH D42 "TICKus() - D100"

    D42 has the time of the LOGIC TO PROFILE, in MICROseconds. Put D42 in a Trend View. It should be somewhat consistent (but we've seen trigonometric functions have interesting execution times based on the 22.5 degree quantized (1/4 of a quadrant)).

    LOOPING is also a potential scan time hit, and sometimes loops can be eliminated by utilizing the PLC's "scan" as the loop. But even when you need loops (FOR/NEXT, WHILE/WEND, REPEAT/UNTIL), Do-more supports .TimeSlice concept for each PROGRAM/TASK codeblock to limit the amount of time a code-block stays in a loop before it "tasks out" and runs the other code-blocks, then on the next ladder scan, returns back to the LOOP that was "time sliced" right where it left off. .TimeSlice is in MICRO seconds. There is even a YIELD instruction if you have a very long block of code without loops, but want to utilize "tasking out", continuing the scan for all the other code blocks, then continuing where you left off in the code block where the YIELD was hit on the previous scan.

    Leave a comment:


  • skyfox
    replied
    Originally posted by MikeN View Post
    Just because the done bit goes on doesnt mean we want to stop using that data. It is perfectly valid to get counts or time beyond what the preset is at.
    I am not questioning the validity of getting count data if that was one's intention. It is also valid for one to not want to unnecessarily impact scan time, if that elapsed time is of no use after the done bit was set. In my case, I only wanted the done bit to indicate that it got done without having to interrogate two 32 bit values to see if x number time had elapsed.

    Leave a comment:


  • MikeN
    replied
    This is the same thing as with counters. Users may not really care about the .done bit at all. Preset may even be left at/set at 0 in ladder program. Just because the done bit goes on doesnt mean we want to stop using that data. It is perfectly valid to get counts or time beyond what the preset is at.

    Leave a comment:


  • BobO
    replied
    Originally posted by skyfox View Post
    Mmmmm. May be I missed some thing.

    Let's say there are 20 Timers in the program.
    They all reach their done state say within an hour or so after being enabled.
    I want them to stay in done state until I comeback to them couple of hours later.

    In the mean time.....

    All 20 timers are still timing and calculating elapsed time. (When not needed)

    This has no effect on CPU scan time?
    Timers and counters are essentially stateless, accumulating time or counts and refreshing associated bits every scan. The .Done bit is nothing more than .Acc >= Preset, and .Acc is live and writeable by program code outside of the associated instruction. Yes it affects scantime to some small degree, but not enough to care.

    If running code becomes a scantime issue, use tasks, programs, and stages to reduce what is running at any time. Modularity is far more effective than worrying about the slight bump of a timer.

    Leave a comment:


  • bcarlton
    replied
    I guess the instruction's code could test the Done bit before updating the accumulator but there are some valid reasons to be able to manipulate the timer's accumulator external to the timer. Just know that this can happen and code accordingly.

    Leave a comment:


  • skyfox
    replied
    Mmmmm. May be I missed some thing.

    Let's say there are 20 Timers in the program.
    They all reach their done state say within an hour or so after being enabled.
    I want them to stay in done state until I comeback to them couple of hours later.

    In the mean time.....

    All 20 timers are still timing and calculating elapsed time. (When not needed)

    This has no effect on CPU scan time?

    Leave a comment:


  • BobO
    replied
    Legacy. And because it is helpful. And because it costs nothing.

    Leave a comment:


  • RogerR
    replied
    I dont know why it is set up like that, but use it regularly.
    If a timer is used to start a process and the process ending resets the timer, the accumulated value (higher than the .done bit) can be used to show the process failed or did not end.

    Leave a comment:


  • Why is the timer keeps counting after done bit gets set?

    Just curious as to what the thought process behind this is. One would think this just wastes valuable CPU resources.
Working...
X