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
-- 
"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

Reply via email to