Announcement

Collapse
No announcement yet.

Why doesn't this counter work?

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

  • Why doesn't this counter work?

    So this is a part of a longer program, running on a D-260.
    The physical machine consists of three sections that can be enabled independently: VFD (C1), and two pairs of servo drives (C2 and C3).
    I use MWX commands to send speed commands to each drive, and then MRX to read drive statuses.

    I have two counters like this.
    One for MWX only when there is new data to send, and then another counter for the MRX that is supposed to run whenever the MWX is not.
    I had this section running, but it seems to be temperamental.

    Any ideas or suggestions for improvement would be greatly appreciated.

    -Kevin H
    Seattle, WA

  • #2
    khawkinson,

    You did not mention if you had tried a SGCNT (stage counter). It is a counter that works inside stages.
    PERCUSSIVE MAINTENANCE: The fine art of whacking the devil out of an electronic device to get it to work again.

    Vaughn

    Comment


    • #3
      The 'C' bit (C34) must be OFF for at least one scan while this stage is enabled. After that when it transitions to ON the counter will count up 1.

      At the point(s) where the stage is enabled (by a JMP or SET) place a RST of C34 so that it will then be turned on (if the logic does so) within the stage.

      For the counter to count multiple times within the stage there must be times when NONE of the rungs are true (C34 is turned OFF). It doesn't appear that this is possible with the logic shown. This also assumes that C34 is not being turned on by logic outside of this stage.

      It is not necessary to use a differential contact of C34 in the count line for the counter. The counter performs this function itself. An ordinary contact would be sufficient, though the differential is not causing a problem.
      Last edited by bcarlton; 09-14-2013, 09:42 AM.
      thePLCguy

      Bernie

      Comment


      • #4
        Vaughn, I don't have a need to reset the counter from outside the stage, so a SGCNT didn't seem appropriate.

        Bernie, thanks for clearing that up. I can change all those OROUT commands to SET commands, and add a rung that uses SP7 or SP6 to RST C34.
        -Kevin H
        Seattle, WA

        Comment


        • #5
          Well that didn't work.
          -Kevin H
          Seattle, WA

          Comment


          • #6
            So, at the end of the day, I scrapped the counter idea.
            Instead, I decided to just cycle through my 10 separate MRX and MWX stages, and use the C1, C2, and C3 flags to enable the MRX/MWX instruction inside each stage.
            It's cleaner and simpler, but also slower. I hope to offset that by cranking up the baud rate.

            Interesting side effect: now the servos run backwards.
            -Kevin H
            Seattle, WA

            Comment


            • #7
              For this type of MWX/MRX structures to multiple drives I place all the MWX/MRX instructions (as you imply) into seperate sequential stages. Each stage checks that the port is not busy (and other possible conditions) then fires the MXW/MRX and JMPs to the next stage, the last stage JMPing back to the first. This group of stages are the communications that happen routinely (for example status updates.)

              If I have some communications which will run only occasionally but, when they do, will have priority, I place them in stages before (lower numbered) than the ones noted above. When the main ladder logic determines that one of these communications should take place then it simply SETs that stage. Just as above the stage checks for the port not busy (which it will be when the current communication is done), sends the message then (if that is all that is needed) the stage just RSTs itself. This communication will have happened as soon as the current one (from the 'routine monitoring' section) is completed - that is, as soon as possible. The stages in the first mentioned section will not even care that another communication has been slipped in-between.

              Sometimes when communication instructions require - for example a 'move' command to a servo - I must send two communications in order - send the target position - then send the 'GO' command. Sequential stages with their own communication commands make this easy.
              thePLCguy

              Bernie

              Comment


              • #8
                Billiant!

                Originally posted by bcarlton View Post
                If I have some communications which will run only occasionally but, when they do, will have priority, I place them in stages before (lower numbered) than the ones noted above. When the main ladder logic determines that one of these communications should take place then it simply SETs that stage. Just as above the stage checks for the port not busy (which it will be when the current communication is done), sends the message then (if that is all that is needed) the stage just RSTs itself. This communication will have happened as soon as the current one (from the 'routine monitoring' section) is completed - that is, as soon as possible. The stages in the first mentioned section will not even care that another communication has been slipped in-between.
                Prioritized Message Queue implemented in Stage! Brilliant!!
                There are 10 kinds of people in this world, those who know binary, and those who do not.

                Comment


                • #9
                  One aspect which makes this rather simple is that, in the DL, when a message is triggered the 'port busy' signal is immediately TRUE. The message runs to completion by itself. The actual instruction does not have to be enabled after that point. You can immediately JMP to the next stage which just waits for NOT Port Busy. This also allows for the easy preemption by the lower numbered - enabled - communication stage.
                  thePLCguy

                  Bernie

                  Comment


                  • #10
                    Thanks Bernie.
                    Your suggestion worked for me.
                    -Kevin H
                    Seattle, WA

                    Comment


                    • #11
                      I know it's an old post but just to had to try it.
                      Note the location of the CNT counter.
                      Works because an OFF to ON transition has happened. There's no need of the Positive Differential Contact for this instruction, it's already built-in to the CNT.
                      Solution:
                      Attached Files
                      Last edited by LWgreys; 12-07-2013, 07:12 PM. Reason: a little more info added

                      Comment

                      Working...
                      X