VB6.0用掲示板の過去のログ(No.2)−VBレスキュー(花ちゃん)
[記事リスト]
[新規投稿]
[新着記事]
[ワード検索]
[管理用]
| 投稿日 | ： 2005/07/26(Tue) 11:43 |
| 投稿者 | ： G13 |
| Ｅメール | ： |
| ＵＲＬ | ： |
| タイトル | ： Re^4: MSCommのOn_Comm受信 |
おはようございます。
仕様がある程度理解でしました。
> 可変長は UA DLNGH DLNGL BCC の四つになります。
> UA：従属局のアドレス
> DLNGH：TEXTデータ（最大2000）の上二桁の値になります
> DLNGL：TEXTデータ（最大2000）の下二桁の値になります
> BCC：DLE DLNGH DEL DLNGL TEXTデータ DLE ETX がBCCの計算対象範囲となっています。
>
> >*1:ポーリングに対する応答か否定応答(NAK)を判別する種別コード見ないな感じですか？。
> おっしゃる通りです。ポーリングに対しNAKかレスポンスを返す仕様となっています。
> また、レスポンスの作りはセレクティングと酷似しています
> 参考：
> ポーリング DEL POL DLE HA DLE UA という6バイト固定の構造です。
> 他にACK NAK ENQ などありますが、2バイト目のPOLの箇所が ACK NAK ENQ と置き換えるだけで別コマ
ン
> ドとしています。
> セレクティングとレスポンス
> セレクティング DEL SEL DLE HA DLE UA DLE DLNGH DEL DLNGL TEXTデータ DLE ETX （DLE）BCC
> という構造です。最後のBCCの前のDLEが()で括られている理由はBCCが10のときはDLEを付加するという
> 仕様のためです。
> レスポンスに関して、6バイトの固定コマンドと同じように２バイト目をRSPに置き換えることで別コマ
> ンドとしています。
>
> >*2:データ長の算出開始位置ですか？
> 上記記載
TEXTデータ部のみのデータ長ということを理解しました。
> >*3:データ長(High/Low)は、どこからどこまでの長さが指定されていますか？。
> 上記記載
了解です。
これがフレーム全体の長さを示すかも知れないと思っておりましたが、*2の通り
TEXTデータの長さのようですから、受信判定には使用しなくても良いでしょう。
> >*4:フレームの最終を示すコードですか？
> 構造は上記に記載した通りなのですが・・・最終を示すのはETXかBCCなのでしょうが、私にはどちらが
> 最終フレームとして扱って良いかわかりません。最後についているという単純な意味合いでBCCだと認
> 識していました。
いえ、最終はETXです。BCCは送るデータによって可変するので。
ETXを検出して、後ろの1バイト(DLEが割込む場合2バイト)をBCCと扱えばいいです。
> >*5:BCCは、どこからどこまでをどう計算した値ですか？
> 上記記載
STXは含まない、ETXは含むなのですね？。ま、仕様なのか・・・。
BCCはフレームが受信して、フレーム形成が正しいか否かの検定の際、受信したフレームデータから
計算して正否を判定しなければなりません。
> >送るのが、NAKとセレクティングですか？又、セレクティングにデータが引っ付いている
> >のですか？どんなプロトコルですか？
> 種類と省略兼ねてNAKとセレクティングを挙げましたが実際は上記記載のようにいくつか存在します。
> 上記の説明で先回答となってしまいます。
> プロトコルに関して、的外れになる予感がしますが、そもそもこのプロジェクト名が「××（社名）プ
> ロトコル」なのです。
> そのプロトコル仕様書に沿って作っている感じです。
>
> >NAKとかセレクティングって、普通コマンドボタンからいきなり送信するって
> >普通ないですよね？テストプログラムなの？
> 上記の通り、客先ではなく、メインでプログラムを書いている方は別に存在し、その方のデバック用の
> ツールとして作成しているため
> 「手動でもコマンドを投げれるように」との指示の元作成しています。
>
> >COMM_CODE.DLNGH って、バイト型の変数だと思うんですが、文字列をセット
> >していますね。VAL関数とかで、数値に変換してから代入しましょう。
> 有難うございます。まさにその通りで、特定の処理のときはツジツマが合いましたがパターンを変える
> とダメになっていました。
> なんとか、原因をつきとめれたのですが、まさに指摘されている箇所でした。
>
> >データに、DLEがあったら、DLE+DLEにしていますよね。その場合に、
> >データ長は増やさないのですか？増やさない場合は、受信側が単純に
> >DLNGH・DLNGLからデータの長さがわからないので、受信側が面倒にな
> >りますね。
> 仕様上テキストデータ内に&H10（DLE）と同じものがあった場合、次に来る値も&H10（DLE）と
> 二つ連な
> って初めて1バイトの＆H10として認識させる仕様になっています。
> これは従属局がマイコンになる予定があるらしく、そういった透過処理が必要になるみたいです。
> 受信側も少し工夫がいると言われているので、これは仕様のようです。（自分ではまだわかっていな
> く、「みたい」とか「のようだ」の表現が多く申し訳ありません。）
テキストデータ内に、&H10,&H10という連続したデータが存在しないことを前提としている。
ということでしょう。
> >データに、DLEがあったら、DLE+DLEにしていますよね。その場合に、
> >データ長は増やさないのですか？
> これは加算しないようです。受信側でも加算されたものを減算させ真の値と扱うようです。
了解しました。
非常に単純に、受信した1フレームを取り出せそうですね。
DLE(&H10) + ETX(&H02) を検出するまで1フレーム分のデータは受信し切れていない。
と言えます。但し、この後に続くBCCを取り出す処理は必要ですけど。
受信カウンタ(グローバル変数)を準備し、-1:未受信。0以上を受信中とする。
On_Commイベント内
受信開始からバイト配列データを確認して、DLE & ETXが見つかるまで、バイト配列の
グローバル変数へデータをコピーしていく。
DLE & ETX が検出されたら、BCCの取り出しとして、次の1バイトを検定=&H10か否かで、
もう1バイトを取り出す。
これで1フレームの取り出しが完了。
フレーム内コード及び、BCCを検定し、正常ならテキストデータを表示する。
＃言葉で書くと判りにくいかも。
- 関連一覧ツリー
（★ をクリックするとツリー全体を一括表示します）
- 返信フォーム
（この記事に返信する場合は下記フォームから投稿して下さい）