On Saturday 19 May 2018 14:47:46 Chris Albertson wrote: > I'm doing something like this but for another non-MK related project. > I want to capture the count associated with an optical encoder and > the worst case is the encoder is sending "edges" every 30 micro > seconds. The solution is easy if you use a hardware counter. You > gate the counter to a latch. I think if something is changing very > quickly and you care a lot about accuracy you need to do the work > "logically close" to the encoder, not four processing steps later. > With MK most people are using either FPGA based mesa card (which is > the VERY best place to do this) or the PRU in the Begal Board. If yu > wait until the cost is inside the Linux machine the hardware counter > may have crossed another transition. Of course the down side of > doing this at a low level is you need to program the device. FPGA > programming has a bit of a learning curve and and PRU requires some > study too. > > ( method does not apply here. I keep the count inside a hardware > timer/counter register in an ARM-M micro controller.) > > In general doing this at the lowest level possible is best but like > harder to do. The FPGA is the best place > I'm useing mux2's as sample-holds, freezing each from a different signal. But w/o tieing up a 2nd encoder, my accuracy is limited by the granularity of the values read because the freeze signal are tied to the servo-thread rate. Accuracy on the lathe is limited by the 240 scale on the lathes encoder.
On the milling machine, the error is a much larger value, but its granularity is still married to the servo-thread. To put the 240 scale on the lathe for a 1.5 degree accuracy, the high gear scale in the mill is 7161.61, and 14 thousand and change in low gear. But the millisecond granularity is a much larger value if the spindle is running wide open, which is nearly 3,000 rpms. That corresponds to a nominally 42,285,000 HZ/minute edge signals into the encoder. So its turning 3 whole revolutions per servo-thread. There are of course other factors I haven't thought of yet, but rigid tapping needs low gear for taps above 1/4", so motor inertia enters boldly, making rigid tapping at the higher spindle speeds a bit of a guessing game due to the turn-around time. I may find I'll have to bring up a 2end encoder, and use a variation of Jon & Maximes theory to do it, but this sounds like a special firmware for a 5i25 project. So I'll leave it at its present hal programming state until such time as I see the need for that sort of accuracy. I don't, at this point, foresee the need. But that guy Murphy is reading this over my shoulder, so all bets are off... :( > On Fri, May 18, 2018 at 9:10 PM, Gene Heskett <ghesk...@shentel.net> wrote: > > On Friday 18 May 2018 22:15:37 Jon Elson wrote: > > > On 05/18/2018 07:57 AM, Maxime Lemonnier wrote: > > > > Well, from the halscope capture, the index signal looks quite > > > > clean. it is digitally generated anyways. > > > > > > That is misleading, it is only sampled by the PPMC driver > > > 1000 times a second, and is also sampled at > > > the encoder filter clock rate (1 - 10 MHz, selectable) by > > > the PWM controller board. But, if you don't get any > > > triggers except at the rate you are sending them, then maybe > > > it is fine. > > > > > > Jon > > > > Jon is correct there. The sample rate of the halscope is the thread > > rate its running on. usually the 1 kilohertz floating point > > capable "servo-thread". Its incapable of registering or showing > > something that may change state at 500+ kilohertz. > > > > So this, to get an idea of whats going on, needs at least a dual > > trace triggered scope with a 100mhz bandwidth, or a digital sampler > > with a similar bandwidth. I have both. Likewise, the triggering > > logic being discussed here, also needs to be real, external IC's on > > a circuit board, the logic bits and pieces for linuxcnc are tied to > > the thread they are addf'd to in the hal file, with a maximum state > > change at the 1000 hz servo-thread rate. The external logic can > > generally keep up with state changes at a 20+ megacycle rate for the > > $0.25 parts when you buy them in tubes of 25 or so. > > > > But this is an interesting project, so please Maxime, keep us posted > > on progress and problems. > > > > -- > > 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 -- 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
