DNC運転中の暴走

質問

現在NC横中グリ盤と、CFカードを使用する入出力機器をRS232Cケーブルで接続し、DNC運転を行っております。

　昨晩、担当のオペレーターがワークをセットしプログラムをスタートさせ、別の機械の段取りを行っていたところ、運転中の機械の主軸がワーク上から全然外れた位置を走っているのに気づき、慌てて機械を停止させました。その時、NCをリセットさせてしまったので、実行中のブロック指令がどうなっていたのか等の確認は出来ませんでしたが、誤加工形状から判断するに、プログラム開始から20ブロックほど進んだところで誤動作を起こしているようでした。

　NC自体が暴走したのか、入出力機器とNC間の通信に異常が起きたのかの判断をつけかねているのですが、仮に通信の異常が原因であった場合、パリティチェックをONにすれば、もし通信異常が発生した時アラームが出るだけで、誤動作は防げるのでしょうか？
　詳しい方、ぜひご教授願います。

回答No.7

noname#230359

回答（６）さん、回答（４）です。
ご指摘の通り、キーボードの打ち間違い及び符号の入れ忘れです。
ご迷惑御掛けしました。

回答No.6

noname#230359

回答(5)さんwrote、
>G02X-245.529Y19.921I4056.663J3908.351 は正しいNCデータではないと思います。

回答(4)さんwrote、
>>G90G92X0Y0Z100.
>>GOOX-246.036Y19.373
>>G01X-245.694Y19.75F500
>>X-245.692Y19.752
>>X-245.603Y19.844
>>G02X-245.529Y19.921I4056.663J3908.351
>>G03X-245.448Y20.005I-3344.106J3222.212

>>G02X-245.529Y19.921I4056.663J3908.351
ではなく、
>>G02X-245.529Y19.921I4056.663J-3908.351
ですね。
これは、回答(4)さんが本文を書かれたときに「-」を付け忘れただけでは？

>>GOOX-246.036Y19.373

これも「GOO(オー)」ではなく「G00(ゼロ)」ですし、ここからもコピペされたものではないことが推測できます。

回答No.5

noname#230359

回答ではないのですが。

回答（4）のかたと同じような経験があります。

G02X-245.529Y19.921I4056.663J3908.351 は正しいNCデータではないと思います。
円弧の始点と終点と円弧の中心位置が矛盾しているのではないでしょうか。
この原因はきっとCAMのバグです。

高価なCAMでもたまににたようなバグNCデータを作ることがあります。

NCデータのシミュレーションソフトで調べて見るとわかります。
ただシミュレーションソフトでも無視するのがあリます。

暴走と決め付けないでまずNCデータを疑うほうが先かもしれません。

回答No.4

noname#230359

はじめまして。
参考になるかどうかはわかりませんが、私共で使用している工作機械（制御装置はファナックの６Ｍと１０Ｍです）で、10Mに限って、下記のプログラムを実行しようとすると、必ず暴走します。弊社の別の工場にある同型機でも試しましたが、やはり暴走しました。
%
G90G92X0Y0Z100.
GOOX-246.036Y19.373
G01X-245.694Y19.75F500
X-245.692Y19.752
X-245.603Y19.844
G02X-245.529Y19.921I4056.663J3908.351
G03X-245.448Y20.005I-3344.106J3222.212
・
・
・
プログラムの7行目（G02の円弧指令のブロック）で前後のブロックの移動距離はわずかですが、ここで暴走を始め、機械のリミットを踏むまで移動し、アラームで止まってしまいます。メモリ運転でもDNC運転でも試しましたが、結果は同じでした。しかし同じプログラムを６Ｍの制御装置で実行すると、何の問題もなく（暴走しない）動きます。制御装置によって微小区間の大きい円弧指令の処理が苦手なようで、メーカーのサービスマンを呼んで見てもらいましたが解決しませんでした。

23年間工作機械と携わって来て、こんな症状は初めてでした。

結果、ＣＡＭのプログラム出力時、プログラムデータ量を減らす目的で円弧を入れられる部分は入れる設定にしていましたが、以後は危険なので円弧指令は出力しない設定にしました。機械を入れ替える予定も無いので、今はこの状態で稼動させていますが、それ以後は暴走は無くなりました。

追伸
これはあくまで、弊社の機械に限っての事なので、他所様の機械で暴走するとは限りませんので、その点はご理解下さい。
また、borikuso様の症状とは違うかもしれませんが、あくまで参考例として書き込みさせていただきました。

回答No.3

noname#230359

も一つ追加です。通信機器の電源コンセントは何処から？NC機に備え付けのコンセントはノイズがいっぱいのことが多いので普通の壁面から取りましょう。

お礼

再びご回答いただき感謝しております。

　電源については壁面の100Ｖ電源を使用していたのですが、電圧を測定した結果、94Ｖしか電圧が掛かっていないことが判明いたしました。
　外部入出力機器メーカーに問い合わせたところ、動作保証範囲が100～240Ｖということでしたので、現在は遊休中のトランスを引っ張ってきて、三相200Ｖのうち２本を使い、110Ｖに下げて使用しております。

　とにかく、はっきりした原因が掴めない状況なので、考えられる要因は全て潰しているのが現状です。

　大変参考になりました。有難うございます。

回答No.2

noname#230359

現在、ISOまたはEIAコードで通信されているのでしたら、パリティチェックはされているでしょう。(ISO…偶数・EIA…奇数)

ですが、パリティチェックでは、偶数個のビット誤りや、キャラクタそのものが失われたりした場合等は、エラー検知されません。

現在、プロトコルBで通信されているなら、NCメーカも推奨するプロトコルAでの通信とすれば、チェックサムによるエラー検知もされ信頼性は上がりますが、それでも完全ではありませんし、CFカード入出力機とNCがプロトコルAに対応している必要があります。

意味が伝わっていないようなので。追記します。

ISOもEIAもデータ部が7bitで、残りの1bitがパリティビット、合わせて8bitとなっています。ですので、
◇ISOのコードチェックをしていれば、偶数パリティチェック。
◇EIAのコードチェックをしていれば、奇数パリティチェック。
をしていることになるわけです。

NCのパリティチェック機能は、この8bitにさらにパリティビットを付けてパリティチェックをするものです。
ですので、8bitJIS・EBCDIC等のデータ部が8bitのコードに使用する場合には効果があります。

お礼

ご回答いただきありがとうございます。
　今までISOコードで通信していたのですが、NCと外部機器のデフォルト設定がパリティチェック無しになっていたので、そのまま使用していました。
　現在はパリティチェックを有効にして使用しております。

回答No.1

noname#230359

はいと簡単に言えればいいのですが事は相単純ではない。一般にNCでパリティチェックというと8ビット一文字の8ビット目のパリティチェックですが情報理論的には完全ではないです。2ビット誤りを検出できないから。
基本的には誤りの原因を除くのが一番いい。ノイズ源を除去、遠避ける。２３２のコードをシールド、耐ノイズ性の高いものに変えるとか、CFカードを使用する入出力機器のグランドをきちんとするとか。

お礼

ご回答いただきありがとうございます。
　現在、シールド性の高いケーブルを手配中です。なお、入出力機器の入力電圧（工場の100Vコンセント）が94Vと低い数値であることが判明したため、電源についても対策中です。
　大変参考になりました。ありがとうございます。