[KrausMotor]

I have a project in stainless 303 based on a 3 inch length of 5/8 round stock.
It has some features such as holes and a flat surfaces in the first inch or so, the rest is pretty much a complex contour cut. So after rough waterlines repeated 90 degrees apart all around the piece, and some drilling operations I use rotary machining with a 3/16 ball mill with a 5% step-over basically using the 4th axis in as much of a continuous turn as the individual z axis step allow as the ball mill traces a spiral path around the part. This step takes about an hour and the 4th axis rotates past 0 degrees about 250 times. The finish is great, but there seems to be a very small cumulative rotational error that, by the time the features are under the ball mill , has progressed to almost 30 degrees.

Would the Tormach homing device, cure that error by telling Mach3 where 0 degrees is at every rotation?

Interestingly if I tell the 4th axis to return to 0 at the highest speed it is capable of turning from the end of the run, it thinks 0 is actually the rotational error. To me that means the error is somehow tied in to Mach 3 handling of the G code.

any ideas?

[philbur]

Are your CAM coordinates set for incremental or absolute.

Phil

[KrausMotor]

I believe they are set by G90, so absolute, but I'll double check.
thanks

[Zetopan]

Would the Tormach homing device, cure that error by telling Mach3 where 0 degrees is at every rotation?

I doubt that your rotary axis is actually loosing steps. You should first check
the rotary table coupling to ensure that it is tight and not slipping. If that is
not the problem simply perform an MDI input of "G0 A90000" and wait for the
rotary table to complete the positioning. If it stopped exactly on zero on your
rotary table you will have confirmed that Mach 3 can handle 250*360 degrees
of rotation (note that is really an excessive number of degrees, for reasons I
will explain below). If the above test passes perform an MDI input of "G0 A0"
and again check to see if the table stops at exactly zero after rotating in the
reverse direction. It is entirely possible that Mach cannot correctly handle any
rotations that large in an accurate manner. Note that 250*360 degrees would
result in 180 million microsteps taken in the same direction on a rotary table.

The Tormach rotary table homing sensor is unlikely to help you at all since it
is only used when initially homing the table; it is not used during any actual
machining moves.

If you cannot constrain the machining to reverse every 360 degrees or so,
another alternative that you could try is have the Post wrap 360 to zero and
then position the rotary table back to zero after every wrap. This prevents
the commanded angles from getting very large, although it would obviously
slow down the machining while waiting for the table to "unwind".

250*360 is an excessive number of degrees since any operations performed
run the risk of returning a reduced precision. For example, the tangent of an
angle (say 3.7 degrees) computed in single precision has a certain amount of
error in the result. If I add 250*360 to that 3.7 degrees and then compute
the tangent of that the error could potentially be increased by a factor of
250 because we are effectively asking for a factor of 250 lower error for the
result to be off by the same amount. This is in inherent accuracy problem
with floating point precision, so you should always try to avoid angles larger
than a few times 360 degrees.

Interestingly if I tell the 4th axis to return to 0 at the highest speed it is capable of turning from the end of the run, it thinks 0 is actually the rotational error.

I do not understant what you mean by "it thinks 0 is actually the rotational error".

[Zetopan]

Oops, my example error amount is incorrect. I was first assuming that the
starting angle was 360, but I changed that the 3.7 degrees to reduce the
potential confusion. As a result the actual error amount would be computed
as (250*360+3.7) / 3.7, which is a potential error of 24325 times larger. In
actual practice steps are generally taken so that the error does not get
magnified by this much. This still remains a simplified example of why, in
general, you should do to try to avout dealing with really large angles.

[KrausMotor]

I do not understant what you mean by "it thinks 0 is actually the rotational error".[/QUOTE]


What I meant is exactly what you say I should do to test the rotary table. At the end of it's run ( with it's 30 degrees of error) I typed a G0 A0, which should have brought back the table to 0 ( if by some miracle the error gets unwound so to speak) or an augmented compound rotational error, but the table stopped after the correct amount of degrees (90000) or 360*250 turns with the same 30 degree error. That tells me that it is able maintain accuracy even after 250 rotations, when only the A axis is involved.

I think something is amiss in the Mach3 handling of the g code with multiple axis and very small rotational steps.
cheers

[Zetopan]

I think something is amiss in the Mach3 handling of the g code with multiple axis and very small rotational steps.
cheers

OK, based on what you have said thus far we cannot yet blame Mach3 since
there were machining loads on the rotary table. Have you checked the motor
coupler to ensure that it is tightly clamped? You can get 30 degrees of error
if the coupler slips during a large machining load. If the coupler checks out
perform the two MDI example steps that I suggested without performing any
machining. With the coupler tight and no machining loads on the rotary table
you can test how well Mach3 handles 250 continuous rotations in both of the
directions.

Without doing both of the above we cannot unambiguously determine what
caused the positioning error. I would try 250 rotations on my rotary table to
see if Mach3 handles that, except for two problems. My rotary table is very
different from what Tormach sells (it generates around 2X the rotary force),
and my PCNC 1100 is currently nonoperational since I am quite literally in the
middle of the 3-phase stepper upgrade.

[KrausMotor]

Ok, I've performed the two steps you suggested, 250 rotations to A 90000 and then back to 0. both performed excellently, the rotary table always ending on exactly 0 degrees as well as I can determine by eye. Except for the stepper motor getting quite hot there seems to be no fault with the rotary table as
I have also checked the coupling and it is tight and does not slip.

now what?

[tbaker2500]

It could be worth contacting Tormach and see if they have encountered this.

[Zetopan]

Ok, I've performed the two steps you suggested ... now what?

I had actually typed the "likely problem" if all of the above had worked, over
2.5 hours ago. But when I clicked on the "preview" button just before I was
going to do a “submit”, CNCzone suddenly decided to take me to a strange
page while also discarding my entire text of several paragraphs. This second
attempt will be a bit briefer.

Since the mechanics and Mach3 correctly handle those large rotations, I have
Some more questions - but I will also presume the answers and describe what
is most likely to be happening in your situation.

I particular, the below statement from you caught my attention, and it directly
relates to something that I previously pointed out.

I think something is amiss in the Mach3 handling of the g code with multiple axis and very small rotational steps.

My questions are: How many rotationsl steps are there in your 90,000
degrees of machining, and what sizes are those rotational steps?

I don’t know if Mach3 uses single, double or double extended precision
floating point (all three are available in X86 CPUs – I used to be a CPU
architect years ago). I am assuming that Mach3 uses single precision
floating point for this analysis. It is a reasonable assumption since even
with 0.1 mil resolution that still allows for about 140 feet of linear travel
on any of the X,Y,Z axes. Note that for the below analysis I am totally
ignoring the mechanical accuracy; I'm only considering the floating point
accuracy.

Single precision floating point has a best case resolution of 1 part in 16,777,215.
Hence, when a rotary table is positioned at 1 degree, the smallest numerically
exact step that it can take is about 5.9604648328e-8 degrees. What this means
is that if you could command the rotary table to take the smallest exact size at
1,0 degrees, the floating point result would be exactly correct. What happens
if we command the table to move by 7e-8 degrees? Internally (inside Mach3)
it numerically moves by about 5.9604648328e-8 degrees since that is just the
closest floating point value that it can represent. The movement error is fully
insignificant with a single step.

When a rotary table is positioned at 360 degrees the smallest possible exact
step size now becomes about 2.1457673398e-5 degrees. This is unsurprisingly
360 times larger (coarser) than it was at 1.0 degrees.

When a rotary table is positioned at 90,000 degrees the smallest possible exact
step size now becomes about 0.0053644183495… degrees. This is 90,000 times
larger (coarser) than it was at 1.0 degrees.

What all of this means is that as the rotary table winds up from 0.0 degrees to
90,000 degrees each step that it can precisely take becomes larger and larger.
If you ever command the table to rotate by a large sequence of incremental
steps and any of those steps is not an exact integer multiple of the available
resolution at that degree setting, the actual movement would get rounded
to the nearest numeric value that the floating point can represent. Hence,
each movement is ever so slightly inaccurate and accumulating enough of
these can cause problems.

As a simple example, multiplying 0.00048828125 degrees by 184320000 steps
results in exactly 90,000 degrees. However, starting at 0.0 degrees and then
adding 0.00048828125 degrees together 184,320,000 times literally cannot
sum up to the same exact 90,000 degrees because at some point (near 8192
degrees in this example) the floating point step size cannot be accurately
added since it is not exactly representable.

The above is not really a Mach3 problem, even if it is using single precision.
It is an inherent problem with floating point precision and a misapplication.
For comparison, would anyone expect the same rotational resolution when
the rotary table was positioned at 1.0 degrees and a billion billion degrees?
If so, it would require a floating point representation that had more than 25
decimal digits of precision. In contrast, single precision floating point has
about 7.22 decimal digits of precision, which is more than enough for any
milling machine with 0.1 mil resolution.

Commanding a rotary table to move to 90,000 degrees by using a very large
number of very tiny steps while expecting the same accuracy at when it is
at 1 degree is comparable to having a milling machine with 0.1 mil resolution
with X,Y,Z travels that are about 26 million billion miles long. It simple is not
a reasonable thing to do.

The fix for this is to have the CAM package be aware that the rotary table is
constrained to 360 degrees (or a small multiple of that) so that a reasonable
(winding and unwinding) tool path gets generated.

[KrausMotor]

It could be worth contacting Tormach and see if they have encountered this.

Absolutely! But these things always happen on weekends...

cheers

[KrausMotor]

I had actually typed the "likely problem" if all of the above had worked, over....(or a small multiple of that) so that a reasonable
(winding and unwinding) tool path gets generated.

Yes that seems a likely assumption. I am using G code generated by Sprutcam using rotary machining technology with a spiral step and very small stepover to achieve a good finish. It seemed to be the right thing to do, but not very efficient time wise or result wise. I'll have to reconsider my machining strategy.

There are many ways to skin a cat

cheers

[Moggot]

I had actually typed the "likely problem" if all of the above had worked, over
2.5 hours ago. But when I clicked on the "preview" button just before I was
going to do a “submit”, CNCzone suddenly decided to take me to a strange
page while also discarding my entire text of several paragraphs. This second
attempt will be a bit briefer.

I would, honestly, like to see the full writeup. It's really fascinating stuff.

I do wonder, though, about the Tormach 4th axis. I've used mine less then I would have thought, but in my limited experience, doing really tiny parts, I grew concerned about the amount of backlash that is inevitable in it's design. If I understand things correctly the table drive experiences backlash just like a traditional lead screw/nut, so each change of direction will experience some amount of rotation before it 'engages' again. I've never taken one of these tables apart, so I may be mistaken and backlash in the context of one of these tables may be a more subtle beast. I think I'm right, though.

Tormachs suggested settings will result in either 30 to 60 arc seconds of lost motion (according to the manual), the difference being the looser fit will prolong drive life. That translates into .0008 to .016 degrees of error every direction change. I'm not sure which is the greater issue over a long program; very large angular values causing decreased precision or lost motion from repeated direction reversals. 250 reversals would result in about 4 degrees of error if you use the looser backlash setting. Probably enough to cause problems in a lot of work.

The 'fix' might be to break the program up into some smaller sections, and rehome a couple of times throughout the program. That is assuming that the table is working 'correctly', and not experiencing some other sort of mechanical issue.

[tbaker2500]

Tormachs suggested settings will result in either 30 to 60 arc seconds of lost motion (according to the manual), the difference being the looser fit will prolong drive life. That translates into .0008 to .016 degrees of error every direction change. I'm not sure which is the greater issue over a long program; very large angular values causing decreased precision or lost motion from repeated direction reversals. 250 reversals would result in about 4 degrees of error if you use the looser backlash setting. Probably enough to cause problems in a lot of work.

I don't have one of these, so I can't speak from authority. But it sounds to me like you are describing .0008 to .016 degrees of slop when changing directions. This is not lost steps, and not cumulative. The motor is moving correctly each time, but it has to take out the slop in the gear train.

[Zetopan]

250 reversals would result in about 4 degrees of error if you use the looser backlash setting. Probably enough to cause problems in a lot of work.

Rotary table backlash is NOT accumulative. If you have reversed the rotary
table direction and lost 40 arc seconds of motion, then on the next reversal
you will be back to your original zero arc seconds of lost motion, AFTER you
move at least 40 arc seconds in the new direction.

All even reversals takes you back to zero arc seconds of lost motion and all
odd reversals result in a small amount of lost motion (40 arc seconds in this
example).

[philbur]

Surely the sumation error tends to zerror for a large number of random length steps.

MACH works on floating point double precision.

Phil

PS: If you take absolute steps rather than incremental doesn't the issue goes away in any case.

What all of this means is that as the rotary table winds up from 0.0 degrees to
90,000 degrees each step that it can precisely take becomes larger and larger.
If you ever command the table to rotate by a large sequence of incremental
steps and any of those steps is not an exact integer multiple of the available
resolution at that degree setting, the actual movement would get rounded
to the nearest numeric value that the floating point can represent. Hence,
each movement is ever so slightly inaccurate and accumulating enough of
these can cause problems.

[philbur]

Could the error not also originate in the CAM application. What CAM are you using. After all it's the CAM that does the number crunching, MACH just does what it's told.

Phil

Interestingly if I tell the 4th axis to return to 0 at the highest speed it is capable of turning from the end of the run, it thinks 0 is actually the rotational error. To me that means the error is somehow tied in to Mach 3 handling of the G code.

any ideas?

[KrausMotor]

[QUOTE=philbur;1232642]Could the error not also originate in the CAM application. What CAM are you using. After all it's the CAM that does the number crunching, MACH just does what it's told.

I talked to Tormach and Eric suggested I turn off toolpath viewing in Mach3 to allow the software to completely dedicate itself to the program steps. That didn't work.

The backlash on the rotary table is adjusted correctly, I tripple checked.

I'm using Sprutcam and chose rotary machining with a spiral machining path, a 10 percent tool offset from the y axis zero, which stays pretty much fixed during machining. I use a 3/16 ball mill and the spiral stepover is 5 percent to achieve a nice finish. The piece has been rough waterline milled in four quadrants, so the 3/16 ball mill has only about .010 to cut and offers minimal resistance to the rotary table. I noticed that on the section part where the profile is the same all around it, the rotation is only in one direction, but when the profile contains separate features radially, the table turns back and forth.

I'm starting to think the steps are too small to be resolved accurately.

I eventually solved the problem of machining the part, by redesigning it so that I could cut features at predetermined rotational positions, using the rotary as a fixed work piece fixture, and after having done the rotary machining only to the part where positional error in the A axis is irrelevant.

cheers

[GJeff]

That's a work-around but doesn't identify the real problem. I'd love to know where the issue was and if it's a mechanical limitation, software limitation, or just a misconfiguration. Is there anyone here actually use the rotary table live while machining with good results?

[Spinnetti]

I had my new 4th axis slip when under load. I took the coupler off and reinstalled/locktited..