tagCANDY CGI VBレスキュー(花ちゃん)の Visual Basic 6.0用 掲示板
VBレスキュー(花ちゃん)の Visual Basic 6.0用 掲示板
[ツリー表示へ]  [ワード検索]  [Home]

タイトル Re: 経過報告
投稿日: 2010/02/06(Sat) 01:04
投稿者オショウ
今回の問題とは直接的には関わらないかもしれませんが
一応、突っ込んでおきます。

> @FAネットワークの通信量
>   担当者に確認してもらいましたが、通信に影響が出るほどの
>   通信量の行き来は検出されなかったそうです。

  パケットモニタとか入れて計測したんですか?

> A装置側の機器異常のチェック
>   割と年数のたっている装置なので先日もパーツを交換したそうですが、
>   PCとの通信関係に影響しそうなところは異常は出ていないそうです。

  希望的観測のような・・・何をどうやって調べたか・・・
  もっと物理的に調べる方法を導入しないと、調査にならないかと。

> BPC1の異常チェック
>   ハードウェアではTCP/IP、シリアル供に故障等はありませんでした。
>   停止可能日に半日ずつ単体テストを実施。

  異常って目に見えるくらいなら、もう終わってます。
  オシロとかレコーダー入れて波形を観測した結果ということなら
  納得します。

> CLANやシリアルケーブルの再点検
>   ノイズ対策済みのものを使用中。

  ええ〜と、FA関係では、ノイズ対策品というものは無意味。
  光ファイバ入れているなら納得。メタルケーブルなら鉄管に入れて
  第一種の電気工事でアースに落としてあるから・・・とかの保障が
  あるならばよし。

  それでもアースから回り込むと云う場合を想定して、特別な避雷機
  や逆流遮断回路が入っている。とか・・・

> DTCP/IP通信とシリアル通信のタイムアウト時間の調整( テストPG )
>   継続実施中。

  TCP/IP側には、パケットモニタ入れてログ解析するくらいでないと
  原因の切り分けの明確な材料にならない。

> EACK、NAK等のチェック処理の実装テスト( テストPG )
>   継続実施中。
>   チFック処理が無い理由は特にないようです。逆になんで無いのか聞かれました...。

  NAK時の再送要求が行われて、リトライ動作して保障されるアルゴリズム
  が、無いなら、その有用な機能を使っていない・・・ように思いますが。

> FDoEvents の整理
>   シリアル通信処理以外での DoEvents は全て外しました。
>   しかしながら現象は解消されませんでした。

  この辺は、プログラムのコーディング・アルゴリズムに依存するので
  一概には言えない・・・まぁ〜原因にはよくなりますが。

  どんな順序で動作しても、非同期通信が成り立つように作ってあるな
  らば、DoEvents入っていても問題にならない・・・(私のコードには、
  結構入っている。なんせ結構マルチスレッド的に作ってあるもので)

※  非同期スレッドと非同期スレッドを同期させる・・・みたいな仕組み
  をちゃんと作れれば、FA関係は怖くない・・・シリアル通信の同時
  8ポート通信+GP-IB機器12台+ネットワーク(DBサーバーやFTP)
  それらを絶え間なく通信させて24時間365日稼働してますが、も
  う数年のオーダーで特に問題なし・・・HDDやPCが壊れるのが先!

> Gチェックサムについて
>   現在のシリアル通信でもチェックサム有りで通信しています。
>   ただ、肝心のNAKチェック処理が無いので機能していない。

  勿体ない・・・

  あ!チェックサムありはいいけど、チェックサムチェックしてます?

  受信した段階で再度チェックサムを計算しなおし、受信データに付与
  されているチェックサムと一致するかを確認する。

  チェックサム付きでもチェックしていなければ、結果、何もしていな
  いのと同じ・・・

> 上記現象はデバックモードではなく実行ファイル形式で動作させている場合のみ出る現象のようです。
> 何故かはよくわかりませんが...。

  マイクロソフトの仕様というか、バグというか・・・

  メッセージボックスは結構問題になるので、24時間稼働装置のPC
  ソフトでは、メッセージボックスは使わない。
  ListViewとかに履歴表示を行うようなことにしている・・・

以上。

- 関連一覧ツリー をクリックするとツリー全体を一括表示します)

古いスレッドにレスはつけられません。