Announcement

Collapse
No announcement yet.

Counter rate readout to C-more

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


  • Counter rate readout to C-more

    I'm using a D0-06DR PLC with a flow meter that is pulsing a signal into X0. I can program the flow meter to output any number of pulses per Kg/hr to the
    X0 input. The maximum flow that the meter will ever see is 400Kg/hr. I want to have a readout on the C-More screen to indicate the flow in Kg/hr based on the pulse that X0 sees using the HSIO. Does anyone have a sample program do this?


  • #2
    Click Tach to c-more readout

    Here's a simple program I'm trying out to replace a press rpm display. The pulse prox is being flagged 8 times each revolution, so the Click gets confused above 500 rpm. I was hoping not to have to pull the flywheel cover, but that would have been too easy. If I generate 4 pulses a revolution, it should be ok at higher speeds. I would like to look into some of direct soft plc's. From what I've read, there's designated high speed I/O and count functions.
    Attached Files

    Comment



    • #3
      Try setting X1 to interrupt instead of pulse catch.
      If you have an urgent issue, please contact AutomationDirect's Technical Support team.

      AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

      Comment



      • #4
        Thanks for the tip, I'll try that and report back.

        Comment



        • #5
          Originally posted by kgreen02 View Post
          Here's a simple program I'm trying out to replace a press rpm display. The pulse prox is being flagged 8 times each revolution, so the Click gets confused above 500 rpm. I was hoping not to have to pull the flywheel cover, but that would have been too easy. If I generate 4 pulses a revolution, it should be ok at higher speeds. I would like to look into some of direct soft plc's. From what I've read, there's designated high speed I/O and count functions.
          While I agree that this would be a good place to use an interupt, at 8 pulses per revolution, even 1000 rpm is 7.5 ms per pulse. A CLICK program as short as the one you posted should scan in not more than 2ms and therefore should be able to handle quite a bit more than 500rpm. Though since you need two scans per pulse to detect a transition you won't be able to do very much faster than 1000rpm or so, maybe 1500 though I wouldn't bet money on it, without using an interupt. What kind of speeds are you looking at? even 500rpm sounds fast for a "press" (though if it is a geared press I can imagine the flywheel going that fast)

          I think your problem is in your use of an immediate contact for X001. While I don't know exatly how a CLICK hamdles pulse capture, about the only way i can think of is that high level at the pulse capture input sets a latch, in order for the input to repond more than once that latch will have to be reset at some point. I asume it is reset when the PLC scans the input, after the curent value is copied to the working input buffer. In your case, the prox sets the latch, then the input scan tries to clear it, if the flywheel is going slow enough that the prox is still on, the latch gets set again for your immdaite input to see, but if it's going faster your immediate input sees nothing,. While the pulse repitition period at 500 rpm is 15ms, depending on what size of object the prox is detecting the pulse width may be very much shorter. If you had used a regular contact you'd see the pulse the regular scan had caught via the pulse catch latch.

          Comment



          • #6
            I tried setting the x1 input to an interrupt sub-program, it improved some, but not enough. The high limit on these presses trips at 1000 rpm, but most jobs we run average 500-800 rpm. I had it stuck in my head that the count pulse needed to be immediate, so I also made the interrupt ckt the same way. That's a very interesting thought too about the pulse width. The pickup is mounted in line with the 8 16mm bolt holes in the flywheel, so it stays dark until it reaches an opening. The tool is out of the press tonight, time to wheel out there and try some things. Thanks again for the feedback.

            Comment



            • #7
              Originally posted by kgreen02 View Post
              That's a very interesting thought too about the pulse width. The pickup is mounted in line with the 8 16mm bolt holes in the flywheel, so it stays dark until it reaches an opening. .
              Wait, this is a photoeye? If so, there is your problem. Most photoeyes don't have enough light to dark transition time to do rpm. Switch to an inductive prox.
              If you have an urgent issue, please contact AutomationDirect's Technical Support team.

              AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

              Comment



              • #8
                No, it's a prox. poor term on my part. I did try changing the instruction to "not" on X1 to make a shorter pulse. It still has the same result. As tinker mentioned, according to the scan times, we should be able to read these pulses no problem. I'll have to get back to this one Monday. A good weekend and Easter to all.

                Comment



                • #9
                  Hey kgreen02;
                  Is it a 1kHz capable prox? Does it have no turn-on delay? Some proxes have up to 10ms latency or repeatability, which could cause the problems you're seeing. The other factor is the size of the "holes" the prox is seeing. Are the on and off dimensions of the prox sensing area equal size? There needs to be slightly more open space than metal, to account for the prox head's range sensitivity fan. You can track the on and off times with separate timers at a lower rpm to make sure they are symmetrical, because the RPM limitation will be determined by the shortest interval of either the activation or de-activation.
                  With a balanced prox activation and a 3 ms scan time the PLC should be able to scan up to 1000 rpm @ 8 pulses per rev, well beyond what you need.
                  Hope this helps.
                  Speakerman.
                  "Analog" is still binary, it's just at molecular resolution!

                  Comment



                  • #10
                    I don't know what the khz capacity of the prox is. I'm using a "balluff" BES0071, can't find that info on the data sheet. I've relocated the prox to the clutch hub, which has 3 spokes approx 1 1/4" wide. it works nice like that, but I really would like to keep the multiplier as low as possible with the 8 pulses. Increasing the update time's not an option, they'd have it going through the roof on a 2 1/2 second rpm update. Thanks for the suggestion, I'll have to some more prox research..

                    Comment



                    • #11
                      Hey kgreen02;
                      Looking at the prox you have, it's listed at 600Hz with a 5% repeatability. Should be accurate enough. It only has a 5mm range though, so the target path needs to be really flat, or it will either miss counts, or risk getting sheared off.
                      Also, I feel I should clarify the description above, regarding 7.5 ms per pulse. It is actually 3.75 ms per on-state and 3.75 ms per off-state, per pulse, assuming it's a perfectly balanced activation. This is very difficult to achieve at high speed.
                      Dividing the PPR and RPM gives the time between pulses, as in the example calculation of 7.5 ms for 1000 RPM @ 8 pulses per rev. There is an on and off state within this interval, so it is in fact 16 pulses per revolution, 8 positive and 8 negative, and the interval must be divided in half to figure out the activation windows. The PLC scan time has to see both states for the counter to work accurately.
                      Theoretically, it is possible, but in the real world things are usually not that perfect. Also PLC scan times do fluctuate for all kinds of mundane reasons. Don't base projections on the number you see most of the time, expect it to frequently climb above that. Unless your scan time is 2ms or less, it could be problematic.

                      I would recommend either of the following:
                      1. Use a four-pulse per rev target, make sure the on and off pulses are symmetrical, and count both the on and off state of the prox activations as immediate contacts. This will give you a resolution of eight pulses per rev with twice the activation window for the scan time to see. 7.5 ms on and 7.5 ms off at 1000 rpm. Four small targets bolted between the 8 points you were measuring would be perfect, if that's possible. If you have a millwright or machinist handy there, they could make you some targets. Not seeing it I can only speak in generalities.

                      2. You're using three pulses per rev now. If they are fairly symmetrical, then doubling them with the off states and immediate contacts as described above gives you six.

                      Happy programming,
                      Speakerman
                      "Analog" is still binary, it's just at molecular resolution!

                      Comment



                      • #12
                        Hey there Speakeman, I like that idea of including the off states in the count, then I could drop the multiplier down to 10. As you stated, inevitably it's going to get different counts at times, so the fluctuations will only be +/- 10 to 20 RPM, maybe a bit more at the higher speeds. This is only a reference for the drive speed until the encoder based control displays actual crank revolutions per mn with the clutch engaged.
                        Happy programming to you as well, Kevin

                        Comment



                        • #13
                          Hey Kevin;
                          The counter activation contacts need to be positive and negative differentials or the counter input won't toggle. I haven't used the click, so I'm not sure if a contact can be both immediate and POSCON/NEGCON. If not, scrap the immediate portion.
                          Good luck.
                          Speakerman
                          "Analog" is still binary, it's just at molecular resolution!

                          Comment



                          • #14
                            Do it like this:

                            POSCON X0
                            PD C0

                            NEGCON X0
                            PD C0

                            STR C0
                            CNT CT0
                            If you have an urgent issue, please contact AutomationDirect's Technical Support team.

                            AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

                            Comment



                            • #15
                              I don't think these type of contacts are available on the Click software, at least not that I've come across yet. My first thought when you mentioned this was to add another counter using 'not' X1, then changing the math box to ctd1 + ctd2 x 10 = result. I'll keep searching the help files in the meantime. Thanks for the great suggestions!

                              Comment

                              Working...
                              X