On Tuesday 04 February 2020 11:08:32 andy pugh wrote:

> On Tue, 4 Feb 2020 at 16:09, Jon Elson <[email protected]> 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 hardware counter was not properly zeroed out
>
> What I mean is that 32-bit overflow is not likely to be a problem
> during a rigid tapping move, assuming that index-zero works properly.
>
> (Though in my Mesa drivers the index actually just sets an offset, and
> rawcounts continue to accumulate).

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

 by ((index*scale)+ signed raw since last reset)? 

That would transfer any overflow concerns even in 32 bit stuff to the 
index count, and you'd only need slow floating-point to show it to a 
human.  All integer internally. Might take some logic to make sure it 
wasn't incing raw at the reset point, but that could be handled in the 
addf order by using the edge selected from instant direction. That way 
you'd always be using the same point regardless of direction, and it 
would also be done while raw was stable.

Theres always more than one way to skin a cat, the most important being 
to assure its dead first and the addf order would assure that.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to