PIC DRO?

[Sam_40]

Greeting and salutations,
I am starting on a project; the idea of the project is similar to DRO (Digital Read Out):
The idea is to use quadrature encoder with 100 PPR coupled to 10TPI shaft. This should give a .001” reading per each of the quadrature encoder pulse.

I am thinking of:
1- Using my favorite 18F2685, using the quadrature encoder the A signal to do the counting.
2- Using quadrature encoder A and B to figure out the direction so if per say CW the count is ++ if CCW the count is --.
3- I will integrate algorithm or code to take care of the mechanical backlash.
4- I am planning to use three quadrature encoders one for each shaft.
5- Display the reading on PC HyperTerminal.

FYI: I did research. I found that some PICs have QEI built in them. I am also aware of extra hardware to connect the encoder to. However I have a few 18F2685 and the quadrature encoders. The conventional DRO will not work for my need as one of the shafts is 14 feet long (168000 PPR) at 500 counts per second at maximum shaft speed. The above is just what I have in mind, I appreciate any input.
The questions for my idea:
1- How reliable, repeatable, and accurate the readings for my setup if I run the PIC at 40MHz using external OSC? Keep in mind; I am all over making the connection very short, the pull ups the signals from the encoder is 5V and square (reading from bread board). 
2- What pins to use for such task? Is it better to #RB or any pin will do the job? I am not planning to use any of the sleep modes.
3- Is it better to use 3 PICs, one to read each encoder or can one PIC handle all 3 encoders? If using 3 PICs how can I get them to communicate to a single PIC?
4- How to define the count in CCS for 168000 and make this number display in + or -?
5- Is there similar project so I can edit/copy to fit my need?
6- How to set the 232 for the speed of the PIC? For example; if the PIC is running at 40MHz what is the #use rs232 parameters? I will be using MAX232 between the PIC and the PC.

Some of my questions they may be interrupted as design questions and out of topics. I just ask to get help from you guys so I can start on the right bath and minimize headache to myself and minimize future compiler questions about this project. I am still new to PIC and CCS C compiler.

Thank you for your help,

[Ttelmah]

A lot of the questions here are dependant on the encoders you choose.
Really high quality ones, have their own signal processing to ensure the waveforms are good, and warrant the accuracies and repeatability of the pulses etc..

However there is a key problem in wanting to use three encoders. With all encoder sampling systems, you have to _ensure_ that a particular pattern is handled before the next edge arrives, or edges can be lost. Now doing one encoder on a PIC is easy. Two, not much worse (given that almost all PIC's have 4 INT_RB bits available, and these are ideal for detecting the changes). However the more inputs you have, the higher the risk of missing an edge, while you are processing the inputs from one of the other encoders. The more the chip is doing the higher this risk becomes. Fortunately, 500 counts per second, is very slow in encoder terms, however this would be a lot easier, on a chip with six interrupt on change inputs. On one with four (your 2685), it'd become very difficult to ensure counts are not missed.
That having been said, it would then be easier to just have each PIC handle one QEI, or two, and link chips with I2C. Two chips, one handling a single QEI, and the serial interface, and the second just handling the other two QEI's would be a better match to the hardware. However if using two chips, you then have to accept it'd be a whole lot easier to just use off the shelf QEI decoder chips. Code scale changes from something that will be a lot of work, to something relatively simple.
You have to also understand that a proper QEI decoder, will also contain filtering to clean up the signal edges, and be able to ensure that no counts are missed while other things are going on. The former would require extra hardware between the QEI and the PIC, unless you use an encoder that has this built in, and the latter will be down to careful software design - more work....

A search here for 'Quadrature', will find lots of posts on how to handle such modules.

I'd honestly suggest just using something like the LFLS7366R-S. One of these gives you a 32bit counter operated from the QEI signals, and readable using SPI. It also ensures that the count will not update during a read, yet will not miss anything while this is happening. Three of these connected to a PIC using the SPI pins, with three CS lines, makes the whole job much easier.

An int32, can handle counts up to 429467296.

Your #use rs232 parameters will depend on what baud rate you want.

[temtronic]

I have to 'second' Mr. T.s comments about using the US Digital devices. Have done so for 2+ decades. The encoders are far better than anything HP offered back then and the 7166 chips work flawlessly.Originally used them with the 16F877 for multiaxis robots,some still in use today. I'd use an encoder/chip/PIC for each axis and a 'master' PIC to handle communications and readout.This way IF a sensor fails, a common spare unit makes for fast repair. Consider using RS485 for slave-host. Easy to implement, high noise immunity, and 'robust'.


Jay

[Sam_40]

Thank you guys for the very informative replies,
I will consider everything you guys said.

I will try to use one PIC for each encoder and one to communicate the three PIC and to the PC.

Ttelmah,
I did the search as you suggested, I am working on the code you provided in this link:
<http://www.ccsinfo.com/forum/viewtopic.php?t=44491&highlight=quadrature>

I never did any project that requires PIC to PIC communication, would you please point me to example that uses four PICs, or if you provide with example code, Just a simple code, with the position as fixed value and I will put everything together for my project. I just want to see how to use the I2C protocol the most efficient way for this project.

for example;

int32 position; /* 32 bit number 0 to 4294967295 -2147483648 to 2147483647 */

PIC 1 position value is 100
PIC 2 position value is 200
PIC 3 position value is 300

PIC3 will send the above to the PC

I read about how to connect the 4 PIC to each other to use the I2C. Using RC3 and RC4, connect all PICs in parallel and at one end, pull up resisters.

[Ttelmah]

I think you need to step back and learn some basic programming before starting to think about your project.

The baud rate is the rate that data is sent. It is the rate at which the signal changes per second (for a signal with just two 'states' - high and low, it is the same as the bit rate). It does not depend on the PIC clock, but you have to calculate the 'baud rate divisor', which says what division of the PIC clock is needed to give the rate you want to use.

With CCS, you just specify the baud rate, so:

#use rs232(UART1, BAUD=9600, ERRORS)

will do all the calculations to setup UART1 to talk at 9600 bps. The default will be 8 bits, no parity. The clock statement tells the compiler what clock you are using so it can do the calculations. You need to decide how fast you want your device to talk to the PC.

There are dozens of other settings you can use (interrupt driven RX & TX buffering for example, synchronous operation rather than async, control of TX enable signals etc.), but for simple RS232 comms all you need is this statement, a MAX232 or similar buffer and the connections from the PIC's hardware UART pins to this, and then this to the PC or whatever else you want to talk to.

Key thing at all stages is work _one step at a time_. Get your PIC working. First flash an LED, to prove you have got the clock working right. Then do a basic RS232 test and show this on your PC with a terminal program. Then the compiler comes with hundreds of examples. You could make your encoder chips use basically the code in EX_SPI_SLAVE.c to send their data as SPI slave devices. Add a CS (chip select) to the implementation (look at the manual on how to add 'SS' -SLAVE SELECT to the SPI setup, and the data sheet for what pin this uses on the slave devices), then just have the master operate a pin connected to this, and read the four bytes from the counter in the slave device.
However I have to repeat you would be much better off using the external chip. The one I list, gives you the counter already implemented, has hardware glitch filtering on the opto inputs, which unless you are unbelievably lucky, you _will_ need, and duplicate registers, so it keeps counting on the second set, while sending a reading when requested. All things that will involve hardware/software solutions.
The chips are $3.95 in 'one off', dropping to under $2, once a few are bought, and will save you hours of programming, and a lot of board space. One PIC talking to three of these, good power supply, a MAX232, and serial connection, and the project is finished. While you are waiting for them to come, you can spend the time becoming competent enough as a programmer to actually have a hope of writing the code...

[Sam_40]

Thank you,
I have enough information to get started. I appreciate your help.

[Eugeneo]

I was thinking about this. It sounds like a fun project.

You could create a FIFO buffer that captured only the PORTB change on interrupt. This will ensure a deterministic maximum interval. Also attach a counter value to it so you can later detect errors in the mechanics.

Use a standard QDI algorithm outside the interrupt to calculate all the position values.

Use the attached counter value to interpolate and assign a relative rotational acceleration.

Calculate the maximum rotational change based on inertial mass and the maximum torque of the motor. P=MV^2 so it is exponentially velocity dependent.

Compare the two - and if they are not within a certain range, there are conditional errors generated that can or cannot be compensated for.

Detect for FIFO overrun errors.

Use the Transfer Buffer Empty to ensure no blocking during serial txs.

Use and monitor the voltage of a dioded super cap to detect for a low voltage condition or a power disconnect to save the relative encoder positions for the next startup.