正規表現

正規表現の情報は、ネット上に豊富にあると思うので、詳細は検索してみてください。
下記は「正規表現」の説明をAIに聞いてみた回答です

概要

本チャットログでは、「正規表現（Regular Expression）」の基本要素について、最小限かつ代表的な機能に絞って説明している。主な用途は文字列の検索・置換・抽出であり、「文字列パターンを表現する小さな言語」として位置付けている。

1. 文字列とリテラル

• abc
  • 文字列「abc」にそのままマッチするパターン。

2. メタ文字（特別な意味を持つ記号）

• . : 任意の1文字
• ^ : 行頭
• $ : 行末
• * : 直前要素の0回以上の繰り返し
• + : 直前要素の1回以上の繰り返し
• ? : 直前要素の0回または1回
• | : OR（または）
• () : グループ化・キャプチャ

具体例

• a.*b
  • 「a」で始まり「b」で終わる行全体にマッチ（間の文字列は任意長）
• colou?r
  • color または colour にマッチ（u がある/ない両方に対応）。

3. 繰り返し回数の指定（量指定子）

• {n} : ちょうど n 回
• {n,} : n 回以上
• {n,m} : n〜m 回

具体例

• \d{3}-\d{4}
  • 123-4567 のような「数字3桁-数字4桁」形式にマッチ。

4. 文字クラス

• [abc] : a か b か c のいずれか1文字
• [^abc] : a,b,c 以外の1文字
• [0-9] : 数字
• [A-Za-z] : 英字（大文字・小文字）

5. 代表的なエスケープシーケンス

多くの処理系で共通して使われるもの。

• \d : 数字 [0-9]
• \w : 単語構成文字（英数字 + _）
• \s : 空白文字（スペース・タブ・改行など）
• \D : 非数字（\d 以外）
• \W : 非単語構成文字（\w 以外）
• \S : 非空白文字（\s 以外）

6. エスケープが必要な記号

次の文字はメタ文字として特別な意味を持つため、そのままの記号として扱うにはバックスラッシュでエスケープする必要がある。

• 対象文字
  • . * + ? ^ $ ( ) [ ] { } | \
• 使用例
  • \. : ドットそのものにマッチ
  • \? : 疑問符そのものにマッチ

補足

ここまでが「基本の道具」としての正規表現の要素一式であり、今後はこれらを組み合わせて「メールアドレスの簡易チェック」など、実用的なパターン作成にも応用できると示唆している。

個別でみれば、なんとなくわかる気もしますが、これが組み合わさると、まったく呪文です
ただ、いろんなパターンの質問とAIの回答を照らし合わせると、なんとなく理解できてくるので、正規表現にかぎらず、AIは言語学習資料としても本当に役立ちます。

ファナック系、NCデータ構造

NCデータの分析ソフトを検討する場合、NCデータ構造の知識は必須です
NCデータの知識がないまま、AIの回答だけで進めると、間違いなく後々苦労します
ファナック系のプログラム構造は、下記記事でも紹介しています

NCプログラム／プログラム構造

最近の投稿は、覚書きとしても残しておきたかったので、素人ながらLinux系の投稿が連続していましたが、今回は気分を変えて、今まで携わってきたＮＣ関連の記事を書こうと思います。ＮＣプログラムとは？ＮＣ工作機械のコントローラへの指令の集まりです。プログラムとありますが、ファナック系は基本的には命令コード...

www.kazuban.com

2019.11.30

「ワード」＝「アドレス」+「数字・数値」
「ブロック」＝「ワード」の集まり
「NCデータ」＝「ブロック」の集まり

NCブロックからNCアドレスを抽出する課題なので、NCコードを少し復習しておきます

ブロックの末尾は制御器では「EOB」ですが、PC側では改行コードになります
改行コードはOSにより変わりますが、基本的にアスキー形式での転送で大丈夫だと思います
NCデータの最小単位は、「ワード」と呼ばれていて、
「アルファベット一文字」+「数字、符号、小数点」が一塊になっている要素です
例えば「G02」とか「X-12.345」の構成です。
先頭のアドレス文字で機械への指令の種類を表し、ワードで具体的な指令になります
この「ワード」が集まり、一行の構成になった文字列が「ブロック」と呼ばれます
さらに、「ブロック」が複数行あつまって、NCデータになります
CAM利用の場合、作成したNCデータファイルをNC機械へ転送し加工動作を制御します
分析ソフトを検討する場合、まずはNCデータをブロックに、ブロックをワードに分解したほうが整理しやすいです
今回の課題では、正規表現を利用して「ブロック」を「ワード」に分解するコードを作成します
やりたい事をAIに投げかけると、それなりの回答をもらえます。
ただ、ＮＣコードのように、機種依存や複雑な表現がある場合、AIへすべて完ぺきなコードを期待してもなかなか思うような回答は得られません。
また、最初は良くても開発を進めていくうちに、改造したくなる場合もあります
やはり、ある程度の理解は必要です。

ブロックから正規表現でワードに分解する

具体的に正規表現を書き、「ワード」に分解した結果と照らし合わせながら理解を進めようと思います
「ワード」＝「大文字アルファベット一文字」+「数字」なので、一番単純な正規表現のパターンは、”[A-Z]\d”になります
また、正規表現パターンで、文字列から部分文字列を抽出するのに、AIは「re.findall関数」を教えてくれました
（findall関数についての詳細は、ネット検索やAIに聞いてみてください）
サンプル文字列は複数のパターンを織り交ぜた、”G0G1G00 G03M3 T102M30″　でやってみます
（文字列並びのみのサンプルで、NCデータとしては意味ありません）

アドレスと数字抽出

import re

block = "G0G1G00 G03M3 T102M30" # サンプルNCブロック文字列
words = re.findall(r"[A-Z]\d", block)
print(f"{words}")

#---------- 結果 --------------
#['G0', 'G1', 'G0', 'G0', 'M3', 'T1', 'M3']

ちょっと期待とは違いますが、とりあえずは、アドレスと数字がリストで取り出せました
たった一行で分解された文字列リストが作成されました、すごいですね～
一文字づつ文字列操作で処理させたら、結構なコード量になっていると思います
ただ、「\d」としたため、「数字は一文字」しか抽出してくれませんでした
ここで「\d{2}」としてみると、「数字二文字」のみ取り出してくれます
今回の例ですべて取り出すには「\d{1,3}」とすればすべてヒットします
「\d+」でも同様の結果になりますが、こちらの方は文字数制限はなくなります
今回のサンプルでは、”[A-Z]\d+”で行こうと思います
ちなみに、「\d{0}」とすると、アドレスのみ取り出せます。

import re

block = "G0G1G00 G03M3 T102M30" # サンプルNCブロック文字列
words = re.findall(r"[A-Z]\d+", block)
print(f"{words}")

#---------- 結果 --------------
#['G0', 'G1', 'G00', 'G03', 'M3', 'T102', 'M30']

さらに、アドレスと数字を分けて抽出したい場合

グループ化と呼ばれる（丸括弧）でパターンを囲むと「tuple」として分離してくれます
抽出した後の処理内容によっては、こちらが便利かもしれません

import re

block = "G0G1G00 G03M3 T102M30" # サンプルNCブロック文字列
words = re.findall(r"([A-Z])(\d+)", block)
print(f"{words}")
for addr, val in words:
    print(f"addr={addr}:val={val}")

#---------- 結果 --------------
#[('G', '0'), ('G', '1'), ('G', '00'), ('G', '03'), ('M', '3'), ('T', '102'), ('M', '30')]
#addr=G:val=0
#addr=G:val=1
#addr=G:val=00
#addr=G:val=03
#addr=M:val=3
#addr=T:val=102
#addr=M:val=30

軸（X,Y,Z・・）の小数点にも対応させる

ここまでは、GやMコードでしたが、軸指令に対応するには、符号や小数点も考慮する必要があります
余談ですがプログラミング初心者の場合勘違いしやすいのが、数字と数値の違いです。
「12.23」の場合、数値としては「12 + 0.23」のように演算ができますが、
数字の場合は、「1」「2」「.」「2」「3」と途中に「.」があるだけのただの数字文字の連続です
正規表現の場合も、数字・符号・小数点の文字の集まりとして処理するので、数値で考えてしまうと期待と違う結果になり、悩む事になります
さて、文字を意識してサンプル文字列データに軸指令を追加して、上記のコードで実行してみます

import re

block = "G90G01 X12.5Y+20.3Z-5.63F1000" # サンプルNCブロック文字列
words = re.findall(r"[A-Z]\d+", block)
print(f"{words}")

#---------- 結果 --------------
#['G90', 'G01', 'X12', 'F1000']

やはりこのコードでは、±符号と小数点が入るとマッチしないので、省かれてしまいますね
まず符号に対応するためにはアドレス「A-Z」の後に[+-]を追加します

import re

block = "G90G01 X12.5Y+20.3Z-5.63F1000" # サンプルNCブロック文字列
words = re.findall(r"[A-Z][+-]\d+", block)
print(f"{words}")

#---------- 結果 --------------
#['Y+20', 'Z-5']

これでは、符号「+-」が必須に判断され符号付の文字列しかヒットしませんでした
符号文字は「無くてもいい」の意味で[+-]?としてみます

import re

block = "G90G01 X12.5Y+20.3Z-5.63F1000" # サンプルNCブロック文字列
words = re.findall(r"[A-Z][+-]?\d+", block)
print(f"{words}")

#---------- 結果 --------------
#['G90', 'G01', 'X12', 'Y+20', 'Z-5', 'F1000']

符号部分を[+-]? とすることで、符号がなくてもマッチするようになりました
次に小数点とそれ以下にも対応させてみましょう
NC制御器は、数値として扱いますが、文字としての小数点の扱いは結構面倒です。
小数点がある場合、ない場合、小数点から始まる場合、小数点で終わる場合・・など
まずは、小数点の有無に対応させるため、「\d+\.\d+」を考えましたが、
この場合、小数点がないとマッチしなくなります
そこで「？を付加」すれば「無くてもいい」にも対応できます

import re

block = "G90G01 X12.5Y+20.3Z-5.63F1000" # サンプルNCブロック文字列
words = re.findall(r"[A-Z][+-]?\d+\.?\d+", block)
print(f"{words}")

#---------- 結果 --------------
['G90', 'G01', 'X12.5', 'Y+20.3', 'Z-5.63', 'F1000']

だいぶ理想に近づいてきましたが、「X.124」や「23.」など、小数点での始まりや終わりには対応できません
サンプル文字列に追加して確かめてみましょう

import re

block = "G90G01 X12.50Y+20.3Z-5.63 I.5 J22.F1000" # サンプルNCブロック文字列
words = re.findall(r"[A-Z][+-]?\d+\.?\d+", block)
print(f"{words}")

#---------- 結果 --------------
#['G90', 'G01', 'X12.50', 'Y+20.3', 'Z-5.63', 'J22', 'F1000

やはり、「I.5」にはマッチせず「J22.」の「.」は省かれていますね
ここも余談ですが、NCで「22.」を「22」に変換してしまった場合、制御器によってはとんでもない事になりかねないので十分意識しておく必要があります。

整理してみると

• [A-Z]：NCコードのアドレス
• [+-]?：必須ではない、符号
• \d+：複数個の数字
  ここまでで、「Gコード」「Mコード」には対応できている
• \.?：小数点は必須でない
• \d+：複数個の数字

やはり、「小数点で終わる」場合「\.?」なので、省略されてしまいますね
ではどうすればいのか？
AIに聞いたところ、グループ化と言う方法があり、”( )”で囲む事で、一塊としてでマッチングのルール設定できるようです
ただし、”( )”では、囲みごとに分割されタプルのリストとして抽出されます
グループごとに分割させたくない場合には“(?: )“で囲む仕様があり非キャプチャグループと呼ばれマッチングのルールには使用するが分割はされないようです。
今回の例では、分割させたくないので、”(?: )“を使ってみます
最後の「\d+：複数個の数字」をグループ化して、必須ではない複数個の数字として設定します

import re

block = "G90G01 X12.50Y+20.3Z-5.63 I.5 J22.F1000" # サンプルNCブロック文字列
words = re.findall(r"[A-Z][+-]?\d+\.?(?:\d+)?", block)
print(f"{words}")

#---------- 結果 --------------
#['G90', 'G01', 'X12.50', 'Y+20.3', 'Z-5.63', 'J22.', 'F1000']

これで、「22.」には対応できました。次は、小数点で始まる「.5」の場合です。
ここまででも、結構な呪文になっているのに、さらに複雑になりそうです。
ここもAIに相談すると、グループの中で（A | B）の書式で「AまたはB」とマッチング範囲の選択ができるようで、この書式での書き方を教えてくました

import re

block = "G90G01 X12.50Y+20.3Z-5.63 I.5 J22.F1000" # サンプルNCブロック文字列
words = re.findall(r"[A-Z][+-]?(?:\d+\.\d+|\d+\.|\.\d+|\d+)", block)
print(f"{words}")

#---------- 結果 --------------
#['G90', 'G01', 'X12.50', 'Y+20.3', 'Z-5.63', 'I.5', 'J22.', 'F1000']

• [A-Z]：NCコードのアドレス
• [+-]?：必須ではない、符号
• — ここからグループ化 —
• \d+\.\d+：数字+小数点+数字
  または
• \d+\.：数字+小数点
  または
• \.\d+:小数点+数字
  または
• \d+：複数個の数字のみ

書き方は他にもあると思いますが、グループ化して、マッチさせたいパターンを一つ一つORで区切るこの方法は私には理解しやすかったです

複雑な正規表現の可読性を高める

いちおう動作はしましたが、ここまでくると、読みにくいですね～
可読性を高める方法として、さらにAIが「re.VERBOSE」を提案してくれました
具体的に、上記のコードを書き替えてみます
パターンを一行づつに分割できて、行ごとにコメントも追記できるので、複雑になってもわかりやすくなります

pattern = re.compile(
    r"""
    [A-Z]        # A-Zアドレス
    [+-]?         # 符号
    (?:           # 小数点処理、非キャプチャグループ
      \d+\.\d+      # 数字、小数点、数字
      |\d+\.        # または、数字、小数点
      |\.\d+        # または、小数点、数字
      |\d+          # または、数字のみ
    )
    """,
    re.VERBOSE,
)
words = pattern.findall(block)
print(f"{words}")

#---------- 結果 --------------
#['G90', 'G01', 'X12.50', 'Y+20.3', 'Z-5.63', 'I.5', 'J22.', 'F1000']

さらにちょっと特殊な、G や M　コードにも対応させてみます

通常、NCワードは「アドレス＋数字」ですが、拡張されたワーク座標系指令やサブプロ呼び出しなどちょっと特殊な構成のコードもあります
全てに対応は難しいと思いますが、「G54.1P1」や「M98P100」などにも対応してみようと思います。
これら対応するためには、上記のパターンでは処理できないのでパターンを追加します
やはり、可読性が上がる、re.VERBOSE を利用します

block = (
    "G05P10000 G90G01 X12.50Y+20.3Z-5.63 I.5 J22.F1000 G54 G54.1P12 M98P1100 M198 P2299"
)
pattern = re.compile(
    r"""
    # --- 特殊構成、G54.1P12 / M98P1234　など---
    [GM]          # G や M アドレス
    \d+(?:\.\d+)? # 54　や　54.1 
    \s*P\d+       # スペースとP文字と数字
    # --- 通常のアドレス+数字 ----
    |[A-Z]        # A-Zアドレス
    [+-]?         # 符号
    # --- 小数点対応 ----
    (?:           # 非キャプチャグループ
      \d+\.\d+      # 数字、小数点、数字
      |\d+\.        # または、数字、小数点
      |\.\d+        # または、小数点、数字
      |\d+          # または、数字のみ
    )
    """,
    re.VERBOSE,
)
words = pattern.findall(block)
print(f"{words}")

#---------- 結果 --------------
#['G05P10000', 'G90', 'G01', 'X12.50', 'Y+20.3', 'Z-5.63', 'I.5', 'J22.', 'F1000', 'G54', 'G54.1P12', 'M98P1100', 'M198 P2299']

どうにかできました。
次の課題は「G04X10.」とかにも対応したいと思っていますが、これ以上条件が増えると大変です
正規表現パターンを変数化できれば、もう少しわかりやすいと思います

正規表現のraw文字列の変数化

AIに聞いてみました。さすがAI、できますよ！との回答をもらいました
AIの回答を参考に上記コードを書き直してみました。

block = (
    "G05P10000 G90G01 X12.50Y+20.3Z-5.63 I.5 J22.F1000 G54 G54.1P12 M98P1100 M198 P2299"
)
num = r"[+-]?(?:\d+\.\d+|\d+\.|\.\d+|\d+)"  # +12.123|-24.|.56|30
g54_1 = r"[GM]\d+(?:\.\d+)?\s*P\d+\.?"      # G54.1P1 M98P1122
nomal = r"[A-Z]"  # 通常のアドレス
pattern = re.compile(
    rf"""     
    {g54_1}         # G54.1P1 , M98P1122
    #----------------------
    |{nomal}{num}   # G01 , X-12.356
    """,
    re.VERBOSE,
)
words = pattern.findall(block)
#---------- 結果 --------------
#['G05P10000', 'G90', 'G01', 'X12.50', 'Y+20.3', 'Z-5.63', 'I.5', 'J22.', 'F1000', 'G54', 'G54.1P12', 'M98P1100', 'M198 P2299']

なるほど、だいぶ見やすくなりました
今後の仕様変更にも対応しやすくなったと思います
興味ある方は是非、「G04X10.」への対応もやってみてください。

まとめ

これまでも単純な正規表現に触れる機会はありましたが、複雑な記述はまるで「呪文」のようで、敬遠していました。
しかし、正規表現は文字列操作において非常に強力な武器になります。
独学ではやる気なしでしたが、AIと対話する事で、ある程度は理解できてきました。
今後もAIと対話しながら一歩ずつ分析していくことで、正規表現だけでなく、プログラミング言語全体の理解力も深めていけると感じています。

リニアライゼーション・微小直線化

同時５軸加工

もう少し、５軸の話をします。
イメージしやすいように、主軸側に回転軸がある構成で考えてます。
先端点制御機能を使用しないで、直行軸(X,Y,Z)と回転軸を同時に動かしての同時５軸加工の場合、
主軸はXYZ指令の位置（P1→P2→P3）へ直接向かいますが、回転軸も回転するため、工具先端では削り残りや削りすぎが発生してしまいます。
先端点制御機能は、この誤差が出ないように、主軸切込み軸を調整してくれますが、先端点制御機能がない場合には、この誤差はそのまま加工してしまいます。

この誤差は、一行の指令での移動距離が長いほど大きくなります。
したがって、当時の５軸CAMは、回転が発生する移動指令を、微小直線に分解する処理を行っていてリニアライゼーションと呼ばれていました。
この一回の移動距離を微小にする事で、先端点制御を使用しない同時５軸制御でも、誤差を少なくして加工しようと言う事です。
ところが、微小指令になる事で、NCデータサイズは格段に大きくなり、読み込みの遅い制御機では太刀打ちできません。
読み込み機能も、ハイデンハインやレダースなどの、EU制御機は、１０００行や１００００行先読みと言われていましたから、読み込みスピードもヨーロッパに軍配が上がっていた時期だったと思います。
現在では、ほぼ解消されていると思います。

２軸・３軸加工パスの直線化

回転軸を同時に動かさない場合、上述の誤差は起きません。
むしろ、微小直線化する事で、データ容量が増え、制御機の読み込み能力によっては機械動作は不安定になります。
ただ、制御機能力も急上昇していて新しい制御機では、３D加工でも浅切込み高速切削の加工方法が推奨されるようになると、CAMの内部計算の問題なのか、微小直線補間（G01）での出力が普通でした。
ところが古い制御機では、読み込み能力や容量の問題で、微小直線での動作は不向きでした。
そこで今度は微小直線補間を円弧に近似するCAMも出てきました。
当時紙テープやDNC運転の古いマシンを動作させる場合には、結構重宝した記憶があります。
現在では、円弧近似データのほうが、一般的になっていると思います。
そんなわけで、今考えている、円弧補間の直線化は、逆戻りな発想かもしれません。

直線補間と円弧補間

Gコードで、２軸での輪郭動作定義をする場合、直線（G01）、円弧（G02,G03)のコードで定義していきます。
同時３軸の場合でも、ヘリカルオプションが有効な機械の場合、円弧補間で定義できます。
上でも書きましたが、円弧補間を使ったほうが、データサイズも小さく、NCデータを確認する場合でも動きを想像しやすいデータになります。
ところが、これを受け取った制御機はどうでしょう？
筆者はNCの制御方法には、まったくのド素人ですが、円弧補間の場合でも結局は各軸に分解され直線的な指令をしているのではないでしょうか？？
もし、私が制御機だったら、円弧補間での指令より、直線補間での指令が楽なように思います。
最近は制御機は、送受信や処理能力も高速になったので、全て直線補間でもいいのでは？との考えもあります。
ただ、問題もあります。
制御機によっては、工具径補間（G41,G42)させる場合、エラーになる可能性のあります。
ここが解決できれば、制御機的には、すべて直線のほうがいいのではないでしょうか？

事前に直線化する制御機がもある？

筆者の想像ですが、あるメーカーの高速ミリングマシンは受け取ったGコードを円弧補間であっても、事前に微小直線化してCNCへ送っている予感がしています。
この制御機は、NCデータを読み込むとシミュレーション機能で動作の確認ができますが、シミュレーション時の、Gコードがすべて直線補間に変換されていました。
上で問題にした円弧補間の工具径補正の場合でも、補正が適応されたデータがシミュレーションされています。
つまり、制御機内部に円弧動作や補正を任せるのではなく、事前にソフト的に補正経路を直線化したデータを制御機へ送っているイメージです。
実際にこのシミュレーション用に変換されたコードで機械が動作するのかは、検証できていませんが、筆者の推測では、制御機は全て直線補間で動作していると思っています。

２，３軸でのリニアライゼーションの効果は？

同時５軸でない場合、リニアライゼーションは効果はあるのでしょうか？
Ai「Google Gemini」 に聞いてみました。

NCコードのリニアライゼーションは、主に以下の目的で行われます。
・円弧補間を直線補間に置き換える:
・円弧補間の計算負荷を軽減し、加工時間を短縮できる。
・一部のNC装置では円弧補間がサポートされていない場合がある。
・シンプルな直線運動の方が制御が容易である。
・非線形な動きを直線的に近似する:
・複雑な形状を複数の直線で近似することで、プログラムを作成しやすくなる。
・加工精度が厳しくない場合、直線近似で十分な場合もある。

注意点
・精度: リニアライゼーションによって加工精度が低下する場合がある。
・計算負荷: 分割数や多項式の次数が増えると、計算負荷が増大する。
・工具の寿命: リニアライゼーションによって工具の摩耗が促進される場合がある。

なんとなく、私の思っていた事とだいたい一致してます。
ただ、加工精度や工具寿命の件はちょっと疑問です。

微小直線動作での加工精度検証

会社の３軸マシン用のCAMでは、等高線などの３D加工でも、円弧近似してくれますが、パラメータにより直線補間でも出力可能です。
このCAMを使用して、円弧補間モードと直線補間モードでNCデータを出力し加工テストしてみました。
結果的には、それほど差はありませんでしたが、すべりガイド機とLMガイド機で若干の差がでました。
すべりの方は、円弧補間のほうが加工時間も加工面も良好でしたが、逆にLMガイド機は直線補間のほうが勝っていました。
ただ、すべりガイド機のほうが、年式も古いので、製造年数の影響も出たかもしれません。
今回のテストでは、大きな差はみられませんでしたが、新しい機械で高速加工機であれば、効果がでるかもしれません。

２軸加工での、X,Y軸の比率を変えたい

前置きが長くなってしまいましたが、ここからが本題です。
今回作成ソフトの本来の目的は、X、Yの加工輪郭の比率をCADを使用せず、生のNCデータで調整できないか？と言う事です。
筆者の知る限りでは、円弧補間が含まれるGコード全軸同じスケールリングしか対応していないと思っていましたが、「GEMINI」に聞いた所、ファナックのGコードG51では可能だとの回答をもらいましたが、検証はできていません。
ただ下記は、「HEIDENHAIN iTNC530」の取説の抜粋ですが、円弧以外では各軸違う値でスケーリングはできるが、円弧補間では同じ比率が条件になるとありますから、制御機によってはできない場合もあると思います。

プログラミングの前に、次の点に注意してください。
円弧の座標を共有する座標軸は、同じ係数で拡大または縮小する必要があります。
各座標軸を、独自の軸固有のスケーリング係数でプログラミングできます。
さらに、すべてのスケーリング係数の中心の座標を入力できます。
輪郭のサイズは、中心を基準にして拡大または縮小され、必ずしも (サイクル 11 のスケーリング係数のように) アクティブなデータムを基準にして拡大または縮小されるわけではありません。
（Google 翻訳）

したがって、円弧補間を使用せず、全て直線補間であれば、各軸で違うスケーリングができそうです。
今回作成した、ソフトは、ここが目的になります。
直線補間のみのデータにすれば、Gコード指令を使って各軸違う比率にスケーリングできそうだと言う事です。
さらに、部分的とか特殊な変形させるソフトを開発する場合でも、直線（G01）コードは、次の行先の座標があるだけなので、円弧（G02,G03）に比べると、はるかに単純で楽です。
機械も年季が入ってくると、XYの加工精度比率に誤差が出てくる場合があります。
現状、XYの比率がよくない機械で精度を保つには、加工結果を基にCAD上で輪郭を描き直し、パスを出し直す事になりますね。
ところが直線補間のみのNCデータであれば制御機のスケーリングで対応できる可能性がありますし、専用にソフト開発する場合でも簡単になります
直線補間のみであれば、終点の座標値を誤差分だけ足し算引き算でいけそうです。
そんな訳で、あまり利用価値はないかもしれませんが、円弧補間が含まれるNCデータを、直線補間化するソフトを作成してみました。

円弧補間を直線分解する方法

トレランス以内で円弧を直線分割

直線化により円弧軌跡が変換でトレランス以上の誤差になると意味がありません。
指定トレランス以内に収まるように、直線分割する角度を求める計算式を求めます。

トレランス以内で、分割する角度は、「（円弧半径ートレランス）/円弧半径」のアークコサインで求められ、この角度の二倍で一分割の角度が求まります。
Gコードを読み取り、円弧補間の場合、円弧中心から円弧の始まり座標び向かう直線の角度から、分割角度ごとに円弧終点まで分割するような処理をさせます。

ソフト的には、対象円弧を、円弧の中心点から円弧始点への直線と、中心点から終点までの直線の範囲を、分割角度で分割した弦を直線に変換させています。

プログラム構成

• NCデータファイルを読み込む
• 円弧補間以外はそのまま出力
• 円弧補間の場合、上記計算式に伴いトレランス内で直線分割する
• 変換したデータをファイルとして保存する
• 確認用としてオリジナルデータと直線化データをそれぞれDXFファイルにも出力可能

プログラム制限

• 筆者のプログラミングスキルの問題で長いデータの場合に計算時間がかかりそうです
  一応、途中強制終了できるような仕様にしていますが、必要なデータのみサブプログラム的に、必要な輪郭だけのファイルにしておくほうが無難です。
• 今回は、「I」「J」仕様の円弧補間のみの対応です。
  「R」方式には、対応していません。
  また、「I」「J」方式の場合、国内ではほとんど、「I」「J」値は、相対指令ですが、EUでは、アブソリュート指令も多いです。
  今回は、国内で一般的な相対指令仕様でのみ対応しています。

ソフト公開

「LinearizationOfArc.zip」のファイル名で公開しました。

こちらの、「自作ソフト公開」のページから、ダウンロードできます

展開後「README.TXT」に使用方法など書いてあります。
今後の展開としては、直線のみになった輪郭データを利用して、輪郭の一部分のみ変形できたらいいな～と思っています。
輪郭精度が重要な場合、主に輪郭の凸凹のフィレットが、削り過ぎたり、削り残ったり、する場合があります。
そのような場合、その部分のみ、NCデータを変形させる事で、輪郭加工精度を向上できないか？
とういう事です。

3Dプリンタ、Adventurer3 Pro　キタぁ～

約５年前に購入した３Dプリンタ「FlashForge Finder」が壊れました。最近動かす機会も減って数か月ぶりのプリント。一個目は正常に終了しましたが、二個目の途中でフィラメント詰まり。詰まりを解消しノズル掃除して、再度スタートでもまた詰まり。予備のノズルに交換したけど、また詰まり・・・今度はま...

www.kazuban.com

2022.08.23

その時も、精度確認しましたが、購入から約１年たちましたし、
最近「eSUN」のフィラメントを使い始めた事もあり、再度精度確認してみます。
また、「FlashPrint5」の調整方法もよく理解していなかったので、こちらも検証してみます。

確認モデル1

まずは、確認用として非常に単純なモデルを用意しました。

□２０mmのブロックに、□10mmの□孔が開いている形状で、厚さは5mmの簡単なモデルです。

スライサー、デフォルトでテスト印刷

スライサーは「FlashPrint 5」を使用して、「樹脂の種類」を「Flashforge-PLA」のデフォルト設定で
ラフトのみ「無効」にしてプリントしてみましたが、ちょっと反りがでたので、
最初の一層目のみ、最大スピードを30mm/sに変更し再度プリント。

外径X方向：20.0mm
外径Y方向：20.2mm
内径X方向：9.8mm
内径Y方向：10.0mm
厚さ：　5.0mm

ホームセンターで購入のアナログノギスでの測定なのと、積層ピッチが「0.18」で、
側面は積層痕でガタガタしてるので、その程度の測定精度ですが、これを基に調整してみます

プリント補正

「FlashPrint 5」の「エキスパートモード」では、「その他」の項目でプリント精度をある程度調整する事ができます。

「Material Shrinkage Compensation」では、仕上がり寸法の「縦横」の誤差を比率で調整する機能のようです。
「容量を調整する」を「はい」にすると、凸形状、凹形状の調整ができます。
設定値は、片側入力なのか両側入力なのか？
また、はたしてきちんと補正してくれるのか？
スライス後、G-Codeで確認してみます。
上の確認モデル１：外径□２０mm、内径□10mmをスライスして確認してみます。

補正なし

まずは、パス幅0.4mm、補正なしで、スライしてみます。

内径は□10mmなので、パス幅0.4mmを半分を考慮して、X,Yとも「5.2mm」になってます。
外径は□20ｍｍ、なので、パス幅半分を考慮して、やはり同様にX,Y共に「9.8」になってます。
パス幅の中心をノズルが通り、パス幅の半分が仕上がり側面になるようなパス計算のようです。

Y Compensation = 1%

次に、Yのみ「1%」補正してみます。
「1%」なので、内径□10mmは、Yのみ10.1mm、外径□20mmは、Yのみ、20.2mmになるはずです

ちゃんと、補正されているのがわかります。

内側のみ補正：「内部補償＝0.1mm」

内部補償と言う言葉がちょっとへんですが、凹側面の補正の事だと思います。
設定値0.1mmが半径補正値なのか？両側補正値なのか？も確認してみます。

内側のみ、±5.25になっていますから、両側で0.1mm補正されているのがわかります。
外側は、補正されていなくて、正常ですね。

プリント結果に合わせた補正

これで、「Material Shrinkage Compensation」と「容量を調整」の補正値の入れ方がわかりました
テスト印刷結果から、内側がネライより径で0.2mm小さく、X,Yの比率では、Y方向を1%小さくしてみます。

補正後のプリント結果は、補正が効いているを確認できました。

確認モデル２

補正値を設定し、もう少し複雑なモデルを印刷してみます。

測定した結果は、まあまあでした。
測定機器がノギスと言う事もありますし、面精度がガタガタなので、正確な測定はできません
まぁ、幅で0.1ｍｍには、入っていると思います。
ただ、形状の製作精度の検証は、幅だけでは不十分で、位置関係の測定も必要ですが、自宅ではできません。
そこで、反対側を作成し、ある程度のクリアランス（隙間）を設けて、組み付けてみようと思います。

相手側をモデリング

相手側は、ブロック素材から、ブーリアン演算で引き算させる事で簡単にできます
さらに、クリアランス（隙間）を付けるため、Fusion360では「プレスプル」と呼ばれている機能で幅を修正します。

片側0.1mmのクリアランスに設定しました。
この２つのパーツが組み合わされれば、クリアランス片側0.1mmと言っても、
数か所の凸凹形状や各部分の位置関係がすべてその範囲以内で出来ていると言うことなので
それ以上の精度だと言えます。

二部品結合

さて、二つの部品を結合してみましょう！

最初ちょっと硬かったですが、いい感じに結合できました。
はずすのも結構大変です、スクレーパーで少しずつ広げていって、どうにか外れました。
この積層痕の悪い面精度でも、入ったので、面精度が良ければ、もう少し簡単に挿入できると思います。
片側0.1mmよりも、確実にいい精度でプリント出来ていると思います。
今回の積層条件では、硬い締結の場合には、「片側0.10」のクリアランス。
もう少しゆるく取り外ししたい場合には、「片側0.15」ぐらいが、いいように思います。

CAD/CAMにもほしい機能

工作機械でも、メカ的にミクロン精度に保つ事は非常に大変でコストもかかります。
最終的には制御機内でソフト的に補正を行っている工作機械がほとんどだと思います。
ただ今回おこなった補正は、「FlashPrint 5」スライサーの機能を使いました。
工作機械的には、CAMの部分での補正です。
輪郭全周の一定補正であれば、工具径補正で調整可能ですが、X軸、Y軸の比率が公差を超える可能性がある場合、
現状ではCADで加工モデル形状を編集・調整するしかありません。
特に２D輪郭の場合は結構やっかいです。
CAMにもこのような、X軸、Y軸の比率を自動調整してくれる機能があれば、便利ですね。

FLASHFORGE ３Dプリンタスライサー FlashPrint の 「.GX」 ファイル編集ソフト

FlashForge製３Dプリンタ専用スライサー「FlashPrint」は「.GX」拡張子のG-Code を生成します。G-Codeファイルはメモ帳やエディタなどで読めるように、アスキー（テキスト）形式が一般的ですがFlashPrintの「.GX」は、ファイル上部に、バイナリ文字が含まれていて正常な...

www.kazuban.com

2022.12.04

データによってはエディタ領域にうまく読み込めない現象が起きていました。

ヘッダー部分、切り分け方法ミス

調べてみると、テキスト形式のデータでないと、エディタ表示できないため
バイバリー形式のヘッダ部分を切り離す処理をしていますが、ヘッダの最後の文字の判断を間違えていました。
ヘッダー部分には、プリンタタッチパネルに画像が表示できるように、データ内に画像のデータも収めているようです。
したがって、画像によって、ヘッダ部分の長さや、文字も変わってきます。
筆者が、ヘッダー部の最後と判断する方法がうまくいっていない場合があったようです。
今回の更新では、ヘッダー終了後のG-Codeデータは先頭が、下記コードを想定しています

;machine_type:

したがって、このコードが先頭にない場合は、「Header Error」になります。
「EditorForFlashPrint5.exe」では、データ作成する時に、必ずこの先頭コードは確認しています。
現状では、手持ちの「.GX」データで、検証して問題は起きていませんが、
環境によっては今後も同じような現象がおきるかもしれません。

ヘッダのデータ容量が大きい場合の処置

ヘッダ部分には、画像データが挿入されていそうなので、画像によってはかなり大きくなる場合があるようです。
ヘッダ部分は、プログラム的に、静的文字配列を使っているため、予想よりも大きな文字数になった場合、うまく動作しなくなってしまいます。
現状では、想定文字数よりも、大きくなった場合には、メッセージを出し、強制終了させています。

G-Codeデータ容量が大きい場合の読み込み進捗表示

Adventurer3での使用で開発したので、それほどデータ容量は気にしていませんでしたが
私の環境では、１０MBぐらいのデータになると、かなり読み込みが遅くなります。
読み込み時には、G-CodeデータのZ指令（高さ）なども一行ずつ確認していますが
筆者のレベルでは、そういった処理方法のプログラムがあまり高速にできていません
遅い場合のストレスとなるべく解消するため、読み込み状態を表示するようにしました。

G-Codeデータ容量が大きい場合の検索や編集

読み込みが終わると、任意文字や高さの検索やG-Code編集を行うと思いますが
この処理もデータが大きい場合、異様に遅くなる場合があります。
こちらも、C++Builderの「memoコンポーネント」を使っていますが、その処理方法がへたくそなのかもしれません。

EditorForFlashPrint5 Ver1.7 公開

いくつかのデータで検証した結果では、５Mb程度のデータであれば、それほど気にならないと思います。
それ以上になってくると、レスポンスがきになるかもしれません。
ただし、筆者が検証した限りでは、遅いだけで、データ的には正常です。

フリーソフトページから、ダウンロードできます。
ver1.7 になります。

変数

C言語など、プログラミング言語でコードを書く場合、悩ましいのが「変数の名前」です。
変数名は、後日読み直す時など、あまり単純な名前だけにすると、この変数は何だったっケ？
と、変数の分析からから始める必要があり、分かりづらいコードになってしまいます。
プログラミングの変数名は、使える文字（言語によっては漢字も）や文字数の制限も少なく
自由度があるので悩んでしまいます。
しかしカスタムマクロは「#」+「数字」なので、悩みは少ないかもしれませんが
逆に変数名が単純なこの言語仕様から、結局分かりづらいコードになってしまいます。
さらに数字の範囲で、ローカル変数、コモン変数、システム変数と性質が変わるので
ゴチャゴチャです。

とりあえず、ローカル変数（#1～#33）を使おう

ローカル変数は、プログラムが異なる場合、同じ変数でも、それぞれ別の意味として作用しますが
コモン変数「#100～」は同じ変数として扱われます、
したがって、マクロプログラムのなかで、別マクロを呼び出した場合、そのマクロによって
書き換えられてしまう危険性があります。
特に必要性がない場合には、ローカル変数を使用した方が無難です。

変数宣言

C言語などは、これから「使う変数名」を必ず変数宣言をする必要がありますが
必須でない言語も多くあります。
カスタムマクロも

#1=50.0
G00 X#1

このように、いきなり変数を使用する事ができます。
ただし、長く複雑になるにつれて、変数の役目が分からなくなってきます。
プログラム上部で、使用する変数を初期化しておいたりコメントとして、
明示しておく事でこのマクロではどんな目的で、どの変数を使っているのか、
分かりやすくなります

(—————————)
#10=#0 (Tool Length)
#11=#0 (T)
#12=#0 (V)
#13=#0 (f)
#14=#0 (SP)
#15=#0 (F)
(————————–)

こんな感じです。ここでは、使用する変数を「#0」で初期化しています。
「#0」は「0（ゼロ）」ではありません。「空」です。
コントローラ側でマクロ参照すると、何も入っていない状態になります。
特に必須ではないですが、使う予定の番号が分かり、逆に使っていない番号もわかります。
さらに「空」にしておいたほうが、思わぬミスの防止になるかもしれません。

コメント

（　）で囲む事で、制御機が無視する文字を入力できます。
一般的には、その変数や箇所の用途が分かりやすいように「コメント」を付加します。
制御機は無視するので、コメントの有無は機械動作に影響ありませんが
他人のマクロや自作のものでも、後日読み直す場合に、理解しやすくなります。
重要な変数には、必ずコメントを付加しましょう！
ただ、制御機によっては、「漢字」を受け付けません。
英語にするか？、ローマ字にするか？読む人が分かりやすいコメントを考えてください。
ちなみに、ソディックは漢字が使えるので、かなり分かりやすいです。

ユーザー設定パラメータ

カスタムマクロは、ユーザーがパラメータを変更する事で、類似形状定義や面倒な計算を
自動的に定義させCAMを使用しなくても汎用的な加工データを作成する事ができます。

ユーザー定義変数

利用するユーザーが定義するパラメータは、変数を利用しますから、
この変数は分かりやすいように、プログラム上部にコメント付きで書くようにします。
利用ユーザーは、この変数を変更するだけで、希望の加工データが作成できるようにしておきます。

G90G00G17G40G80G49
(++++++++++++++++++++)
#1=54. (WORK ORIGIN)
#2=5.7 (Hole Dia)
#3=-16.0 (Drill Shoulder Heigth)
#4=0.0 (Surface Coordinat)
#5=50.0 (Initial Point)
#6=5.0 (R Point)
#7=3.0 (Q )
#8=8. (Coolant )
(+++++++++++++++++++)

・　
・

このように、上部にまとめておき、利用者の編集部分は、コメント文で区切りをいれ
分かりやすくしておきます。

マクロ仕様の説明

プログラム最上部には、そのマクロの説明や、バージョン、作成日、作成者など
記入しておくと、管理しやすくなります。

%
O1234
(+++++++++++++++++++++++++++++++)
( Drill Program Ver1.0 )
( 2023-02-18 By Kazuban)
(++++++++++++++++++++++++++++++)

ファイル名仕様

コントローラによっては、「O番号」でなく、ファイル名が使用できる機械もあります。

%
O1234
・
・

↓

%
<DRILL.NC>
・
・

このように、O番号でなく、「 <　> 」　でファイル名を囲みます。
呼び出しは、P「番号」でなく同様に「 <　>」で呼び出します。
あまり一般的ではないので、もしかすると、調べてみるとあなたの機種も可能かもしれません。
ちなみに、ソディックは「 (　) 」になります。

M98<DRILL.NC>

G65<DRILL.NC>A5.7B2

例えば、「センター」「下穴」「面取り」「タップ」と複数のマクロを呼び出すプログラムの場合
O番号で呼び出すよりも、分かりやすく、管理も楽になります。

マクロ呼び出し（G65、G66）の引き数

マクロ呼び出しでマクロプログラムを呼び出す場合、引数を指定して変数を渡す事ができます。
したがって、上の例のように、プログラムを開いて変数を編集するのではなく
呼び出しの引き数で変数を設定する事ができます。
これは、便利なようですが、引数のワードに対応している変数番号がバラバラで
非常に分かりづらく間違いやすいです。

引数対応変数のコメントの活用

G65などマクロ呼び出しの前に、引数対応変数をコメントにしておくと、
プログラムする場合も、編集する場合も、わかりやすくミスも防げます。

G90G00G17G40G80G49
(++++++++++++++++++++)
#1=54. (WORK ORIGIN)
#2=5.7 (Drill Dia)
#3=-16.0 (Drill Shoulder Heigth)
#4=0.0 (Surface Coordinat)
#5=50.0 (Initial Point)
#6=5.0 (R Point)
#7=3.0 (Q )
#8=8. (Coolant )
(+++++++++++++++++++)
・
・
(++++ Drill +++++++++)
(A:#1=#2_Drill Dia)
(B:#2=#3_Drill Shoulder Depth)
(C:#3=#4_Surface Coordinat)
(I:#4=#5_Initial Point)
(Q:#17=#7_Q)
(R:#18=#6_R Point)
(—- argument table ——)
(A:#1 B:#2 C:#3 I:#4 J:#5 K:#6 D:#7 E:#8 F:#9 H:#11 M:#13)
(Q:#17 R:#18 S:#19 T:#20 U:#21 V:#22 W:#23 X:#24 Y:#25 Z:#26)
(—— Drill Macro Read ——)
G65 P1234 A[#2] B[#3] C[#4] I[#5] Q[#7] R[#6]

マクロで使用するメインのユーザー定義の変数は、「#2」～「#7」なのに対して、
呼び出されるドリルマクロ「O1234」は、「#1、#2、#3、#4、#17、#18」
の変数を使い、プログラムします。
間違えろと言わんばかりですが、コメント付加で少しはミスも防げます。
Q、Rアドレスは、一例として固定サイクルに似せただけで、特に必須ではありません。

モーダル情報変更の注意点

「G91は意外と便利」という記事で少しふれましたが、
複数個所に輪郭加工させるマクロを作成する場合、「G91」と「G66」を使うと結構便利です。
こちらで紹介しているサブプログラムをマクロ化すれば、真円切削するサイクルが作れます。
ところが、このようなモーダル情報をメインから呼び出されるマクロ内で
変更する場合には注意が必要です。

マクロ内でのG90,G91指令は注意

メインプロの座標系指令（G90、G91）をマクロ内で変更した場合には注意が必要です。
マクロから戻った時点で、座標指令が変わってしまっていると、
メインプロだけ見ると、マクロ読み込み前の指令が目立つので、マクロ後の状態も
その状態（モーダル）だと思い込みやすいので大変危険です。
マクロでは、必ず元に戻すようなコードを書きましょう。
これは、座標系指令だけでなく、加工条件や主軸工具などのモーダル情報も同様です。
例えば、タッチプローブで測定させるマクロを利用する場合で、
そのマクロが内部でプローブと交換する仕様で測定後元の工具に戻さなかった場合、
マクロの呼び出し前と後で主軸工具が違う事になります。
モーダル情報は、マクロ終了時には、元に戻しておくほうが思わぬミスを回避できます。
X、Yなども、モーダルなので、前の行から動作のない軸は省略する場合もよくあります
これが、マクロを挟んだ場合、思わぬ位置誤動作になる事もあります。
X、Y、Z、など軸指令は、省略しないほうが安全ですし
マクロプログラムでは終了時に、主軸を安全位置へ退避させておくとより安全です。

モーダル情報を得るシステム変数

モーダル情報は、システム変数の「#4001～」「#4100～」で取り出す事ができます。
制御機によっても違うと思うので、使用機械の取説の確認は必要ですが、
マクロ作成で利用できそうなシステム変数は下記になります。

★モーダル情報
　#4001～#4030
　　下二桁はＧコードグループ番号
　　グループ01 : G00,G01,G02,G03,G04
　　グループ03 : G90,G91
　　グループ14 : G54,G55,G56,G57,G58,G59

　#4107 : Ｄコード
　#4109 : Ｆコード
　#4111 : Ｈコード
　#4113 : Ｍコード
　#4114 : シーケンス番号
　#4119 : Ｓコード
　#4120 : Ｔコード

★現在位置情報
　#5021～#5024 （X、Y、Z、４軸：機械座標系）
　#5041～#5044 （X、Y、Z、４軸：ワーク座標系）

G90、G91 の情報は、「#4003」
現在のワーク座標系での、Ｚ軸座標は「#5043」
T番号は、「#4120」 から取り出せます。

マクロの最初で取り出し、終了前で戻す

まったく、モーダル情報を扱わないマクロの場合とか、メインプロ側から呼び出す前後で
確実に処理する場合には不要だと思いますが、余裕があればやっておいたほうが安心です。

#1=#4003 (G91orG90)
#2=#4120 (T No)
・・
T03 M06
G91
・・
・・
G[#1]
T[#2] M06
M99
%

サンプルデータ

上記の事を考慮して、簡単なマクロサンプルを作ってみます。
このマクロは、単純にZ方向に切込み、径補正で真円加工し、
イニシャル点に戻るだけのマクロです。
ただし、段差等は考慮せず、加工上面がZ=0としています。
G66モーダル呼び出しを使用する事で、加工位置データも別サブプログラムにできます。
位置データを別プログラムにしておくと、同じ位置で別工程加工を行う場合に便利です。
例えば、同じ箇所に「ドリル」「穴荒加工」「穴仕上」「面取り」の工程がある場合
穴加工位置指令は、すべて同じデータを指定できます。

メインプログラム

%
O1234
(++++++++++++++++++++)
( Circle Milling Main Ver1.0 )
( 2023-02-18 By Kazuban)
(++++++++++++++++++++)
#1=54.(WORK ORIGIN)
#2=10.0(Ciecle Dia)
#3=-5.0(Depth)
#4=300.(Feed)
#5=100.(Depth-Feed)
#6=30.0(Initial-Point)
#7=5.0(R-Point)
#8=1.(D)
(++++++++++++++++++++)
#10=3.(T)
#11=#10(H)
#12=3500.(SP)
(++++++++++++++++++++)
G90G00G17G40G80G49
(++++++++++++++++++++)
N0001
G#1
T#10
M06
G90G00X0Y0
G43Z#6H#11
M01
( START )
G90G00
Z[#6]
S#12M03
M08
(++++++++++++++++++)
(A:#1 B:#2 C:#3 I:#4 J:#5 K:#6 D:#7 E:#8 F:#9 H:#11 M:#13)
(Q:#17 R:#18 S:#19 T:#20 U:#21 V:#22 W:#23 X:#24 Y:#25 Z:#26)
(++++++++++++++++++)
(A:#1=#2_Ciecle Dia)
(B:#2=#3_Depth)
(C:#3=#4_Feed)
(I:#4=#5_Depth-Feed)
(J:#5=#6_Initial-Point)
(K:#6=#7_R-Point)
(D:#7=#8_D)
(++++++++++++++++++)
G66P0101A[#2]B[#3]C[#4]I[#5]J[#6]K[#7]D[#8]
M98P1000(Position data)
G67
G90G00Z[#6]
M09
G91G28Z0
G91G49Z0
G90M05
( END )
M30
%

マクロ・サブプログラム

%
O0101
(++++++++++++++++++++)
( Circle Milling Macro Ver1.0 )
( 2023-02-18 By Kazuban)
(++++++++++++++++++++)
(————————)
(A:#1=#2_Ciecle Dia)
(B:#2=#3_Depth)
(C:#3=#4_Feed)
(I:#4=#5_Depth-Feed)
(J:#5=#6_Initial-Point)
(K:#6=#7_R-Point)
(D:#7=#8_D)
(————————)
#10=[#1/2](Circle_Radius)
#11=[#6-#5](To R-Point)
#12=[#2-#6](To Depth)
(————————)
#27=#4003
(————————)
G90 G00
Z[#5]
G91
Z[#11]
G01 Z[#12] F[#4]
G01 G41 X[#10] Y0.0 D[#7] F[#3]
G03 X[-#1] Y0.0 I[-#10]
G03 X[#1] Y0.0 I[#10]
G01 G40 X[-#10] Y0.0
G90 G00 Z[#5]
G[#27]
M99
%

加工位置データ

%
O1000
(++++++++++++++++++++)
( Hole Position )
(++++++++++++++++++++)
X50.Y50.
X50.Y-50.
X-50.Y-50.
X-50.Y50.
M99
%

まとめ

カスタムマクロを書く上においての、注意点や気にしたほうがいい点などまとめてみました。
メインプロだけの場合には、メインだけ確認すればいいですが、サブプロを呼び出す形式の場合
サブプロ内でのモーダル値の変更は、十分気を付ける必要があります。
マクロプログラムは、変数によりパラメータ化できるので、便利ではありますが「#」の羅列で
より分かりづらくなります。
使用する変数をまとめたり、コメント文をうまく使い、わかりやすくする工夫が必要です。

FlashForge のG-Codeを覗いてみる

NC屋としては、３DプリンタのG-Codeにも興味があるので、FlashPrint5が吐き出した、Adventurer3用データを覗いてみました。前回、FlashPrint5 の「.GX」拡張子のG-Codeを編集できるソフトを公開しました。このソフトで、閲覧や編集が可能になります。一般的なエディタ...

www.kazuban.com

2023.01.16

FLASHFORGE ３Dプリンタスライサー FlashPrint の 「.GX」 ファイル編集ソフト

FlashForge製３Dプリンタ専用スライサー「FlashPrint」は「.GX」拡張子のG-Code を生成します。G-Codeファイルはメモ帳やエディタなどで読めるように、アスキー（テキスト）形式が一般的ですがFlashPrintの「.GX」は、ファイル上部に、バイナリ文字が含まれていて正常な...

www.kazuban.com

2022.12.04

今回は、実際にG-Code を手打ちしてみたいと、思います。

ランニング運転用G-Code

一般的に機械は、ランニング（暖気）運転を行ったほうが良いとされています。
特に、工作機械の場合には、暖機運転で加工精度が変化しますから必須です。
家庭用３Dプリンタの場合には、その重要性は少ないと思いますが、
メンテナンスなどで、掃除やグリスアップした時など、可動範囲全体で動作させたほうが
いいと思います。
手動操作で移動させる事は可能ですが、G-Codeで自動ランニング運転データを
作成してみたいと思います。

Adventurer3用のG-Code

前回、FlashPrint5が出力した、G-Code を分析してみました。
ヘッダー部分では、ヘッドの選択や温度設定、ファンの可動などの指令が書かれています。
ランニング運転には、ほとんど必要なさそうです。
可動範囲は、150×150×150mmなので、この範囲で動作するような「G1（直線移動）」コード
を羅列すればよさそうです。
ただし、「.g」ファイルの場合には問題ありませんでしたが、「.gx」ファイルの場合には、
「M118」でこのプログラムの動作範囲を指定しないとエラーになりました。

作成方法

１．まず適当なモデル「20mm_Box」などで、FlashPrint5でG-Codeを作成します。
２．「EditorForFlashPrint5」に読み込みと、編集が可能になります。
３．不要なコードを削除し、必要なコードを追加します。
４．「.g」の場合なら、通常のエディタで作成可能ですが、プリンタ本体のタッチパネルの
　ファイルリストにアイコンが表示されません。
　「１．の適当なモデル」をデータのイメージしやすいモデルでダミーのデータを作成すれば、
　アイコンは表示できますが、ちょっと面倒ですね。
５．ランニング運転用のコードは下記のようにしました。

M118 X75.0 Y75.0 Z150.0 T0
G90
G1 Z50.000 F1000
G1 X75.0 Y-75.0 Z150.0 F4800
G1 X-75.0 Y75.0 Z10.0
G1 X-75.0 Y-75.0 Z150.0
G1 X75.0 Y75.0 Z10.0
G1 X75.0 Y-75.0 Z150.0
G1 X-75.0 Y-75.0 Z10.0
G1 X-75.0 Y75.0 Z150.0
G1 X0 Y0 Z50.0
G1 X75.0 Y-75.0 Z150.0
;end gcode
G91
M18

動作風景（倍速です）

ビルドプレートのレベル（水平）確認用G-Code

ビルドプレートに、線をプリントする事で、水平を確認するデータを作成してみます。
今回はランニング運転と違い、プリントさせるので、ヘッド温度や、フィラメント押し出し
などのコードも必要となります。
温度設定などは、「20mm_Box」などのデータを参考にすればいいと思いますが
押し出し量「E」の設定を算出しなければいけません。
FlashPrint5 でサンプルの「20mm_Box」でデータを作成し、分析してみます。
プレ押し出しは「有り」、積層ピッチ「0.2」、モデル一層目の厚み「0.2」の設定で
スライスしてみます。

プレ押し出し

FlashPrintに、プレ押し出しの厚みなどの設定項目は見当たらないので、
詳細はわかりませんがG-Code を見る限りでは、「Z0.2」で動いています。
ただ、プレ押し出し幅や厚みは、通常プリントよりも大きめになりますね。
通常印刷よりも、押し出し量は、多く設定されていると思われます。
G-Codeの「:pre-extrude」の部分を覗いてみます。

・
M108 T0
G1 X15.00 Y-15.00 F4800
;preExtrude:0.20
M106
G1 Z.200 F420
;structure:pre-extrude
G1 X15.00 Y-15.00 F4800
G1 X15.00 Y15.00 E4.3504 F1200
G1 X-15.00 Y15.00 E8.7009
G1 X-15.00 Y-15.00 E13.0513
G1 X15.00 Y-15.00 E17.4017
・
・

このデータから、「E」押し出し量を求めてみます

移動量　押し出し量
Y30.0 …… E4.3504
X30.0 …… E8.7009 – E4.3504 = 4.3505
Y30.0 …… E13.0513 – E8.7009 = 4.3504
X30.0 …… E17.4017 – E13.0513 = 4.3504

全て軸移動量　30mm で、E4.35mmの押し出しになってます。
1mmで換算すると、0.145mm

この結果から、プレ押し出し量は、「1mm」の長さで「0.145mm」押し出しているようです。

インナーシェル

次にインナーシェルの部分になります。高さは、「Z0.2」です。
このデータが、通常プリントの押し出し量になるかと思います

・
・
;layer:0.20
G1 E12.4017 F1500
G1 Z.200 F420
G1 X9.40 Y-9.40 F4200
G1 E17.4017 F1500
;structure:shell-inner
G1 X9.40 Y-9.40 F4200
G1 X9.40 Y.60 E17.7642 F600
G1 X9.40 Y9.40 E18.0833
G1 X8.20 Y9.40 E18.1268
・
・

同様に、このデータから、「E」押し出し量を求めてみます

Y9.40+0.60=10 … E17.7642-E17.4017=0.3625
Y9.40-0.60=8.80 … E18.0833-E17.7642=0.3191
X9.40-8.20=1.2 … E18.1268-E18.0833=0.0435

10mmで0.3625、8.8mmで0.3191、1.2mmで0.0435
1mmで換算すると、0.036mm　になります。

「E」押し出し量の求め方

さて、「E」はどうやって求めるんだろう？
と、検索してみたら、ありました。やっぱりネットの時代はすごいです。
このサイトの計算式で計算すると、「0.2mm」の積層高さで「1mm」プリントする場合
E = 0.033mm　になります。
上記FlashPrint5 のデータとほぼ同じです。誤差は若干の調整と考えます。
これで、「0.2mm」の積層高さで「1mm」引っ張る場合「E=0.036」の裏付けが取れました。
この値をもとに、G-Codeを書いて行こうと思います。

ポイント

・温度設定などの、開始停止コードは、サンプルデータを参考にしますが、
　ビルドプレートの温度は、レスポンスを考慮して「30°」にします。
・ヘッドに残っているフィラメントの状態が分からないので、プレ押し出しする事にします。
・確認プリントの積層高さは、「0.2mm」にします。
・次の輪郭への移動時は、フィラメントは「5mm」巻き戻し、「Z0.5mm」で移動させます。
・移動後、戻したフィラメントは、もとへ戻します。
・プレ押し出し直後の最初のみ、気持ち（1mm）巻き戻った状態に設定しています。
・動作輪郭は、最大幅「150mm」ではじめて、内側へ「5mm～10mm」づつオフセットした
　四角形の輪郭にします。
・「E値」は、絶対値での定義では、面倒なので「G92」でリセットしながらとします。
　NC機械では、最近は「G92」の使用は少なくなってきましたが、この場合には便利です。
・最後は、垂れ流し防止で、「2.5mm」巻き戻して終了とします。

こんな感じで、G-Code 書きます。

M118 X75.00 Y75.00 Z0.30 T0
M140 S30 T0
M104 S210 T0
M104 S0 T1
M107
G90
G28
M132 X Y Z A B
G1 Z50.000 F420
G161 X Y F3300
M7 T0
M6 T0
M651 S255
;layer_count: 1
M108 T0
G1 X-10.00 Y-10.00 F4800
;preExtrude:0.20
M106
G1 Z.200 F420
;structure:pre-extrude
G92 E0
G1 X10.00 Y-10.00 E2.9 F600
G92 E0
G1 X10.00 Y10.00 E2.9
G92 E0
G1 X-10.00 Y10.00 E2.9
G92 E0
G1 X-10.00 Y-10.00 E2.9
;—– Move
G92 E0
G1 E-5.0 F1500
G1 Z0.5
G1 X-75.00 Y75.00 F4200
G1 E-1.0 F1500
G1 Z0.2 F420
;—– Width150.0
G1 X-75.00 Y75.00 F4200
G92 E0
G1 X75.00 Y75.00 E5.4 F600
G92 E0
G1 X75.00 Y-75.00 E5.4
G92 E0
G1 X-75.00 Y-75.00 E5.4
G92 E0
G1 X-75.00 Y75.00 E5.4
;—– Move
G92 E0
G1 E-5.0 F1500
G1 Z0.5 F500
G1 X-70.00 Y70.00 F4200
G1 E0 F1500
G1 Z0.2 F420
;—– Width140.0
G1 X-70.00 Y70.00 F4200
G92 E0
G1 X70.00 Y70.00 E5.04 F600
G92 E0
G1 X70.00 Y-70.00 E5.04
G92 E0
G1 X-70.00 Y-70.00 E5.04
G92 E0
G1 X-70.00 Y70.00 E5.04
;—– Move
G92 E0
G1 E-5.0 F1500
G1 Z0.5 F500
G1 X-65.00 Y65.00 F4200
G1 E0 F1500
G1 Z0.2 F420
・
・
・
;—– Move
G92 E0
G1 E-5.0 F1500
G1 Z0.5 F500
G1 X-20.00 Y20.00 F4200
G1 E0 F1500
G1 Z0.2 F420
;—– Width40.0
G1 X-20.00 Y20.00 F4200
G92 E0
G1 X20.00 Y20.00 E1.44 F600
G92 E0
G1 X20.00 Y-20.00 E1.44
G92 E0
G1 X-20.00 Y-20.00 E1.44
G92 E0
G1 X-20.00 Y20.00 E1.44
;—- End
M107
G1 Z0.5 F1500
G92 E0
G1 E-5.0
G1 Z10.0 F500
G1 Z50.0 F4000
G1 X0 Y0
G1 E-2.5 F1500
;end gcode
M104 S0 T0
M140 S0 T0
G162 Z F1800
G28 X Y
M132 X Y A B
M652
G91
M18

動作風景（×４倍速です）

うちのガラスプレートには、張り付きが弱いため、マスキングテープを張ってます。
また、四角輪郭の始まり付近で、剥がれる事もありました。
場合によっては、送り速度の調整や、「スティックのり」などを試してみてください。

まとめ

NC工作機械では、G-Code手打ちで機械を動かす事はよくありますが、３Ｄプリンタの場合は
ほとんどないと思います。
カスタムマクロのような、変数（＃）などが使用できると、少しは使い道があるかもしれませんね
まぁ、手打ちで機械が動くと言うのは、楽しいものです。

今回紹介のG-Code「.gx」ファイル、「Running.gx」と「TableLevelCheck.gx」は
下記からダウンロードできますので興味あれば、使ってみてください。

３Dプリンタ、G-Code 資料

とりあえず、ググってみました。
一般的な「Gコード」「Mコード」は下記で参考になりそうです

http://replicat.org/gcodes
http://replicat.org/mcodes

基本的なGコードは、工作機械と若干の互換もあるみたいですね

• G0 – Rapid Motion
• G1 – Coordinated Motion
• G2 – Arc – Clockwise
• G3 – Arc – Counter Clockwise
• G4 – Dwell
• G20 – Inches as units
• G21 – Millimeters as units
• G28 – Home given Axes to maximum
• G30 – Go Home via Intermediate Point (not implemented)
• G53 – Set absolute coordinate system
• G90 – Absolute Positioning
• G91 – Relative Positioning
• G92 – Define current position on axes

Mコードは、工作機械もそうですが互換性は少ないです
終了や工具（ヘッド）交換ぐらいでしょうかね？
ただ、FlashPrint5 では、終了コードは、「M18」のようです。

• M2 End program
• M6 Tool change. This code waits until the toolhead is ready before proceeding. This is often used to wait for a toolhead to reach the its set temperature before beginning a print. ReplicatorG also supports giving a timeout with M6 P<secs>.
• M30 program rewind

こんなページもありましたが、やはり内容はだいぶ違いますね。
FlashForge 用の資料も見つけました
slic3r-configs/Flashforge Gcode protocol(open).md at master · minsk-hackerspace/slic3r-configs · GitHub
https://googlegroups.com/group/flashforge/attach/46dc32d7dc6079ae/FlashForge%20Gcode%20Protocol(open).pdf?part=0.1

参考にしやすいように、ここに書かれているFlashForge仕様をまとめてみました。

• G1　：直線補間｜X軸｜Y軸｜Z軸｜E押出し長｜F送り
• G4　：一時停止時間設定｜P（ms）｜S（s）
• G28　：ホーム位置｜X軸｜Y軸｜Z軸｜なし：全軸
• G90　：絶対座標指令
• G91　：相対座標指示
• G92　：現在位置座標系設定
• M6　：ヘッド選択｜T0（右ヘッド）｜T1（左ヘッド）｜S（待ち時間：初期値600s）
• M7 　：プラットフォーム温度待ち｜S（待ち時間：初期値600s）
• M17　：ステッピングモータを有効｜X軸｜Y軸｜Z軸｜A軸｜B軸｜E（A&B）｜なし：全軸
• M18　：ステッピングモータ無効｜X軸｜Y軸｜Z軸｜A軸｜B軸｜E（A&B）｜なし：全軸
• M104　：ヘッド温度設定｜S（°C）｜T0 or T1（右・左ヘッド）
• M105：エクストルーダーとプラットフォーム温度確認
• M106　：冷却ファン有効
• M107　：冷却ファン無効
• M108　：ヘッド交換｜T0 or T1（右・左ヘッド）
• M112：緊急停止
• M114：現在位置取得
• M115：機械情報取得
• M119：マシンの状態確認
• M140　：プラットフォーム温度設定｜S（°C）
• M132　：メモリからホームポジション位置を読み込む｜X軸｜Y軸｜Z軸｜A軸｜B軸
• M907　：ステッパー電流値を設定｜X軸｜Y軸｜Z軸｜A軸｜B軸

FlashPrint5 が作成したG-Code

FlashPrint5に標準で用意されている、サンプルの「20mm_Box」をスライスさせてみます。
作成された、「20mm_Box.gx」の内容をみてみましょう。
通常のエディタでも、最上部部分が文字化けしますが、読めない事はないです。
前回公開した、「EditorForFlashPrint5.exe」では、閲覧、編集、保存が可能です。
もし、興味あれば、ダウンロードしてみてください。

全体の構造

先頭の「;」はコメント文です。
まず最初の数行で、スライス条件が、コメント文でまとめられています。

スライス条件情報の後、ヘッダー部分で機械をプリント可能状態へ準備運転させています。
その後、実際のプリント部分ですが、動作指示は全て「G1：直線補間」で定義されていますね
工作機械と違い、G2,G3 の円弧補間は、あまり必要ないのかもしれませんね。
最後に、初期状態へ戻して終了です。

コメント文でスライス条件掲示

データの最初に、スライス条件が、まとめられています。
参照する人は少ないかもしれませんが、後日条件を確認したい場合など
G-Codeデータだけで確認できそうです。
条件を突き詰めている人には、重宝するかもしれません。

;machine_type: Adventurer 3 Series
;right_extruder_material: PLA
;right_extruder_material_density: 1.24
;filament_diameter0: 1.75
;right_extruder_temperature: 210
;layer_height: 0.18
・
・

データ構造を分析

M118 　：　正確にはわかっていません。後ほどわかる範囲で説明します。
M140 S50 T0　：　プラットフォーム温度設定　S（°C）
M104 S215 T0　：　右（T0）ヘッド温度設定　S（°C）
M104 S0 T1　：　左ヘッド温度設定ですが、シングルヘッドの場合不要
M107　：　冷却ファンＯＦＦ
G90　：　絶対座標指令
G28　：　全軸ホーム位置へ移動
M132 X Y Z A B 　：　メモリから原点位置を読み込む
G1 Z50.000 F420　：　Z50.000 へ420mm/sのスピードで移動
G161 X Y F3300　：　X、Y軸の最小点へ移動
M7 T0　：　プラットフォーム温度待ち
M6 T0　：　右ヘッド（T0）ヘッド選択
M651 S255　：　筐体ファンON
;layer_count: 60
M108 T0　：　ヘッド交換
G1 X11.85 Y-16.35 F4800　：　X11.85 Y-16.35 へF4800で移動
;preExtrude:0.20
M106　：　冷却ファンＯＮ
G1 Z.200 F420　：　Z0.200 へF420で移動
;structure:pre-extrude　———– プリント開始 ———————
G1 X11.85 Y-16.35 F4800
G1 X13.55 Y-15.58 E.2706 F1200　：　E指令：フィラメント押し出し量mm
G1 X14.97 Y-14.37 E.5412
・
・
G1 X-9.06 Y8.48 E211.5981
G1 X-8.48 Y9.06 E211.6248
G1 X-9.06 Y9.05 E211.6438
M107　：　冷却ファンＯＦＦ
G1 E209.1438 F1500　：　フィラメント引き戻し「211.6438 – 209.1438 = 2.5mm」
G1 Z11.650 F420
G1 X10.94 Y9.05 F6000
;end gcode　———– プリント終了 ———————
M104 S0 T0　：　右（T0）ヘッド温度キャンセル
M140 S0 T0　：　プラットフォーム温度キャンセル
G162 Z F1800　：　Z軸の最大点に移動
G28 X Y　：　X、Y軸ホーム位置へ移動
M132 X Y A B 　：　メモリから原点位置を読み込む
M652　：　筐体ファンOＦＦ
G91　：相対座標指示
M18　：ステッピングモータ無効

M118

「M118」はよくわかりません。検索しても適格な説明はみつかりませんでしたが
ラフトなども含めた造形範囲を定義しているような感じです。
なんとなく分かったのは、プラットフォーム中心からの、上下（Y軸）左右（X軸）高さ（Z軸）
の最大値のようです。
一軸に対して、「＋－」の座標的な意味はないようで、数値的に大きい方で定義するようです。
検証として、標準サンプルの「20mm-Box」を「センターに配置」して、
「ラフトなし、プレ押し出しなし」の他は標準条件でスライスしてみました。

M118 X10.94 Y10.00 Z10.10 T0

となりました、「X10.00」を予想していましたが、「X10.94」でした。
ただこれは、プリントのスタート位置をスライサーが若干調整しているのでは？
と勝手に解釈し無視する事にします。
次に、モデルを「X+10.0」「Y+10.0」に移動して、同様にスライスします。

M118 X20.94 Y20.00 Z10.10 T0

X軸、Y軸とも10mmシフトしたので、中心からの距離も10ｍｍ長くなります。
モデルの幅は変わりませんが、M118の値は、「10mm」プラスされています。
次に、一旦センターに戻し、センターから「X-10.0」「Y-10.0」に移動して、
同様にスライスします。

M118 X20.00 Y20.00 Z10.10 T0

このように、「0.94」を無視すれば、上記と同様の値になりました
座標の方向性は関係なく、大きな値になるようですね。
まぁ、通常はこの設定はスライサーに任せればいいと思いますが、
プリンタの最大値に設定したい場合には、Adventurer3の造形範囲「150×150×150mm」の場合

M118 X75.0 Y75.0 Z150.0 T0

でよさそうです。

FlashPrint が苦手な書式

コードを確かめていて、FlashPrint のプレビューがおかしくなるコードが見つかりました

１．工作機械のISOコードの場合、「G1 」と「G01」は同等ですが、「G01」の指令では
　　FlashPrint で 正常に描画できません。

２．また、ISOコードでは、NCワードとワードの区切りは無くても問題ありませんが
　　FlashPrint は「スペース」で区切らないと、同様に正常に描画できませんでした。

ただし、単純に移動するだけのコードで試してみたところ、FlashPrintでは異常でしたが
実際にAdventurer3に送って動作させると、正常に動作しました。
FlashPrint5の問題かもしれませんが、「G1」のように、コードの数値はそのまま書き
ワードとワードは、「スペース」を間に入れた方がFlashPrintで動作確認できます。

まとめ

機械のウォームアップ（ヘッダー）とクールダウン（フッター）指令が分かりました
ヘッダーとフッターの間に、実際のプリント指令が定義されます。
NC工作機械と違って、手打ちのG-Codeで３Dプリンタを動かす事は少ないと思いますが
次回、マシンをランニング運転させるデータを作成してみようと思います。

バイナリ形式ヘッダー

通常エディタ等で、正常に編集作業をする場合は、アスキー（テキスト）形式に限ります。
バイナリ形式のデータはソフトによっては、読み込めない場合や、
読み込めたとしても、文字化けで表示されてしまいます。

「.GX」ファイルは、メモ帳や秀丸エディタでは、ヘッダー部が文字化けしていますが
ヘッダー以外は、通常のテキストファイルと同じように編集が可能でした。
ただ、編集後保存すると、ヘッダー部分のコードが書き換えてられてしまい、
「FlashPrint」では正常に読み込めないデータになってしまいました。

エディタ上書き保存で、ヘッダー部は、どう変化したのか？

私がメインで使っている秀丸エディタには、バイナリ（１６進数）で表示する機能があります。

この機能を使用して、オリジナルの「.gx」ファイルと、メモ帳で編集後保存したファイルを比較してみます。

「00」コードが「20」に変換されているのがわかりますね。

プログラム言語では、「00」コードは、文字列の最後を表すコードとして扱われます
主に文字列を扱うテキストエディタは、「00」コードは扱いにくいのかもしれませんね。
それで、メモ帳は勝手に「20」に変更したのかもしれません。
ちなみに、１６進数の「20」コードは、「スペース」を表します。
結局、FlashPrintはヘッダーを読んだ時点で、正常に処理する事ができない事になります。

「.G」拡張子ファイル

「FalshPrint 」は、一般的なアスキー（テキスト）ファイルも拡張子を「.g」にする事で
読込み事ができます。
したがって、他のスライサーで出力したG-Codeもアスキー形式であれば、
「.g」拡張子にする事で読み込む事はできると思います。
実は「.gx」ファイルも、バイナリヘッダー部分を削除し純粋なアスキーだけにし
「.g」拡張子で保存し直せば、編集可能になります。

FlashPrint Editor ソフト

実は５年ほど前、「.g」拡張子のテクニックを知らなかったので、
「.gx」ファイルを直接編集できる今回紹介ソフトの前身を作成していました。
このソフト久しぶりに先日試した所、「FlashPrint 5」が出力した「.gx」ファイルが
処理できませんでした。
おそらく、ヘッダー部分の形式が「FlashPrint 5」になり変更になったと思います。
まぁ、あまり必要としている人は少ないかもしれませんが、今回「FlashPrint 5」にも対応し
一時停止と温度設定のコードを追加する機能を追加した、
FlashPrint 編集ソフト「EditorForFlashPrint5.exe 」を作成したので、紹介します。

EditorForFlashPrint5.exe　使用方法

最初このソフトを作ったのは、もともと筆者はNCが専門なので、３DプリンタのG-Code に興味があり
手打ちのG-Code で動かないかなぁ～と思ったのがきっかけでした。
興味があった当時は、手打ちG-Codeで３Dプリンタにプリントさせてみましたが
最近は、３Dプリンタのメンテナンスの時に、空運転する、ランニングデータを
手打ちした程度ですが、打ち込んだデータで機械が動くのは楽しいものです。

追加機能

FlashPrint5はFlashForge専用スライサーなので、通常編集する必要性はほとんどないと思いますが
一時停止の設定が使いにくいと感じているので、一時停止と温度設定のコマンドを挿入する
機能を付けました。
一時停止と温度設定は、以前のFlashPrintは積層高さで指定できましたが、FlashPrint5では、
レイヤー指定に変更になってしまいました。
なぜレイヤー指示になったのか分かりませんが、筆者は積層高さで設定するほうが
設定しやすいので積層高さで設定する機能を追加しました。
他の用途としては、FlashPrint出力のG-Codeを調べたい場合などには使えると思います。

インストールとアンインストール

インストールは特に必要ありません。
ダウンロードした圧縮ファイル（ZIP）を適当なフォルダへ展開し、EditorForFlashPrint5.exeを起動するだけです。
アンインストールも、展開したフォルダを削除すれば完了です。

起動

このような画面で起動します。

使用方法

まずは、画面上に、「.gx」ファイルをドロップ
データを解析し、右側にエディタが起動します。

①　ドロップしたファイルのフォルダです。
　　ここに、編集されたファイルが作成されます。
②　作成されるファイル名。必要あれば、変更してください。
③　ラフト高さを除いた、造形品積層の始まり高さです。
④　全体の高さです。「造形品高さ」+「ラフト高さ」＝「全体高さ」
⑤　コマンドを追加したい、造形品積層高さを指定。
⑥　「Search」ボタンで、データから指定高さを検索します。
　　指定高さと同じ高さがない場合には、一層低い位置を検索します
　　基本は検索位置に挿入ですが、マウスクリックで自由に変更できます。
⑦　検索位置に、「M25」一時停止指令を挿入します。
⑧　温度指定指令を挿入します。
　「T0」ヘッド右、「T1」ヘッド左、「Bed」プラットフォームに温度指定できます
⑨　編集された、ファイルが作成されます。

一時停止と温度調整だけでなく、通常のエディタ的に編集できるので、自信がある方は自分でG-Codeを挿入する事も可能です。

テストプリント

各ステップの高さを、3mm　としたモデルを準備しました。

このモデルから、「FlashPrint5」でG-Codeを作成し、「EditorForFlashPrint5.exe」を使用し
「3.0mm」「6.0mm」位置へ、一時停止「M25」を挿入したデータで印刷しました。

一時停止高さの確認のため、一時停止ごとに、フィラメントの交換を行いました。
一層程度、ヅレている感じもしますが、まぁこんなもんでしょう。
このように、一時停止させる事で、途中で色を変えたり、内部にナットなど別のパーツを挿入したりできるので、プリントの幅が広がります。
今回は温度設定も、「一時停止」の前に挿入してみました。
ヘッド温度は、指定温度へ変更されましたが、プラットフォーム温度は変化しませんでした。
ウチのAdventure3 が対応していないのかもしれません。

まとめ

「FlashPrint」で作成した「.gx」ファイルを、編集するソフトを作成してみました。
必要性は・・・少ないかもしれませんが、G-Codeが触れるのは楽しいものです。
ただし、筆者の環境では、実機はAdventure3しか確認できませんのでご了承ください。

フリーソフトページから、ダウンロードできます。
　2023/01 オリジナルデータの上部のコメント文「;」を全て削除して作成すると
　再度そのデータを読み込んだ場合、正常に読み込めない症状を修正しました
　ver1.6 になります。

カスタムマクロでハイデンハインサイクルを作ってみよう！

最近、機械の立ち上げ作業でバタバタしていて、すっかり更新がご無沙汰しています。忘れられそうなので、５月の連休の空き時間で更新します。ネタとしては、以前から考えていたもので、ファナックカスタムマクロの使用例として、ハイデンハインサイクルをマクロ化してみたいと思います。ハイデンハインサイクルについては、...

www.kazuban.com

2022.05.05

ハイデンハインサイクルに比べると、ファナック固定サイクルの機能は非常に貧弱ですが、
カスタムマクロを自作する事で、無限に拡張する事が可能です。
今回は、カスタムマクロのモーダル呼び出し「G66」を利用して、穴を面取りするサイクルを作成してみようと思います。

G66：マクロモーダル呼び出し

固定サイクルを呼び出すには、「G83 R5.0 Q2.0」のように引数により値を渡す事ができます。
単純なサブプログラム呼び出し「M98」は、引数により値を渡す事はできません。
しかしマクロ呼び出しは引数を渡す事ができますから、固定サイクルが自作できます。
マクロ呼び出しには「G65」という一行のみの単純呼び出し指令もありますが、
「G66」を使用すると、定義したサイクルを「X」「Y」座標指示のみで、モーダルで動作させる固定サイクル的な機能を実現できます。

G66 P1234 A10.2 B5.0 C3.56
X0 Y10.0
X10.0 Y25.6
X-20.3 Y-56.2
G67

この例のように、「G67」でキャンセルされるまで、指定座標で「G66」の呼び出しを実行する事ができます。

引数と変数

カスタムマクロでプログラミングする時に厄介なのが、変数です。
カスタムマクロの変数は「#」+「数値」で定義しますが、識別は「数値」のみなので、
他のプログラム言語に比べると後で読み返した時に、非常に分かりづらいです。
さらに、変数の種類は「ローカル」や「コモン」「システム」などありますが
その種類も「数値」の範囲を意識する必要もあります。
さらにさらにです、カスタムマクロに引数を渡す場合には、「#」ではなく、
「アルファベット」+「数値」で渡します。
例えば、「A10.5」と指令した場合には、マクロ内では、「#1=10.5」と扱われます。
なんとも、分かりづらい仕様です。
さらにさらにさらに、渡された、この「アルファベット」の引き数値と「#」変数番号が連続でなく、制限があったりします。
ほんと、他人が作成したマクロや、昔作ったマクロなど、解読するのに苦労します。
もしかすると、ユーザーに簡単に使用させないための、言語仕様かもしれませんね～。

引数

カスタムマクロの引き数は、「アルファベット」+「数値」で指令しますが、その指令方法には２種類あります。
１・「G」「L」「N」「O」「P」以外のアルファベット

A:#1　B:#2　C:#3　D:#7　E:#8　F:#9　H:#11　I:#4　J:#5　K:#6 　M:#13
Q:#17　R:#18　S:#19　T:#20　U:#21　V:#22　W:#23　X:#24　Y:#25　Z:#26

２・「A」「B」「C」と「I」「J」「K」の多重指令

A:#1　B:#2　C:#3　I:#4　J:#5　K:#6　I:#7　J:#8　K:#9　I:#10　J:#11　K:#12 ～　　K:#33

１．は、マクロを使う立場からは、２１種類のアルファベットを使えるので、識別しやすいと思いますが、アルファベットに対応する「#」番号が連続していないので、作る立場からは面倒です。
２．は、「#」番号は連続しますが、「I」「J」「K」が連続するので、使用する側からは間違いやすいかもしれません。

ここでは、１．の方法で作成したいと思います。

面取りの動作をマクロ化

真円をGコード化

まずは、Φ２０真円輪郭をGコード化してみます。
分かりやすいように、G90（絶対座標系）モードで作成します。

G90G00G17
G00X0Y0Z30.
G00Z5.
G01Z-10.F500
G01X10.
G03X-10.I-10.
G03X10.I10.
G01X0
G00Z30.

こんな感じでしょうか？進入Ｒは省略しています。
円の定義は１行で定義可能ですが、一定義で一周させると、昔うまく処理できない制御機や
CAMがあったので、２分割しています。

G91（相対座標系）に変換

今回は自作固定サイクルを目指していますが、通常固定サイクルは
・サイクル動作の定義
・加工位置指令で、その位置へ移動しサイクル加工
・サイクル動作のキャンセル
こんな動作ですね。
このように、位置決めした後、同じ動作をさせたい場合には、「G91」が便利です。
G91に関してはこちらでも紹介してあるので、興味ある方は参考にしてください

NCプログラム／G91は意外と便利

下記で説明しましたが、ファナック言語で位置を司令するには「G90:絶対座標系」と「G91:相対座標系」の２種類の方法があります。通常は、図面を見ながらプログラムする場合など、「G90:絶対座標系」のほうが分かりやすいので、こちらを使用する場合が多いと思いますが、同じ形状が並んでいる場合や、穴やポケッ...

www.kazuban.com

2020.03.08

G90をG91に変換するには、上記またはフリーソフト紹介ページでも公開している、
変換ソフトを利用して変換する事ができます。

G90G00G17
G00X0Y0Z30.
G91
G00Z-25.000
G01Z-15.000F500
G01X10.000
G03X-20.000I-10.
G03X20.000I10.
G01X-10.000
G00Z40.000

変換させると、こんなコードにしてくれました。
３行目からG91モードで指令しているので、２行目「G00X0Y0Z30.」の
Ｘ，Ｙ座標を変更すれば、任意位置で円加工できます。

マクロ化

では、マクロ化してみましょう。
変換された「G91」プログラムは、若干手直しします。
そのままでも使用できますが、ポイントは、Z方向だけは「G90」にしようと思います。
加工動作は、位置決め後「G91」にしますが、Z方向のみの指令は、退避位置やＲ点など、
「G90」のほうが分かりやすいです。
上の例では、加工Zまで下りるコードと、最後の「G00Z40.000」は「G91」モードでの指令値ですが、
「G90G00Z30.000」の方が分かりやすいと思います。

(+++++++++++++++++++)
#1=20     (DIA)
#2=[#1/2] (R)
#3=30.0   (Initial Point)
#4=5.0    (R Point)
#5=-10.0  (Z)
#6=500    (F)
(+++++++++++++++++++)
G90G00G17
Z[#3] 
Z[#4] 
G01Z[#5]F#6
G91X[#2]
G03X-[#1]I-[#2]J0. 
X[#1]I[#2]J0.
G01X-[#2] 
G90G00Z[#3] 

このようにしてみました。
変数化したので、上部の「#1」～「#6」の数値を変更する事で、加工径や条件を変更する事ができます。
これは、この変数を変更する仕様として、通常のＮＣプログラム的に使用する事も可能ですが、マクロ化する事で固定サイクルのように、引数で呼び出す事ができるようになります。

ここで使用する変数を確認すると、「#1」～「#6」を使用しています。
このマクロを「G66」で呼び出すには、上記のルールにより、引数アドレスと
「＃」番号を確認する必要があります。

A=#1　B=#2　C=#3　I=#4　J=#5　K=#6 　

ですね。
マクロファイルは、上記プログラムの変数定義以下の部分（９行目以降）を、
「O番号」を付け、「M99」で終了させるNCファイルを作成します。
このマクロファイルを、「O6000」とした場合、上の定義で呼び出す指令は
「G66 P6000 A20. C30.0 I5.0 J-10.0 K500.」となります。

面取りをプログラム化

これで、円動作させる事はできましたが、狙いの面取りをさせるためには、
使用工具径や面取り量、オフセット量などから、加工径や深さを求める必要があります。
動作は単純な円加工ですが、円要素を求めるのは意外と面倒です。
電卓で加工径を求めて、「#1=」で設定してもいいですが、せっかくなので、
工具径と加工穴径と面取り量から、自動計算させましょう。

今回の面取りは、４５°のみを想定しています。
工具も４５°の円錐工具を使用します。
加工動作の円弧径は、工具径補正を使用しない場合、工具（主軸）中心になります。
したがって、「加工半径＝穴半径ー（工具半径+オフセット量）」になります。
加工深さは、「面取り量+オフセット量」ですね。

これを考慮すると、上記のマクロ変数に「面取り量」「オフセット」「工具径」「穴径」を追加する事になります。
「加工径」と「加工深さ」は自動計算させましょう。
ついでに、加工面深さも追加して、マクロを作成してみました。

%
O6000
( Chamfering Macro Ver1.0 By kazuban ) 
(+++++++++++++++++++)
#1=[#8/2-[#6+#7/2]] (circle radius)
(+++++++++++++++++++)
(B:#2 : Surface Coordinat) 
(C:#3 : Initial Point) 
(I:#4 : R Point) 
(J:#5 : Chamfer) 
(K:#6 : Offset)
(D:#7 : Tool Dia)
(E:#8 : Hole Dia)
(F:#9 : Feed)
(+++++++++++++++++++)
G90G00G17
Z[#2+#3] 
Z[#2+#4] 
G01Z[#2-[#6+#5]]F[#9] 
G91X[#1]
G03X-[#1*2]I-[#1]J0. 
X[#1*2]I[#1]J0.
G01X-[#1] 
G90G00Z[#2+#3] 
M99
%

こんなマクロプログラムになりました。
これを呼び出すには、「G66」と共に「P」+「O番号」「引数」を付加して呼び出します。
続いて、加工位置を追加して、最後に「G67」で終了です。

G66 P6000 B0.0 C30.0 I5.0 J2.0 K1.0 D0.5 E12.0 F200
X10.0 Y12.0
X-10.0 Y-10.0
G67

メインプロ作成

次に、実際の加工に使用できるように、工具交換や加工条件などを定義できるメインププログラムを作成します。
このメインプロから、ここまでで作ってきた、面取りマクロプログラムを呼び出すようにします。

変数化

やはり汎用化を考えて、メインプロも変数化しましょう！
パラメータは、「ワーク座標系」「工具番号」「回転数」など実際の加工に必要な項目をプログラム上部にまとめます。
使用者はこの項目だけの変更で、加工できるようになるので便利です。

(++++++++++++++++++++) 
#1=54 (WORK ORIGIN)
#2=10 (Tool Number)
#3=#2 (H Number)
#4=0.5(Tool Diameter)
#5=2300 (Spindle Speed)
#6=200 (Feed)
#7=8 (Coolant)
#8=0.0(Surface Coordinat)
#9=50.0 (Initial Point) 
#10=5.0 (R Point)
(++++++++++++++++++++) 
#11=12.0 (Hole Diameter)
#12=1.0 (Chamfer)
#13=0.5 (Offset)
(++++++++++++++++++++) 
#30=6000 (Macro program No)
#31=6100 (Position program No)
(++++++++++++++++++++) 

メイン内変数とマクロ内変数

上記のように、必要な項目を変数化してみましたが、ここで定義した変数番号「#番号」とマクロ内で定義している変数番号「#番号」は数値的には同じでも、違うものとして扱われますから注意が必要です。
ただ、逆に同じに扱われるとかなり面倒で、変数の値が他のマクロで変更されていまう事も起こってしまいますね。
ほとんどのプログラミング言語に、ローカル変数とグローバル変数がありますが、
よく理解して使い分けしないと思わぬミスにつながります。
一塊のプログラム内だけでリセットされる、ローカル変数のほうがトラブルは少ないです。

メインプロからマクロを呼び出す場合、マクロで使われている変数番号と引数のアドレスを把握し、
メインにおいてその要素を示す変数番号をマクロ引数に渡します。
なんだか、よくわからない説明になってしまいましたが、例えば上記の例で
メインで定義している「Initial Point」は「#9=50.0」です。
マクロで使用する「Initial Point」は「#3 」です。
そうして、引数で渡す「#3」は「C」アドレスですから、「C#9」を渡します。
分かりづらいので、整理してみると

    マクロ変数            メイン変数
(B:#2:SurfaceCoordinat)  ←  #8
(C:#3:InitialPoint)      ←  #9
(I:#4:RPoint)             ←  #10
(J:#5:Chamfer)           ←  #12
(K:#6:Offset)             ←  #13
(D:#7:ToolDia)           ←  #4
(E:#8:HoleDia)           ←  #11
(F:#9:Feed)               ←  #6

具体的なマクロ呼び出し指令は、マクロの「O番号」をたとえば「O6000」とすると

G66 P6000 B[#8] C[#9] I[#10] J[#12] K[#13] D[#4] E[#11] F[#6]

となります。

穴座標位置ファイル

マクロ呼び出しの次は、穴位置のＸ，Ｙの列挙になりすが、この穴位置指令もサブプログラムとして別のファイルにする事ができます。

%
O6100
( Hole Position )
X-35.Y55.
X-50.Y55.
X10.Y10. 
M99
%

この位置ファイルは、今回作成中のマクロだけでなく、通常の固定サイクルにも使用できるので
同じ位置で複数の加工を行う場合には、非常に便利です。
タップ加工をイメージしてください、
センター穴　⇒　下穴加工　⇒　面取り　⇒　タップ　となりますが
この一連の工程をメインプロから固定サイクルやマクロで呼び出すように作成しておけば
穴座標ファイルは一つのみの編集で、大きさの違う同等の加工が可能になります。
M6用、M8用、M10用、M12用　などのように、用意しておくと便利だと思います。

( CENTER DRILL )
・
・
G98 G81 Z-1.0 R5.0 F100 L0(K0)
M98P6100
G80
・
・
( DRILL )
・
・
G98 G83 Z-20.0 R5.0　Q3.0 F200 L0(K0)
M98P6100
G80 
・
・
( CHAMFER  )
・
G66 P6000 B[#8] C[#9] I[#10] J[#12] K[#13] D[#4] E[#11] F[#6]
M98P6100
G67
・
・
( TAP )
・
・
S100
G98 G84 Z-15.0 R5.0 Q2.5 F125 L0(K0)
M98P6100
G80 
・
・
M30

G66 モーダル呼び出し　メインプロ

上記で作成した、マクロを呼び出すメインプロを作成してみました。
マクロと位置座標ファイルの番号も変数化しています。

%
O1000
( Chamfering Program Ver1.0 By kazuban ) 
G90G00G17G40G80G49 
(++++++++++++++++++++) 
#1=54 (WORK ORIGIN)
#2=10 (Tool Number)
#3=#2 (H Number)
#4=0.5(Tool Diameter)
#5=2300 (Spindle Speed)
#6=200 (Feed)
#7=8 (Coolant)
#8=0.0(Surface Coordinat)
#9=50.0 (Initial Point) 
#10=5.0 (R Point)
(++++++++++++++++++++) 
#11=12.0 (Hole Diameter)
#12=1.0 (Chamfer)
#13=0.5 (Offset)
(++++++++++++++++++++) 
#30=6000 (Macro program No)
#31=6100 (Position program No)
(++++++++++++++++++++) 
N0001
G#1
T#2
M06
G90G00X0Y0 
(G43Z#8H#3)
G43Z[#8+#9]H#3
( Chamfer Process )
S#5M03 
M#7
(----------------------------)
(B:#2=#8 : Surface Coordinat) 
(C:#3=#9 : Initial Point) 
(I:#4=#10 : R Point) 
(J:#5=#12 : Chamfer) 
(K:#6=#13 : Offset)
(D:#7=#4 : Tool Dia)
(E:#8=#11 : Hole Dia)
(F:#9=#6 : Feed)
(++++++++++++++++++++) 
G66 P[#30] B[#8] C[#9] I[#10] J[#12] K[#13] D[#4] E[#11] F[#6]
M98P[#31]
G67
(G90G00Z#9)
G90G00Z[#8+#9]
M09
M05
G91G28Z0 
G91G49Z0 
G90M05 
( End of Process )
M30
%

まとめ

固定サイクル的な機能を自作する方法を説明しました。
こちらから、ダウンロードできます。
一例として、穴面取り用のマクロを作成しましたが、机上で検討したのみで
実機での検証・確認はやっておりません。
もし、実際に使用する場合には、十分な確認をお願いします。
また、不具合、気になる点などありましたら、コメントいただけるとたすかります。

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データシミュレーターはほしいですね。