タイトル : Re^2: 経過報告 投稿日 : 2010/02/08(Mon) 10:53 投稿者 : ぽると
オショウさん アドバイスありがとうございます。 > > @FAネットワークの通信量 > パケットモニタとか入れて計測したんですか? パケットモニタにて1週間通信量を計測してもらい、 装置で現象が発生していた時間と照合しました。 通信量自体にもあまり変化は見られませんでした。 > > A装置側の機器異常のチェック > 希望的観測のような・・・何をどうやって調べたか・・・ > もっと物理的に調べる方法を導入しないと、調査にならないかと。 希望的・・・というのは当たりかもしれません。 調査方法について詳細を聞いてみたところ、 「PCを繋いで数回シリアル通信テストして通信できていた」とのことだったので。 継続調査・・・ということになりますね。 > > BPC1の異常チェック > 異常って目に見えるくらいなら、もう終わってワす。 > オシロとかレコーダー入れて波形を観測した結果ということなら納得します。 計測器を使うのは考えに無かったです。 今回の現象の調査とは別としても、今後の調査方法として考えようと思います。 > > CLANやシリアルケーブルの再点検 > ええ〜と、FA関係では、ノイズ対策品というものは無意味。 > 光ファイバ入れているなら納得。メタルケーブルなら鉄管に入れて > 第一種の電気工事でアースに落としてあるから・・・とかの保障が > あるならばよし。 > それでもアースから回り込むと云う場合を想定して、特別な避雷機や > 逆流遮断回路が入っている。とか・・・ そうなんですか! 正直なところ配線等にはあまり詳しく知らないです。 とりあえずこちらで出来るのはノイズ対策品使うくらいでいいかと思っていました。 > > DTCP/IP通信とシリアル通信のタイムアウト時間の調整( テストPG ) > TCP/IP側には、パケットモニタ入れてログ解析するくらいでないと > 原因の切り分けの明確な材料にならない。 Dについては中断してます。 > > EACK、NAK等のチェック処理の実装テスト( テストPG ) > NAK時の再送要求が行われて、リトライ動作して保障されるアルゴリズムが無いなら、 > その有用な機能を使っていない・・・ように思いますが。 全くもってその通りでして、何でこんな作りになっているのか...。 チェック処理の実装についてはテストPGの方では動作確認がとれたので、 近いうちに本番PGにも追加する予定です。 > > FDoEvents の整理 > この辺は、プログラムのコーディング・アルゴリズムに依存するので > 一概には言えない・・・まぁ〜原因にはよくなりますが。 > どんな順序で動作しても、非同期通信が成り立つように作ってあるならば、 > DoEvents入っていても問題にならない・・・ 必要に応じて使われていていればいいんですが、 今回の場合ですと、色を付ける処理とかで使われており、別段処理に時間がかかるような ところでもなかったので外しました。 > ※ 非同期スレッドと非同期スレッドを同期させる・・・みたいな仕組みを > ちゃんと作れれば、FA関係は怖くない・・・シリアル通信の同時 > 8ポート通信+GP-IB機器12台+ネットワーク(DBサーバーやFTP) > それらを絶え間なく通信させて24時間365日稼働してますが、 > もう数年のオーダーで特に問題なし・・・HDDやPCが壊れるのが先! すごいですね。 1ポート+ネットワークで苦戦している私にはまだ難しそうです・・・。 > > Gチェックサムについて > 勿体ない・・・ > あ!チェックサムありはいいけど、チェックサムチェックしてます? 現状のPGには受信後のチェックサムについても、 ACK等と同じく全くチェック処理がないですね。 実装予定のACK等のチェック処理に受信後のチェックサムのチェックも入れてあります。 > > 上記現象はデバックモードではなく実行ファイル形式で動作させている場合のみ > > 出る現象のようです。 > マイクロソフトの仕様というか、バグというか・・・ > メッセージボックスは結構問題になるので、24時間稼働装置のPCソフトでは、 > メッセージボックスは使わない。 > ListViewとかに履歴表示を行うようなことにしている・・・ 応急対策ですが、メッセージボックスについてはリストボックスに表示する形式しました。 |