On Thursday 30 November 2017 14:12:11 Chris Albertson wrote: > I'm Stil not understanding. Gene's math is still not clear. > Thats because the a/b signals ARE coming from a 1000 line encoder on the MOTOR. BUT the index is coming from an encoder on the SPINDLE. IOW, two different encoders. The index from the motors encoder is hanging out in the breeze, and the a/b from the spindle encoder are also disconnected.
The gear ratios between them were measured by some hal code that used a pair of mux2's as sample-holds, in this case the first one is frozen as the counter goes by 5.5, the second one frozen as the counter, which is counting index pulses, goes by 105.5. The are both sampling the encoders rawcount. Those 2 figures are then fed to a sum2, with the gain of input 0 set to -1.00000000 and the 2nd higher count, fed to in1 so the first captured rawcount is subtracted from the second rawcount, giving a value that is 100 spindle turns worth of rawcount.That is then divided by 100 to get the one turn count to high accuracy. Multiplied by 4 so all edges are accounted for. A run was made with the gear in high gear, which by the time the math was done, =7161.16. Repeated with the gear selector in low, then the same math gave 14300 in round figures, these two are then set into the encoder.scale according to which gear its in. The idea is that regardless of which gear its on, one turn of the spindle is still an increment of 1.0000000 to the position output fed to motion. > Is the encoder on the motor or the spindle? If the goal is to do > threading it must be on the spindle or the index pulse is not going to > work. > See above. > If on the motor then what is the gear ratio? See above. > > The trick is to convert FIRST to revolutions per second. > > Some tricks: If the goal is only to control the motor speed and not > the angle of the spindle then you don't need to look at all the > encoder data. First off you KNOW the direction of rotation so you can > ignore the entire idea of "quadrature" Just look at one channel, say > "A" > > Next trick. If you only care about speed and the encoder data is > moving to fast, the first rick is t look only at the rising edge of > one phase. Now you just count "ticks" > > If even these ticks come to fast then use the divide by two hardware > device, like a JK flipflop. > > All that said. The low-end $2 ARM micro controller has build in > hardware quadrature decoding that handles this entire problem with > ZERO use of the CPU. All the phase tracking and counting is don't > with hardware logic. And it works for signals at the MHz level. So > if yu really do have a requirement torun serval encoders at a million > lines per second the solution is not expensive. Advice however is to > design it so the MHz speed signal travels less then an inch, another > words no cable, use PCB traces. I've got some motors here on my desk > that spin at 11,000 RPM and I'm using s $3 computer board to control > speed. No FPGA required. [...] Thank Chris, I hope this clears it up? 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
