文字抜け防止のTVチェックの疑問

Question

文字抜け防止のTVチェックというものがあります。

マシニング側では　EOBを含めて一行の文字数が偶数なら受け入れ

奇数なら　弾くということで、　送信側との文字抜けを防止するという
ことですが、

よく考えれば無理ではないですか？

Gコードや　Mコードは　統一してM00など　3桁に統一できますが

座標などの文字数は　形状によって　奇数にも偶数にもなるから

すべての行が　偶数に終わるようになんか調整できますか？

送信ソフトはナスカマルチ通信というソフトを使っています。
そのソフトの設定はTVチェックを有効にしており、
もしNCプログラムの中に　奇数の行があれば　偶数にして機械に送るという
事です。　だから　私が　NCデータをM0と書こうが、M00と書こうが
関係ないみたいです。　つまり奇数になっている行だけに　選択的にデータを
追加して偶数にして送るという事です。

機械側では偶数のデータだけ受け入れ　奇数ならアラームをだします。

以前ソフトの設定をTVチェックを使うように設定し
２つの設定を試し
有効であった　偶数にして送るの方の設定にし
実際に機械との通信の成功を確認しました。

今の設定で問題はないはずですが、
なぜ今回はアラームが出たのでしょうか？
アラームの内容は　文字数が奇数の行があるという
TVチェックがオンの時にだけでるアラームです。

制御装置　ファナック　0MC　で　PSアラーム2　です。

ソフト側の問題しか考えられないですよね？

Answer

パリティチェックのことですね。

1ビット→８バイト

この場合１文字の単位は偶数

偶数にいくら掛け算をしても偶数ですね。

デジタル処理の最小単位で数字を表すと

0001→ 1
0010→ 2
0011→ 3
　　・
　　・
1000→ 8
1001→ 9
1010→ 10
　　・
    ・
1111→ 15

２進数や１６進数を理解していないと？？かな

大昔はこれから教わったが 
自分で基本プログラムをさわらなければ全く関係ないのだが
ＮＣの故障で基盤にLEDが 4～8ヶ付いてるケースでは状態か確認できる事もあります。

Answer

パソコン、ＮＣとも自動でやります。
　　コンピュータが扱う文字
　　http://homepage2.nifty.com/k_maeda/code/ascii.html

TVチェックは、文字数が奇数偶数のどちらかになるよう、ヌルコードを追加するしないで揃える方式なので、文字として顕れず人は関知できない。
ヌルコード → null → 何も無いの意味。コンピュータが扱う ASCII コードで00H。数字のゼロは30Hで違う。

もうひとつあるのがTHチェック。これは１文字ごとの間違いチェック。
ＮＣは最後まで紙テープが残った機械で、↑そこを見るほうが分かりやすい。
１文字を８穴単位で送受するが、実際は７穴で表現可能。残りの１穴を奇数／偶数のチェック（パリティビット）に使用している。

なので２重にチェックしているが、それでもエラーを完全に防ぐことはできません。間違いが二つ重なればチェックをすり抜けてしまう。

さらなる方法として、その集合ブロック毎での検査。
コンピュータ・ハードディスクへの読み書き、インターネットの通信も少し違う方式でチェックを行い、エラーとなればやり直しをしてます。

＞ソフト側の問題しか考えられないですよね？

常に引っ掛かるならその可能性大。
普段は正常で偶に引っ掛かったのなら、信号にノイズが乗ってエラーとなり、検出が正しく反応したか、ソフトが過剰反応であったか。前者なら誤動作から救われたと感謝すべき。

いずれにしろ出現頻度によって対応すべきや否やは違います。

＞信号にノイズが乗る原因
ラジオに雑音が入るようなあらゆる現象。カミナリが一番判りやすいが、他の電気器具からも、例えばケーブルを蛍光灯にベタッと付くほど接近させると起きるはず。
信号全てがメチャメチャにならず、１個だけのノイズを信号と見誤ればそうなります。

ケーブルがノイズを拾うのが原因なら、間を光ファイバーで結ぶコンバータを使う手もあります。
　　http://www.ibsjapan.co.jp/products/TCF-142.html

＞ソフトの過剰反応
訂正。ハードと言う方が合ってます。
信号のタイミングが送り手と受け手て僅か違う場合に、到着したのかしないのかの判断が変わってしまうことがある。これは転送速度（ボーレート）下げると改善します。

＞dnc運転
RS232Cはイマイチなので、やりたくないですけど、（信頼性高いＬＡＮはＮＣ側が高い）

＞TVチェックを働かせていたらその点は問題ないですか？
気休めかも。

常に出るエラーなら簡単だが、希なものほど原因を突き止めるには苦労すると思います。

最近他に質問があり回答してます。
　　http://mori.nc-net.or.jp/EokpControl?&tid=266416&event=QE0004
私も専門でなく、161件も貯まっているから見てくださいと逃げてます、、、

＞G01がG00
確率は非常に低い。
人間感覚と少し違い、回答（２）で書かれたテープ穴の１穴でミスすると何に化けるかの問題。

＞M03が抜け
まず起こらない。
Ｘ１２３．４５６を送って文字抜けしたとして、先頭ならＮＣエラーで止まる。後ならパスしてしまうが被害は少ない。
ということで暴走にまで至る確率はそれほど高くないです。

原発と同じように、ミスする確率ゼロでないと困ると言い出すと仕事はできない。
通信速度を遅くすればほぼ防げ、速くするのは慎重に見極めつつと言うしかないと思います。

＞メモリに入れる場合はドライランで確認したらあとは安心
ＯＫ。

暫く放置してたから、立て直し、、、まぁいいですけど、、、、他の質問を覗くと判るが点数稼ぎアソビ人の暴風が吹きまくっていて、その応対に割かれ、、、

理解しようとする努力は賞賛されるべきだが、根本は本を読むべきです。
それに RS232C は受け損なうとエラーで止まるのが欠点なので、突き詰めても限界あることも承知すべきです。

全般的に言えることはやはり速度に拘っておられる。
既に回答あるが、パリティＯＮにしても、下げればエラー出なくなるはずです。

ＮＣの頭脳はコンピュータ１個。通信もプログラムの理解もモーター指令も時間を細かく分けて処理をしている。通信はその重要度が低い、つまり時間の割振りが少ないように設計されている。なので通信で能力以上の速度を指定すると間に合わずエラーを返す。これはメーカの設計方針なので変更不可、手出し不能、文句も言えない。

なので通信速度を下げるしかない。そうすれは間に合わないことが減る。

送り手受けてのタイミング、0.00001秒ぐらいかナ？の問題なのでエラーはブロック途中では希で最後で起きる。

文字抜け防止のTVチェックとは？