thread milling is posting out x y z with no I J K

[nmi]

I am testing the thread milling code output for fanuc generic post processor.  I am currently getting very lengthy output because it is doing tiny line segments in xyz.

I can't seem to figure out how to get it to post with IJK like it does for helical entry on adaptive clearing.

Does anyone have any ideas?

Thanks,

Chad

[nmi]

I am testing the thread milling code output for fanuc generic post processor.  I am currently getting very lengthy output because it is doing tiny line segments in xyz.

I can't seem to figure out how to get it to post with IJK like it does for helical entry on adaptive clearing.

Does anyone have any ideas?

Thanks,

Chad

[nmi]

So I had noticed that no matter what post processor I was switching to it would still not output the I J

This then made me believe that it was coming from my settings for the thread milling options.  I thought that i would not want a value in for "horizontal lead in/out radius" so I had this set to zero.  Added a value into it and low and behold that took care of the problem with no I J's being output.

Can someone now please explain why this is needed.  I also noticed that it turned on the cutter comp after doing this, which it wasn't before.  I had thought that linear lead length would take care of turning on CC.

Thanks,

Chad

[paul.clauss]

Hi @nmi

Thanks for posting! It looks like you are experiencing some unexpected results with respect to IJK moves when posting a Thread Milling operation with the Fanuc post. 

Would you mind sharing the file in which you have been experiencing this issue with me? I had a look at this behavior this morning and found that IJK codes were exported whether I used zero or a value for the horizontal lead-in/out radius parameter - I have shown this in the screencast below. Perhaps this is an issue with your specific dataset - having a look at the file should allow us to look into why IJKs were not being output for you.

Please let me know if you have any questions! 

[LibertyMachine]

Interesting....

[nmi]

That is good news because I thought that sounded a bit strange.

Here is the file and please ignore that it has all kinds of drilling and other cycles going into the hole.  I was just keeping things simple with the model for testing code to compare with our current output from another cam package.

http://a360.co/2pORTZF   Let me know if I did not do it right, I am rather new to this.

Thanks,

Chad

[paul.clauss · Accepted solution]

Hi @nmi, @LibertyMachine

Thanks for the responses! Seth - I appreciate the great video that helped me discover the cause of this error. When a value of zero is used for the Horizontal lead-in/out radius with In Control compensation, the tapering of the path is forcing the code to output a spiral move, rather than a true circular move. You can see this in the lines of code from the dumper post below:

262: onMovement(MOVEMENT_CUTTING /*cutting*/)
262: onCircular(false, -1.6784474073073233e-15, 1.1189649382048822e-15, -0.9999999849815068, -0.5262889636783149, -0.5343406406913217, -0.900000024029589, 92.00000192236712)
  direction: CCW
  sweep: 701.999999deg
  normal: X=0 Y=0 Z=1 (XY)
  spiral
  start radius: 0.559017
  end radius: 0.75
  delta radius: 0.190983
  helical pitch: 0.076923

Because this move is being posted as a spiral rather than a circular move, the IJKs are not being output. And because the Thread milling toolpath does not include Smoothing options, it is difficult to force the arc moves, which leads to the many linear moves you were seeing in your code. 

Setting the horizontal lead-in/out parameter to a value allows the path to generate correctly because the outer diameter of the toolpath is no longer tapered unintentionally. I also found that using a zero value for the Horizontal Lead-in/out with Wear compensation rather than In Control. We can see that these options output a truly circular path in the dumper post output below:

262: onCircular(false, -1.6784474073073233e-15, 1.1189649382048822e-15, -0.9999999849815068, -0.15450849307803657, -0.47552825897697387, -0.900000024029589, 92.00000192236712)
  direction: CCW
  sweep: 702deg
  normal: X=0 Y=0 Z=1 (XY)
  radius: 0.5
  helical pitch: 0.076923

As I cannot see any reason for the use of In Control compensation and no Horizontal Lead-in/out to result in a tapered toolpath, I have logged an issue (CAM-7331) with our development team to look into this issue. I will keep this thread updated as I have more information to share about a resolution to this behavior - please let me know if you have any questions. 

[nmi]

@paul.clauss@LibertyMachine

Thanks a bunch guys for the great explanations and clearing up the issue I was getting.  I think where I am messing up is I am trying to use in control compensation too much.  Is it normal for most fanuc controls to use wear for compensation?  Normally at the machine we only adjust for the tool when it cuts a bit small.  The software is always programming tool center and then outputting a cutter compt to adjust the wear.

I have been a bit confused by the different compensation types. Can someone tell me which I should be using when I want the software to program to tool center and output a cutter comp code for wear adjustment at the machine.  I am now assuming it is "wear"  I want to select and not "in control".

Thanks,

Chad

[paul.clauss]

Hi @nmi

Thanks for posting! To program the tool center and then output G41/42 codes to adjust for wear at the machine, you would usually use the In Control option - this will allow you to enter compensation and wear at the machine.

However, because using this option with no Horizontal Lead-out tapers the toolpath (logged as CAM-7331 in my last response on this thread), you may want to use Wear so you can have a zero Horizontal Lead-out value. Wear compensation works as if In Computer was selected (programs the cutting edge of the tool diameter rather than the center of the tool), but outputs G41/42 compensation codes at the machine. This allows you to make adjustments for tool wear at the machine by entering the difference in actual size and the size of the tool in Fusion as a negative number. Inverse wear allows to you enter this delta value as a positive number.

Wear Compensation will consider the tool diameter when generating the toolpath, but output G41/42 compensation codes to adjust at the machine based on the difference in programmed tool diameter vs. actual tool diameter, as shown above.In Control Comp. will put the center of the tool (shown by blue toolpath) directly on the selected face.

Hopefully this helps! Please let me know if you have any questions.