Encoder resolution

[phil.s 0]

Hello all I currently have a FX1N PLC and a 256 pulse per rev 2 channel encoder. As it turns out 256 pulses is not accurate enough and I have been told by using quadrature decoding I can acheive 1024 pulses per rev. However I don't see how you can do this with the PLC. I was using C251 but this only counts the leading edge of each pulse. Anyone know of a way around this problem using the PLC? Thanks

[Sergei Troizky 26]

In Mitsubishi it is so called AB mode which is quadrature mode by operation but does not quadruple the encoder resolution. Having four high-speed inputs available, you can write own interrupts for every edge of both encoder phases and hence create a quadrature high-speed counter. The maximum counting frequency will be much lower than for genuine HSC. Edited 11 Jan 2007 by Sergei Troizky

[phil.s 0]

Thanks for the reply. Do you have a slightly better description or example of how to do this? Thanks Phil

[Crossbow 295]

Your two phases (A and B) of the encoder will go into two inputs (numbers differ based on counter address used) and when A phase leads B phase, counts up. When B phase leads A phase, counts down. But as Sergei said, this does not improve the resolution of the encoder.

[JRoss 84]

You also need a two-channel encoder with A and B phases to make use of quadrature. If your encoder only has one channel, you'll just have to get a new encoder.

[P Daniil 0]

To quadruple the effective resolution you must first detect state changes in A and B and then depending on the previous and current A and B states decide on the direction of motion to increment/decrement a position counter. Alternatively you can buy a ready made module for the job. They typically produce a clock and direction signal pair which you can then use to increment/decrement your position counter. Our multimode encoder filter paper describes the encoder operation and may be of interest.

[phil.s 0]

Thanks for the replies. Unfortunately the kit is already in and installed. Just trying to get it working. So my main query is how to get actual counts from the 4 edges of the waveform if possible. I don't think it is by the sounds of things. At the moment I have 256 pulses per rev but I wanted to try and get 1024 or at least 512. It is a 2 channel encoder by the way.

[JRoss 84]

Ah, now I see where you said "2 channel" in the first post! My fault for reading too quickly. C251 is the correct counter for A/B Phase, and from what Mitsubishi has told me, it should count rising and falling edges, and the programming manual seems to confirm this. I haven't played with it myself, unfortunately, but I may be able to if I can track down an encoder. Do you have a wiring schematic and program file I could use?

[phil.s 0]

Probably easier just to tell you: A phase goes to X0 B to X1 Porgram is using m8000 -[ ]--------------------------------------------(C251 K1) Then x2 (ldp) -[ ]----------------------------------------------[set y1] Then just m8000 -[ ]--------------------------------------------[DHSCR D161 C251 y1]- Thats all it needs to do. Y1 starts an inverter to run a conveyor for the distance in D161. It works out that I get 1.36 pulses per mm which just isn't fine enough. The machine is built so changing things is not really an option at the moment. If you could help that would be great The encoder is a Baumer MDFK 08G2101 by the way with a 32 pole ring magnet. Edited 12 Jan 2007 by phil.s

[Sergei Troizky 26]

Here is what I've written in 5 minutes. Theoretically should work. For maximum counting speed I speculate 1-1.5 rps of the mentioned encoder. Remove phase B interrupts and you'll get a double resolution count instead of quadruple one, but capable for higher frequencies. PRINTOUT.DOC Edited 12 Jan 2007 by Sergei Troizky

[JRoss 84]

That idea could work, though it takes twice as many inputs. For viewers who haven't dealt with interrupts on the FX, this is because only one interrupt pointer can be defined per physical input. Rising and falling edge interrupts are separate pointers, so using both, even on a single signal, requires two inputs. It's been a while since I played with high-speed interrupts, but I thought inputs couldn't be used in regular logic once they were used for high-speed devices. That may not apply to interrupt pointers. Good work for five minutes, Sergei! I like the use of internal relays to prevent dither. Only a couple corrections, and this should work. The inputs need to change to accommodate the four interrupt inputs being used. Change X2 to X4 and X1 to X2. Also, I would have reversed the NO/NC contacts. Up-count has B-phase following A-phase. Finally, there will need to be an EI (Enable Interrupts) in the main sequence so that the interrupts work! Now just use D0 instead of C251 in your DHSCR command, and you're good to go. I may be able to try some things using my simulator, but I won't have access to my demo equipment until Tuesday. I've spent far more than five minutes... back to work!

[Sergei Troizky 26]

Incorect. DHSCS/DHSCR will not work anymore and must be emulated by user program called as a common subroutine from each of these interrupts. And keep in mind that the D0 is 16-bit as shown. Edited 12 Jan 2007 by Sergei Troizky

[JRoss 84]

Duh, they only work on high-speed counters, and we're no longer using one. This is why two heads are better than one!

[Sergei Troizky 26]

Just tested my program. Works but VERY slow. So slow that should be deemed non-working for practical purposes. Also tested another version that does not refresh inputs but determines direction based on the last signal edge registered. This one works for ~0.5 rps with 200p/r encoder. It does not tolerate overfrequency which results not in lost count (as in genuine HSC) but in erratic direction count. The conslusion is- get another encoder

[phil.s 0]

dang I thought that was coming! Thanks so much for all the help though everyone it was really great. Thanks for the word file too Sergei much appreciated. Phil

[P Daniil 0]

All may not be lost, yet. Maybe it is still worth considering the hardware solution: an external x4 module.

[phil.s 0]

What is this then?

[P Daniil 0]

What was tried above by software can also be done by hardware. These are interface-like modules which process the two encoder quadrature A-B signals to produce a clock-direction signal pair at the four parts of the quadrature cycle. The clock and direction signals work as follows: Whenever an A-B quadrature transition happens (at the four points in the A-B cycle) the clock output emits a pulse. At the transition point of this pulse (usually the rising part) the direction output state represents the direction of the movement. So your program, when interrupted by the clock output, should read the direction signal state to determine whether to increment or decrement the position counter. Before proceeding however, ensure that your PLC can do such things in a timely and reliable manner for your application. (I cannot help you on this as I am not familiar with Mitsubishi PLCs). Where to find them: Encoder manufacturers usually have them under their accessories/interfaces/modules pages but in my very biased opinion you should also have a look at our multimode encoder filter which in addition to x4 decoding does a lot more and is a comprehensive solution to encoder problems.

[panic mode 246]

it's good to know it but i don't see this as practical in this case. 1024 or even 2048 PPR encoders are cheap enough and sure cheaper than those devices (380-550 EUR), not to mention simpler system.

[P Daniil 0]

I am sure that any web search will bring up more and cheaper alternatives. (Ours is a results-oriented all-inclusive solution, hence its price tag). As Phil.S. has described it so far, changing to a new resolution seems to be not an easy option (it's a magnet ring plus sensor set-up), so adding the external hardware may in fact cost less.