タイトル : Re^3: MScommの通信について 投稿日 : 2012/06/01(Fri) 13:08 投稿者 : 魔界の仮面弁士
> データビット数・パリティービット数・ストップビット数の修正により解決致しました。 おぉ、良かったです。 > 魔界の仮面弁士さんカラ教えて頂いた通りに確認してみたのですが、 ごめんなさい、コードそのものの内容については忘れてください。 あれは、そういう変換を行う必要があるという意味ではなく、どちらかといえば逆で、 あれと同じような誤変換が、どこかで間違って発生しているかも、という程度の話です。 ---------- 以下、超蛇足 ---------- そもそもは、問題箇所の切り分けが必要と思い、頭の中で (1)環境依存性(OSやハードなど) (1.1)他のOSで実行して再現するか? (1.2)ハードウェアの交換で結果が異なるか? (2)再現性 (2.1)特定のデータだけで再現するのか? (2.2)化け方は一定か、同じデータでも化け方が異なることがあるか? (3)利用方法 (3.1)コントロールの使い方や設定に問題は無いか? (3.2)コントロールは正常でも、受信データの確認方法が間違っていたりはしないか? という回答手法を描いたのですが、まず、(3.2) は問題が無さそうだと思いました。 あの場合の Hex 関数が、文字化けを誘発させることは考えられないので、そうすると >> Buffer の中身は、すでに化けてしまっているようですね。 であろうと判断しました。 次に(3.1)の利用法ミスの可能性ですが、化けた理由を考えるにあたり、最初に疑ったのが 「Binary ではなく Text で扱われているのではないか」という仮説でした。 そのために、とりあえず StrConv する実験コードで化け方を比較してみた、 というのが先のコードです。 仮に同じ化け方になるようなら、InputMode 指定が Text になっているか、または 受信時の変数の受け方(String 変数で受けるなど)に問題があることになりますので。 ところが、結局は異なる化け方でしたし、受信コードも >>> MSComm.InputMode = comImputModeBinary >>> Dim Buffer() As Byte >>> Buffer = MSComm.Input であれば問題無さそうなので、実際には、あのコードは 完全に蛇足だったわけです。混乱させて済みません…。 で、Text 以外で可能性がありそうだと思い当たったのが、通信設定のミスであり、先の >> Settings プロパティの指定が適切でないとか という回答の部分になります。 とはいえ、私は通信系・制御系には疎いので、具体的な情報が出せるわけでは ありません。そのため先の回答では >> …でしょうか(適当)。 といった逃げ口上を書いていたりします。 通信系の話題だったので、ここの常連者回答者のオショウさんであれば、 きっと具体的な話もできるのだろうな……とは密かに思っていたのですが、 あの時点ではまだ誰も回答をつけていない状態だったので、とりいそぎ 投稿してみました。ですが、投稿内容の見直しも不十分だったので、 かえって混乱させてしまったかも知れませんね。失礼しました。 # 実際には、ほぼ同時にオショウさんの回答もついていたし。orz |