How can I improve this code?

[greeniemax]

Hi, I'm not very new to CCS C but I have a problem that I can't seem to get my head around.

I have a rotary encoder, which is 4000 CPR and can work till 6000 RPM, I'm using PIC18F26K22 working at 4PLL at 16MHz, but when I move the encoder even to speed on 60 RPM my code starts missing the points.

I thought maybe it's the problem of printf so I removed all the printf from my code but still nothing. If someone could improve the code or give me a tip as to how to make it check input points faster or what is slowing it down, it'll be really helpful.

[Ttelmah]

Honestly, either get a PIC that has a rotary encoder module, or use an external encoder.

With 'quadrature' encoders, the signal has to be sampled at least four times for every cycle of the encoder output. Either by using interrupts, or by just sampling fast enough.

If your encoder is 4000PPR, and it goes to 6000RPM, then this implies sampling at 1.6 million times per second.

(4000*4*6000)/60 = 1600000

Not even remotely possible, especially if the PIC is wanting to do anything else.....

The software approach, either using interrupts, timers, or just calling a routine, is perfectly acceptable for something like a 16 line encoder moving at a few hundred RPM max, but for anything as fast as you are talking about, and with the number of lines your encoder involves, you need hardware. If you are only driving one encoder, then it is quite easy (just a couple of logic gates), to drive the internal PIC timers to give counts (Microchip have an AN on this).

You need hardware to do this. US Digital do some nice SPI encoder chips, or a few PIC's do have quadrature modules 'built in'.

As a further comment, are you sure your approach is sound?. Normally if using an encoder directly on the motor shaft, it'll be a low accuracy encoder (perhaps only 16PPR). High accuracy encoders are normally used 'after' the gearbox. Part of this is that the finer the encoder, the more accurately the bearing has to hold the shaft. The high accuracy bearings are often not rated for motor speeds, and the vibration of the motor can make the encoder useless.

[temtronic]

MR T is right again ! I've used US Digital's encoder chips for decades, sigh I'm getting old. Used them first on the 'new' 16F877 to control helicopters. While I've never used a PIC with QEI, it would be interesting to see the price/perfomance breakdown vs. a USD device.

Jay

[greeniemax]

Thank you Ttelmah for your great informative response.

I think I know why is it happening though, please guide me if you think I'm wrong.

I have PC817 Photocoupler on the line, I used it to reduce noise, though the board I'm using is for something else.

But the response time for these are slow like 18us up and 18us down, I think this could be causing the problem.

I'll try it with a board with open connection to the processor.

What do you think, might this be the problem? Because 4000 RPM is a lot, it's not even going beyond 100 RPM without giving errors.

[Ttelmah]

Yes, that is probably your current problem, but there is little point in wasting time on your current approach, since it is not going to work at the speed you want. An oscilloscope will tell you in an instant what is happening on your inputs. Basic test equipment is a 'must' if you want to do designs at even a basic level. I built my first scope, when I was at school.

Understand that proper encoder chips will have input circuits designed to reduce noise already built in....

[Ttelmah]

Just to give a 'follow up' on this.

Cost. On chips that have the MFM module (motion feedback), the price is zero. Basically these chips cost the same as their brethren without the module, and (of course) also zero real estate on the PCB. Question is whether there is a chip with this module that fits the other requirements. The PIC18F2431 for example, is $3.22, while similar chips with the same amount of ROM and RAM all come around $3 to $4.
Downside is that except for a few much larger DSPIC's, there is generally only one MFM module in any PIC. If more than one encoder is needed, then external counting is the way to go.
The module has Schmitt inputs and a programmable digital noise filter.

Then there is the question of what the rated speed of the encoder actually 'is'. As I've already said, most high line count encoders (1000PPR+), are not rated to go to 6000RPM. If you look at a fairly normal encoder like the OMRON E6C3 family, these have a maximum output frequency specification of 125KHz. With the comment:

"The maximum electrical response revolution is determined by the resolution and maximum response frequency as follows:
Maximum electrical response frequency (rpm) = Maximum response frequency/resolution × 60
This means that the E6C3 will not operate electrically if its revolution exceeds the maximum electrical response revolution."

So the 3600PPR version is limited to 2083RPM.

It is very unlikely indeed that a 4000PPR encoder will operate to 6000RPM.

I think though his encoders are only 1000PPR, so the *4 is already included in the figure. Then makes sense of the numbers. His maximum frequency then is 'only' 400KHz.
Still though much to fast to handle with software.

He needs to understand, that everything depends on what 'else' is happening outside the routine. Even one calculation, one putc, etc., each costs time, and delays the routine being called again. At 16MHz, with a encoder at this sort of rate, you don't have time to do _anything_....

If he is doing any code outside the routine, then edges _will_ be missed. How long this code takes, will determine the limiting speed. I'd guess he has something that is taking quite a few tens of uSec, hence edges are missed....

[greeniemax]

Thanks for your help guys, I'll surely go with an encoding IC, but I tried it without PC817 and trust me it works great.

I get to about 200 RPM without any problem, I don't need it to work beyond 120 RPM anyways but it's working perfectly now.

Thanks for your support, I'll get the encoding IC for my actual project.