ファナック vs ハイデンハイン vs レダース

NC

ファナックは、国内のみならず海外でも圧倒的なシェアを誇っています。
信頼性や情報量の多さなどはやはりNo1です。
私もファナック系やOSPなど国産機を長い間触ってきましたが、13年ほど前導入された5軸加工機で初めてハイデンハインを体験しました。
これは新鮮でしたし、慣れてくると使いやすかったですね。
一度、ハイデンハインを覚えると、ファナックには戻れないという感じです。
さらに、最近レダースのマシンも導入されました。
このNCは、NC言語と言うよりも、ほとんどプログラミング言語です。
最初は戸惑いましたが理解するとかなりいろんな事ができるようになります。
多数個、多品種、自動化など、カスタムマクロではかなり面倒くさいプログラムがレダースは非常に作りやすいです。
少しでもプログラミングの知識があれば、これに勝るNC言語はないと思います
情報量や信頼性から考えると、やはりファナックは最強です。
ただ、他(EU)のコントローラを触ると、非常に使いやすく感じます。
その違いを考察してみようと思います

ファナック言語

NC工作機械用のNCプログラムとしては、世界的にもスタンダードな言語です
サンプルコードや例題など情報は沢山あるので、学習するには事欠きません。
また、ほとんどのCAMが標準でファナック用のデータは吐き出せますから、新規に導入した場合でも専用のCAMを導入する必要は少ないです
ファナック制御機の機械の立ち上げは、やはり早いですね。
ただ、基本的な切削モードの指令はどの機械メーカー製でもほぼ同じですが、加工動作に入るまでの補助的な指令は機械メーカー独自の指令になっている場合が多いですね。
数種類の機械がある場合には、その違いを処理させる必要があります
その場合、CAMのポストプロセッサと呼ばれるソフトで処理しますが、種類が多いと管理が面倒になってきます
また、最近の機械には、機械上での計測機能付きマシンもありますが、この測定用のプログラムは機械メーカーがマクロで開発している場合が多く、使用方法はバラバラです。
NCデータ内に、測定プログラムも入れ込みたい場合など、かなり面倒になりますね
ファナック制御装置は基本的は加工(動作)の部分を受け持ち、測定も含めた補助の部分は機械メーカーがマクロ等で独自に開発している感じです
これにより、機械メーカーは独自性をアピールできますが、ユーザー側では他メーカーの機械を選択しにくくなりますね
もしかすると、そこも狙いの一つなのかな?

ハイデンハイン

ドイツのハイデンハイン社の制御装置です。
主に5軸の機能が優れていると言われていて、5軸機ならハイデンハインと言われるほどです。
言語は、ファナックのGコードとは違い、Lコードと言う独特の言語です
詳細は、古い記事ですが、こちらを参照してください。

工具管理方法の違い

私が思っているファナックとの一番の違いは、工具情報(長さや径など)の管理方法です
ファナックは、工具単位での管理方法ではなく、補正番号で調整する方法です。
ハイデンハインは、工具ごとのデータベースで管理しています
工具データベースには、長さ・径の他に、コーナーRや切込み角度、長さや径の追加量など30項目ぐらいは登録できるようになっています。
工具の長さや径は、基本的に自動測定で自動的に書き込まれます 。
測定が終了した工具は、工具交換した時点で、制御機は工具データベースの情報をNCデータに反映できます。
特に工具長補正は交換しただけで完了しています。
工具径補正も、NCデータ内に径補正の指令があると、データベースから工具径を認識しその分オフセットされます
ファナックの場合は、どの工具かは関係なく、NCデータで指令された補正番号の数値で補正をしますが、ハンデンハインは持ってきた工具で自動的に補正されますからNCデータに補正番号など指令する必要はありません
逆に考えると ファナックの場合は、補正番号により工具に関係なく自由に補正値を操作できるのがメリット とも言えますが、 補正番号設定ミスのリスクは常にあります

測定サイクル

ハイデンハインは測定プログラム(サイクル)が、コントローラ側で用意されています。
ファナック機の場合は、カスタムマクロなどを駆使して機械メーカーが提供している場合がほとんどです。
Oの9000番台で提供されているのが多いですが、その番号には共通性はありません、さらに引数もバラバラです
したがって機械がかわると、互換性はほとんどありません
ハイデンハイン機は、 コントローラがサイクルとして測定機能を提供していますから、 機械やタッチプローブの機種が変わっても同じコントローラであればNCプログラムの互換性が高いです。
たとえば、 ハームレ用で作成した、測定プログラムも、DMG機で動作する可能性が高いです
私の考えですが、EUはタッチプローブを必須と考えていて、簡単に利用できるように制御機側でソフトを用意し、測定器メーカーや機械メーカーもそのソフトに合わせるように開発しているのではないでしょうか?

レダース

座標系

ファナック機との一番の違いは、座標系です
G54などのように、番号でなく、任意の名前をつける事ができるという小さなメリットもありますが
レダースの座標系設定には、3軸機でもZ軸中心の回転情報を持ってます
これにより、ワークを機械のXY軸に対して、平行に置く必要(通り)がありません。
適当に置いたワークの平行基準を、タッチプローブで測定するだけで、XYの軸が形成されます。
これは、ファナックのNCデータの座標回転(G68)とは全く違い、 機械の軸自体が回転します。
たとえば、X軸に対して30度ぐらい回転させて置いたワークで設定すると、ハンドルでX軸を移動させると、主軸は30度方向に動きます。
軸そのものが、回転した状態になり、 角度が大きいと、結構気持ち悪いです。
ワークをX軸平行に置く必要がないというのは、クランプ段取りにおいても、治具を作成する場合でも非常に便利です。
バイスではできない加工や、治具に平行機能を設ける必要がありません。
5軸の場合なら、段取り後C軸を回転させて、通りを出せますが、3軸機で同様のことが可能になってます
段取り効率は、飛躍的に向上できますね

NC言語

レダースの言語は、全く独自言語です。
したがって、別メーカーとの言語的な互換性は全くありません
ただし、加工させる指令には、 GコードやハンデンハインのL言語を混同で使用できます。
基本的なGコードならファナック用を若干の手直しで使用できます。
言語的には、一般的なプログラム言語 JavaScript に似ています。
ファナックにもカスタムマクロが用意されていて、条件判断や分岐、繰り返しなどの構文はありますが、決してプログラムしやすいとはいえませんね~
一番の難点は、「#」と数字で表す変数ですね。
長くなると、自分で作成していても、迷子になる事もしょっちゅうです
レダース言語は、 英数文字を自由に使えるので分かりやすいです
サブプロ呼び出し方法も大きく違います
ファナックでは、サブプロの終了は「M99」、メインプロの終了は「M30」や「M02」の決まりがありますが、レダースはメインもサブも「M30」でOKです。
したがって、サブをメインとして実行したり、メインを別のメインからサブとして呼び出したりする事ができます。
これにより、多数個・多品種のメインプログラムが簡単に作成できます
さらに、ファイル名もO番号4桁のような縛りはないので、ファイル名で呼び出せますし、Windowsの絶対パスで呼び出せるので、別のドライブやネット上の共有ファイルからでも呼び出しが可能です
レダース言語については、時間を見つけて、詳細を書いてみようと思っています

まとめ

ファナックコントローラは、世界的No1の実績だと思います
CAMで吐き出したNCデータで加工させるだけなら、それほど問題になりません
ただ、マクロプログラムなど、ちょっと複雑なプログラムを作成しようとするとかなり分かりづらいプログラムになってしまいます。
その原因の一つは、「#」の変数です
数値だけで、変数を識別するにはやはり無理があります
さらに、ローカル変数だのコモン変数だのシステム変数だの・・・機種やオプションによって範囲が違いますし、さらにG65などマクロ呼出しを使用しようと思うと引数によって、変数番号が変わってしまいます。いじめに近いですね(~_~;)
CAMで作成した数種類のNCデータを組み合わせて、多数個や多品種の製品を同時に無人加工するようなメインプログラムを作成する場合などは、レダース言語は最強です

コメント

  1. ZENKYU より:

    かずばんさん、こんばんは。

    ハイデンハインにも穴あけサイクルはあるんでしょうか?

  2. kazuban kazuban より:

    ZENKYUさん、こんにちは
    ありますよん!
    タイムリーですね~!
    実は先週から、まさにハイデンハインのサイクルの記事を書き始めたところです
    今週末には公開できると思います。
    最近は実機に触る環境にないので、検証はできないので、昔の記憶を基に書いてます
    次の展開として、ハイデンハインのサイクルのファナックマクロ化を企んでます
    ZENKYUさんにも手伝ってもらえるとうれしいなぁ!

  3. ZENKYU より:

    Fusion360 で ハイデンを選択して出力してみたら
    直線補間の指令になってるみたいだったし
    このサイトの下の方の「ハイデンハイン情報」の記事の中にも
    穴あけサイクルの事は書いて無いようだったのでお聞きしました。

    ちなみに機種は iTNC530 なのでいろいろ教えてください。

    • kazuban kazuban より:

      またまた、グッドタイミング。
      私も、Fusion360の標準ライブラリの中のHeidenhainポストで穴加工を出力してみました。
      私の環境では、正常にサイクルで出力されました。
      この件も、予定の記事には書いています。
      どの程度参考になるかは??ですが、ほぼ出来上がってはいるので
      明日には、公開できると思います。

      公開しました~
      https://www.kazuban.com/blog/heidenhain_cycle/

タイトルとURLをコピーしました