Talk:Incremental encoder

Interface of encoders, vs encoder transducer

The introduction mentions the interface of incremental and absolute encoders, discussing the latency of an interface and the appropriateness for high-speed or real-time applications. I think this confuses the fundamental distinction between an incremental encoder and absolute encoder, so I removed it, but it been added back: https://en.wikipedia.org/w/index.php?title=Incremental_encoder&diff=next&oldid=975107173 Intellec7 (talk) 14:41, 27 August 2020 (UTC)

Hi Intellec7. The intent was to contrast multi-turn encoders (which typically use serial interfaces), but "multi-turn" was omitted to avoid confusion with linear encoders. Lambtron talk 15:21, 27 August 2020 (UTC)

I believe the main contrast should be between incremental and absolute encoders, regardless of the kind (single- or multi-turn) of absolute encoder, so it should be possible to sidestep any conversation about the kind of absolute encoder, and the logical interface of any sensor. I see no need to talk about serial interfaces. Intellec7 (talk) 15:31, 27 August 2020 (UTC)

It may be best to discuss the myriad absolute/incremental differences in rotary encoders. However, I think it's worth pointing out here that in applications that track position over long distances -- which applies to incremental encoders and multi-turn absolute encoders -- incremental encoders do report position at higher rates and with lower latency. Lambtron talk 15:51, 27 August 2020 (UTC)

"incremental encoders do report position at higher rates and with lower latency" This is not an obvious fact to me. What is obvious empirically is that incremental encoders exist at higher resolutions, since the resolution does not depend on the number of "bits" the way it does for an absolute encoder. Note that for an absolute encoder with a binary (not Gray code) disk, the signal of the least-significant bit is just a pulse train the same as one of the channels of a quadrature incremental encoder. Resolution aside, conceptually an absolute encoder is _also_ an incremental encoder. Intellec7 (talk) 16:00, 27 August 2020 (UTC)

Please keep in mind the intended multi-turn context, and the explicit "serial" interface. What I meant was that the maximum report rate of a serial absolute encoder is limited by its serial interface and protocol; incremental's have no such limitations. The latency of a serial absolute encoder is higher because reports are inherently delayed by both polling and serial comm. I think it's useful to at least mention this in the context of "long distance" position tracking -- an application area common to both incremental and multi-turn absolute encoders. Do you think this is worthy of inclusion? If so, is there some better way to cover this that you would consider less confusing? Lambtron talk 17:05, 27 August 2020 (UTC)

I headed this conversation to encourage a distinction between the logical interface to an encoder and the encoder transducer itself. As such, I do not think a discussion of serial interface or polling is warranted in the introduction. I could imagine a clarification in terms of "channels" could be helpful. An incremental encoder will typically have three signal channels: A, B, Z. An absolute encoder will at the lowest level have typically N channels, where 2^N is the number of "absolutely distinguishable positions" (that is not a term of art, but I hope the meaning is clear). The fact that the N channels can be read out serially, either by polling, or at a fixed rate is a detail that I believe does not help elucidate the fundamental difference between an absolute encoder and an incremental encoder, since not all absolute encoders have 1. serial interfaces, 2. serial interfaces that require polling. What all absolute encoders share in common are the existence of the N channels which provide an encoding of the absolute position. I would further argue that the consideration behind choosing an absolute or incremental encoder has less to do with latency and more to do with whether it acceptable to "home" the encoder, so that an incremental encoder can provide an absolute position reference, or whether absolute position is needed to begin with. For example, for the application of measuring velocity, an incremental encoder isn't used because it provides less latency, it is used because the absolute position is not needed. Intellec7 (talk) 17:24, 27 August 2020 (UTC)

I still think this issue should be discussed somewhere (either here or in rotary encoder), but I defer to your opinion here and have stripped all mention of "absolute" from lede paragraph 3. Lambtron talk 17:55, 27 August 2020 (UTC)

I think it's less confusing now. Thanks for that edit. Sorry if I sound dense, but could you clarify which issue you think should be discussed? I can try to add it somewhere. Intellec7 (talk) 21:00, 27 August 2020 (UTC)

@Intellec7: why did you put a cn tag on The resulting, very low latency of incremental encoders allows them to monitor the positions of high speed mechanisms in near real-time? It seems like an obviously true statement to me. Lambtron talk 15:24, 27 August 2020 (UTC)

I think we agree it is important to contrast absolute encoders, but I do not agree the contrast has anything to do with latency, interface, or appropriateness for real-time and/or high-speed applications. That is why I deleted the paragraph. You added it back, so the cn tag was a way to have a more productive way to collaborate on this page. If a citation has an opinion one way or another, then we can talk about it. Intellec7 (talk) 15:36, 27 August 2020 (UTC)

Yes, we seem to be on the same page. However, this sentence states an obviously true aspect of incremental encoders and doesn't even mention (or imply reference to) absolute encoders -- and therefore doesn't deserve a cn tag. Lambtron talk 15:56, 27 August 2020 (UTC)