こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

締切り済みの質問

サムチェックのルール

VB6.0を使用して、画像処理プログラムの開発を行っている者ですが、処理結果を別機器(PLC)へ送信しなければなりません。初めてなのですが、RS232Cでデータ通信を行おうと考えております。
いろいろと書物やWEBを探してみると、サムチェックを行うのが常識とのことです。また、今回扱うデータは6Byteの計測データで、プラスサムチェックを2Byteで行いたいのですが、符号や小数点はサムチェックとして合計するものなのでしょうか?
(0~9までのアスキー文字ならばそのまま合計することは簡単です)あるいはアスキーコード変換してから全てを合計し、合計値の最下位2ビットをサムチェックに使用するのが正しいのでしょうか?
そんなもの常識だろ!と思われる方が多いかと思いますが、ご回答の程よろしくお願い致します。

投稿日時 - 2007-01-16 11:40:50

QNo.2669923

すぐに回答ほしいです

このQ&Aは役に立ちましたか?

3人が「このQ&Aが役に立った」と投票しています

回答(4)

ANo.4

#3 です.ちょっと訂正します.

・「途中に ETX が現れれば…」をすべて
 「途中に STX または ETX が現れれば…」に変更.
 また,このチェックを (2) にも適用する.

> (5) 1バイト受信する.
>   このバイトが ETX でなければデータ長部のエラーなので (8) へ.

より正確には,「データ長部またはこのバイト (ETX) のエラー」.

投稿日時 - 2007-01-19 10:39:12

ANo.3

> 対象となるバイト列というのは常識的に考えて、STXやETXも含めるのでしょうか?

含めません.STX,ETX,データ長は次に示すように,別の方法でチェックされる
ことになるからです.

#1 の伝送フォーマットに対する受信アルゴリズムの一例は次のようになります.

(1) データを受信し,STX が現れるまで読み飛ばす.
(2) データ長を受信する.データ長自体の長さやフォーマット (10進数字だけを
  使うか否か) が決まっている場合,この段階でチェックする (値そのものは
  この段階ではチェックできない).エラーならば (8) へ.
(3) データ部を受信する.
  途中に ETX が現れればデータ長またはデータ部のエラーなので(8) へ.
(4) チェックサムを受信する.
  途中に ETX が現れればデータ長またはチェックサム部のエラーなので(8) へ.
(5) 1バイト受信する.
  このバイトが ETX でなければデータ長部のエラーなので (8) へ.
(6) データ部のチェックサムを計算し,受信したチェックサムと照合する.
  不一致ならばデータ部またはチェックサム部のエラーなので (8) へ.
(7) レコード受信成功
  ・成功を送信側に伝えるため ACK (=&H06) を返す.
  ・受信したデータ部を処理する.
  ・次のレコードを待つため (1) へ.

(8) エラー処理
  ・受信失敗を送信側へ伝えるため NAK (=&H15) を返す.
  ・受信したデータを破棄する.
  ・次のレコードを待つため (1) へ.

このアルゴリズムからわかるように,STX,ETX,データ長部にエラーがあれば,
そもそも受信されないか,受信してもチェックサムを計算することなく破棄されます.

投稿日時 - 2007-01-19 10:01:09

ANo.2

★チェックサムの他に CRC もあります。
・チェックサムよりは CRC16、CRC32 の方が正確ですが、かなり複雑で計算時間や
 検索するためのテーブルがメモリを占めます。→といっても 1KB ですが…。
・チェックサムは単純にバイト列を加算するのが基本ですが、これだと順序が逆転
 しているデータは同じデータとして誤解します。
・つまり、『ABC』という文字列と『CBA』という文字列では両方とも『198』という
 数になりますのでデータの誤りの判定できません。→CRC のアルゴリズムなら
 判定できますが…。
・そこで、もうちょっと正確にするための『変則チェックサム』がいろいろとあります。
・私が以前に考えたタイプを紹介します。

●サンプル
short FuncCalcCheckSame( const char *string, size_t size )
{
short code;

for ( code = 0x0000 ; size != 0 ; size-- ){
code <<= 1;
code ^= *string++;
}
return( code );
}

最後に:
・『code <<= 1;』のシフト部分を『2』とか『3』にするといろいろと精度などが
 変化します。→データによりけりですけど。
・『code ^= *string++;』の部分は足し算の代わりに『排他論理和』を使っています。
・この方が『+』命令よりは高速に計算されます。→アセンブラ・レベルでのお話。
・Visual Basic では『XOR』でしたっけ?→私は C/C++ 言語専門なので上記のサンプル
 はその言語のサンプルです。
・上記のは『short』形の 16 ビットですが、『long』型などの 32 ビットにすると
 単純に精度がかなり上がります。
・また、上記の方法ならば『ABC』という文字列と『CBA』という文字列(データ)を
 正しく誤りと判定できます。
・以上。おわり。

参考URL:http://laputa.cs.shinshu-u.ac.jp/~yizawa/InfSys1/advanced/crc/

投稿日時 - 2007-01-18 05:17:13

お礼

ご回答ありがとうございます。
サムチェックと一口に言ってもいろいろとあるのですね。
サンプルまで付けていただいて。。。すみません。

投稿日時 - 2007-01-19 09:00:57

ANo.1

すぐコメントがつくかと思ったのになかなかつかないようなので…

チェックサムは普通,対象となるバイト列のすべてのバイトの値 (0~255) を
単純に加算して,その下位1~2バイト程度を使用します.

そうすることにより,

・送信するデータの形式や内容にかかわらず,どんなデータでも扱うことができる.
 → 将来,データの仕様が変更・拡張されても,チェックサムを計算するプログラムは
   変更する必要がない.
・処理が単純なのでソフト開発も簡単.


> 符号や小数点はサムチェックとして合計するものなのでしょうか?

> (0~9までのアスキー文字ならばそのまま合計することは簡単です)
> あるいはアスキーコード変換

そういうことをすると,上で書いたことと正反対に,

・処理が複雑になり,ソフト開発に余分な手間がかかる.
・将来,送信したいデータのフォーマットが増えたり変わったりしたら,
チェックサムプログラムも変更しなければならない.
・通信プログラムの用途 (送信できるデータの種類) を限定してしまう.

という具合に,デメリットしかありません.

開発するソフトを,わざわざ余分な手間をかけて劣ったものにするのは
アホらしいとは思いませんか?

「チェックサム」で Google 検索
http://www.google.co.jp/search?sourceid=navclient-ff&ie=UTF-8&rls=GGGL,GGGL:2006-34,GGGL:ja&q=%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%82%B5%E3%83%A0



次に伝送フォーマットの一例を挙げます.

・STX (=&H02)
・データ部のバイト数 … テキスト形式 (10進数字列)
・データ部 (バイト列) … 主にテキストデータ
・チェックサム
・ETX (=&H03)

STX で始まり ETX で終わるフォーマットは,主にテキストデータを送る場合に使われます.
(STX も ETX も ASCII 制御文字です.)

同様の伝送フォーマットを Google 検索 (+チェックサム +STX +ETX)
http://www.google.co.jp/search?sourceid=navclient-ff&ie=UTF-8&rls=GGGL,GGGL:2006-34,GGGL:ja&q=%2B%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%82%B5%E3%83%A0+%2BSTX+%2BETX

投稿日時 - 2007-01-18 00:20:05

お礼

ご回答ありがとうございます。

>対象となるバイト列のすべてのバイトの値 (0~255) を単純に加算して,その下位1~2バイト程度を使用

対象となるバイト列というのは常識的に考えて、STXやETXも含めるのでしょうか?

投稿日時 - 2007-01-19 08:52:53

あなたにオススメの質問