Up the thread a ways, Gene commented that the MPG generates one count per detent.
I thought that the encoder in the MPG generates one *cycle* per detent. A cycle is represents four quadrature edges which means that you get four counts per cycle. So that's four counts per detent. There is a complication that there is one count of hysteresis involved here. So if you turn clockwise and then reverse directions, you might be off one count from where you started. If you repeatedly go back and forth though, you should not accumulate more than one count of deadband. Going back to Stuart's original post where he says that he sees motions of .0075 or .01 per click, that is what I would expect if there was some back and forth motion at some of the clicks. Stuart also sees that the error is not accumulating. My conclusion is that what Stuart is seeing is an artifact, not an error. Ken Kenneth Lerman 55 Main Street Newtown, CT 06470 On Thu, Mar 30, 2017 at 12:54 PM, Jon Elson <el...@pico-systems.com> wrote: > On 03/30/2017 04:04 AM, andy pugh wrote: > > On 30 March 2017 at 04:11, Jon Elson <el...@pico-systems.com> wrote: > >> Now, I am using ilowpass on a 2.6 install, possibly > >> something has changed. > > Nothing has changed since 2014 > > https://github.com/LinuxCNC/linuxcnc/commits/master/src/ > hal/components/ilowpass.comp > > > > The whole component is only 2 lines of code: > > > > ;; > > value += (in - value) * gain; > > out = (int)(rtapi_s64)(value * scale); > > > > > > > Right. Jeff Epler wrote that for me at one of the CNC > Workshops at Roland Freistad's place. It is so SIMPLE, I am > having some trouble seeing how it could be the culprit, > unless maybe given very wrong parameters. > > Anyway, comparing the input and output from ilowpass should > confirm that it is (or is not) causing the problem. > I'm thinking there is a combination of a weak encoder output > drive, electrical noise, maybe A<-> B crosstalk and the PPMC > encoder counter is counting somewhat erratically. I think > putting Halmeter on the encoder count output and then > cranking the encoder known distances at varying speeds might > quickly show this is happening. (or not...) > > Jon > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
