Announcement

Collapse
No announcement yet.

Averaging Value & Direction w/prox

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

  • Averaging Value & Direction w/prox

    I have an impromptu last minute project that requires a couple actions I am a little less familiar with. I could take the time to figure them out, but figured I would query the knowledge here first.

    The first is averaging an analog reading over a few seconds time. I need to monitor for fluctuations in load but the load changes through the process. I can explain further if needed. Its a motor dragging a device that accumulates more restriction as it moves throughout its stroke. Occasionally it encounters a restriction, I need it to stop when that happens.

    The second is accumulating pulses in two directions via a tone wheel with two prox sensors. Any suggestions for a clean way to do this? I can think of some messy ways but won't reinvent the wheel if its not necessary. The only reason the direction is important to me is due to the "wind up" in the system. When the motor shuts off, the pulley freewheels backwards a bit due to the tension. I want that to decrement the value so it doesn't lose its physical location.

    Happy to elaborate further if needed.

    Thanks.

  • #2
    Regarding the position pulses: it would be important that a useable signal, high or low, be available when the wheel is stopped. I had to Google 'tone wheel' and their standard pickup is a magnetic sensor which only functions when the wheel is moving. But if you have good signals and approximately 50% on and off pulses then place one over one edge of a high section . Place the the other directly in the middle of a low section. Assuming the wheel is uniformly cut it doesn't matter which high and low sections you use. Choose them as needed for easy mounting. These two signals will be in quadrature and can be sensed for distance and direction by any high speed counter able to read a quadrature signal.
    thePLCguy

    Bernie

    Comment


    • #3
      I'm not sure what the term is in the controls/automation/PLC world, in the mobile equipment world some rings for position/speed sensing are called a tone ring/wheel.

      The one I have for this project is not like those. It just a ring with two inductive proximity switches (it's an existing setup). The high/low positions are uniform and when one sensor is high the other is low.

      I'm planning to use a P1K. I was hoping the standard discrete input module would respond fast enough, I see 2ms for a max response. I need to measure the pulleys and do the math to figure out the period for the pulses though though.

      Thanks.
      Last edited by durallymax; 02-19-2020, 12:22 AM.

      Comment


      • #4
        Do the prox signals change state simultaneously.
        If not, do as bernie says. On a rising/falling edge of one check the state if the other.
        you can deduce direction.
        there are examples/videos/instructables for 'embedded' controllers/rotary encoders that explain this.

        A bit of info. The second image shows what I mean in the above wordywords.
        Last edited by kewakl; 02-19-2020, 07:23 AM.

        Comment


        • #5
          If you know when the motor shuts off you can always count the pulses after the motor shuts off and subtract them from the total. To use a quadrature input the pulses from the two sensors would need to over lap. More then likely you would need a HSI.

          For averaging use the Average (AVG) Instruction.

          Comment


          • #6
            Since you are making changes to the control system, is there any way you can simply swap out the "tone wheel" with a more universal and simple encoder?


            edit:
            It also kinda sounds like you may just have a simple timing gear and you are counting teeth with a pair of sensors. Which I guess is a fine way to do it
            Last edited by MikeN; 02-19-2020, 10:16 AM.

            Comment


            • #7
              Rather than changing simultaneously the cycles from the two sensors are staggered by 1/4 of a cycle, hence the 'quadrature'. Follow the setup method I proposed.
              thePLCguy

              Bernie

              Comment


              • #8
                Originally posted by bcarlton View Post
                Rather than changing simultaneously the cycles from the two sensors are staggered by 1/4 of a cycle, hence the 'quadrature'. Follow the setup method I proposed.
                Yes.
                Bernie, I do not know if you are responding to my post, but I did mention this in the second line.
                Possibly my written word is getting as indecipherable as my spoken word. I was hoping that the image that I linked would help.
                Sorry if I caused any confusion.

                Comment


                • #9
                  Originally posted by bsinkovich View Post
                  If you know when the motor shuts off you can always count the pulses after the motor shuts off and subtract them from the total. To use a quadrature input the pulses from the two sensors would need to over lap. More then likely you would need a HSI.

                  For averaging use the Average (AVG) Instruction.
                  That sounds like a very simple solution. Thanks. I don't necessarily need to determine the direction with it, if the forward contactor is engaged it better be moving forward or something else is wrong. I don't really have a need for the confirmation of direction by the sensors at this point.

                  As for AVG, I suppose I should've at least opened Productivity Suite before posting lol. I've been in Click lately, that instruction makes things too easy.

                  Comment


                  • #10
                    Originally posted by MikeN View Post
                    Since you are making changes to the control system, is there any way you can simply swap out the "tone wheel" with a more universal and simple encoder?


                    edit:
                    It also kinda sounds like you may just have a simple timing gear and you are counting teeth with a pair of sensors. Which I guess is a fine way to do it
                    I could but I don't know that I need to. The precision requirement for this is +/- 6" or so and not very critical. I just want to avoid any sort of "creep".

                    It's simply a plate on the gearbox shaft that has windows cut into it, functions the same as the timing gear you mention. I misspoke earlier, there are two versions of this. The one I have does not have the sensors alternating high/low, the windows are cut so they are both high and low at the same time(aside from the transition points of course). The other version has them alternating high and low.

                    kewakl the link you provided was helpful, I don't know if I'll use it for this but I am sure I will refer to it again in the future. Thanks.
                    Last edited by durallymax; 02-19-2020, 12:53 PM.

                    Comment


                    • #11
                      The panel is in and running fine now. I couldn't get the average instruction to work the way I needed it to though. I wanted an average of amperage over the last 15-60 seconds and a way to detect if the current amperage exceeded that by a preset value (say 200mA with an average around 1.2A) for a preset time (3 seconds maybe). It appeared I was always chasing the average and upon restart it wanted to start near 0.

                      I ended up just creating an array for the amperage values. Every pulse from position sensor, shifts the array right with a new amperage value. There is a pulse every 39-40ms so I used a math function to offset the array statistics start column by whatever the preset time was (say 3 seconds) and the end column by the averaging time (15-60 seconds). This gave me the results I needed, I don't know if its a good way, but it works. Downside is that the array added 750 tags to a 450 tag program.

                      Comment


                      • #12
                        The average instruction takes an input tag, and a time value or tag with a number in it. The average instruction then outputs the average value of that input tag over the time period it is given. So if you give it a time period of 15,000ms, it will keep the output tag updated with the average over the last 15 seconds.

                        To compare whether you are greater than your average for a certain time and by a certain amount, you could do something like take that same input tag and send it to a Math instruction and add +200 to your value in the math, then output that math to a new tag.
                        On a third rung, make a compare contact that compares whether your tag that is +200 is greater than your tag that is the output of your average. Have that compare contact go to a timer for 3 seconds. If the timer is done, then you have been above your average for 3 seconds.
                        You may have to tweak this a bit, as when the input tag changes and goes up, it is continually adding +200 to it for your compare contact. The average will start going up too, but at a much slower pace. So the way I have described this, you would have to jump up quite a lot and rather quickly to trigger this detection. Changing some stuff around like how often you update the "+200 tag" or how long the timer for the detection is will probably be necessary.

                        Since the average instruction will want to start at 0 on power up, you could write a couple lines of code that bypasses the average for the first 15 seconds of power up. Do something like use a timer for 15 seconds, and if that timer is not cone, then do a copy value instruction to directly copy your input tag for the average to the output tag. This will bypass the averaging until 15 seconds has elapsed. Be sure and put the copy value instruction after your average instruction.
                        Last edited by MikeN; 03-02-2020, 05:52 PM.

                        Comment


                        • #13
                          MikeN what you describe is word for word exactly what I originally did. I tweaked with it for a day but never got the results I was hoping for. The array method seemed to respond better. I like the average instruction better though, cleaner and I don't have to look at all of those tags. To be fair, I had to tweak the array method a bit too and someday I will probably revisit the average function and see if I can get it to work the way I want.

                          Comment

                          Working...
                          X