On Friday 24 February 2017 07:34:16 Ron Bean wrote:
> >What I'd like is a 0.1, 0.2, 0.5, 1.0, 2.0, 5.0 etc gain sequence,
> >extended another decade both directions.
>
> I like this idea a lot, I've been thinking along similar lines. I
> don't understand why every CNC controller uses 10x
>What I'd like is a 0.1, 0.2, 0.5, 1.0, 2.0, 5.0 etc gain sequence,
>extended another decade both directions.
I like this idea a lot, I've been thinking along similar lines. I don't
understand why every CNC controller uses 10x increments.
On Friday 24 February 2017 05:53:35 andy pugh wrote:
> On 24 February 2017 at 10:44, Gene Heskett
wrote:
> > But every scheme I come up demands the encoder be restored to
> > zero on the button release before the accumulated count can make the
> > machine move wildly.
>
>
On Friday 24 February 2017 00:08:42 Chris Albertson wrote:
> I don't think it works this way. It does not power down. But it
> does work exactly as per the specification. There are 100 detented
> divisions per revolution. The A and B phase of course only change
> when there is movement.
>
>
On 24 February 2017 at 10:44, Gene Heskett wrote:
> But every scheme I come up demands the encoder be restored to
> zero on the button release before the accumulated count can make the
> machine move wildly.
LinuxCNC handles that. No need to zero the counts.
Wheel-jogging
On Thursday 23 February 2017 23:14:37 Kurt Jacobson wrote:
> Gene, my MPG works great. Does not have any lag at all. The 400ppr did
> throw me off at first when the machine jogged four times the jog
> scale. I put a fix for that in the MPG comp I wrote, it just divides
> the jog scale by whatever
On Thursday 23 February 2017 22:44:19 Jon Elson wrote:
> On 02/23/2017 08:31 PM, Gene Heskett wrote:
> > But I think its something we may be able to outwit in the hal file.
> >
> > They appear to have a power save shutdown, and a power up lag.
> >
> > And seem to have timings independent from
On Thursday 23 February 2017 22:37:59 Jon Elson wrote:
> On 02/23/2017 08:31 PM, Gene Heskett wrote:
> > But I think its something we may be able to outwit in the hal file.
> >
> > They appear to have a power save shutdown, and a power up lag.
> >
> > And seem to have timings independent from
I don't think it works this way. It does not power down. But it does
work exactly as per the specification. There are 100 detented divisions
per revolution. The A and B phase of course only change when there is
movement.
In theory you can get 400 steps per rev but the wheel has detents so
Gene, my MPG works great. Does not have any lag at all. The 400ppr did
throw me off at first when the machine jogged four times the jog scale. I
put a fix for that in the MPG comp I wrote, it just divides the jog scale
by whatever the mpg-pulses parameter is set to, 4 in this case.
I like the
On 02/23/2017 08:31 PM, Gene Heskett wrote:
> But I think its something we may be able to outwit in the hal file.
>
> They appear to have a power save shutdown, and a power up lag.
>
> And seem to have timings independent from each other. This is going to
> cause, unless we scale the encoder down
On 02/23/2017 08:31 PM, Gene Heskett wrote:
> But I think its something we may be able to outwit in the hal file.
>
> They appear to have a power save shutdown, and a power up lag.
>
> And seem to have timings independent from each other. This is going to
> cause, unless we scale the encoder down
But I think its something we may be able to outwit in the hal file.
They appear to have a power save shutdown, and a power up lag.
And seem to have timings independent from each other. This is going to
cause, unless we scale the encoder down by 4, one edge received occurs
just as you start
13 matches
Mail list logo