Announcement

Collapse
No announcement yet.

Click PLC as encoder for shear

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


  • Click PLC as encoder for shear

    I have an application the is giving me an occasional short piece. Application is as follows:
    Click PLC with X1 set up as an interrupt.
    400 Line encoder wheel generating approx 125 pulses per second.
    Since it doesn't appear that the counter instruction works on the interrupt, i set up a math box to take DD4 add 1 and put it back in DD4, essentially making my own counter.
    The interrupt program has the math instruction on the first line, second line compares to a preset and if equal set a coil to be used in the main program to trigger the shear. This rung also resets DD4 to zero in order to start the count again.

    Every once in a while (randomly, not regularly) i get a piece that is about 1/2" short. Neither the piece before it or after it are long so it is not like the shear is lagging occasionally. I also, put a timer based on shear firing and display this number on the display. This timer varies along with the short pieces, so it seems that for some reason the pulse count is not consistent. I originally suspected the encoder, so I replaced it with a brand new one. (actually, while i was waiting for the new one to arrive, i tried a different encoder we borrowed from another line the in being rehabbed and that acted the same way as well, so i have pretty much ruled out the encoder as well.

    Now i am scratching my head.Scan time runs 1-2msec so everything SHOULD be complete before the next pulse comes in, but is it possible that i am trying to do two math instructions on DD4 at the same time? i even put both of them in the interrupt program on separate rungs figuring it would process them in order and i couldnt find myself in a spot where DD$ wasnt completely set to zero before the interrupt grabbed it to add one to again.

    What am i missing. i was going to post a copy of the code, but apparently cant do that.

    Bob


  • #2
    Sounds like either the signal coming in has some extra pulses from noise or device, or the math is adding 1 to DD4 more than once per pulse.

    Could try -
    * -- Putting in a edge contact on the first line of the interrupt program to ensure that the line only executed once per X1 Input Pulse. The interrupt program is on for around 4 ms at a time at 1/2 frequency of 125 PPM.
    * --Setting the filter on X1 to a value of somewhere between 1 to a few ms.

    Comment



    • #3
      I'm with Roger, sounds like possibly noise.

      Comment



      • #4
        Originally posted by RogerR View Post
        Could try -
        * -- Putting in a edge contact on the first line of the interrupt program to ensure that the line only executed once per X1 Input Pulse. The interrupt program is on for around 4 ms at a time at 1/2 frequency of 125 PPM.
        * --Setting the filter on X1 to a value of somewhere between 1 to a few ms.
        A contact for the input that triggers the interrupt will not work because the inputs may not have been scanned yet (an interrupt being by definition asynchronous)
        For the same reason I doubt the filter would work even if one could configure it, but one can't even select the filter function if one selects interrupt operation.

        Possibly an external analog filter (e.g. resistor/capacitor) could be of some help, but I'd check the existing wiring first, possibly use shielded cable to the encoder?

        Personally, if I wasn't spending my own money, I'd use a BRX and a quadrature encoder. One problem with a simple unidirectional encoder if it happens to stop right on the edge of switching, vibration can cause multiple count with no real movement, , with quadrature it many count up and down by one, but you'd still be within 1 count of were you want to be. The unidirectional encoder can only count up even if there is no real net motion.

        If one want's to post CLICK code it needs to be "ZIPPED" the forum only accepts a limited set of file formats and .CLK is not one.

        Comment



        • #5
          I would use either the second channel from the encoder or just a second encoder connected to a different DI. Then use the same logic with different registers, and then compare the values.

          Additionally I would move the set of the coil to the interrupt and force it to be Immediate.

          As Tinker mention before, " I'd use a BRX and a quadrature encoder", the best solution is to choose the best hardware . The price for the hardware is known, while the engineering, testing, an re engineering is not known.

          Comment



          • #6
            125 pulses per second might be too fast for what the input can take. You should check the switch time for input, it could be fast but not in continuous mode. Usually the input switches once in a while, but longer than 8ms. The fast switching could overload the input module.

            Comment



            • #7
              Originally posted by Alexandru View Post
              125 pulses per second might be too fast for what the input can take. You should check the switch time for input, it could be fast but not in continuous mode. Usually the input switches once in a while, but longer than 8ms. The fast switching could overload the input module.
              I agree. The scan time of a Click is just too slow for this. I'd go with a BRX or P2K.
              If you've done the very best you can, worrying won't make it any better - Walt Disney

              Comment



              • #8
                Originally posted by Alexandru View Post
                125 pulses per second might be too fast for what the input can take. You should check the switch time for input, it could be fast but not in continuous mode. Usually the input switches once in a while, but longer than 8ms. The fast switching could overload the input module.
                While this is an old thread and the OP hasn't been back, I thought I'd point out that the OP was using an interrupt. I've done a little experimentation and I think a short interrupt routine on a CLICK is pretty reliable up to about a 1000Hz. 125Hz would be no problem for an interrupt (as long as the routine wasn't really long) and a very short CLICK program might handle 125Hz with conventional ladder

                Comment



                • #9
                  1000Hz means a scan time of 1ms. Just by calling the interrupt a 1ms is lost. However, I just checked a sinking input specs and they say 2ms minimum for switching the input off-on, and 2.5ms on-off.
                  There is a latency of 4.5ms in hardware alone. Fact that he manages to run for a while shows that hardware is Actually faster than in specs, but not meant to work consistently that fast.
                  It is cool that he manages to turn a click module into a high speed input.
                  I would try to use a quadrature encoder because having 2 channels would reduce the frequency 2 times from 125Hz to approx 67Hz (16ms). Therefore, with 2 inputs each of them lasting 16ms, he would be back in the specs for inputs and the ladder programming is minimal.
                  Last edited by Alexandru; 07-20-2018, 09:25 AM.

                  Comment



                  • #10
                    So the prodigal OP has returned!! this system got put on the back burner, because it has been running "good enough" but now i have some time to address it again. just as an update, i have followed the advice here of considering noise and rerouted the wiring to eliminate (or at least drastically reduce) the chance of noise with no effect.

                    in reviewing the specs of the C0-10DRE-D it says response time of inputs 1-4 are 20 microseconds Off to ON and 30 microseconds ON to OFF. Since my code runs <1 millisecond (not much going on) if i just put a rising edge contact on X1 and forget the whole interrupt thing i should be able to catch 125PPS right? Scan time is about 8 times faster than the pulse train so i should see 4 scans while X1 on and 4 scans with X1 off. so should catch every rising edge. i have proved the code using the rising AND falling edge of the 10msec clock coil (SC4) which theoretically gives me a 200PPS pulse train, but without the physical input involved.

                    If i was at the facility where this is i would just try try it and report back, but i have been everyplace except that plant for a while and not scheduled to be back there for another few weeks. just posing the question to see if it makes sense or if i have gone batshit crazy after living in hotel rooms for weeks at a time.

                    Comment



                    • #11
                      You might try that, but I wouldn't bet a whole lot on it helping, as I said before:
                      " One problem with a simple unidirectional encoder if it happens to stop right on the edge of switching, vibration can cause multiple counts with no real movement, , with quadrature it many count up and down by one, but you'd still be within 1 count of were you want to be. The unidirectional encoder can only count up even if there is no real net motion."

                      Comment



                      • #12
                        In this case it is a very stable continuous process with no starts and stops so not worried about the encoder fluttering on the edge of a pulse. I canít think of the last time I used an interrupt routine but would think it should only run once per pulse but since the scan time is so short could it being running more than once? Hence my thought about rising edge of a standard input. Normally I could see losing pulses but not gaining them. And not gaining them consistently.

                        Comment



                        • #13
                          Originally posted by RBuchenan View Post
                          In this case it is a very stable continuous process with no starts and stops so not worried about the encoder fluttering on the edge of a pulse. I canít think of the last time I used an interrupt routine but would think it should only run once per pulse but since the scan time is so short could it being running more than once? Hence my thought about rising edge of a standard input. Normally I could see losing pulses but not gaining them. And not gaining them consistently.
                          Since you believe your process is stable with no chance of extra counts from the encoder, perhaps you could try a test using a timer that starts timing at the cut and store the largest "count" after the cut and also the smallest "count" after the cut into separate registers. The timer time should be for about 1/10 of the time of a cut to cut period. If you see a large difference between the largest count and the smallest count during the same time period, the safe assumption would be that the cut is somehow "adding" extra counts to the process.

                          Presuming you do see a large count difference, a second test might be to stop the machine after you sense another "large count" piece (after it is cut) and see if it's one of your short pieces.
                          Futti Utu

                          Comment



                          • #14
                            Hi Anvilsoup,

                            i have done something similar but backwards in the original program. i put in a timer that ran between cuts and displayed the time on the firing of the output since we had people saying the shear was hanging but couldn't get through their head that if one piece was short, the previous or next one must be long. The time between cuts varies, indicating somehow extra pulses being counted. when the cut is wrong, it is always short, never long so we are not losing pulses. Which is weird. two different encoders (one brand new) new shielded wiring. Rerouted wiring to get it away from other wires. even moved the encoder to a different location on the line closer to the actual shearing operation. it was farther upstream which should matter but........... One of my options will be to just shear on time and let the operator dial it in but if they change line speed they will have to adjust it again. Not a big thing, but just one more thing they can me missed and make bad product. i am sure this will cut far more accurately than what it happening now, but those of us here know that is just a workaround and not the right way to do it.

                            Comment



                            • #15
                              For the cost of a new encoder, couldn't you have just replaced the click with a BRX and used the built in high speed inputs to do the encoder input properly? $253 for the 6 input, 4 output model with high speed in's and out's.

                              Comment

                              Working...
                              X