splitting encoder pulses

[Guest Ron Baby Ron]

I hope someone can suggest something for me. I need to take readings from a 50 counts per rev encoder for four seperate actions By this I mean eg; first action when 50 pulses have occured (actuate a valve for 20 pulses) Then perhaps when 150 pulses have occured a second similar action. The problem is by the time the forth action has taken place I already will need the first action to have already started again. If I could start four seperate counters from the one set of pulses, I would have no problem. But I have to use X0 and counter 235 (HS) I cannot reset the counter after each action as one of the other actions would be still counting from it. What I need in a nutshell, is a way to have 4 seperate functions from the one set of pulses from the encoder.

[navillusi 2]

Rather than using the four counters, which I assume that you are using the done (finished counting) bit to trigger the events, you could use the accumulative value of the counter to trigger the events by using comparison instructions, i.e: LD> C235 K50 AND< C235 K70 ST {event one} LD> C235 K150 AND< C235 K170 ST {event two}

[Guest Guest_Peter Nachtwey]

Don't reset the encoder! Use the difference between counts to add to software counters. Each scan do this: NewCounts is read from the encoder hardware. DifCounts = NewCounts - OldCounts OldCounts = NewCounts You obviously have the ability to have more than one widget in a production area. Each widget should have its own accumulator that keeps a sum of DifCounts from the encoder. You need to have an array the is as long as the number of widget that can in the production area at once. When a widget enters the production area, use the next location in the accumulator array. If the next location is past the end of the array you must start at the beginning again. Set this new location in the accumulator to 0. Example. NewWidgetNumber = NewWigetNumber + 1; If NewWidgetNumber >= MaxWidgetNumber then NewWidgetNumber = 0 Accumulator[NewWidgetNumber] = 0; Each scan the DifCounts should be added to each widget in the production area. For WidgetNumber = 0 to last WidgetNumber Accumulator[WidgetNumber] = Accumulator[WidgetNumber] + DifCounts; Now do your comparisons with the accumulators associated with each widget. Now you will find that production line can be very long with many widgets in the production area at once. Have fun

[JimRowell 1]

Navillusi's approach is good but there are a couple of complications you need to consider. Your counter is going to overflow rather quickly on you and mess up your values. You could reset the counter on the zero pulse of the encoder each rev(assuming your encoder has that feature) but if you need multiple revolutions to reach the counts you want or if a target will cross over the zero point then that raises problems too. So, assuming you are sure you can't just tie 4 inputs together and use separate counters...... One approach I suggested a while back was this: Whenever you need to re-calculate a target (eg. the user changed the setting or whatever), you must store the current encoder count as a positive number. If its already positive, just store it. If its negative, convert it to a positive by just clearing the sign bit (the highest bit) and then store it. DON'T do a 2's compliment on it. You can clear the high bit by simply doing a "WAND H7fff" for 16-bit or DWAND H7fffffff" for 32-bit . Now add the appropriate number of pulses to this same positive number and store that as the target. Now get the carry flag which was affected by your addition and store it too. The carry flag will be set if your addition caused an overflow. That's telling you that your encoder should also overflow before it will be valid. Now on each subsequent scan you need to check to see if the target has been met. Note: "current count" in the following means current encoder count after clearing the sign bit. The target has been reached (or past) when: if the stored carry flag was low AND: (current count < stored count OR current count >= target) if the stored carry flag was high AND: (current count < stored) AND (current count >= target) This may seem like a lot of work for the plc to do but each operation is fairly fast to execute. Jim Rowell

[Sergei Troizky 26]

The pulses top frequency is not indicated in the initial data. Probably, there is no need in high-speed processing at all. If it is high-speed, there is more than one solution, as always. Why not use set/reset by high-speed counter with targets recalculation? There are 6 of them available simultaneously in FX1N/FX2N. Or, instead of declaring the high-speed counter, assign an interrupt to this input. In the interrupt you can increment as many data registers as you need, and reset them independently when necessary. This can be done in 16 or 32 bit format for each register. Then you can compare the values to the targets and set/reset outputs. This may be done in the interrupt body or in scan, depending on necessary speeds of operation. Edited 18 Feb 2004 by Sergei Troizky

[Guest Guest]

A big thankyou to all of you. I had thought about the compare and it was the road I was trying. But I knew that the counter would overflow and I could not think of an accurate way of recalculating. The math for this project is already streching me to the limit as each cycle, the count for the 4 valves changes according to a recipe in the HMI. And the first valves count dictates when the rest follow and for how long. Luckily, this is a research and development project where I am being paid by the hour. It is highly secret, done behind closed doors as the resultant machine is hoped to make a lot of money for the owners. Not to give too much away - the 4 valves are actuating rods that make a pattern on the product passing below. The pattern will be of varying lengths with no gaps so each valve is filling in just their bit of the pattern as the product passes below. This is why I have used an encoder. This is connected to the belt carring the product. I also have to do a speed calc to advance and retard the valves actions depending on the speed of the belt. The result will be a continuos pattern but constantly varying. The PLC is a FX1N and the HMI an E300 I would estimate that the encoder would give about 70 pps with the belt at full speed (which, I think would be rare to run at this speed) I am actually having fun with it, but this encoder overflow has been on my mind from the start. I shall take time to properly study all the methods mentioned here and implement them. One thing though, as it sounds the easiest. How do I use interupts to increment the registers. That at first glance seems like the best way (BTW I understand INC d0 etc) If I could get 4 registers incrementing in sympathy with the pulses from the encoder, my troubles are over.

[JimRowell 1]

At only 70 pps you can use pretty much any method that appeals to you. The idea of using interrupts is fine at that speed. It's not okay at high speeds. The hardware interrupt inputs are specified for a minimum pulse width of 200 microseconds. That's 400 microseconds of ON plus OFF time giving you a maximum frequency of 2500 pps (pulses per second). With high resolution encoders and/or high revs, that can be too low. For instance, a 5000 ppr encoder would be limited to 0.5 revs per second. Bear in mind that X0 and X1 are good for 60,000 pps if you use high-speed counters, no interrupts and no high-speed functions (the functions can bring the max speed down to as low as 5.5 khz). Ironically, high-speed compare functions are about as fast as a one-legged donkey. I rarely use them. Inline compares are much better. You have to ask what you are gaining vs what you are losing. Interrupts will offer some simplicity in some cases and remove it in others. You still have to deal with count overflow and as the count frequency increases, will all those interupts begin to interferre with your regular scan? What if you later decide to add bi-phase counting to allow for reversing? It could get awkward rather quickly. In your case, it may be a good idea to use interupts. Just giving you some thoughts. Jim Rowell

[Sergei Troizky 26]

Frankly, I don't understand what is the problem with overflow. At 70pps a 32 bit counter will overflow only after over 8500 hours of continuous operation. I do not believe the meantime to failure of the machine to be greater.

[Guest Guest]

LOL! Good point! This all started I guess expecting a much higher speed. Still, we don't want to create another Y2K thing.

[JimRowell 1]

Sorry Sergei, that was me. Forgot to log in.

[Guest Guest]

Really!!!! well I never thought of that. (I didnt - and still dont know, the maximum count value of a 32 bit counter) I havnt done much with high speed counters. I have done a lot of encoders for positioning but they always had a maximum that they could travel in any direction so overflow was never an issue. They will never run the machine in one run for anything like that time as the material feeding this belt is batch mixed and then used up. Then a complete new batch and restart. (and reset and new recipe) You have put my worried mind to rest. I can carry on with my compares programming and know things will work as I thought.