On Wed, 5 Feb 2020 at 14:47, Ed wrote:
> The last here is interesting. Does the accumulating create a problem
> when hobbing?
Incidentally, have you seen my config and rough-and-ready hobbing user
interface?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Hobbing
--
atp
"A motorcycle is a bicycle
On Wed, 5 Feb 2020 at 14:47, Ed wrote:
> The last here is interesting. Does the accumulating create a problem
> when hobbing?
>
> I ask because I am setting up a horizontal mill to do hobbing and have
> wondered if there would be a problem when a cut may take 3 hours with a
> lot of revolutions
On 2/4/20 10:08 AM, andy pugh wrote:
On Tue, 4 Feb 2020 at 16:09, Jon Elson wrote:
On 02/04/2020 05:33 AM, andy pugh wrote:
Rigid tapping and threading reset at the start of the
cycle, so are probably OK.
Ahh, but that led to a bunch of confusion years ago, when
the 32-bit extended software
On Tuesday 04 February 2020 13:57:02 andy pugh wrote:
> On Tue, 4 Feb 2020 at 18:58, Gene Heskett wrote:
> > Wouldn't you be able to reset raw counts on the index edge and count
> > index up or down from zero to get the same results
>
> Rawcounts is useful if the encoder is also being used to
On Tue, 4 Feb 2020 at 18:58, Gene Heskett wrote:
> Wouldn't you be able to reset raw counts on the index edge and count
> index up or down from zero to get the same results
Rawcounts is useful if the encoder is also being used to commutate the
motor.
(And for certain other applications)
--
On Tuesday 04 February 2020 11:08:32 andy pugh wrote:
> On Tue, 4 Feb 2020 at 16:09, Jon Elson wrote:
> > On 02/04/2020 05:33 AM, andy pugh wrote:
> > > Rigid tapping and threading reset at the start of the
> > > cycle, so are probably OK.
> >
> > Ahh, but that led to a bunch of confusion years
On Tuesday 04 February 2020 11:00:58 Jon Elson wrote:
> On 02/04/2020 12:14 AM, Gene Heskett wrote:
> > Neither do I, even the big cinci's x shouldn't, but I've got an
> > encoder on the G0704 that could on a long enough job, the scale in
> > low gear is effectively a bit over 14,000/rev in low
On Tuesday 04 February 2020 06:33:05 andy pugh wrote:
> On Tue, 4 Feb 2020 at 03:56, Jon Elson wrote:
> > I don't know if there's anybody out there with table travel
> > that exceeds a 32-bit integer
> > encoder count.
>
> Maybe not a table, but consider the spindle on a hobbing machine,
>
On Tue, 4 Feb 2020 at 16:09, Jon Elson wrote:
> On 02/04/2020 05:33 AM, andy pugh wrote:
> > Rigid tapping and threading reset at the start of the
> > cycle, so are probably OK.
> Ahh, but that led to a bunch of confusion years ago, when
> the 32-bit extended software bits of
> the 24-bit
On 02/04/2020 05:33 AM, andy pugh wrote:
Rigid tapping and threading reset at the start of the
cycle, so are probably OK.
Ahh, but that led to a bunch of confusion years ago, when
the 32-bit extended software bits of
the 24-bit hardware counter was not properly zeroed out when
the index reset
On 02/04/2020 03:58 AM, andy pugh wrote:
On Tue, 4 Feb 2020 at 04:04, Jon Elson wrote:
I think it is better to use uint32_t and uint64_t and-or
int32_t and int64_t so that you get the exact same integer
length no matter the kernel and libraries.
I don't think that there is any point
On 02/04/2020 12:14 AM, Gene Heskett wrote:
Neither do I, even the big cinci's x shouldn't, but I've got an encoder
on the G0704 that could on a long enough job, the scale in low gear is
effectively a bit over 14,000/rev in low gear.
Question is, would I recognize the blip when it did over
On Tue, 4 Feb 2020 at 03:56, Jon Elson wrote:
> I don't know if there's anybody out there with table travel
> that exceeds a 32-bit integer
> encoder count.
Maybe not a table, but consider the spindle on a hobbing machine,
fitted with an ROD271 18,000 counts per turn encoder
running at 3000 rpm
On Tue, 4 Feb 2020 at 04:04, Jon Elson wrote:
> I think it is better to use uint32_t and uint64_t and-or
> int32_t and int64_t so that you get the exact same integer
> length no matter the kernel and libraries.
I don't think that there is any point sign-extending uint32, so the
type you want to
On Monday 03 February 2020 22:55:04 Jon Elson wrote:
> On 02/03/2020 08:25 PM, Jon Elson wrote:
> > On 02/03/2020 06:46 PM, andy pugh wrote:
> >> Is he using a 64-bit kernel? The size of integers might
> >> have changed.
>
> Yes, the customer reports it IS a 64-bit kernel, and the
> logic there
On Monday 03 February 2020 19:46:30 andy pugh wrote:
> On Fri, 31 Jan 2020 at 17:38, Jon Elson wrote:
> > Hmmm, some interesting things to note. His input scale is
> > 85333.33 counts/inch.
> > 85333 * 50331 looks like it is very close to a 32-bit
> > rollover (4294895223).
> > The PPMC devices
On 02/03/2020 08:25 PM, Alec Ari via Emc-developers wrote:
Would using `long long` instead of `long` be a potential fix then? I'm not a
very good C coder but I've noticed higher precision using `long long` over all
else, never seen `long long` fail for me.
I think it is better to use
On 02/03/2020 08:25 PM, Jon Elson wrote:
On 02/03/2020 06:46 PM, andy pugh wrote:
Is he using a 64-bit kernel? The size of integers might
have changed.
Yes, the customer reports it IS a 64-bit kernel, and the
logic there can't be expected to work
right on a 64-bit long variable. I'll have
On 02/03/2020 06:46 PM, andy pugh wrote:
On Fri, 31 Jan 2020 at 17:38, Jon Elson wrote:
Hmmm, some interesting things to note. His input scale is
85333.33 counts/inch.
85333 * 50331 looks like it is very close to a 32-bit
rollover (4294895223).
The PPMC devices use a 24-bit hardware counter,
Would using `long long` instead of `long` be a potential fix then? I'm not a
very good C coder but I've noticed higher precision using `long long` over all
else, never seen `long long` fail for me.
The commit I referred to is this one, but andypugh probably has a better idea
on this than I do,
On 02/03/2020 02:19 PM, Alec Ari via Emc-developers wrote:
Hi,
I encounter problems like this all the time; you use a version of software,
update the software, and a bug gets introduced between versions when the code
very seemingly related to the problem, HASN'T CHANGED. If the driver code
On Fri, 31 Jan 2020 at 17:38, Jon Elson wrote:
> Hmmm, some interesting things to note. His input scale is
> 85333.33 counts/inch.
> 85333 * 50331 looks like it is very close to a 32-bit
> rollover (4294895223).
> The PPMC devices use a 24-bit hardware counter, and then
> rollover and extension
Hi,
I encounter problems like this all the time; you use a version of software,
update the software, and a bug gets introduced between versions when the code
very seemingly related to the problem, HASN'T CHANGED. If the driver code
hasn't changed, is it the same Linux kernel, distribution,
Hello, all,
I have a customer with a problem when using a late master
release. It shows up on Axis
as 2.9.0-pre0-814-gb39c7ba5e He is using the Pico
Systems PWM controller.
His problem is before homing, when jogging the axis in the
negative direction, when it
reaches zero the displayed
24 matches
Mail list logo
