Rotary position changes by small amounts where a fixed tilt angle is defined (multiaxis parallel)

[Carbonwerkes]

Hey guys

Ive run into an annoyance with my 4^th axis moving a bit in an operation where I want it fixed.

The operation in question will mill a simple pattern into a shallow domed surface. Analogy would be pistol grips or knife scales, where maybe I want a pinstripe or crosshatch pattern on a shallow curved surface. The goal with the rotary is to put the work at 20deg rotated on the X axis, so that Im cutting with the side of a ball mill- and not with the tip.

Im running a simple multiaxis parallel op- where I have the 4^th axis set to 70 for tilt angle and 0 for rotary angle. 5^th axis is locked at 0.

Problem is, the post is outputting what seems to be some noise- where in 10 lines I might see A20, A20.001, A20, A20.002. This matters- since it will trigger backlash comp and I can see negative effect on the finished surface.

What is puzzling to me, aside from the system not observing the 20deg rotation value defined, is that this output is never < 20, and it always reverts to 20 between non-20 values. There is no A20, A20.001, A20.003, A20. It would be A20, A20.001, A20, A20.003 etc spread over whatever- 20 lines or so. Seems to have rotational change at start, midline, and end of each pass.

These things suggest to me this isnt rounding noise- but it is hard to understand why if 20.003 is a valid/required tilt to achieve some other geometrical constraint that I never see A19.997.

Any idea if there is a way in multiaxis parallel to force A20 as the output?

 

Thanks all-

Rob

[cam-eleon]

I've had slight unexpected drifting of rotary axis in the past. No with your exact toolpath. I would resolve it by locking in the angle with my limits. try the axis lock in the toolpath. You have to turn on (check) "limits" in tool axis control in order to set limits. I would try that first. Enter 20 and 20 or what ever the value is. You don't have to have a range. That's what I used to do.

[crazy^millman]

7 hours ago, Carbonwerkes said:

Hey guys

 

Ive run into an annoyance with my 4^th axis moving a bit in an operation where I want it fixed.

 

The operation in question will mill a simple pattern into a shallow domed surface. Analogy would be pistol grips or knife scales, where maybe I want a pinstripe or crosshatch pattern on a shallow curved surface. The goal with the rotary is to put the work at 20deg rotated on the X axis, so that Im cutting with the side of a ball mill- and not with the tip.

 

Im running a simple multiaxis parallel op- where I have the 4^th axis set to 70 for tilt angle and 0 for rotary angle. 5^th axis is locked at 0.

 

Problem is, the post is outputting what seems to be some noise- where in 10 lines I might see A20, A20.001, A20, A20.002. This matters- since it will trigger backlash comp and I can see negative effect on the finished surface.

 

What is puzzling to me, aside from the system not observing the 20deg rotation value defined, is that this output is never < 20, and it always reverts to 20 between non-20 values. There is no A20, A20.001, A20.003, A20. It would be A20, A20.001, A20, A20.003 etc spread over whatever- 20 lines or so. Seems to have rotational change at start, midline, and end of each pass.

 

These things suggest to me this isnt rounding noise- but it is hard to understand why if 20.003 is a valid/required tilt to achieve some other geometrical constraint that I never see A19.997.

 

Any idea if there is a way in multiaxis parallel to force A20 as the output?

 

 

 

Thanks all-

 

Rob

 

Without a sample file sorry not even going to try to guess. Toolpath multi Axis toolpaths take so many things into account without something to see exactly what you are seeing no idea. All toolpath have some error calculations in them and if there are .0001" slivers or edges that the software is seeing then those are telling the system to try to either machine them or avoid them depending on what you are using for avoidance or title limits. Since you see this on a regular bases should be easy to make a sample and share a Z2G with your post since how the post is configured will also have a part in what your seeing.

[Carbonwerkes]

12 hours ago, cam-eleon said:

I've had slight unexpected drifting of rotary axis in the past. No with your exact toolpath. I would resolve it by locking in the angle with my limits. try the axis lock in the toolpath. You have to turn on (check) "limits" in tool axis control in order to set limits. I would try that first. Enter 20 and 20 or what ever the value is. You don't have to have a range. That's what I used to do.

This does work for me. Strangely, even with the axis lock/limit set (i.e. at 70/70) I still see the NC file with the initial A position at A20.001. I may step through the post and see what the NCI is saying vs if the post is doing something unexpected. But yea, thanks for the suggestion- it does seem to work for multiaxis parallel at least.

Have a great weekend everyone- thank you for the help.

Best

Rob

[cam-eleon]

Change the lock value to lock it in at your initial 20.001 deg if that works for you. Or 70.001 or 69.999 what ever....

[Colin Gilchrist]

Is you geometry "Perfect"? Analyze the underlying geometry, and make sure your surface/face itself isn't at 0.000025 or -0.000011 or some small value like that.

What is your Cut Pattern Geometry?

With 5-Axis Paths, we have separate controls for:

1. The "shape" of the cutting motion across your surfaces. This is your "Cut Pattern", and in general should not be the surfaces you're actually "leaving behind". We typically want a Cut Pattern which is as simple as possible. Think "a flat surface" or "simple cylinder", which lays "underneath" the geometry you want to cut.
2. The "orientation" of your tool. This is the Tool Axis Control, and you can certainly use the "angle to axis", or "rotated about axis" controls, but if your Cut Pattern is a simple (geometrically 'perfect') Cylinder, you can then just use "Surface", and your angles will be relative to the "Normal Vector" of each tool position. 
3. The "surfaces you want your tool to be Tangent to". This is the "Collision Control" function. I think it is poorly named, because this is really "what shape do I want to leave behind, as my tool moves across the part geometry". The most common control option here is "Retract Tool > Along Tool Axis". Simple > you just want the tool to remain tangent to a group of surfaces. In this feature > Check Surfaces are really "separate tangent control surfaces". The function the same as Drive Surfaces, except you get a separate "group of surfaces" for each of the 4 different Collision Control strategies.

Try this > 

Make a new Toolpath, using just a simple cylinder, centered on your rotary axis. Ignore the actual surfaces you want to cut for the moment.

• Just do a simple Parallel 5X path, on the cylinder.
• Set the Tool Axis Control to "Surface", but do not add any Tilt to the path.
• Do not add any Collision Control strategies yet. (Disable if necessary.)

Do you get output at "A0.", without the "flutter" in the third place decimal of the rotary? In other words > does the path stay locked to that angle correctly?

If you then go in and add "Tilt" to the path, does the A-Axis stay "locked" at that angle?

We're trying to ascertain if the issue might be Post related (rounding) or if this is "Input Geometry" related.

[huskermcdoogle]

I've chased there error for ages....   Typically though I am moving the rotary and it is the Y axis fluttering back and forth sometimes up to .002mm.  I haven't nailed it down yet, but I have found version to version differences with Mastercam in how it posts out.  I think it has to do with the floating point math and rounding on the backend going from NCI to posted code.  My recommendation would be to create a variant of your post and round your rotary output to two places for now to get some clean code, see if it makes the difference in your finish.  Otherwise, dig into the NCI using excel and run some math's on the vector output to see if the angles resolve correctly in the NCI to see if it is a math error getting from there into the posted code.  If it doesn't exist in the NCI, then it is an issue in the math generating the vector, which depending on the comp method (center or tip) will effect your tangent point position slightly, and is likely a product of poor geometry. 

Just to give an idea of how deep I have dug on this in the past, I have seen a y axis shift issue with simple cylinder pattern surfaces, and no tilt, pointed directly at the center of rotation.

[Carbonwerkes]

Colin- When I get a bit of time, Ill setup a test as you defined. Right now im treading water with a bunch of things and the workaround re: lock at least allows me to see the output I would expect. Im doing some very fine patterning- more or less just pinstripes on subsection of an American football- large radius for the X axis curvature, and smaller radius for the Y relative to the part . The challenge is just that even a tiny error in rotary synch.backlash comp is dead obvious, since the pinstripe is shallow cut with a 3/32 ball; any inconsistency changes the width of the scallop, and since that seems to happen in a few places along the path, consistently for each pass, you see these weird patterns/shift of depth of scallop etc. Its very intolerant of error.

I will have a look at the NCI though; that is quicker for me anyway, and if the output from MC is locked at 20, but the post is altering that- OK. I expect this is MC, because I have seen these biases trend, where the deltas seem higher (i.e. 20.01) near the extents of travel on the X axis vs the center of the part where I see these tiny errors. If this is just a .000x rounding error, I would not expect to see this change. I just dont understand the order of precedence in how MC generates the path. If the 'angle' definition is early in the flow, and there are other components like damping or whatever that apply later,  I could see how this could happen. It seems to me impossible to have damping or other smoothing/filtering have effect if the output can just be clamped at the final phase of the process. But, the table lock thing works- so I assume this happens at or near the end of flow where it will simply clamp a value. Not clear to me how this impacts coordinated motion- if X/Y/Z are filtered and coordinated with A upstream, and then A is changed later... So maybe it is all being handled before the motion coordination logic happens, but 'angle' is upstream of 'lock' to the extent that some other factor can exist between the two...

Best

Rob

[crazy^millman]

For that shape I would drive it with curves and use curve 5 axis using vectors to drive the toolpath. Sometimes the simple process make the best code. Like I proved with the 4 Axis file I provided to CNCZACK earlier this week. 

[Chally72]

Hi Rob, I sent you a message but haven't heard from you. If possible, I'd like to take a look at that toolpath so that we can determine if it's a toolpath-level issue or a rounding issue when the NCI vector is converted to an angle- (Very likely the latter and I'd like the team to look at it).  

[Colin Gilchrist]

On 3/4/2022 at 6:59 PM, Carbonwerkes said:

Colin- When I get a bit of time, Ill setup a test as you defined. Right now im treading water with a bunch of things and the workaround re: lock at least allows me to see the output I would expect. Im doing some very fine patterning- more or less just pinstripes on subsection of an American football- large radius for the X axis curvature, and smaller radius for the Y relative to the part . The challenge is just that even a tiny error in rotary synch.backlash comp is dead obvious, since the pinstripe is shallow cut with a 3/32 ball; any inconsistency changes the width of the scallop, and since that seems to happen in a few places along the path, consistently for each pass, you see these weird patterns/shift of depth of scallop etc. Its very intolerant of error.

I will have a look at the NCI though; that is quicker for me anyway, and if the output from MC is locked at 20, but the post is altering that- OK. I expect this is MC, because I have seen these biases trend, where the deltas seem higher (i.e. 20.01) near the extents of travel on the X axis vs the center of the part where I see these tiny errors. If this is just a .000x rounding error, I would not expect to see this change. I just dont understand the order of precedence in how MC generates the path. If the 'angle' definition is early in the flow, and there are other components like damping or whatever that apply later,  I could see how this could happen. It seems to me impossible to have damping or other smoothing/filtering have effect if the output can just be clamped at the final phase of the process. But, the table lock thing works- so I assume this happens at or near the end of flow where it will simply clamp a value. Not clear to me how this impacts coordinated motion- if X/Y/Z are filtered and coordinated with A upstream, and then A is changed later... So maybe it is all being handled before the motion coordination logic happens, but 'angle' is upstream of 'lock' to the extent that some other factor can exist between the two...

Best

Rob

One thing which is critical to understand > there is no "rotary value" output in the NCI File. All "rotation" is calculated using Linear Algebra and Matrix Math, inside the Post.

So you're not going to "see a rotary value" in the NCI. Only Planar Positioning (Toolplane-Based Toolpaths), and 4-Axis/5-Axis "live" cutting, using Vector output. The "Tool Vectors" get resolved by the Post, using math, to calculate the Angle Value.