Quick thoughts: DT Ints with encoders

[kevlar129bp]

Hello all,

Here I go again. Working on a project...Digitizing Arm...and needing to count pulses from 6 encoders. The encoders will be counted in quadrature, therefore, I will need to monitor interrupts from 24 different lines...

Each encoder:
Lines: 500
Counts: 2000 (in quadrature)
Gear Reduction: 10.8:1
Total Counts: 21600

WORD sized variable to hold counts

Here is my question(s):

Using DT Ints portB change interrupts, am I led to believe I am going to need 3 individual pics to achieve 24 portB lines, or is there a slicker way to get my 24 IO lines that have interrupt on change?
Should I run 6 pics (1 per encoder) to keep the counts super accurate?

The plan calls for a button to be on the stylus, and upon a button press, the counts from each encoder will be sent to the pc via RS232, to be processed into a point cloud for SolidWorks.

If I run 1 pic, the serial stream would be a piece of cake...

If I run 6 pics, does it not get a little tricky?
Maybe a "master" pic collecting the data from all the encoder pics...then
the "master" sending all the counts to the pc?...
OR
All encoder pics sharing the same TX line and "bus busy" line, therefore when an encoder pic is transmitting, it will pull the "bus busy" line high, halting other encoder pics from their transmissions?

I guess I'll stop here and see what thoughts I get.

As far as code thoughts..I'm good there. I guess I'm seeking hardware thoughts at this stage.
I think tracking the encoder counts is the most important aspect of this project...

Any thoughts at this point, are good thoughts!

Thanks all,

Chris

[HenrikOlsson]

Hi,
Why do you need 24 inputs for 6 encoders?

If it was me doing it, I'd probably go with one PIC per encoder or perahaps one PIC for two encoders, each one reporting to a master. Keeping track of multiple encoders (with this kind of resolution) in software won't be easy.

/Henrik.

[kevlar129bp]

Thanks Henrick,

Good point with the 24 IO lines
I only need 12...

Channel A
Channel B

I was thinking the NOT channels too...Doh!

Thanks for the thoughts.

Anyone else want to chime in?

Chris

[kevlar129bp]

BTW:

The serial stream from the encoder pics will just be the counts...
no angles, math, etc.
That will be handled on the pc side of things.

Chris

[kevlar129bp]

Here's a screen-shot of the temporary VB prog... to give you guys a visual.

[HenrikOlsson]

That's pretty cool! I've played a bit with digitizing arms from FARO and they are very impressive devices, good luck and please keep as posted on the progress!

/Henrik.

BTW. I think the term is forward kinematics...

[kevlar129bp]

Right you are Henrik . Good thing it's just the form title .
I think I am going to go with the 6 pics reporting to a master via SEROUT2.
I'll have the master report to the pc via HSEROUT. I think the speed will benefit
from this scheme as well.

Chris

[HenrikOlsson]

Hmm, SEROUT2 (ie software UART) may not be a good idea. The interrupts will screw with the timing. The PIC12F1822 looked perfect for this untill I saw it was listed as a future product... (It's an 8-pin device with USART and Interrupt on change feature). Maby you can use it for the production model ;-)

The PIC16F688, though a 14pin device, is available and has both USART and interrupt on change feature (on 6 pins), have a look at that.

[kevlar129bp]

Hey Hendrik,

I'll take a glance at the parts you mentioned. Kinda cool you mentioned the uarts. Maybe you can answer a lingering question for me... In the example of the six "slaves" reporting to the "master"... If I send HSEROUT from the slaves, what would be the protocol for receiving at the master? Would I use SERIN2? What mode? Etc, etc?

That question has driven me nuts for some time!

I'm thinking 20 Mhz on the slaves and 40 Mhz on the master.

What are your thoughts?

Thanks again,

Chris