Announcement

Collapse
No announcement yet.

P2000 Timer (TMR) potential bug or documentation problem

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


  • P2000 Timer (TMR) potential bug or documentation problem

    Hello.
    Getting used to the P2000 series and looking at the TMR function. When I select the "reset when timer reaches preset value" option, the =Preset (.Equal) does not seem to go high. Since the option is for the timer has "reached" the preset value, =Preset should be true for one scan. Or, am I misinterpreting what "reached" means in this context?

    I am using Productivity Suite 3.1.0 (11) with a P2-550 w/ 1.2.2.75 firmware.

    Any thoughts?
    Last edited by ApisControls; 01-11-2018, 08:22 PM.


  • #2
    The '=' output bit may be on for ONE SCAN. You may need to set a 'trap' for that bit.
    Can you post your timer rung?
    Last edited by kewakl; 01-12-2018, 05:20 AM.

    Comment



    • #3
      The = would likely be true for only 1 scan. What is your data type for current value.

      Comment



      • #4
        I haven't used this but from the name of the subfunction it sounds like when the timer instruction is executed and it turns out that the accumulator is ≥ the preset then the timer is reset. On exiting the execution of the timer the accumulator is no longer equal to or greater than the preset so the flag isn't set. This probably be used when you are just using accumulator comparisons outside of the timer, possibly for multiple events during the timing, and don't have a need for that bit.

        Set up a short timer using this subfunction and use the .Equal bit as an input to a counter. I'm guessing it won't count.

        If you need the .Equal then don't use this subfunction and just use a NO of the .Equal on the Reset input.
        Last edited by bcarlton; 01-17-2018, 12:33 AM.
        thePLCguy

        Bernie

        Comment



        • #5
          OP: since you say "Getting used to the P2000 series and looking at the TMR function."
          I usually just use the same tag for = Preset and > Preset to equate to => Preset

          Comment



          • #6
            Kewaki have you verified that. Might it not behave like the 'last one wins' effect?
            thePLCguy

            Bernie

            Comment



            • #7
              I do the same that Kewaki does.

              Bernie, no because the equal preset it only true for one scan. As soon as that scan is over, it drops out, but the greater than "takes over".

              Comment



              • #8
                Originally posted by bcarlton View Post
                Kewaki have you verified that. Might it not behave like the 'last one wins' effect?
                Bernie, I have not *observed* that. I hope that some future firmware rev does NOT 'fix' that.

                Comment



                • #9
                  Why would it? The rung is only true for that one scan. If they were to "fix it", they would be going against the basics of how ladder logic works as far as top to bottom, scan loops, etc.

                  That said, they've broken significant things in past releases. Things that worked perfectly fine in previous versions.

                  Comment



                  • #10
                    I think Bernie's concern is whether the instruction sets condition tag1, then sets condition tag2, then sets condition tag3, etc, or more likely, clears all condition tags, then sets relevant condition tags. The first won't work with overlaps, but the second will.

                    Comment

                    Working...
                    X