On Thursday 17 May 2018 12:05:17 Jon Elson wrote: > On 05/17/2018 08:24 AM, andy pugh wrote: > > It isn't clear from your description precisely when you > > want this to happen, but I imagine that choosing the > > conditions is also something easiest inside the custom > > component. > > Let me explain what mr. Lemonnier is trying to do. > He has a signal from an external device.
Which is not what I assumed from the original post, hence my confusion. > He wants to record > the position of an encoder when there is a pulse from that > device. Now, the rub is he wants to be moving the axes > quickly, so that there are multiple encoder counts/servo > period. But, he wants the exact position recorded when the > pulse comes. > > So, after stewing over his problem for a while, I realized > there was a way to do it. Feed the encoder to TWO encoder > counters. One works normally, and is for position control > under LinuxCNC. The other receives the external pulse on > the Z input. And, when the external pulse is expected, turn > on the index-enable pin of encoder. When the pulse comes, > the encoder counter will be zeroed, just like a spindle > encoder on a G33.1 or an axis when homing to the index > pulse. Now, motion continues, and then the servo thread > triggers. The axis will have the position when the servo > period triggered, and the extra encoder counter will have > the distance traveled between the pulse on Z and when the > servo period triggered. By calculating axis position MINUS > extra encoder, you get the axis position when the Z pulse > triggered the extra encoder to zero. And that makes perfect sense. > So, a component needs to set the encoder-index to true, and > then watch for it to go false. When it sees the > encoder-index go false, if does the subtraction and stores > the difference in a net. It then turns the index-enable > back to true. And this occurs outside of motions control so is not subject to the quantizing effect of being inside the servo-thread. This is truly thinking outside the box represented by the servo-thread time. Something difficult. But since all that sounds like it needs realtime linkage that is not part of the servo-thread, it will be "external" wireing. Thats a bit hazy yet. But I like it as it could represent an alternate method of detecting the overshoot at the bottom of a g33.1 peck too. Maybe, but I don't see a huge simplification of the following logic to make human readable values out of the diff. And I'd still need to make the distance measurement result available to the gcode in the form of a #<_named> variable in order to implement the ultimate broken tap saver part of the idea. > Jon > Thanks Jon. > ---------------------------------------------------------------------- >-------- Check out the vibrant tech community on one of the world's > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users -- 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-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
