@erco
I'm enjoying the thread...but since I had nothing noteworthy to add... I just watched from afar......
But, know this..... This info is also appreciated by me. [noparse][[/noparse]If it matters.. :> ]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Before you criticize someone, walk a mile in his shoes. That way if he gets angry, he'll be a mile away and barefoot. - unknown
I'm attaching a·bitmap of my encoder disk here. Low-res, quick & dirty, made quite simply with MS paint, since it has so few segments. Interestingly, my Hamamatsu P5587 sensors couldn't read them at all when printed on a very good quality·inkjet printer using plain paper. A laser printer and coated paper was required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"If you build it, they will come."
· I think a bit of a test where the the count is being monitored and then a decision is made based on the incrementing or decrementing register would give a realistic feel for the ability to track the encoder and do something with the value.
· I'll see if I can re-arrange my test rig to give it a try as well.
Tom: Very true. In the interest of maximizing speed, the fast-executing code I used doesn't do anything except count pulses. Not incredibly useful, unless this Stamp is a slave processor, and the count displayed on the LEDs is being monitored by a master processor that's doing the comparison and controlling the motor.
For one-Stamp operation, (per Tracy's post) one or more IF checks added to the code will slow down the loop execution and reduce the maximum RPM. So the benchmarks determined so far (more motor smoke to come) are definitely for the idealized case where the Stamp ain't doing nuttin' else!
I know, I'm building a case for a faster processor or multiple processors... the Propeller, for instance! Ironically the Prop is so fast, a single cog could go much faster than the Stamp in this encoder application, while doing several other things. One of these days...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"If you build it, they will come."
erco said...
Judging from the lack of replies to this post, I'm the only one who gives a flying fandango about the BS2's ability to read a quad encoder at speed.
I am impressed. I had missed this thread and found the videos the other day by accident·on youtube. Wow! I need to play with this my self.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
This thread has been a huge help for me, and I wanted to say thanks.
I was looking to hook up an optical encoder from an old cnc mill, and through this thread and others have been able to get it up and running on my BOE. It's a 50 detent knob with 400 p/rev and 5V supply, so it hooked right up and functions decently on Chris' program.
The encoder is drastic overkill for what I'm doing with it, but it was free and it's going to look cool. Thanks again for the valuable info.
The recent thread about Quadrature decoding redirected me here; hope it is Okay to re-open an old thread.
I used a different method and was able to get to 450 transitions/second with a vanilla BS2. The code is appended, as well as an analyzer captures at 160 transitions/second and 450 transitions/second.
I did not wait for a transition in the loop; I used a jump table: ON GOTO
top: jKey = (jKey << 2) OR INA 'produces a 4-bit value (16 cases) of 4 previous possibilities and 4 current possibilities
On jKey GOTO NC, Lft, Rght, ERR, Rght, NC... '00 to 00 is no change, 00 to 01 is moved Left, 00 to 10 is moved right, 00 to 11 is illegal, etc
NC displays the current count and goes to top.
Lft turns on a led, decrements a counter, turns off the led and goes to the top.
Right turns on a different led, increments a counter, turns off the led and goes to the top.
Err increments a different counter, turns on a third led and goes to the top, leaving that led on.
The OR at top can use the entire INA because the other two bits are the respective led and are known to be low at that time.
The analyzer captures shows it is very comfortable at 160 TPS, and just barely keeping up (but it DOES) at 450.
Comments
I'm enjoying the thread...but since I had nothing noteworthy to add... I just watched from afar......
But, know this..... This info is also appreciated by me. [noparse][[/noparse]If it matters.. :> ]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Before you criticize someone, walk a mile in his shoes. That way if he gets angry, he'll be a mile away and barefoot. - unknown
I'm attaching a·bitmap of my encoder disk here. Low-res, quick & dirty, made quite simply with MS paint, since it has so few segments. Interestingly, my Hamamatsu P5587 sensors couldn't read them at all when printed on a very good quality·inkjet printer using plain paper. A laser printer and coated paper was required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
·Thanks for that. Enjoy your trip!
· I think a bit of a test where the the count is being monitored and then a decision is made based on the incrementing or decrementing register would give a realistic feel for the ability to track the encoder and do something with the value.
· I'll see if I can re-arrange my test rig to give it a try as well.
·Cheers,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk
http://www.siskconsult.com
·
http://www.thingiverse.com/thing:1527
Robert
Are going to·juice the little·motor· to 24 volt and beyond to see if it can live·through a another day· To·see how far we can push a Basic Stamp·
Just an
·I just have to keep reading this post to see just how far you can push a Basic Stamp·and to what limit
Keep up the good work
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Now wanting to learn Spin· Thanks for any··that you may have and all of your time finding them
·
·
·
·
Sam
For one-Stamp operation, (per Tracy's post) one or more IF checks added to the code will slow down the loop execution and reduce the maximum RPM. So the benchmarks determined so far (more motor smoke to come) are definitely for the idealized case where the Stamp ain't doing nuttin' else!
I know, I'm building a case for a faster processor or multiple processors... the Propeller, for instance! Ironically the Prop is so fast, a single cog could go much faster than the Stamp in this encoder application, while doing several other things. One of these days...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Have you done any more test with this quad encoder
I had a another gate opener controller fail and
I am gong to try to use the codes that are posted and do some testing my self and see if this will work on the gate opener that why I asked
I was looking to hook up an optical encoder from an old cnc mill, and through this thread and others have been able to get it up and running on my BOE. It's a 50 detent knob with 400 p/rev and 5V supply, so it hooked right up and functions decently on Chris' program.
The encoder is drastic overkill for what I'm doing with it, but it was free and it's going to look cool. Thanks again for the valuable info.
I used a different method and was able to get to 450 transitions/second with a vanilla BS2. The code is appended, as well as an analyzer captures at 160 transitions/second and 450 transitions/second.
I did not wait for a transition in the loop; I used a jump table: ON GOTO
NC displays the current count and goes to top.
Lft turns on a led, decrements a counter, turns off the led and goes to the top.
Right turns on a different led, increments a counter, turns off the led and goes to the top.
Err increments a different counter, turns on a third led and goes to the top, leaving that led on.
The OR at top can use the entire INA because the other two bits are the respective led and are known to be low at that time.
The analyzer captures shows it is very comfortable at 160 TPS, and just barely keeping up (but it DOES) at 450.