The encoder.N.x4-mode is still in master but it's for the software encoder...
JT On 3/14/2017 12:50 PM, Gene Heskett wrote: > On Tuesday 14 March 2017 11:26:41 John Kasunich wrote: > >> On Tue, Mar 14, 2017, at 10:56 AM, Gene Heskett wrote: >>> Greetings all; >>> >>> I threw out quite a few lines of code, but while its now working, >>> its working at 4x the movement I am asking it for. >>> >>> I am now sending my distance increment to the axis.x.scale and >>> joint.0.scale inputs. >>> >>> and sending the hm2...encoder.count to axis.x.counts and >>> joint.0.counts >>> >>> It seems that regardless of what I >>> setp hm2_[HOSTMOT2](BOARD).0.encoder.01.scale at,from 1 to 16 >>> tested, one click is a count of 4 at the count output. So I am >>> getting 4x the movement I want. So sending a .0002", gets me .0008" >>> rad change and .0016" dia change. >>> >>> Is there a fix for this unwanted 4 per click? Or am I getting a 4x >>> multiplier because I am feeding both axis and joint the encoder >>> count? >>> >>> Thanks all; >>> >>> Cheers, Gene Heskett >>> -- >> The jog scale inputs are "distance you want to travel per jogwheel >> count". >> >> Your wheel sends four counts for one detent. >> >> If you want one detent to be 0.001" set jog-scale to 1/4 of that, >> 0.00025". >> >> If you want one detent to be 0.010", set jog-scale to 0.0025". >> >> And so on... >> >> hm2_[HOSTMOT2](BOARD).0.encoder.01.scale has nothing to do with it. >> That is used INSIDE the encoder driver to scale the floating point >> output of the encoder. Wheel jogging doesn't use the floating point >> output of the encoder, it uses the raw counts. >> >> The reason for that is so that you can change the jog-scale any time >> you want. > I can do that, but the real fix has apparently been removed in the > 2.8-pre branch. What I needed, and the manpage says its there on this > machine, and in the manpage out there, and that was the > encoder.L.x4-mode. > > I can put a mul2 in with one input setp to .25, but why was the x4-mode > removed AND left at the default of counting every edge, which obviously > gives an output of 4 for one click. Thats simpler and I'll try that > first, but... > > I have another problem too, halshow now cannot see anything from > hostmot2! To me thats a genuine bug. ISTR it worked a week ago. Version > now on the pi is 2.8.0-pre1-2771-gdc2ff49, fresh last night. > > I just tried the counter-mode FALSE so it only counts the rising edge of > phase a. But as I suspected, it very quickly looses track of where it is > on the dials reversal. Grrrrr. I may have a better idea. Ignore the > encoders count output entirely. I am already developing a click(x|z) > signal that is only true when both phases of the encoders input are > true, and a direction derived from its velocity output. I'll take the > steered up and down count pulses from that and feed them to another > updown, and use its output to drive the jog-counts inputs to motion. > Thats also one count per click, but its presumably at the peak of the > area between detents, and need not be clamped since it will be zerored > when the timer times out, disabling the jogwheel entirely. At that > point, the direction outputs I am using should be accurate. But I expect > I'd better start nearly from square one and rewrite 95% of it. > > Cheers, Gene Heskett ------------------------------------------------------------------------------ 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
