Cutter Comp Alarm when Thread Milling

[Anonymous]

I have an Okuma Genos M560V with a P300 control and I am running into an issue when thread milling a 1/2-13 into a test part. When I put even -.0001 on the tool I get 2299 Alarm-B Cutter comp.: no intersection point 300 (300 refers to "when making inside cut").  I can put +.020 comp on the tool with no problems. I sent it to Hartwig to run on one of their M560's to make sure it is not an issue with the cutter comp tolerance parameter. They have the same problem.

I have been working with D3 Technologies to edit a post for my machine and although Fusion seems to do everything I need, the post support doesn't seem to be there. I may have to find a CAM software with better Okuma post support even if I end up paying through the nose. What do you think?

(G56 H1 D1 CALLED AT THE BEGINNING OF THE TOOL)

G01 Z-0.7596 F23.57
G41 X0.0473 Y0.0009 (THIS G41 LINE RUNS FINE)
G03 X0.0461 Y0.0502 Z-0.75 I-0.0253 J0.0241
X-0.0501 Y-0.0508 Z-0.7115 I-0.0481 J-0.0505
X0.0461 Y0.0502 Z-0.6731 I0.0481 J0.0505
X-0.0032 Y0.049 Z-0.6635 I-0.0241 J-0.0253
G01 G40 X-0.002 Y-0.0003
G00 Z0.1
Z-0.679
G01 Z-0.759 F23.57
G41 X0.0507 Y0.0044
G03 X0.0495 Y0.0539 Z-0.75 I-0.0253 J0.0241 (THIS IS THE LINE THAT IT ALARMS OUT ON)
X-0.0536 Y-0.0544 Z-0.7115 I-0.0516 J-0.0541
X0.0495 Y0.0539 Z-0.6731 I0.0516 J0.0541
X0.0001 Y0.0527 Z-0.6641 I-0.0241 J-0.0253
G01 G40 X-0.002 Y-0.0003
G00 Z0.1
Z-0.679
G01 Z-0.759 F23.57
G41 X0.0507 Y0.0044
G03 X0.0495 Y0.0539 Z-0.75 I-0.0253 J0.0241
X-0.0536 Y-0.0544 Z-0.7115 I-0.0516 J-0.0541
X0.0495 Y0.0539 Z-0.6731 I0.0516 J0.0541
X0.0001 Y0.0527 Z-0.6641 I-0.0241 J-0.0253
G01 G40 X-0.002 Y-0.0003
G00 Z1.

NOTE: The photos shows -.005 I have tried -.0001, -.0025, -.0001

[seth.madore]

I'm sorry to hear about your troubles. Can you share the Fusion file that you used to generate this code?

File > Export > Save to local folder. Return to thread and attach the .f3d file in your reply.

Counterpoint to your frustration: A great post processor reseller is going to be leaps and bounds more affordable than any other CAD/CAM system on the market, given the breadth of what Fusion covers. I'm not saying this as an employee, but as a machine shop owner that uses this product on a daily basis.

[Anonymous]

I believe you are right and hope to find a solution. Do you have any post processor resellers that you recommend? What brand of machine tools do you run?

[LibertyMachine]

Any recommendation I have CANNOT be viewed as the opinion and recommendation from Autodesk. I have not had first hand experiences with many of them, so take that with a grain of salt. I will say this; the boys over at CadPro really know their stuff. If there is anyone that can get you the post you are looking for, it's them.

I run a DMG Mori and Kitamura VMC. Both machines are loosely based on the generic Fanuc post, with a fair amount of tweaks that I have implemented over the years.

[Anonymous]

We tried carrying the decimals for XYZ out to 6 places and now I am able to run. Sounds like a rounding error to the people at D3 and I imagine there is a parameter in OSP that will allow us to return to posting at 4 places because 6 is a little nuts. Thoughts?

[seth.madore]

That's what I've been leaning towards as well. My Kitamura had something similar happen, although it didn't alarm out. When it encountered a rounding error, it ignored the line and proceeded to the next one. You can imagine what that did to a thread mill.....

I will admit that this was one issue that I had to punt to people smarter than I...

Let me look into my post and see if I can figure out what code was added to produce exact numbers

[seth.madore]

So here is the logic in my post that gives me exact points in circular work:

/** Adjust final point to lie exactly on circle. */
function CircularData(_plane, _center, _end) {
  // use Output variables, since last point could have been adjusted if previous move was circular
  var start = new Vector(xOutput.getCurrent(), yOutput.getCurrent(), zOutput.getCurrent());
  var saveStart = new Vector(start.x, start.y, start.z);
  var center = new Vector(
    xyzFormat.getResultingValue(_center.x),
    xyzFormat.getResultingValue(_center.y),
    xyzFormat.getResultingValue(_center.z));
  var end = new Vector(_end.x, _end.y, _end.z);
  switch(_plane) {
  case PLANE_XY:
    start.setZ(center.z);
    end.setZ(center.z);
    break;
  case PLANE_ZX:
    start.setY(center.y);
    end.setY(center.y);
    break;
  case PLANE_YZ:
    start.setX(center.x);
    end.setX(center.x);
    break;
  default:
    this.center = new Vector(_center.x, _center.y, _center.z);
    this.start = new Vector(start.x, start.y, start.z);
    this.end = new Vector(_end.x, _end.y, _end.z);
    this.offset = Vector.diff(center, start);
    this.radius = this.offset.length;
    break;
  }
  this.start = new Vector(
    xyzFormat.getResultingValue(start.x),
    xyzFormat.getResultingValue(start.y),
    xyzFormat.getResultingValue(start.z)
  );
  var temp = Vector.diff(center, start);
  this.offset = new Vector(
    xyzFormat.getResultingValue(temp.x),
    xyzFormat.getResultingValue(temp.y),
    xyzFormat.getResultingValue(temp.z)
  );
  this.center = Vector.sum(this.start, this.offset);
  this.radius = this.offset.length;

  temp = Vector.diff(end, center).normalized;
  this.end = new Vector(
    xyzFormat.getResultingValue(this.center.x + temp.x * this.radius),
    xyzFormat.getResultingValue(this.center.y + temp.y * this.radius),
    xyzFormat.getResultingValue(this.center.z + temp.z * this.radius)
  );

  switch(_plane) {
  case PLANE_XY:
    this.start.setZ(saveStart.z);
    this.end.setZ(_end.z);
    this.offset.setZ(0);
    break;
  case PLANE_ZX:
    this.start.setY(saveStart.y);
    this.end.setY(_end.y);
    this.offset.setY(0);
    break;
  case PLANE_YZ:
    this.start.setX(saveStart.x);
    this.end.setX(_end.x);
    this.offset.setX(0);
    break;
  }
}

This logic lies after the onLinear statements and BEFORE the onCircular

[Anonymous]

Thank you Seth, I will report back after testing.

[Anonymous]

D3 used your bit of code and I reposted at 4 places instead of 6. The thread mill ran successfully but I am not sure what part your code is playing as it posts the same numbers at 4 places with and without it. 

There is one other factor that I did not notice yesterday evening. When I tested the post using 6 decimal places the arcs were broken up into 90 degree segments. This was not the case with the post that was alarming out, which used 180 arc segments.

I am used to expressing a full circle with one line of code and not breaking it up into segments. Is it necessary or beneficial to break it up? It certainly seems more complicated when making hand edits, and it creates more lines of code.

It seems plausible that breaking up arcs into 90 degree segments may be contributing to the solution, but this is not my preference. I will follow up when I have done more testing. 

[Anonymous · Accepted solution]

I wanted to provide an update/solution. On Friday I received a post update which runs successfully and doesn't break up the arc. I am not sure what exactly solved the issue, maybe  D3 will weigh in at some point. Based on my interactions with D3 I feel better about Fusion and the post, the gentleman I have been working with is very sharp. 

Here is the same 1/2-13 thread used throughout the testing, one change is helical leads is left unchecked. 

Z1.
Z-0.67
G01 Z-0.75 F23.57
G41 X0.0485 Y0.0087 
G03 X0.0398 Y0.0573 I-0.0286 J0.0199
Z-0.6731 I-0.0398 J-0.0573
X-0.0087 Y0.0485 I-0.0199 J-0.0286
G01 G40 X0. Y0.
G00 Z0.1
Z-0.67
G01 Z-0.75 F23.57
G41 X0.0514 Y0.0126 
G03 X0.0427 Y0.0614 I-0.0287 J0.02
Z-0.6731 I-0.0427 J-0.0614
X-0.006 Y0.0526 I-0.02 J-0.0287
G01 G40 X0. Y0.
G00 Z0.1
Z-0.67
G01 Z-0.75 F23.57
G41 X0.0514 Y0.0126 
G03 X0.0427 Y0.0614 I-0.0287 J0.02
Z-0.6731 I-0.0427 J-0.0614
X-0.006 Y0.0526 I-0.02 J-0.0287
G01 G40 X0. Y0.
G00 Z1.