Serin usage?

[champion]

Skimask, we get it. You know what you're doing with a PIC, but it's not helping anyone to brag about what you can do or have done. This site is about helping people work out their issues with projects relating to the PIC and MELabs stuff. If you have a suggestion, please let me and the others know. But just bragging is a little lame. Also, my issue has to deal with the output of the encoder not generating enough ppr to have the kind of revolution that I need, thus requiring a quadrature decoder to increase the ppr of the encoder. I have no doubt that the PIC will be able to handle the pulses after that. The thing I can't figure out now is how to interface the decoder with the PIC from the PicBasic code side. Thanks for your help and I hope someone has an idea as to what I could try as far as the code to implement this contraption goes.

[HenrikOlsson]

Hi Champion,
That IC uses a synchronous serial interface so SERIN will not work. I think you need to have a look at the SHIFTIN command instead. I'm not sure if it can shift in all 22bits in one shot but perhaps it can. It can definetly read the lower 16bits in one go - perhaps that's enough for you.

Counter VAR WORD

LOW CS		'Select chip
HIGH PLSR	'Load counter to shift register

'Shift in 16bits of data. you may need to experiment with the mode number.
Shiftin CNTdata, CLKsr, 3, [Counter\16]
Low PLSR
High CS		'Deselct chip.

'Display or whatever.

The datasheets indicates that the PLSR needs to be held high while reading the first bit so I guess it CAN be held high while reading the rest too since the shift register is loaded on the rising of PLSR going high. You'll have to experiment there.

Try to get it to read the lower 16bits first, then we can figure out a way to read all 22. I think that the tricky part will be what to to with the 22bits when you have them in the PIC.

/Henrik Olsson.

[champion]

Try to get it to read the lower 16bits first, then we can figure out a way to read all 22. I think that the tricky part will be what to to with the 22bits when you have them in the PIC.

/Henrik Olsson.

Henrik,

I am wrong in thinking that I will just be able to convert however many bits I can get into a decimal? If it's over 8 bits I might have to do a little work with it but... I'm new, but I think it shouldn't be too bad. No? Thanks a lot for your help!

[HenrikOlsson]

Hi,

I am wrong in thinking that I will just be able to convert however many bits I can get into a decimal? If it's over 8 bits I might have to do a little work with it but... I'm new, but I think it shouldn't be too bad. No? Thanks a lot for your help!

PBP performs math on variables up to 16bits wide (WORD). With more bits than that (22 for example) you will have to do a little work.

It all depends on your application. If you use the lower 16bits of the available 22 you won't loose any resolution but you are limited to 720 degrees on the encoder before the lower 16bits 'roll over'. If 720 degrees is enough - great! If not you will have to use all 22bits. I think it would be pretty easy to get all 22 bits into the PIC but then, again, it all depends on what it is you want to with them once they are there.

Remember that PBP does integer math only. You have 91.0222 encoder counts per degree but you can't simply do Degrees = Count / 91.0222. The result you'll get will be the integer partof the result only. There are way around this but the best aproach may vary depending on if you just want to display the encoder position in degrees or if you need to to more calculation on the result.

Hope it helps.

/Henrik Olsson.

[skimask]

Skimask, we get it. You know what you're doing with a PIC, but it's not helping anyone to brag about what you can do or have done. This site is about helping people work out their issues with projects relating to the PIC and MELabs stuff. If you have a suggestion, please let me and the others know. But just bragging is a little lame. Also, my issue has to deal with the output of the encoder not generating enough ppr to have the kind of revolution that I need, thus requiring a quadrature decoder to increase the ppr of the encoder. I have no doubt that the PIC will be able to handle the pulses after that. The thing I can't figure out now is how to interface the decoder with the PIC from the PicBasic code side. Thanks for your help and I hope someone has an idea as to what I could try as far as the code to implement this contraption goes.

>Skimask, we get it.
We may get it, but you apparently haven't yet...
And I ain't braggin' 'bout squat... I haven't done anything miraculous or extraordinary or anything new and fantastic that anybody else has already done a dozen times. So...WAAAAAAAAAHHHHHHH!!!!

So, be that as it may, if you are having trouble with the decoder, get rid of it. IF you can make a PIC do the work of this optical encoder, and IF you can figure out how to transmit data between 2 PICs, then MAYBE, just MAYBE you could set up one PIC running at high speed doing nothing but reading the optical encoder and POSSIBLY send that data to another PIC to do work for you instead of a single PIC handling everything (which again, shouldn't be a problem in the first place). But with 2 PICs, you'd be splitting up the tasks into managable chunks.

And I'm out....

[champion]

> if you are having trouble with the decoder, get rid of it. IF you can make a PIC do the work of this optical encoder

Um, what are you talking about? How should I measure angular position with the very high accuracy I need without an encoder? How am I gonna have the PIC do the work of the encoder? Youre lost.

[skimask]

Um, what are you talking about? How should I measure angular position with the very high accuracy I need without an encoder? How am I gonna have the PIC do the work of the encoder? Youre lost.

Yep, you're right, I am completely lost...After reading through the datasheet linked above and for teh 2122-5 itself, I found that what you're trying to do is physically impossible without a decoder/counter chip in between the PIC and the encoder. After all, who would've ever thought of using a couple of the interrupts and registers on a PIC to detect level changes on the outputs of an optical encoder. 'cause that would just be silly.

NOT! There are loads of 'google-able' references out there for directly connecting a quad-encoder to a PIC, with very high resolution/accuracy (which is obviously dependant upon the encoder itself), AND easily complete other tasks at the same time, all without missing pulses from multiple encoders...but I give up. Sometimes ya just can't tell a person anything.

[champion]

Yep, you're right, I am completely lost...After reading through the datasheet linked above and for teh 2122-5 itself, I found that what you're trying to do is physically impossible without a decoder/counter chip in between the PIC and the encoder. After all, who would've ever thought of using a couple of the interrupts and registers on a PIC to detect level changes on the outputs of an optical encoder. 'cause that would just be silly.

NOT! There are loads of 'google-able' references out there for directly connecting a quad-encoder to a PIC, with very high resolution/accuracy (which is obviously dependant upon the encoder itself), AND easily complete other tasks at the same time, all without missing pulses from multiple encoders...but I give up. Sometimes ya just can't tell a person anything.

Skimask, I don't think that you have read about my problem. I believe I said before that I need a resolution of at least 360*60=21600 pulses per revolution. Okay, try and find an encoder that has more than 8192 ppr for less than $100. You can't. Then I guess you could use a quadrature decoder along with the encoder to increase the resolution. There you have 8192*4=32768 ppr. That's enough resolution. So what is it that you think that is physically impossible? Didn't you read above that I was using a decoder? And why do you keep talking about missing pulses or any need for a higher frequency oscillator? I think you're probably a smart guy so that's why I must assume that you are simply not reading the entire thread carefully. Go back and read through all of the posts before you make any more comments. k?

PS. I now have the entire system up and running right now, so thanks for all of your help. You rock!!!

[skimask]

Skimask, I don't think that you have read about my problem. I believe I said before that I need a resolution of at least 360*60=21600 pulses per revolution. Okay, try and find an encoder that has more than 8192 ppr for less than $100. You can't. Then I guess you could use a quadrature decoder along with the encoder to increase the resolution. There you have 8192*4=32768 ppr. That's enough resolution. So what is it that you think that is physically impossible? Didn't you read above that I was using a decoder? And why do you keep talking about missing pulses or any need for a higher frequency oscillator? I think you're probably a smart guy so that's why I must assume that you are simply not reading the entire thread carefully. Go back and read through all of the posts before you make any more comments. k?

Somebody's sarcasm detector is broken...
I get it, got it, bought the movie...
1 minute of resolution - gear reduction works too, depending on the physical application of course
How do you increase the resolution from an encoder which only puts out X ppr?
Missing pulses? higher oscillator? what?
Read thru it -
You said you have an encoder All I said was that you could save some headache, not to mention PCB space, by using a PIC with some creative programming and still have loads of accuracy at high rpm, instead of relying on a dedicated decoder/counter/shift register and probably save a couple bucks on top of it. Not only that, but you never did say what the end product might be (crank trigger, star follower, gps guided egg cracker, etc).

[Archangel]

Somebody's sarcasm detector is broken...

You think so? Look again at his avatar!