Fusion360 ポストプロセッサ危険な設定

このサイトでも、下記記事から連載でFusion360 CAM のポストプロセッサの編集方法を紹介してきました。
筆者も自作したポストを実際の加工にも使用していますが、先日製品に食い込んでしまうパスを発見しました。
シミュレーションレベルで発見できたので大事にはいたりませんでしたが、その事例を紹介します。

Fusion360 CAM ポストプロセッサ徹底解説・概要編

数回にわたって、Fusion360 CAM のポストプロセッサの説明をしようと思います。しかし、筆者自身も独学なので、わかっている範囲での説明になりますし、もしかすると間違いもあるかもしれませんので、ご了承ください。ただ、ポストプロセッサは...

www.kazuban.com

2020.11.28

あっ！食い込んでる。

Fusion360 CAMは、全ての加工ではないですが実際の加工にも自作のポストプロセッサで利用しています。
やはりCAMには得意不得意があるので、使い分けしています。
今回かなり複雑なパスをFusin360で出力させてみました。
ところが、加工前のNCデータシミュレーションで 食い込みを発見しました。
別のCAMでも、気に入らないデータを出力する事はよくありますが、これはかなり致命的です。

上画像は、NCデータをTRYCUTでシミュレーションした結果です。
下画像は Fusion360 でのシミュレートで不具合は発生していません。

おそらく、Fusion360 CAMの内部計算レベルでの不具合ではなく、 ポストプロセッサでの不具合だと推測できます。

NCデータ分析

まずは、食い込んだNCデータを分析してみると、このようなデータが見つかりました。

・
・
N128625 G01 X114.328 Y-83.682
N128630 G02 X114.332 Y-83.676 I0.437 J-0.282
N128635 G01 X114.384 Y-83.598
N128640 G02 X114.388 Y-83.592 I0.433 J-0.288
N128645 G01 X114.413 Y-83.555
N128650 G02 I0.429 J-0.294
N128655 G01 X114.446 Y-83.507
N128660 G02 X114.45 Y-83.501 I0.428 J-0.295
N128665 G01 X114.486 Y-83.45
N128670 G02 X114.488 Y-83.448 I0.424 J-0.301
N128675 G01 X114.522 Y-83.401
N128680 G02 X114.525 Y-83.396 I0.423 J-0.303
・
・

これだ！
この行は、X、Y軸指令がなく、I、J指令しかありません。
Ｘ，Ｙ軸はモーダルなので、始点終点が同じ円弧補間指令だと言うことですね。
これは、ＮＣ言語的にはどのような指令でしょうか？
そう、真円指令です。
直前の、Ｘ，Ｙ座標に戻ってくる真円動作となります。
確認のためデータ量が多いので、その付近の一部分だけ抜粋し、
以前このサイトで公開した、自作のＮＣデータチェックソフトで確認してみましょう

予想通りです。
この部分で、真円動作となるため、食い込みが発生したのです。
Fusion360 CAMのシミュレータでは食い込みは発生していないため、内部計算レベルでの不具合ではなく、
NCデータを出力するのは、ポストプロセッサなので、ポストが原因だと思われます。
食い込みは標準付属の「fanuc.cps」でのデフォルト設定では発生しませんでした。
使用した自作のポストを見直してみる必要がありそうです。

ポスト見直し

ポストプロセッサで、円弧補間を出力させている箇所は、「onCircular( )」関数です。
ところが、この部分は自作ポストでは、標準ポストから修正していませんから、改造が原因ではなさそうです。
Ｘ，Ｙ軸指令が消えてしまっているので、Ｘ，Ｙの出力方法を見てみます。
この関数で、X座標を出力させている部分は、「xOutput.format(x)」ですが、この指令はモーダル情報も考慮するため直前の座標と同じ場合には、モーダル仕様により、出力データは 「空（ヌル）」になります。
ようするに、直前のＸ，Ｙ座標が同じだったため、Ｘ，Ｙ指令が省略されてしまったのです。
ところが、Ｉ，Ｊ指令は出力されているので、ＣＡＭ的には移動要素はあるようです。
ただし、ポストが円弧と判断する限界値の設定は必要なので、その設定値が問題ではないか？と推測しました。

カーネル設定変数

ポストプロセッサには、こちらでも紹介している、特殊な変数があります。
そのなかでも下記の円弧指令に関連すると思われる変数ですが、
この変数でデフォルト値を設定していますが、
この部分、あまり意識しないまま設定していました。

minimumChordLength = spatial(0.25, MM);
minimumCircularRadius = spatial(0.01, MM);
maximumCircularRadius = spatial(1000, MM);
minimumCircularSweep = toRad(0.01);
maximumCircularSweep = toRad(180);

とりあえず、小さいほうが精度がよくなりそうな気がしたので、あまり考えずデフォルトは「0.001」に設定するような仕様にしていました。

minimumChordLength = spatial(0.001, MM);
minimumCircularRadius = spatial(0.001, MM);
maximumCircularRadius = spatial(1000, MM);
minimumCircularSweep = toRad(0.001);
maximumCircularSweep = toRad(180);

「minimumChordLength」は、円弧の最小弦の長さ。
「minimumCircularRadius」は、円弧の最小半径です。
推測するに、ＣＡＭ側からこの数値よりも小さい値の円弧が定義された場合には、円弧指令コード「G02 , G03」コードは出力せずに、直線補間コード「G01」を出力するのだと思います。
この変数は、 ポスト処理のプロパティで設定可能です

標準ポスト「fanuc.cps」のプロパティで「（ビルトイン）最小弦の長さ」を「0.001」にした所
今回テーマと同様の 不具合のあるNCデータを吐き出しました。
このプロパティは、設定値より大きい場合、円弧として出力するような意味のようです。

小数点以下桁数

もう一つ重要な変数があります。

var xyzFormat = createFormat({decimals:(unit == MM ? 3 : 4), forceDecimal:true});

これは、Ｘ，Ｙ，Ｚの出力フォーマットは、「mm」単位であれば、小数点以下３桁で出力しろ、の定義です。
この設定値と上のプロパティの設定値の関係が不具合の原因がだったと分かってきました。
「円の弦の長さプロパティ」を「0.001」に設定した場合、CAMからの指令が「0.001」よりも若干でも大きい場合、ポストは円弧指令として出力させます。
ところが、ＸＹ軸の小数点以下出力桁数は３桁なので、単軸での移動距離が「0.001」より小さい場合には、まるめ方によっては移動距離ゼロ（直前と同じ値）になります。
結局、モーダル仕様の場合、Ｘ，Ｙ指令は省略される事になります。
これが、「G02 I0.429 J-0.294」と出力され、真円動作となり食い込みが発生した原因ではないでしょうか？！。
ちなみに、小数点以下桁数を、４桁にしたとろ

var xyzFormat = createFormat({decimals:(unit == MM ? 4 : 4), forceDecimal:true});

食い込み動作は発生しませんでした。

解決策

したがって、 「minimumChordLength（円弧最小弦長さ）」は、ＸＹ軸の小数点出力桁数よりも一桁大きな数値にしたほうが安全だと言えます。
さらに、どうしても微小な円弧補間が必要な場合を除いて、「minimumCircularRadius（円弧最小半径）」も極端に小さくする必要ななさそうです。
NC指令値の小数点以下桁数を、増やすのも一つの策ですし、実際に１μを狙う機械には４や５にしています。
ただし、工作機械によっては、小数点以下３桁以上では動作しないか誤動作する機械もあるので注意が必要です。
まずは「minimumChordLength」のデフォルトは、２桁（0.01）で対応しようと思います。

minimumChordLength = spatial(0.01, MM);
minimumCircularRadius = spatial(0.01, MM);
maximumCircularRadius = spatial(1000, MM);
minimumCircularSweep = toRad(0.001);
maximumCircularSweep = toRad(180);

二重対策

これで、デフォルトで使用する場合では今回のような不具合は発生しないと思いますが、
いいのか？悪いのか？Fusion360はポスト設定プロパティ画面で変更が可能になってます。
「（ビルトイン）最小弦の長さ」を「0.001」に変更してしまうと、同様のデータが出力されてしまう可能性がありますね。
安全を考慮するなら、この部分もポスト側でチェックさせてほうがいいと思います。
方法は、２種類考えられます。
一つは、「var xyzFormat」変数の、「decimals:」の値と、「minimumChordLength」の値を比較して、エラーを出力させる方法です。
もう一つは、 円弧出力時に、Ｘ，Ｙ軸指令両方が省略されたら、その指令自体省略してしまう方法です。
今回は、後者で対策しようと思います。

ポスト修正

ポストプロセッサの「円弧補間」を出力する関数は、「onCircular( )」です。
この関数を修正します。
以前紹介した、「Microsoftの「Visual Studio Code」」であれば、「FUNCTION LIST」から簡単に関数を見つける事ができます。

この関数の上部では、

if (isFullCircle()) {
 ・
 ・

で、真円かどうかの条件判断をしています。
今回の場合、Ｘ，Ｙの指令がモーダルにより省略されて真円動作となってしまいましたが、本質的には真円ではないので、この条件のブロックには属しません。
このブロックから抜けた、

} else if (!properties.useRadius) {

このブロック以降が対象となります。
まず、「!properties.useRadius」の意味は、プロパティ設定で「円弧指令にＲ指令を使わない」の意味で、
この場合に、このブロックを実行します。
「円弧にＲ指令を使う場合」にはその次の「else」以下のブロックになります。
R指令の場合は、円弧が１８０度以上の場合には「マイナス（ー）」指示となるため、今回の場合にはCAMは「マイナス（ー）」指令は出さないと思います。
したがって、「!properties.useRadius」の「円弧指令にＲ指令を使わない」場合のブロックを修正します。
修正の概要としては、
・まずＸ，Ｙ，Ｚ軸の出力内容を、変数に代入
・その、Ｘ，Ｙの内容がどちらかでも「空（ヌル）」でない場合のみ
・円弧補間（G02,G03）の出力
・逆に、どちらも「空（ヌル）」の場合に、出力省略。
・同様処理を、ＺＸ、ＹＺ平面にも適応
という処理に変更したいと思います。

　・
　・
  } else if (!properties.useRadius) {
    switch (getCircularPlane()) {
    case PLANE_XY:
      var xOut = xOutput.format(x);   
      var yOut = yOutput.format(y);   
      var zOut = zOutput.format(z);   
      if(!(xOut=="" && yOut=="")){
        //writeBlock(gPlaneModal.format(17), gMotionModal.format(clockwise ? 2 : 3), xOutput.format(x), yOutput.format(y), zOutput.format(z), iOutput.format(cx - start.x, 0), jOutput.format(cy - start.y, 0), getFeed(feed));
        writeBlock(gPlaneModal.format(17), gMotionModal.format(clockwise ? 2 : 3), xOut, yOut, zOut, iOutput.format(cx - start.x, 0), jOutput.format(cy - start.y, 0), getFeed(feed));
      }
    break;
    case PLANE_ZX:
      var xOut = xOutput.format(x);   
      var yOut = yOutput.format(y);   
      var zOut = zOutput.format(z);   
      if(!(zOut=="" && xOut=="")){
        //writeBlock(gPlaneModal.format(18), gMotionModal.format(clockwise ? 2 : 3), xOutput.format(x), yOutput.format(y), zOutput.format(z), iOutput.format(cx - start.x, 0), kOutput.format(cz - start.z, 0), getFeed(feed));
        writeBlock(gPlaneModal.format(18), gMotionModal.format(clockwise ? 2 : 3), xOut, yOut, zOut, iOutput.format(cx - start.x, 0), kOutput.format(cz - start.z, 0), getFeed(feed));
      }
      break;
    case PLANE_YZ:
      var xOut = xOutput.format(x);   
      var yOut = yOutput.format(y);   
      var zOut = zOutput.format(z);   
      if(!(yOut=="" && zOut=="")){
        //writeBlock(gPlaneModal.format(19), gMotionModal.format(clockwise ? 2 : 3), xOutput.format(x), yOutput.format(y), zOutput.format(z), jOutput.format(cy - start.y, 0), kOutput.format(cz - start.z, 0), getFeed(feed));
        writeBlock(gPlaneModal.format(19), gMotionModal.format(clockwise ? 2 : 3), xOut, yOut, zOut, jOutput.format(cy - start.y, 0), kOutput.format(cz - start.z, 0), getFeed(feed));
      }
      break;
    default:
      if (properties.allow3DArcs) {
　・
　・

確認

オリジナルと修正したポストファイル両方でパス出力し比較してみます。
比較しやすように、シーケンス番号は出力させず
どちらも「（ビルトイン）最小弦の長さ」は「0.001」にしています。

予定通り、Ｉ，Ｊのみの、円弧補間の行は出力されていません。
TRYCUTでNCデータシミュレーションしてみます。
食い込みは改善されました！

まとめ

今回の不具合は標準ポストでデフォルト設定での使用では出なかった不具合ですが、
プロパティでは変更できてしまう設定なので、やはり危険ではあります。
また、Fusion360のシミュレータはCAMレベルでのシミュレーションなので
ポスト出力も含め、NCデータの不具合は発見できません。
特に、ポストプロセッサを自作や編集で使う場合は
やはり、実加工前には最終的にNC工作機械へ入力する、
NCデータシミュレーターはほしいですね。