Re: [Emc-users] Lost fractions of a step

[John Alexander Stewart]

Thank you for the follow up - it was an interesting discussion to follow
(along with the "how long will a rotary table turn?" one that Marcus
started)

John.
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Cecil Thomas]

As promised, here is the follow up:

1. After extensive testing of the A axis running a 
non-integer-step-producing angle several thousand iterations it 
appears, just as John K said, that the "leftovers' are dealt with 
within the planer in an intelligent way and there are no measurable 
residual errors.

2. The backlash in the rotary axis is less than .5 degrees.

3. The backlash for the Z axis is less than .002 but had been set to 
.005 in the .ini (it had to be me that put it there since no one else 
has touched the machine)

4. The real culprit was the Z axis.  I put a dial indicator in the 
spindle and zeroed it at Z0 with the spindle traveling down. wrote a 
program to lift the indicator clear of the table and cycle the Z axis 
up and down 1000 times at G00 feed rate then run it back to Z0 moving 
down.  It lost about .010 inches.  I cut the max velocity and max 
acceleration by 25 percent and ran it again.  The step loss was not 
detectable on the indicator.

It would appear that the fat tooth was caused by Z axis step losses 
due to trying to move the axis up faster than it was comfortable 
with. (I can relate to that, It's how I feel sometimes)

So... As the Fonz would say... " I was wrwrwr...wr...wrong" 
about the truncation of fractions of steps and I caused the problem 
by not setting up my max velocity and acceleration carefully enough.

I also noticed that the temperature in my shop this time of year is 
around 50 degrees F while it often runs as warm as 80 in the 
summer.  I'm guessing that I did the testing for the original max vel 
and acc in the summer when the lube was thin and now that it has 
thickened up a little there is more resistance to moving the 
axis.  Guess it would be a good time to check X and Y to see if the 
season has affected them.

Thanks again for the help.

Cecil


Thanks to everyone for their input.  John answered the right question.

The bottom line appears to be that Linuxcnc does "round" both up and 
down to the  "nearest" step as opposed to just dropping the "leftover"

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[richshoop]

,I too have a similar problem. Built a rotary table (small, about 4" dia). 
Ordered a worm and wheel pair from Boston Gear, thought I ordered a 72 tooth 
worm wheel, which moves 5 degrees per one rev of the worm, divided by 400 
steps, resolves to 0.0125 degrees per pulse Can't accurately read the 
catalog any more. Actually ordered and got an 80 tooth worm wheel 4.5 
degrees per one rev of the worm, divided by 400 steps, resolves to 0.01125 per 
pulse. Looking into a gear pair from HPC gears to mechanically correct the 
problem. 

- Original Message -

From: emc-users-requ...@lists.sourceforge.net 
To: emc-users@lists.sourceforge.net 
Sent: Sunday, January 3, 2016 2:04:39 AM 
Subject: Emc-users Digest, Vol 117, Issue 17 

Send Emc-users mailing list submissions to 
emc-users@lists.sourceforge.net 

To subscribe or unsubscribe via the World Wide Web, visit 
https://lists.sourceforge.net/lists/listinfo/emc-users 
or, via email, send a message with subject or body 'help' to 
emc-users-requ...@lists.sourceforge.net 

You can reach the person managing the list at 
emc-users-ow...@lists.sourceforge.net 

When replying, please edit your Subject line so it is more specific 
than "Re: Contents of Emc-users digest..." 


Today's Topics: 

1. Re: Lost fractions of a step (Valerio Bellizzomi) 
2. Re: Lost fractions of a step (Dave Caroline) 
3. Re: Lost fractions of a step (Dave Caroline) 
4. Re: Lost fractions of a step (Dave Caroline) 
5. Re: Lost fractions of a step (Tobias Gogolin) 
6. Re: Lost fractions of a step (Dave Caroline) 
7. Lost fractions of a step (Roland Jollivet) 


-- 

Message: 1 
Date: Sun, 03 Jan 2016 07:51:05 +0100 
From: Valerio Bellizzomi <vale...@selnet.org> 
Subject: Re: [Emc-users] Lost fractions of a step 
To: "Enhanced Machine Controller (EMC)" 
<emc-users@lists.sourceforge.net> 
Message-ID: <1451803865.3209.36.ca...@noc1.sel> 
Content-Type: text/plain; charset="UTF-8" 

Good year to all, 
I have a board that can do microstepping but I would not use 
microstepping because the manual says that while it rises the precision 
it also reduces the torque. 


On Sun, 2016-01-03 at 01:02 -0500, Cecil Thomas wrote: 
> My question is about what happens to the "leftovers" when the 
> precision of the g code commanded position cannot be met by the 
> hardware executing it. 
> Several years ago I wrote a program to "generate" involute gear teeth 
> by making multiple cuts of the same tooth from differing angles with 
> a rack shaped cutter. This eliminates the need for the different 
> cutters when making only one cut per tooth. I have used it many 
> times to cut relatively large gears with a relatively small number of 
> teeth with virtually no noticeable error. 
> 
> A few days ago a friend who repairs watches wanted to know if I could 
> figure out what gear (wheel to you watch guys) size, pitch or module 
> and number of teeth would be required to replace a missing one. (the 
> original was long gone). I had no problem working from the center 
> distance and the matching pinion coming up with the appropriate design. 
> 
> However, when I cut the gear I had the right number of teeth but the 
> last tooth was much too wide. 
> 
> It would appear that I had lost a bunch of steps on the rotary 
> axis. Further investigation reveals what I think is the root cause 
> but I would like someone with more knowledge than me to confirm or 
> disprove my analysis. 
> 
> The gear had 86 teeth (in the power train, not in the timing train) 
> and I made 9 cuts per tooth. That is 774 commands and about all but 
> 86 of them in the same direction. 
> 
> My rotary axis is a 200 step stepper into a 30 to 1 worm drive 
> microstepped by 10 so 1.8 degrees divided by 300 equals .006 degrees 
> per microstep or 166.6667 steps per degree. 
> 
> Unfortunately when the g code calls for a 1 degree move the motion 
> planner can only issue 166 steps since it can't issue .6667 
> steps. That means that the actual movement of the A axis is only 
> 166/166.7 or .996 degree. That is .004 degree lost as far as I 
> can tell. That might be close enough for one or even several 
> commands but after 688 comands in the same direction that constitutes 
> 688 x .004 or 2.7 degrees lost. 
> 
> That is a significant portion of a tooth on a high tooth number 
> wheel. Depending on the actual value of the command the actual lost 
> motion could be anything from nothing to essentially a whole step or 
> .005 degrees. 
> 
> I think that I can lessen the impact of the lost portion of the steps 
> by using the MOD operator to determine how much is left over after 
> dividing the commanded move by .006. Then use IF ELSE, IF the 

Re: [Emc-users] Lost fractions of a step

[John Dammeyer]

Great explanation Peter!
Happy New Year.
John Dammeyer

> -Original Message-
> From: Peter Homann [mailto:gro...@homanndesigns.com]
> Sent: January-03-16 5:36 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Lost fractions of a step
> 
> 
> It depends on the drive that you have.
> 
> Geckodrives morph from 10 microstepping to full stepping by the time the
> motor
> reaches a few revs per second, so no torque is lost. You get the best of
both
> worlds, very smooth slow speed movement and the torque of full stepping.
> 
> Also, a lot of people do not understand the purpose of microstepping. It
is
> not there to increase the resolution, but to provide smooth movement at
> low
> speeds.
> 
> On most machines, if you issue a single microstep, the axis is unlikely to
> move at all as there is insufficient force to overcome the friction in the
> drive system and the stepper detent force.
> 
> When determining the resolution or accuracy of the machine, you should
> use the
> distance moved by a full step, and not the microstep distance. In a pinch
you
> could use the distance travelled by a half step as the accuracy value as
it is
> quite good. Any higher microstep than the half step is not accurate.
> Sure you will have higher resolution, but that is not accuracy, and it is
> accuracy that you are after.
> 
> 
> Cheers,
> 
> Peter
> 
> 
> 
> On 03-Jan-16 5:51 PM, Valerio Bellizzomi wrote:
> > Good year to all,
> > I have a board that can do microstepping but I would not use
> > microstepping because the manual says that while it rises the precision
> > it also reduces the torque.
> >
> >
> > On Sun, 2016-01-03 at 01:02 -0500, Cecil Thomas wrote:
> >> My question is about what happens to the "leftovers" when the
> >> precision of the g code commanded position cannot be met by the
> >> hardware executing it.
> >> Several years ago I wrote a program to "generate" involute gear teeth
> >> by making multiple cuts of the same tooth from differing angles with
> >> a rack shaped cutter. This eliminates the need for the different
> >> cutters when making only one cut per tooth.  I have used it many
> >> times to cut relatively large gears with a relatively small number of
> >> teeth with virtually no noticeable error.
> >>
> >> A few days ago a friend who repairs watches wanted to know if I could
> >> figure out what gear (wheel to you watch guys) size, pitch or module
> >> and number of teeth would be required to replace a missing one. (the
> >> original was long gone).  I had no problem working from the center
> >> distance and the matching pinion coming up with the appropriate design.
> >>
> >> However, when I cut the gear I had the right number of teeth but the
> >> last tooth  was much too wide.
> >>
> >> It would appear that I had lost a bunch of steps on the rotary
> >> axis.  Further investigation reveals what I think is the root cause
> >> but I would like someone with more knowledge than me to confirm or
> >> disprove my analysis.
> >>
> >> The gear had 86 teeth (in the power train, not in the timing train)
> >> and I made 9 cuts per tooth.  That is 774 commands and about all but
> >> 86 of them in the same direction.
> >>
> >> My rotary axis is a 200 step stepper into a 30 to 1 worm drive
> >> microstepped by 10  so 1.8 degrees divided by 300 equals .006 degrees
> >> per microstep or 166.6667 steps per degree.
> >>
> >> Unfortunately when the g code calls for a 1 degree move the motion
> >> planner can only issue 166 steps since it can't issue .6667
> >> steps.  That means that the actual movement of the A axis is only
> >> 166/166.7 or .996 degree. That is .004 degree lost as far as I
> >> can tell.  That might be close enough for one or even several
> >> commands but after 688 comands in the same direction that constitutes
> >> 688 x .004 or 2.7 degrees lost.
> >>
> >> That is a significant portion of a tooth on a high tooth number
> >> wheel.  Depending on the actual value of the command the actual lost
> >> motion could be anything from nothing to essentially a whole step or
> >> .005 degrees.
> >>
> >> I think that I can lessen the impact of the lost portion of the steps
> >> by using the MOD operator to determine how much is left over after
> >> dividing the commanded move by .006.  Then use IF ELSE,  IF the
> >> remainder is Greater Than .5 steps then 

Re: [Emc-users] Lost fractions of a step

[Peter Homann]

It depends on the drive that you have.

Geckodrives morph from 10 microstepping to full stepping by the time the motor 
reaches a few revs per second, so no torque is lost. You get the best of both 
worlds, very smooth slow speed movement and the torque of full stepping.

Also, a lot of people do not understand the purpose of microstepping. It is 
not there to increase the resolution, but to provide smooth movement at low 
speeds.

On most machines, if you issue a single microstep, the axis is unlikely to 
move at all as there is insufficient force to overcome the friction in the 
drive system and the stepper detent force.

When determining the resolution or accuracy of the machine, you should use the 
distance moved by a full step, and not the microstep distance. In a pinch you 
could use the distance travelled by a half step as the accuracy value as it is 
quite good. Any higher microstep than the half step is not accurate.
Sure you will have higher resolution, but that is not accuracy, and it is 
accuracy that you are after.


Cheers,

Peter



On 03-Jan-16 5:51 PM, Valerio Bellizzomi wrote:
> Good year to all,
> I have a board that can do microstepping but I would not use
> microstepping because the manual says that while it rises the precision
> it also reduces the torque.
>
>
> On Sun, 2016-01-03 at 01:02 -0500, Cecil Thomas wrote:
>> My question is about what happens to the "leftovers" when the
>> precision of the g code commanded position cannot be met by the
>> hardware executing it.
>> Several years ago I wrote a program to "generate" involute gear teeth
>> by making multiple cuts of the same tooth from differing angles with
>> a rack shaped cutter. This eliminates the need for the different
>> cutters when making only one cut per tooth.  I have used it many
>> times to cut relatively large gears with a relatively small number of
>> teeth with virtually no noticeable error.
>>
>> A few days ago a friend who repairs watches wanted to know if I could
>> figure out what gear (wheel to you watch guys) size, pitch or module
>> and number of teeth would be required to replace a missing one. (the
>> original was long gone).  I had no problem working from the center
>> distance and the matching pinion coming up with the appropriate design.
>>
>> However, when I cut the gear I had the right number of teeth but the
>> last tooth  was much too wide.
>>
>> It would appear that I had lost a bunch of steps on the rotary
>> axis.  Further investigation reveals what I think is the root cause
>> but I would like someone with more knowledge than me to confirm or
>> disprove my analysis.
>>
>> The gear had 86 teeth (in the power train, not in the timing train)
>> and I made 9 cuts per tooth.  That is 774 commands and about all but
>> 86 of them in the same direction.
>>
>> My rotary axis is a 200 step stepper into a 30 to 1 worm drive
>> microstepped by 10  so 1.8 degrees divided by 300 equals .006 degrees
>> per microstep or 166.6667 steps per degree.
>>
>> Unfortunately when the g code calls for a 1 degree move the motion
>> planner can only issue 166 steps since it can't issue .6667
>> steps.  That means that the actual movement of the A axis is only
>> 166/166.7 or .996 degree. That is .004 degree lost as far as I
>> can tell.  That might be close enough for one or even several
>> commands but after 688 comands in the same direction that constitutes
>> 688 x .004 or 2.7 degrees lost.
>>
>> That is a significant portion of a tooth on a high tooth number
>> wheel.  Depending on the actual value of the command the actual lost
>> motion could be anything from nothing to essentially a whole step or
>> .005 degrees.
>>
>> I think that I can lessen the impact of the lost portion of the steps
>> by using the MOD operator to determine how much is left over after
>> dividing the commanded move by .006.  Then use IF ELSE,  IF the
>> remainder is Greater Than .5 steps then  ADD a full step (command =
>> command PLUS .006 degrees) ELSE issue the commanded number (do nothing).
>>
>> This should statistically reduce the error by rounding up or down and
>> redistribute it randomly among all the cuts although it will not
>> eliminate it. The greater the number of cuts the better the
>> approximation will be.
>>
>> Sorry for the long post but I couldn't condense it much and get the
>> idea across.  Can anyone confirm or disprove my observation or come
>> up with a better solution?  Obviously I could add another reduction
>> stage to my rotary axis but I would like to avoid that if possible.
>>
>> Cecil
>>
>>
>> --
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
>
> --
> ___
> Emc-users mailing list
> 

Re: [Emc-users] Lost fractions of a step

[Cecil Thomas]

Thanks to everyone for their input.  John answered the right question.

The bottom line appears to be that Linuxcnc does "round" both up and 
down to the  "nearest" step as opposed to just dropping the "leftover"


So it already does what I was proposing to do with the MOD operator.
Apparently the actual accumulated error just turned out to be 
coincidentally very close to the amount that would be due to the 
dropping of the fractional part.

So... I will continue to investigate the problem.  By the way, I 
never write code that does not make a setup move before each critical 
move to make sure backlash is cleared without resorting to the 
backlash function in the .ini file.  I have run extensive tests on 
the rotary axis and I am confident that the reduction ratio is 30:1 
dead on so it looks as though I must be actually losing steps 
somewhere between linuxcnc and the axis.

It now occurs to me that the gremlin might actually be in the Z axis 
because steps lost in the Z axis would mimic A axis lost steps due to 
the way my program cuts the teeth.  The Z axis lost steps would 
probably mostly occur on +Z direction since that is the direction 
that requires the stepper to lift the head against gravity as well as 
friction and inertia. I'll try running some tests on Z for lost steps 
and also try slowing things down in Z Maybe a counterweight or 
spring to help the stepper  to lift the head.

I will keep you informed.
Thanks again,

Cecil

At 02:07 PM 1/3/2016, John wrote:

>On Sun, Jan 3, 2016, at 01:02 AM, Cecil Thomas wrote:
> > My question is about what happens to the "leftovers" when the
> > precision of the g code commanded position cannot be met by the
> > hardware executing it.
>
>LinuxCNC does not work in steps.  It uses floating point values
>for all internal calculations.  It also uses absolute coordinates, not
>relative ones.
>
>And so it goes all the way around.  No two teeth are 32.72727
>degrees apart, because the physical hardware can't do that.
>But EVERY tooth is within 0.5 degrees of the proper position,
>because LinuxCNC calculates the proper position BEFORE
>rounding it to the nearest step.
>
>Hope this helps clear it up,
>
>John Kasunich
>
>   John Kasunich
>   jmkasun...@fastmail.fm
>
>--
>___
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[andy pugh]

On 3 January 2016 at 21:35,   wrote:
> ,I too have a similar problem. Built a rotary table (small, about 4" dia). 
> Ordered a worm and wheel pair from Boston Gear, thought I ordered a 72 tooth 
> worm wheel, which moves 5 degrees per one rev of the worm, divided by 400 
> steps, resolves to 0.0125 degrees per pulse Can't accurately read the 
> catalog any more. Actually ordered and got an 80 tooth worm wheel 4.5 
> degrees per one rev of the worm, divided by 400 steps, resolves to 0.01125 
> per pulse. Looking into a gear pair from HPC gears to mechanically correct 
> the problem.


It is trivial to solve that problem in software. Adding gears will
just add backlash.
Set the step scale to suit the actual gears and it will all work just fine.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Gregg Eshelman]

On 1/3/2016 8:00 AM, Cecil Thomas wrote:

> As I have designed my program there are many more moves in one
> direction than in the other so I assume that the "shortness"
> accumulates over a large number of moves.  My calculations for the
> accumulation of error in my system seem to match the measured
> results.  I can change my program to  try to balance the forward and
> back moves or I can add a stage of reduction to the A axis to reduce
> the magnitude of the "leftovers" or both but before I proceed I would
> like to be sure that the trajectory planner does as I assumed "Only
> round down".

For a test, can you change it to make one pass, rotate the gear 1/4 turn 
(or some other fraction of a turn) and make a pass, then rotate back to 
the start plus one tooth. Make that pass then rotate 1/2 turn the other 
way plus one tooth.

Alternate back and forth like that until you've made the same number of 
cutting passes as you would going around one direction and check the 
accuracy of the gear.

If it works it works and you've found a way to even out the cumulative 
error.

If it doesn't work or it works but you end up with teeth that are too 
narrow or too uneven, then you still have a problem to track down.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Dave Caroline]

I forgot to mention, I had no accumulated step loss in my tests, I
started each test with encoders at 0 and they completed with 48000 and
2, not even a +-1 digit error which surprised me.

Dave Caroline

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Dave Caroline]

In my experience of watch and clock gear cutting, heating is almost
non existent as an error source, for steel one cuts under a lubricant
which cools and brass is cut dry with a sharp cutter and often the
clamping washers if used will keep it cool. Only one "brass" wheel
gave me a problem and that was in naval brass for a tower clock, it is
closer to a bronze.

Dave Caroline

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Lost fractions of a step

[Roland Jollivet]

Just chipping in...

So on your rotary axis, you have 60 000 steps per revolution. If you set up
a dial gauge and do a simple G1 with 600 000 steps, or 10 rev's, is there
much residual error?

Otherwise, if the accuracy is good enough for one rev, then, in fake code;
- home rotary
- cut one tooth with +3 deg, - 3deg  (or whatever one tooth requires)
- home rotary axis
- move to 6 degrees
- cut one tooth with +3 deg, - 3deg
- start again, for next tooth

So now each tooth should be cut within the maximum error of a single
rotation.

Regards
Roland


On 3 January 2016 at 08:02, Cecil Thomas  wrote:

> My question is about what happens to the "leftovers" when the
> precision of the g code commanded position cannot be met by the
> hardware executing it.
> Several years ago I wrote a program to "generate" involute gear teeth
> by making multiple cuts of the same tooth from differing angles with
> a rack shaped cutter. This eliminates the need for the different
> cutters when making only one cut per tooth.  I have used it many
> times to cut relatively large gears with a relatively small number of
> teeth with virtually no noticeable error.
>
> A few days ago a friend who repairs watches wanted to know if I could
> figure out what gear (wheel to you watch guys) size, pitch or module
> and number of teeth would be required to replace a missing one. (the
> original was long gone).  I had no problem working from the center
> distance and the matching pinion coming up with the appropriate design.
>
> However, when I cut the gear I had the right number of teeth but the
> last tooth  was much too wide.
>
> It would appear that I had lost a bunch of steps on the rotary
> axis.  Further investigation reveals what I think is the root cause
> but I would like someone with more knowledge than me to confirm or
> disprove my analysis.
>
> The gear had 86 teeth (in the power train, not in the timing train)
> and I made 9 cuts per tooth.  That is 774 commands and about all but
> 86 of them in the same direction.
>
> My rotary axis is a 200 step stepper into a 30 to 1 worm drive
> microstepped by 10  so 1.8 degrees divided by 300 equals .006 degrees
> per microstep or 166.6667 steps per degree.
>
> Unfortunately when the g code calls for a 1 degree move the motion
> planner can only issue 166 steps since it can't issue .6667
> steps.  That means that the actual movement of the A axis is only
> 166/166.7 or .996 degree. That is .004 degree lost as far as I
> can tell.  That might be close enough for one or even several
> commands but after 688 comands in the same direction that constitutes
> 688 x .004 or 2.7 degrees lost.
>
> That is a significant portion of a tooth on a high tooth number
> wheel.  Depending on the actual value of the command the actual lost
> motion could be anything from nothing to essentially a whole step or
> .005 degrees.
>
> I think that I can lessen the impact of the lost portion of the steps
> by using the MOD operator to determine how much is left over after
> dividing the commanded move by .006.  Then use IF ELSE,  IF the
> remainder is Greater Than .5 steps then  ADD a full step (command =
> command PLUS .006 degrees) ELSE issue the commanded number (do nothing).
>
> This should statistically reduce the error by rounding up or down and
> redistribute it randomly among all the cuts although it will not
> eliminate it. The greater the number of cuts the better the
> approximation will be.
>
> Sorry for the long post but I couldn't condense it much and get the
> idea across.  Can anyone confirm or disprove my observation or come
> up with a better solution?  Obviously I could add another reduction
> stage to my rotary axis but I would like to avoid that if possible.
>
> Cecil
>
>
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Dave Caroline]

And another thing, almost all rotaries have backlash, do make sure
this is removed in gcode before you start cutting this will result in
a single tooth error.

Dave Caroline

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Tobias Gogolin]

I suspect that if you were indeed to cut each tooth completely and
sequentially you could get the spiral wave of material heat extending that
would cause even stranger errors!  In the effort to cut a little of each I
would use the Fibonacci number applied to 360degrees - as I remember aprox.
137 deg in the 'stepover' to find the next tooth do work a little upon...
On 3 Jan 2016 07:25, "Cecil Thomas"  wrote:

> My question is about what happens to the "leftovers" when the
> precision of the g code commanded position cannot be met by the
> hardware executing it.
> Several years ago I wrote a program to "generate" involute gear teeth
> by making multiple cuts of the same tooth from differing angles with
> a rack shaped cutter. This eliminates the need for the different
> cutters when making only one cut per tooth.  I have used it many
> times to cut relatively large gears with a relatively small number of
> teeth with virtually no noticeable error.
>
> A few days ago a friend who repairs watches wanted to know if I could
> figure out what gear (wheel to you watch guys) size, pitch or module
> and number of teeth would be required to replace a missing one. (the
> original was long gone).  I had no problem working from the center
> distance and the matching pinion coming up with the appropriate design.
>
> However, when I cut the gear I had the right number of teeth but the
> last tooth  was much too wide.
>
> It would appear that I had lost a bunch of steps on the rotary
> axis.  Further investigation reveals what I think is the root cause
> but I would like someone with more knowledge than me to confirm or
> disprove my analysis.
>
> The gear had 86 teeth (in the power train, not in the timing train)
> and I made 9 cuts per tooth.  That is 774 commands and about all but
> 86 of them in the same direction.
>
> My rotary axis is a 200 step stepper into a 30 to 1 worm drive
> microstepped by 10  so 1.8 degrees divided by 300 equals .006 degrees
> per microstep or 166.6667 steps per degree.
>
> Unfortunately when the g code calls for a 1 degree move the motion
> planner can only issue 166 steps since it can't issue .6667
> steps.  That means that the actual movement of the A axis is only
> 166/166.7 or .996 degree. That is .004 degree lost as far as I
> can tell.  That might be close enough for one or even several
> commands but after 688 comands in the same direction that constitutes
> 688 x .004 or 2.7 degrees lost.
>
> That is a significant portion of a tooth on a high tooth number
> wheel.  Depending on the actual value of the command the actual lost
> motion could be anything from nothing to essentially a whole step or
> .005 degrees.
>
> I think that I can lessen the impact of the lost portion of the steps
> by using the MOD operator to determine how much is left over after
> dividing the commanded move by .006.  Then use IF ELSE,  IF the
> remainder is Greater Than .5 steps then  ADD a full step (command =
> command PLUS .006 degrees) ELSE issue the commanded number (do nothing).
>
> This should statistically reduce the error by rounding up or down and
> redistribute it randomly among all the cuts although it will not
> eliminate it. The greater the number of cuts the better the
> approximation will be.
>
> Sorry for the long post but I couldn't condense it much and get the
> idea across.  Can anyone confirm or disprove my observation or come
> up with a better solution?  Obviously I could add another reduction
> stage to my rotary axis but I would like to avoid that if possible.
>
> Cecil
>
>
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Lost fractions of a step

[Cecil Thomas]

I guess I wasn't as clear as I had hoped about my question.
To be more specific:
When the commanded value for a move is converted into steps (or 
microsteps) and that number of steps contains a fractionWhat 
happens to the fractional part of a step

I am not speaking of dropped steps as would be the case in a stepper 
whose movement is inhibited by not being able to complete a step due 
to load, velocity, acceleration, setup or duration.
I am only questioning whether LinuxCNC drops the non integer portion 
of a step when converting from commanded position change to steps.

I have assumed that the system can only issue steps as an integer and 
that the fraction is dropped.  If this is the case then the system 
can ONLY "round down" so all commanded moves that don't convert to 
integers wind up being short of the desired move.  Never "long".  The 
only way the error can "even out" is by virtue of having the effect 
balanced by equally "short" moves in the opposite direction.

As I have designed my program there are many more moves in one 
direction than in the other so I assume that the "shortness" 
accumulates over a large number of moves.  My calculations for the 
accumulation of error in my system seem to match the measured 
results.  I can change my program to  try to balance the forward and 
back moves or I can add a stage of reduction to the A axis to reduce 
the magnitude of the "leftovers" or both but before I proceed I would 
like to be sure that the trajectory planner does as I assumed "Only 
round down".


Cecil 
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Dave Caroline]

The internal numbers in gcode are floats there is no rounding down
unless you put small constants in your gcode, I calculate the tooth
angle in gcode so internally it is as accurate as needed.

eg do not calculate yourself use a line such as
#=[360/#]


I never see your problem and have been using linuxcnc since 2.2.
I would see a problem if I did not nod the a axis to remove the backlash.


Dave Caroline

On 03/01/2016, Cecil Thomas  wrote:
> I guess I wasn't as clear as I had hoped about my question.
> To be more specific:
> When the commanded value for a move is converted into steps (or
> microsteps) and that number of steps contains a fractionWhat
> happens to the fractional part of a step
>
> I am not speaking of dropped steps as would be the case in a stepper
> whose movement is inhibited by not being able to complete a step due
> to load, velocity, acceleration, setup or duration.
> I am only questioning whether LinuxCNC drops the non integer portion
> of a step when converting from commanded position change to steps.
>
> I have assumed that the system can only issue steps as an integer and
> that the fraction is dropped.  If this is the case then the system
> can ONLY "round down" so all commanded moves that don't convert to
> integers wind up being short of the desired move.  Never "long".  The
> only way the error can "even out" is by virtue of having the effect
> balanced by equally "short" moves in the opposite direction.
>
> As I have designed my program there are many more moves in one
> direction than in the other so I assume that the "shortness"
> accumulates over a large number of moves.  My calculations for the
> accumulation of error in my system seem to match the measured
> results.  I can change my program to  try to balance the forward and
> back moves or I can add a stage of reduction to the A axis to reduce
> the magnitude of the "leftovers" or both but before I proceed I would
> like to be sure that the trajectory planner does as I assumed "Only
> round down".
>
>
> Cecil
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Gene Heskett]

On Sunday 03 January 2016 10:00:50 Cecil Thomas wrote:

> I guess I wasn't as clear as I had hoped about my question.
> To be more specific:
> When the commanded value for a move is converted into steps (or
> microsteps) and that number of steps contains a fractionWhat
> happens to the fractional part of a step
>
> I am not speaking of dropped steps as would be the case in a stepper
> whose movement is inhibited by not being able to complete a step due
> to load, velocity, acceleration, setup or duration.
> I am only questioning whether LinuxCNC drops the non integer portion
> of a step when converting from commanded position change to steps.
>
> I have assumed that the system can only issue steps as an integer and
> that the fraction is dropped.  If this is the case then the system
> can ONLY "round down" so all commanded moves that don't convert to
> integers wind up being short of the desired move.  Never "long".  The
> only way the error can "even out" is by virtue of having the effect
> balanced by equally "short" moves in the opposite direction.
>
> As I have designed my program there are many more moves in one
> direction than in the other so I assume that the "shortness"
> accumulates over a large number of moves.  My calculations for the
> accumulation of error in my system seem to match the measured
> results.  I can change my program to  try to balance the forward and
> back moves or I can add a stage of reduction to the A axis to reduce
> the magnitude of the "leftovers" or both but before I proceed I would
> like to be sure that the trajectory planner does as I assumed "Only
> round down".
>
>
> Cecil

I tend to write my code in loops, and I have never been presented with 
such an error that wasn't traceable back to PEBKAC. The biggest problem 
I have with my cheap 4" motorized table is backlash, and I assume some 
cyclic error because the bullgear has at least a thou of eccentricity in 
it.  I wrote, 2+ years ago, a program to sharpen a table saw blade by 
polishing the face of the tooth, writing it so that the table revolved 
at least 50 times, but each revolution was calculated to take 
about .0001" off the face of the tooth. I wanted a touch that would not 
cause any great flexure in the diamond coated wheel in the dremel's 
chuck because it was facing it at as close to zero degrees as I could 
mount the dremel.  It took most of 2 days to run.  That blade was of a 
tooth style no longer marketed by anybody, a CMT with an ATBF tooth 
sequence, a high angle tooth to the left, one just like it to the right, 
and a flat topped tooth that ran about a thou lower than the high angle 
tooth's tips. It gave the cleanest cuts in hardwood I've ever seen.  
Bottom of the kerf is dead flat.  And it was even better after that 
resharpen. I have 2 of those blades, and they will not be thrown away 
until there is no carbide left to sharpen.  But I've not yet EDM'd the 
bolt holes to bolt it to the rotary table for the other blade yet.  The 
one I sharpened is still on the saw, and has cut quite a few feet of the 
1/8" thick side sheet alu of a wrecked UPS stepvan that I use to make 
boxes for my stuff.

And it just cut out all the mahogany to make 3 more of those blanket 
chests on the Dec 2014 Fine WoodWorking cover.  Still reasonably sharp, 
no burns if I keep the wood moving.

So, whatever linuxCNC's code does with the leftover fractional steps, I 
haven't a clue, other than it is totally not a problem here.  I suspect 
it does save it, and add it (or subtract it as the case might call for) 
to its calculations for the next move.  That would average it out to 
less than a .0001" dial indicator can detect.  OTOH, my tables drive is 
90/1, or 4 degrees per full rev of the motor and I am microstepping /8.

Given that ALL of the BoB's we can get from fleabay are needlessly 
opto-isolated (because most of the common drivers we use are already 
isolated), and that the opto's are call a surveyor & set stakes slow in 
comparison to all the other edge delays in a typical system, the first 
thing I would do is add at least .5 microseconds to the step timeing, 
and at least 1 more microsecond the direction setup and hold timings 
just to see if the error goes away.

FWIW, I have noted that there CAN be a difference in speeds attained 
depending on the direction so I scoped the output and found that when 
moving in one direction, the direction was being changed, then reverted 
after the step had been issued. I do not recall if that was a software 
step drive, or the 5i25's output but it was far enough back up the 
calendar count that it had to be software stepping.  I certainly do NOT 
see that on my lathes cnc4pc C1G BoB's leds which are visible in normal 
operation, and theres a 5i25 doing the work in that install.

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 

Re: [Emc-users] Lost fractions of a step

[andy pugh]

On 3 January 2016 at 06:02, Cecil Thomas  wrote:
> My question is about what happens to the "leftovers" when the
> precision of the g code commanded position cannot be met by the
> hardware executing it.

It should all even out over multiple moves.

The commands to the step generator are absolute positions, so the
input to the stepgen would be 1 degree, 2 degree, 3, degree etc, and
you would see step deltas of
166. 167, 166 and so on.

It is also unlikely to be a problem with the accuracy of the worm,
that would be a cyclical not cumulative error.

If you are absolutely sure that you you have the scaling correct then
it might be that you are losing a microstep on reversals. perhaps take
a look at your direction setup timing.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step - Clock Wheels and Pinions

[Gene Heskett]

On Sunday 03 January 2016 12:37:55 Kirk Wallace wrote:

> On 01/02/2016 10:02 PM, Cecil Thomas wrote:
> ... snip
>
> > Several years ago I wrote a program to "generate" involute gear
> > teeth by making multiple cuts of the same tooth from differing
> > angles with a rack shaped cutter. This eliminates the need for the
> > different cutters when making only one cut per tooth.  I have used
> > it many times to cut relatively large gears with a relatively small
> > number of teeth with virtually no noticeable error.
> >
> > A few days ago a friend who repairs watches wanted to know if I
> > could figure out what gear (wheel to you watch guys) size, pitch or
> > module and number of teeth would be required to replace a missing
> > one. (the original was long gone).  I had no problem working from
> > the center distance and the matching pinion coming up with the
> > appropriate design.
>
> ... snip
>
> I have been looking at clock gearing off and on for a while. So far, I
> have found that clock tooth forms are cycloidal, but not really. It
> seems there is a British standard which is based on the ideal
> cycloidal form but uses a circular arc for the curved part of a tooth,
> rather than a cycloid, and clearance is added according to practical
> experience. I haven't been able to find the contents of the standard,
> but I'm still looking. My plan was to use a very small diameter
> (.015") end mill as a universal gear cutting tool for thin wheels from
> sheet brass. The wheel can be drawn in CAD, converted to g-code then
> cut in XY without using a rotary axis. I would appreciate any links or
> information that could get me closer to actually cutting wheels and
> pinions. Although, pinions are a different kettle of fish.
>
Yes, and recipes are scarce.

> I'm also working on a New Haven clock that seems to use custom screw
> threads (#3-40?) that don't appear in Machinery's Handbook or anywhere
> else.

Since all of our thread cutting canned software is infinitely adjustable, 
I would think some carefull measurements would lead to a G76 
configuration that could duplicate at least the screw.  But because the 
size isn't boring bar country, the threading tap may have to be made 
with G76 and some pretty precise flute cutting.  Probably involving some 
A2 rod that is subsequently hardened, something I don't have the heat to 
do here.

Yep, its starting with hemp or cotton seed to grow a rope, but...

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step - Clock Wheels and Pinions

[Dave Caroline]

The book which has a selection of standards is Gears for small
mechanisms by W.O. Davis, it was reprinted by TEE publishing ISBN
1857610156
Note the correct form has a rectangular root which stops the end mill kludge.
We just used the Thornton cutters to get it right.

The cycloidal form has a number of "standards"  swiss,black forest and
the british one based on the swiss.

http://www.clock-works.clara.net/cata/wnpc3.html

Dave Caroline

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[John Kasunich]

On Sun, Jan 3, 2016, at 01:02 AM, Cecil Thomas wrote:
> My question is about what happens to the "leftovers" when the 
> precision of the g code commanded position cannot be met by the 
> hardware executing it.

LinuxCNC does not work in steps.  It uses floating point values
for all internal calculations.  It also uses absolute coordinates, not 
relative ones.

Here is an example - I'm going to exaggerate things to make it
simple to follow, nobody would actually have a step resolution
this low:

Assume you have a 360 step per revolution motor with no gear
reduction.  So the machine can only go to integer degrees.

You want to cut an 11 tooth gear.  The tooth spacing is 32.7272727
degrees.

You cut the first tooth at 0.0 degrees.  Then you tell LinucCNC
to index by 32.727272727 degrees.  Internally, it calculates that it
wants to be at 0.0 + 32.727272727 degrees = 32.7272727.
As far as the motion controller is concerned, that is where the 
machine is going.  Step generation happens at a lower level in the
code.  At the step generator level, the closest possible location to
32.7272727 is 33.000, so it sends 33 steps, and the physical
machine goes to 33.000 to cut the second tooth.

Now you tell LinuxCNC to index by another 32.7272727 degrees
for the third tooth.  The motion controller believes that you are
already at 32.7272727, so it calculates the new position as 
32.7272727 + 32.7272727 = 65.4545454 degrees, and sends
that to the step generator.  The step generator knows that you
are really at 33, and the closest thing to 65.4545454 is 65, so 
it sends 65 - 33 = 32 steps.

Fourth tooth - LinuxCNC believes you are at 65.4545454 degrees
and adds 32.7272727 to get 98.1818181.  That goes to the step
generator.  Nearest possible step is 98, you are currently at 65,
so it sends 98-65 = 33 steps.

And so it goes all the way around.  No two teeth are 32.72727 
degrees apart, because the physical hardware can't do that.
But EVERY tooth is within 0.5 degrees of the proper position,
because LinuxCNC calculates the proper position BEFORE
rounding it to the nearest step.

All of the internal calculations are done in double precision math,
with about 17 digits of accuracy.  Even if you make thousands
of revolutions, the internal accuracy far exceeds the limits of any 
mechanical system.

Hope this helps clear it up,

John Kasunich

  John Kasunich
  jmkasun...@fastmail.fm

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step - Clock Wheels and Pinions

[andy pugh]

On 3 January 2016 at 17:37, Kirk Wallace  wrote:

> I'm also working on a New Haven clock that seems to use custom screw
> threads (#3-40?) that don't appear in Machinery's Handbook or anywhere else.

I thought it might be a watch pendant thread, or Progress, but I can't
find anything that coarse at that diameter:
http://www.bodgesoc.org/thread_dia_pitch.html


-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step - Clock Wheels and Pinions

[Kirk Wallace]

On 01/02/2016 10:02 PM, Cecil Thomas wrote:
... snip

> Several years ago I wrote a program to "generate" involute gear teeth
> by making multiple cuts of the same tooth from differing angles with
> a rack shaped cutter. This eliminates the need for the different
> cutters when making only one cut per tooth.  I have used it many
> times to cut relatively large gears with a relatively small number of
> teeth with virtually no noticeable error.
>
> A few days ago a friend who repairs watches wanted to know if I could
> figure out what gear (wheel to you watch guys) size, pitch or module
> and number of teeth would be required to replace a missing one. (the
> original was long gone).  I had no problem working from the center
> distance and the matching pinion coming up with the appropriate design.

... snip

I have been looking at clock gearing off and on for a while. So far, I 
have found that clock tooth forms are cycloidal, but not really. It 
seems there is a British standard which is based on the ideal cycloidal 
form but uses a circular arc for the curved part of a tooth, rather than 
a cycloid, and clearance is added according to practical experience. I 
haven't been able to find the contents of the standard, but I'm still 
looking. My plan was to use a very small diameter (.015") end mill as a 
universal gear cutting tool for thin wheels from sheet brass. The wheel 
can be drawn in CAD, converted to g-code then cut in XY without using a 
rotary axis. I would appreciate any links or information that could get 
me closer to actually cutting wheels and pinions. Although, pinions are 
a different kettle of fish.

I'm also working on a New Haven clock that seems to use custom screw 
threads (#3-40?) that don't appear in Machinery's Handbook or anywhere else.


-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Lost fractions of a step

[Cecil Thomas]

My question is about what happens to the "leftovers" when the 
precision of the g code commanded position cannot be met by the 
hardware executing it.
Several years ago I wrote a program to "generate" involute gear teeth 
by making multiple cuts of the same tooth from differing angles with 
a rack shaped cutter. This eliminates the need for the different 
cutters when making only one cut per tooth.  I have used it many 
times to cut relatively large gears with a relatively small number of 
teeth with virtually no noticeable error.

A few days ago a friend who repairs watches wanted to know if I could 
figure out what gear (wheel to you watch guys) size, pitch or module 
and number of teeth would be required to replace a missing one. (the 
original was long gone).  I had no problem working from the center 
distance and the matching pinion coming up with the appropriate design.

However, when I cut the gear I had the right number of teeth but the 
last tooth  was much too wide.

It would appear that I had lost a bunch of steps on the rotary 
axis.  Further investigation reveals what I think is the root cause 
but I would like someone with more knowledge than me to confirm or 
disprove my analysis.

The gear had 86 teeth (in the power train, not in the timing train) 
and I made 9 cuts per tooth.  That is 774 commands and about all but 
86 of them in the same direction.

My rotary axis is a 200 step stepper into a 30 to 1 worm drive 
microstepped by 10  so 1.8 degrees divided by 300 equals .006 degrees 
per microstep or 166.6667 steps per degree.

Unfortunately when the g code calls for a 1 degree move the motion 
planner can only issue 166 steps since it can't issue .6667 
steps.  That means that the actual movement of the A axis is only 
166/166.7 or .996 degree. That is .004 degree lost as far as I 
can tell.  That might be close enough for one or even several 
commands but after 688 comands in the same direction that constitutes 
688 x .004 or 2.7 degrees lost.

That is a significant portion of a tooth on a high tooth number 
wheel.  Depending on the actual value of the command the actual lost 
motion could be anything from nothing to essentially a whole step or 
.005 degrees.

I think that I can lessen the impact of the lost portion of the steps 
by using the MOD operator to determine how much is left over after 
dividing the commanded move by .006.  Then use IF ELSE,  IF the 
remainder is Greater Than .5 steps then  ADD a full step (command = 
command PLUS .006 degrees) ELSE issue the commanded number (do nothing).

This should statistically reduce the error by rounding up or down and 
redistribute it randomly among all the cuts although it will not 
eliminate it. The greater the number of cuts the better the 
approximation will be.

Sorry for the long post but I couldn't condense it much and get the 
idea across.  Can anyone confirm or disprove my observation or come 
up with a better solution?  Obviously I could add another reduction 
stage to my rotary axis but I would like to avoid that if possible.

Cecil


--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Valerio Bellizzomi]

Good year to all,
I have a board that can do microstepping but I would not use
microstepping because the manual says that while it rises the precision
it also reduces the torque.


On Sun, 2016-01-03 at 01:02 -0500, Cecil Thomas wrote:
> My question is about what happens to the "leftovers" when the 
> precision of the g code commanded position cannot be met by the 
> hardware executing it.
> Several years ago I wrote a program to "generate" involute gear teeth 
> by making multiple cuts of the same tooth from differing angles with 
> a rack shaped cutter. This eliminates the need for the different 
> cutters when making only one cut per tooth.  I have used it many 
> times to cut relatively large gears with a relatively small number of 
> teeth with virtually no noticeable error.
> 
> A few days ago a friend who repairs watches wanted to know if I could 
> figure out what gear (wheel to you watch guys) size, pitch or module 
> and number of teeth would be required to replace a missing one. (the 
> original was long gone).  I had no problem working from the center 
> distance and the matching pinion coming up with the appropriate design.
> 
> However, when I cut the gear I had the right number of teeth but the 
> last tooth  was much too wide.
> 
> It would appear that I had lost a bunch of steps on the rotary 
> axis.  Further investigation reveals what I think is the root cause 
> but I would like someone with more knowledge than me to confirm or 
> disprove my analysis.
> 
> The gear had 86 teeth (in the power train, not in the timing train) 
> and I made 9 cuts per tooth.  That is 774 commands and about all but 
> 86 of them in the same direction.
> 
> My rotary axis is a 200 step stepper into a 30 to 1 worm drive 
> microstepped by 10  so 1.8 degrees divided by 300 equals .006 degrees 
> per microstep or 166.6667 steps per degree.
> 
> Unfortunately when the g code calls for a 1 degree move the motion 
> planner can only issue 166 steps since it can't issue .6667 
> steps.  That means that the actual movement of the A axis is only 
> 166/166.7 or .996 degree. That is .004 degree lost as far as I 
> can tell.  That might be close enough for one or even several 
> commands but after 688 comands in the same direction that constitutes 
> 688 x .004 or 2.7 degrees lost.
> 
> That is a significant portion of a tooth on a high tooth number 
> wheel.  Depending on the actual value of the command the actual lost 
> motion could be anything from nothing to essentially a whole step or 
> .005 degrees.
> 
> I think that I can lessen the impact of the lost portion of the steps 
> by using the MOD operator to determine how much is left over after 
> dividing the commanded move by .006.  Then use IF ELSE,  IF the 
> remainder is Greater Than .5 steps then  ADD a full step (command = 
> command PLUS .006 degrees) ELSE issue the commanded number (do nothing).
> 
> This should statistically reduce the error by rounding up or down and 
> redistribute it randomly among all the cuts although it will not 
> eliminate it. The greater the number of cuts the better the 
> approximation will be.
> 
> Sorry for the long post but I couldn't condense it much and get the 
> idea across.  Can anyone confirm or disprove my observation or come 
> up with a better solution?  Obviously I could add another reduction 
> stage to my rotary axis but I would like to avoid that if possible.
> 
> Cecil
> 
> 
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users




--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lost fractions of a step

[Dave Caroline]

Microstepping increases resolution but not accuracy, you can easily
lose torque in intermediate positions, any stiffness in the rotary
will just add error.
Perhaps the worst thing I have seen though is rotary error itself, the
lower the reduction ratio usually means a greater error from the
worm/wheel in the rotary. Here you see tooth width error at worm wheel
tooth rate.

I was working at a clockmakers and I had some high count wheels
rejected. This made me measure all the rotaries we had plus a gear set
I had ready for the George Thomas design and a rotary we borrowed,
only one a 1940's Boley was within any kind of spec. On this we made
new dividing disks and cured our quality problem.

As it happens my xmas project is to start to document the errors in
this typical setup as used by many.
http://www.archivist.info/cnc/wormtest/
The page is not yet finished I need to finish the tooth error average
for the 48 tooth gear and the high resolution microstepping error,
which currently shows as regular noise on the upper graphs.

Dave Caroline

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users