| ??? 03/01/05 16:17 Read: times Msg Score: +1 +1 Good Answer/Helpful |
#88787 - Peter is right! Responding to: ???'s previous message |
His solution is bullet-proof (no accumulating error), as long as one condition is met: there must be always be at least one sample between the edges. This condition is met, if the "plateau" (clear of any transition) between the edges is long enough (> period of sampling) - this is given by the encoder rotation speed and its construction.
This has nothing to do with the frequency of eventual oscillation when the encoder stops at an edge; this can be arbitrarily high or low. The fact of periodical sampling together with the existence of the "clean areas" is the filtering itself. Note, that it is sampled by a periodical clock, not the inputs' edges - Peter stressed this.
For example, let the encoder stay between state 1 and 2. It has seen state 1 at the last moment of sampling. It the next sampling sees state 2, OK, let it be 2. If the next is 1 again, OK, let it be 1. And so forth, until the encoder starts moving. The design ensures, there is at least one sample in the "clear" area, either 1 or 2, depending on the direction of the movement. And so it does not lose a single step. The only uncertainty is the +- 1 step while it is sitting at the edge wiggling, this error is not accumulating. Of course, anything similar in CPLD/FPGA/DSP/silicon will work, too. Jan Waclawek PS. Sorry, I am not able to read vhdl so I don't understand, how Jez's solution works - is it similar or not. |
| Topic | Author | Date |
| Digital position encoder | 01/01/70 00:00 | |
| Dont do this. | 01/01/70 00:00 | |
| Signals are not connected directly | 01/01/70 00:00 | |
| Is assembly ok? | 01/01/70 00:00 | |
| For Mehdi | 01/01/70 00:00 | |
| its easy in software | 01/01/70 00:00 | |
| but | 01/01/70 00:00 | |
| same resolution | 01/01/70 00:00 | |
| But...what if ? | 01/01/70 00:00 | |
| So what is the solution? | 01/01/70 00:00 | |
| absolutely no problem | 01/01/70 00:00 | |
| Thank you | 01/01/70 00:00 | |
| PLEASE not again | 01/01/70 00:00 | |
| Sorry | 01/01/70 00:00 | |
| list.hw.cz | 01/01/70 00:00 | |
| thank you | 01/01/70 00:00 | |
| Re: PLEASE not again | 01/01/70 00:00 | |
| Re frequency | 01/01/70 00:00 | |
| So what frequency do we sample at? | 01/01/70 00:00 | |
| I try to explain Peter's idea again | 01/01/70 00:00 | |
| We know it ! | 01/01/70 00:00 | |
| Nothing ??? | 01/01/70 00:00 | |
| it takes time | 01/01/70 00:00 | |
| Code doesn't function | 01/01/70 00:00 | |
| reverse direction ! | 01/01/70 00:00 | |
| This is not a problem | 01/01/70 00:00 | |
| incorrect operation? | 01/01/70 00:00 | |
| right connection ? | 01/01/70 00:00 | |
| I dunno | 01/01/70 00:00 | |
| Now... | 01/01/70 00:00 | |
| check the sample condition ! | 01/01/70 00:00 | |
| clarify | 01/01/70 00:00 | |
| @Erik | 01/01/70 00:00 | |
| @Peter | 01/01/70 00:00 | |
| Grey code | 01/01/70 00:00 | |
| Grey code more | 01/01/70 00:00 | |
| Grey INCREMENTAL ? | 01/01/70 00:00 | |
| I guess 98 | 01/01/70 00:00 | |
| Gray code | 01/01/70 00:00 | |
| Not a gray code | 01/01/70 00:00 | |
| Grey | 01/01/70 00:00 | |
| Yes of course its Grey code | 01/01/70 00:00 | |
| Absolute Vs Incremental | 01/01/70 00:00 | |
| So now... | 01/01/70 00:00 | |
| Yes it can but only... | 01/01/70 00:00 | |
| Peter is right! | 01/01/70 00:00 | |
| Lover not a fighter :-) | 01/01/70 00:00 | |
| Lover of software | 01/01/70 00:00 | |
| steps lost or not | 01/01/70 00:00 | |
| Determining direction | 01/01/70 00:00 | |
Its not Grey, its Gray ! | 01/01/70 00:00 |



