On Friday 31 March 2017 11:32:53 Kenneth Lerman wrote: > Up the thread a ways, Gene commented that the MPG generates one count > per detent. > It does not, the encoder scale is set to 4, so at the encoder out, one "click" is 4, but later I mult2 that by .2500000, and this is what is fed to jog-counts.
> 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. Correct it seems. Thats exactly why I divide by 4 in the mult2 module > 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. Once I had slowed the MAX_ACCELS to get rid of the joint errors, I find that I can crank as fast as I can, overrunning the axis motor so it goes on a bit, but then I can crank it back the other way, and IF I started at a touched off zero, and the dial on zero when I touched off, and then crank back and reset the dial to zero, and look at at the dro, it also says zero, so I am not losing any counts. But I should point out that for step range setting, due to the input to our updown counter, I am obtaining the fwd/reverse signal from the encoders velocity output with a wcomp. But this is only for the step size adjustment, not the actual step itself. Another thing I'm doing, is, when the activity timer expires, everything except the step size, here on this lathe is directly in inches starting at .0001" on a 1,2,5 sequence, is reset to all balls, so each such timed interval starts from scratch. This circuit has no hysteresis, and this reset at timed out may have something to do with that. I'm in hog heaven with how its working except that each axis has to be moved by some amount before the dials can move it. Once I have home switches installed that motion will qualify, but ATM its a PITA because that required motion destroys the positioning from when it was shut down, and which is restored on startup. As far as I am concerned, pressing F2 should enable them just like everything else is. But something else has to move an axis before the dial can. My time ATM is spent on the spindle driving pulley, and the G2/G3 is again eating my days as there seems to be no proper order for it to use an 0/0 set of moves in relative mode to cut a circle wherever the hell the code drives it to, and which is to be considered the center of the counterbore I want to cut. The start to finish error is always 50% according to the popup during the reload. I'm going to make that a separate post however. > 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 Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ 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
