2018年05月22日

機械の精度管理

 来月からまたちらほら機械が入る予定。新しい機械が入ったらまたいつものように自分が色々とセットアップして担当者に引き渡す予定ですが、そろそろこういう作業も誰かしらに引き継いで貰わねばと思うんですが、機械の精度、パラメータ設定、マクロなど、小難しい事が多くてなかなか上手く教えられないのが悩みのタネ。

 そもそもGコードの所からまだ十分理解されてないし。

 セットアップする際には精度をどう維持管理していくかを念頭に置いて作業を行う訳ですが、つい半年程前に書いた記事の中で「5軸のマシニングセンタで精度管理する為には、主軸のゲージラインを基準にするのが一番良いと思っている」と書きましたが、本当の事を言うとうちでは実際にはゲージライン基準で運用していません。

 何故ならば、実際にはそう出来ないから。

 ではどの様にしているかというと、ずばり『基準工具方式』です。

 どれか適当な工具を基準工具として登録し、例えその工具の本当の長さが登録した数値と異なっていたとしてもそれは無視して、兎に角基準工具の長さありきで他を全て合わせるという方式です。

 そんなんで大丈夫なの?と思うけしょうけど、現実機械の中で自己完結させながら精度を維持管理する為にはそれしかやりようが無いんじゃないかと思って自分はそんな方式で運用しています。

 求める精度がサブミクロンとかで無ければ、この方式で十分目的は達成出来ます。

 もしサブミクロンの精度が必要となったらどうしたら良いでしょうか。自分はその世界に居ないので確信は持てませんが、恐らくそれを実現するにはテーブル基準でやるしか無いんじゃないかと思います。もう少し具体的に言うとJeyecore方式。

 ナノの世界になるとこれでも難しそうなので更に進んだ対応が必要になると思いますが、私にはちょっとそこまでは想像出来ません。

 Jeyecore方式を自分は勝手にテーブル基準と見做していますが、メーカーがそう捉えているかは謎です。自分が勝手にそう決めつけている理由としては、Jeyecoreの装置は普通テーブル側に取り付けるだろうという事と、工具長だけでなく主軸の回転中心まで捉えて補正するという所から、主軸を絶対的な基準として居ないと判断出来るからです。

 ゲージライン方式の欠点は主軸のゲージラインが変化した場合に、周りがそれに合わせる必要がある所です。基準工具方式も似たような所がありますが、相対的な変化量がゲージラインを基準にするよりかいくらか軽減出来るという所と、測定が容易という所がちょっと違います。

 世の中色んなやり方があると思いますが、いったいどれが正解なんでしょうね?

追記 2018.05.24

 上でJeyecore方式をテーブル基準と書きましたが、運用方法次第ではJeyecoreを使って基準工具基準にする事も勿論可能です。Jeyecoreは単なる道具の1つですからそれに拘る必要もありませんが、あれに類する物を使うとしたら、3軸のMCだとテーブル基準で運用するのが素直な感じがします。一方5軸の機械では軸構成によってはテーブル基準にするのが得策では無くなると思われるので、まぁその辺りは運用でカバーするしかないでしょう。

 機械に絶対的な基準は無いので、まずはあらゆる所が常に変位するという大前提に立って、その中で何処を基準にして他を合わせていくか、それが実務作業の中で実現出来るかを考えるのが運用技術かと思います。


posted by antec at 21:19 | Comment(0) | 工作機械 | このブログの読者になる | 更新情報をチェックする

2018年03月22日

転ばぬ先の杖

 一昨日まで特におかしな所もなく動いていたのですが、今朝になって突然NCが起動しなくなってしまいました。

V33_BootError.jpg
この状態でフリーズ

 こうなってしまうと手に負えないのでFANUCさんのサービス窓口にお電話した所、やはりNCの基盤交換が必要でしょうという事で、部品交換の手配をしてもらいました。

 幸いFANUCさんの保守契約を結んでいるので、基盤絡みの部品交換は契約期間中何度でも無償でして頂けるそうです(モータやバッテリーなどの消耗品は対象外)。この辺のサービスは流石FANUC様。

 牧野さんから10年越えたら色々とトラブル出るから保守入りましょうというご案内を度々頂いていて、機械本体の保守は数年前から入りました。そして昨年からFANUCさんの保守にも入る事にしたのですが、それからこれで3回目の出動依頼になります。

 保守入っていなかったら修理費はかなりな額になっている筈ですがとても助かりました。

 同時期に保守結んだもう1台の方は全然お世話になっておりませんが、それを差し引いても保守入ってて良かったです。

 ただ近頃SRAMのバックアップを怠っていたので、そちらの復帰が必要になるとちょっと面倒な事になりそう。保守や機械のメンテだけでなく、データのバックアップもこまめに取っておかないと行けませんね。

追記 2018.03.24

 23日の午後にFANUCさんが来てくれて、10分程の作業で直して下さいました。CPU基盤とDRAM基盤の交換だけで済んだみたいで、データの方は無事でした。

 因みに自分の方ではSRAMのバックアップをここ数年取っていませんでしたが、今年の2月にサーボアンプの交換をお願いした際だかにFANUCさんの方でバックアップを取ってくれていたようで、最悪データが消し飛んでも2月の状態には復帰出来たようです。やっぱりプロの仕事は違いますね。

 そう言えば保守契約を結ぶ際に故障が無いことが加入条件となっているので実機の確認に来てくれたのですが、その時にもバックアップを取ってくれて居たような気がします。

 てな訳でFANUCの保守はかなりのお得感がありましたよというお話でした。

タグ:制御装置

posted by antec at 21:54 | Comment(0) | 工作機械 | このブログの読者になる | 更新情報をチェックする

2018年02月01日

S500X1

 M140に続いて再びBrotherの機械が入りました。今度はS500X1

 今までタッピングセンターでは工具長測定にBIGのベースマスターを使っていましたが、M140では工具折損検出装置を利用して測るようにしました。小型の5軸機はワークを取り外さないとテーブルにベースマスターを置くような空いたスペースが無いので。

 これが中々好評なのでS500X1にもオプションを付けておいたのですが、ちょっとこちらの方はそのままでは工具折損検出の役割にしか使え無さそうな状態。

 具体的に言うとセンサーを取り付けているステーが板金で華奢なのと精度が出ていないので、測定子の水平が出ていないのです。それもわずかφ3の範囲でコンマ台の傾き。そりゃ〜ないでしょう。

 もちろんこんな状態でも工具折損検出くらいには使えると思います。オプションの名目も『工具折損検出装置』ですから、クレーム付けた所で相手してくれないでしょう。

 という訳でそのままではこちらの目的としている工具長測定装置として使えませんが、かと言って折損検知だけで我慢する事も出来ないので、何とかして目的が果たせるように改善を図る事にしました。

 まず板金をテーブルのT溝にM10のキャップ1本で止めていますが、板金が薄すぎて曲がってしまっています。そのせいでセンサー付近をちょっと揺するとふにゃふにゃ。

 これをどうにかする為に、M10の狭い範囲で締め付けるのが問題と見て、ブロックを噛まして出来るだけ広い面で押さえつけるようにしました。これだけでもかなり剛性はUPします。

S500X1_Tool_Breakage_Detection_Sensor.jpg
工具折損検出装置

 続いて測定子の水平ですが、板金の精度が悪すぎてシムを噛まして何とか出来る様な気がしなかったので、仕方がなくプライヤーで曲げ曲げしながら根気よく水平が出るまで調整しました。柔な作りだと却ってこういう操作は楽ですね。いつまで精度維持出来るか分かりませんが。

 やれるだけ調整してみて、それでもダメだったらステーを削り出しで作り直そうかと思っていましたが、まぁ何とか使えそうな状態にはなったので、暫くこれで運用してもらってそれでもやっぱりダメだなぁとなったら改めて考える事にしました。


 因みに本来このセンサーはテーブルの左奥に設置されていますが、バイスを2連にしているとバイスの固定側口金のすぐ左隣にセンサーが来るので、フェースミルでセンサーを削ってしまわないか心配になります。

 幸いうちでは小物が主体なので、テーブルの前の方に移設した方が普段の加工の邪魔にならなさそうだったので設置場所も移してみました。こういう融通が効く所はDIYの利点かも。

タグ:工作機械

posted by antec at 20:54 | Comment(0) | 工作機械 | このブログの読者になる | 更新情報をチェックする

2017年11月24日

メインサブ両対応

 相変わらずの需要がよく分からないNCマクロネタです。

 機械の段取り時に使う様なプログラムは、それを単体で直接動かしたい時もあれば、別のプログラムからサブプログラムとして呼び出したい時もあったりしますよね?無いですか?

 単体で動かすプログラムは最後M30かM2で終了させますが、サブプロとして利用する場合にはM99で終わらせないとメインプログラムに戻ってくれません。

 従ってそのようなメインプログラムにもサブプログラムにも成り得るプログラムでは、どちらの状態で実行されているか判断して終了のMコードを切り替えてやる必要があります。

 今回はそんな処理をするマクロの例を紹介します。

サンプル1

%
O1234 (SAMPLE PROGRAM 1)


#30 =99. (M99)
IF[#4000 NE #4115] GOTO9900
#30 =30. (M30)

N9900 (END OF PROGRAM)
M#30
%

解説1

 システム変数 #4000 はメインプログラム番号、#4115 はそのプログラム自体のプログラム番号が格納されている変数です。サブプロ実行中は #4115 にサブプログラム番号が入ります。従って #4000 と #4115 が同一か否かで、そのプログラムがメインプログラムとして実行されているのか、それともサブプログラムとして呼ばれているのかが判別出来ます。

 因みにMDIで動かした場合には #4000 は“空”(#0)です。

 M99/M30 はわざわざ変数を介さなくても直接指令すれば良さそうなもんですが、これにはちょっとした理由があります。機械のパラメータ設定によりますが、外部機器からプログラムを読み込む際にM99やM30があるとそこで読み込みが止まってしまう機械があります。その様な機械でプログラムの後半が欠落するのを防ぐため、直接指令するのを避けました。

サンプル2

 動作確認しておkと思ったら、世の中には #4000 が無い制御装置もあるみたいなので別の方法を考えました。

(SAMPLE PROGRAM 2)
#13 =#4113 (MODAL M CODE)


#30 =99. (M99)
IF[#13 EQ 98.] GOTO9900
#30 =30. (M30)

N9900 (END OF PROGRAM)
M#30

解説2

 システム変数 #4113 には直前に指令されたMコード番号が格納されています。

 プログラム先頭で #4113 を調べた場合、もしこのプログラムが別のプログラムから M98 にてサブプロ呼び出されていた場合には #4113 には 98 が入っている筈です。一方メインプログラムとして実行された場合には #4113 には 0 か 2 か 30 の何れかが入っていると思います(処理系依存)。

 この方法ではサブプログラム呼び出しではなく、G65 のマクロ呼び出しされた場合にそれを判別出来ません。FANUCなら #4012 (G65,G66,G67) のシステム変数にてマクロ呼出しされたかどうかを調べる事が出来ますが、ブラザーのNC (CNC-C00) では #4012 は G66,G67 しか返さないようで、G65で呼ばれたかどうかが判別出来ません。

おわり

 そんなのM98Pするだけのプログラム1個置いときゃ良いじゃん、なんて事は決して口にしてはいけません。


posted by antec at 23:39 | Comment(1) | 工作機械 | このブログの読者になる | 更新情報をチェックする

2017年11月18日

2号機

 先日またM140X2が入ってきました。X1と合わせると3台目。いつものように最初の立ち上げ作業は自分がやって、出来たら担当者に引き渡します。

 今回のちょっと新しい試みとしては、工具長測定の改良と、テーブル自動心出しの実装。

 テーブル自動心出しは自分が担当する方の機械でやってる事で、今までM140Xxには付けて無かったんかいという感じですが、これ標準で付いてくるBLUMのスタイラスが太短くて有効長が足りない為に、加工段取り状態で測る事が難しかったので放ったらかしにしていました。まぁ自分が使わない機械なんてそんなもんです。

 工具長測定はA軸の横っちょに付いてて、測定時にA軸を100度に倒して使います。一応カタログの名目は『工具折損検出装置』なので本来は工具長測定装置では無いのでしょうけど、測定マクロさえ作れば工具長測定も行う事が出来ます。

 因みにうちの場合はX1納入時の操作説明中に指導員の方がその場で工具長測定マクロを組みながら使い方を教えて下さりました。

 ここに使われているタッチセンサーはメトロールの『高精度MT-タッチスイッチ〔Pシリーズ〕』と思われますが(憶測)、センサー単体の公称繰り返し精度0.0005mmと比較すると、実運用上の測定精度がそこまで高くありません。

 測定精度が安定しない主な理由としては、機械の熱変異とA軸の繰り返し位置決め精度の影響ではないかと考えています。なので今回の改良点はその2点。具体的には

  • 基準工具によるキャリブレーション
  • 測定後にA軸を戻さない

 5軸のマシニングで精度を管理しようと思うと、主軸ゲージラインを基準にするのが一番良いと思っています。なので本来なら工具長は信頼性のあるツールプリセッタで測るのが良いと思っていますが、残念ながら弊社にはツールプリセッタが無いので、機内で工具長を測っています。

 機内での工具長測定の問題点は、熱変異等の影響によって測定値がいつも同じにならないという事が挙げられます。

 3軸のマシニングならその時加工に使う工具の長さが揃っていれば絶対値としては間違っていてもそれ程支障がありませんが、5軸の機械では回転軸との関係が狂ってしまうと致命的なので、ゲージラインからの寸法がいつでも正しく測れる事がとても重要なのです。

 そんな訳で、正確にゲージラインからの長さを測った基準工具にてキャリブレーションしてから工具を測るようにすると、機械原点から測定子までの距離が変化していても正しい工具長を測れるようになります。

 基準工具の注意点は、基準工具の長さ自体が温度変化で変わる事です。線膨張率を12e-6[/K]とすると、基準工具の長さが100mmあって温度変化が10℃あれば 12e-6*100*10=0.012mm となり、結構無視出来ない量。

 A軸の繰り返し位置決め精度の問題は、A軸を動かさなければ問題にならないだろうという安直な考えから、キャリブレーション時に測定姿勢へ位置決めしたら、あとはずっとそのままにしておけばA軸の繰り返し位置決め精度の影響は排除出来ると考えました。勿論キャリブレーションだけでなく、工具長を測った後もそのまま。従来は律儀に測定が終わったら水平に戻していましたが、どうせ工具長を測る時は人が付いているのだから別に戻す必要も無かったのかも。その方が何本か連続で測る時には時間短縮になるし。

 こんな程度の事でも十分良い精度で測れるようになったので、今後は初品から安定した寸法で加工出来るようになるんじゃないかと期待します。

 因みにC軸がZ軸に対してちょっと傾いているので(X軸方向に0.009/100、Y軸方向に0.002/100くらい)、テーブル中心をテーブルの根元付近で測ると、バイスの上に掴んだワークの位置で測った時と一致しません。

 同様にA軸もX軸と平行ではないので、テーブルの心出しと座標変換(G68.2のマクロ版)の両方でそこら辺の誤差を見込んだ補正を掛けています。

 多分CNC-C00のロータリフィクスチャオフセット機能ではそこらの問題には対応出来ないんじゃないかと思いますがどうでしょうか。

 因みに大抵の機械では工具長測定装置はテーブル側に付いているので、5軸テーブルの心出しを行った際に傾斜軸中心のZ値に連動して工具長測定の基準高さパラメータも更新するようにするだけでも、工具長測定の精度が結構向上します。こうする事でいちいち基準工具でキャリブレーションしなくてもそれなりには測れるので便利です。


posted by antec at 12:11 | Comment(0) | 工作機械 | このブログの読者になる | 更新情報をチェックする