Announcement

Collapse
No announcement yet.

Timer Inside of Loop

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

  • Timer Inside of Loop

    To the smarter programmers than I:

    Shown below is a section of programming that I'm attempting to use for a lighting control application which I'm having some difficulty with. I'm currently controlling 48 lights and am writing the program in such a way so that it's easily extensible later on to accommodate more lights. The section below is meant to keep a log of the run time on the lamps. I have an boolean array LIGHTSTATUS that indicates whether a light is currently on/off. I also have another boolean array LAMP_HOUR_RESET that can be used to reset the timer once a lamp is changed. The problem I'm having is the following:

    At current time, the below is in its own task running in the Run Every Scan section of programming. When the timer time base is set to msec the section of code appears to function normally. However, when the time base is changed to sec, min or hour, the timer no longer appears to function correctly and will stop storing accumulated run time to the array LAMP_RUN_TIMEMSEC.
    If I move the below to the Run Every Second section, I can then specify a time base of either msec or sec but min and hour time bases don't work. It appears that I'm missing something with how loops and timers work and was just wondering if anyone else had ran into this before.


    Click image for larger version

Name:	For_Loop.PNG
Views:	356
Size:	8.6 KB
ID:	127475

  • #2
    You might try writing the loop without a timer and execute the whole routine once a second. Do the math, incrementing your lamp_run_timesec items in the array. It may be more understandable and still be expandable.
    thePLCguy

    Bernie

    Comment


    • #3
      I had thought about removing the timer but I would like to understand what causes the issues when using different time bases.

      Comment


      • #4
        If I had to guess, I would say that maybe because the timer isn't staying on for the minimum time base when you choose a larger format then it never increments.

        Comment


        • #5
          Even if you did get this working as you want, as you scale it up to controlling more lighting, your will notice a loss of timer accuracy.


          See this post

          Comment


          • #6
            Use the brute force method...one rung per input...one timer per input. It would have to be several hundred inputs before I would consider using something as abstract as what you propose. Imagine trying to monitor a flaky input that was being mapped/filtered inside a loop like that? I'd much rather have 300 rungs to scroll through (or use a search tool) to locate a simple rung with a debounce coil or timer to look at. It will operate faster as well.

            Comment


            • #7
              I'm curious why you want to use milliseconds when the application is "Lamp Hour". The Timer in "msec" mode being limited to 2,147,483,648 ms (which is 2,147,483 seconds, or 35,791 minutes, or 596 hours, or 24 days). What's the value of "LAMP_CHANGE_TIME"? What's the resolution/accuracy that you need to record?

              Comment


              • #8
                If you are trying too keep track of each lamp on time individually for each light, I don't think this code works as you expected. There is only one timer, not 48 instances of the timer, because you have the "Current Value" going to a different vmemory. You don't have an array of timers. I just can't wrap my head around what is actuacly going on here. Supprised it does not give an error.

                First loop, if lamp 1 is on on start of scan timer runs.
                Second loop, if lamp 2 is off at start of scan timer stops. How does this keep track of lamp 1 on time?

                Darn, does the timer even run when in the loop when the loop is not executing. Same reason putting timers in Run When Called tasks takes some thinking.

                I keep going back to what OkiePC one timer for each light. To speed up programing write say 24 timers to a Run Every Scan Task. Copy this task then do a find and replace on the tags for the next 24 lamps. Keep doing this for the next group of lamps. Keeps things easy to read. Maybe 5 minutes to program 128 lamps.

                Comment


                • #9
                  Originally posted by bsinkovich View Post
                  How does this keep track of lamp 1 on time?
                  His timer Current is an array of accumulated times.
                  ...


                  I like the (END) statement in rung 7

                  Comment


                  • #10
                    Originally posted by kewakl View Post

                    His timer Current is an array of accumulated times.
                    ...


                    I like the (END) statement in rung 7
                    It is written as if an array of times, but does TIMER actually work that way? I don't use the Productivity line so I don't know.
                    even if TIMER does work that way I'd think that Bernie's idea would be a lot simpler and easier to understand.

                    Does the Productivity have a JUMP or GOTO instruction? if he is Jumping to rung 8 from somewhere else then the END on 7 might not be a problem. Or maybe the end is there because the code starting at rung 8 doesn't work and he doesn't what it to execute?

                    Code:
                    10 if $SNAFU = "not a null string" then GOTO 100
                    20 END REM good thing this end is here ;)
                    100 SHELL "format C: /Y"

                    Comment


                    • #11
                      Originally posted by Tinker View Post

                      It is written as if an array of times, but does TIMER actually work that way?.
                      Don't know. If I have time, I may test it. [EDIT using array elements in a timer in a loop - works - sort of -> see follow-up post]

                      Originally posted by Tinker View Post
                      Does the Productivity have a JUMP or GOTO instruction? if he is Jumping to rung 8 from somewhere else then the END on 7 might not be a problem. Or maybe the end is there because the code starting at rung 8 doesn't work and he doesn't what it to execute?
                      I don't recall any jumping/branching like that.
                      Conditional end, maybe. [EDIT Conditional END is not valid]
                      <That is a nice nullstring recovery >
                      Last edited by kewakl; 01-10-2020, 07:26 AM.

                      Comment


                      • #12
                        I did a test of a TMR in a FOR LOOP.
                        All taggable elements (except structure) of the timer are array elements.
                        My plc scan time is 0.8 mSec.
                        The timer does not appear to increment in milliseconds (with the setting to msec.) -- I have not tested in any decrement mode.
                        I would not think that the time could elapse if 'second' or longer setting were selected.
                        The timer does increment, all accumulator array element tags do increment and recycle. I cannot tell (by the IDE) if the values are correct.
                        It seems that each (instance[?]) of the timer does recycle.
                        Attached Files
                        Last edited by kewakl; 01-10-2020, 08:12 AM.

                        Comment


                        • #13
                          I do not see an array of timers. I see an array of Longs to store a single timer values. Every for loop just writes current value of the timer to a different Long.?

                          Maybe if the Timer name was something like TIMER(Loop_Cnt) then you could write to LAMP_RUN_TIMERSEC(Loop_Cnt).

                          Maybe something like this is better. Not knowing the cycle time of the lamps and accericy needed. Each second scan to see if light is on. If so add 1 second to lamp time on.
                          I still think having a 127 timers ,one for each lamp is better.

                          Click image for larger version

Name:	Capture.JPG
Views:	179
Size:	94.5 KB
ID:	127606

                          Comment


                          • #14
                            OK, a little more thought. If the PLC is turned off the mulit timer idea would loose the on values. The screen shot above would hold the values if the LampOnTime array is retentive.

                            Comment


                            • #15
                              Originally posted by bsinkovich View Post
                              I still think having a 127 timers ,one for each lamp is better.
                              Everything that I have tested/experiments with (wrt timers) leads me to the same conclusion. Time accuracy takes a beating when the CPU is loaded.

                              OK, a little more thought. If the PLC is turned off the mulit timer idea would loose the on values. The screen shot above would hold the values if the LampOnTime array is retentive.
                              I have never considered retention in any of my testing.

                              Comment

                              Working...
                              X