福福電子工房

福福電子工房 HOME

無料相談やってます！

RS-232Cについて分らない事があれば、メールでお気軽にお問い合わせください。
弊社でわかる事であれば、無償にてお答えいたします。
お問い合わせいただいた内容は、このページでご紹介する場合がございます。予めご了承ください。
無料相談はメールのみの受け付けです。お電話では、お答えできません。

掲載リクエスト受付中です！

次のページから、匿名で記事の掲載をリクエストできます。

掲載リクエストページ

このページに載せてほしい情報があれば、上記ページよりリクエストしてください！

目次

• はじめに
• D-SUB 9pin コネクタ
• ピンアサイン
• ストレートケーブル と クロスケーブル
• 調歩同期方式(非同期・ASYNC)
• 通信書式
• 通信速度
• 通信プロトコル
• 通信テキストの考え方
• 通信ライン(半二重と全二重)
• RS-422とRS-485
• ポーリング
• トークンリング
• BCC
• モデム
• 制御線に関して
• 通信速度の限界
• ターミネーター(終端抵抗)
• 規格に対する誤解
• 今後のRS-232C
• 制御コード一覧
• 通信の検査方法
  
  
• 通信時間の計算方法
  
• 質問とその回答
  
  
• デバッグ・不具合調査の方法 【 失われた給料を取り戻す！ 】

シリアル通信トラブルシューティング

• 送信した内容と異なる内容を受信する
• なんだかレスポンスが遅い？
• 相手機器から通信異常が発生する
• こちらから送信したコマンドと異なる動作を相手機器が行う
• 相手機器から応答が無い
• まれに通信異常が発生する
• まれに誤動作が起きる

■はじめに

RS-232Cとは、中低速のシリアル通信で最も普及している通信規格のひとつです。
正確には、EIA-232と言うそうなのですが、誰もそんな呼び方はしていません。(少なくとも私の接している業界では…)
RS-232Cの最後の“C”も元々はバージョンだったらしく、CのほかにBやDが有ったような記憶があります。
でもでも、みんな単純に“RS-232C”と呼んでいます。
このページでも、RS-232Cの正確な規格ではなく、実践的・一般的な説明を行いますので、細かいことにこだわらず、単にRS-232Cと呼びます。
また、RS-232C通信と言っても更に様々な方式が存在します。このページでは、その中でも最も簡単で広く使用されている調歩同期方式(ASYNC)について説明しています。

さて、RS-232Cとは、中低速のシリアル通信と説明しましたが、シリアル通信って何でしょう？
シリアル通信の他にはパラレル通信があります。それぞれ一長一短です。
シリアル通信とパラレル通信の特徴を簡単に説明すると、信号線が１本か複数本か？と言った違いです。

シリアル通信は、1バイトのデータを1ビットずつ1本の信号線で送信します。
パラレル通信は、1バイトのデータを一括で8本の信号線で送信します。(16bitや32bit、またはそれ以上を一括して送信する場合もあります。)

パラレル通信は、全ての信号線のタイミングを揃えなければ成りません。距離が長くなるほどタイミングのズレが生じ、伝送が難しくなります。
また、電線のコストが何倍にも膨らみます。

このため、伝送距離が短ければパラレル通信が速度的に有利ですが、伝送距離が長くなるほどシリアル通信が採用されます。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■D-SUB 9pin コネクタ

PC/AT互換機(Windowsパソコン)のCOMポートは、『D-SUB 9pin』(デーサブキューピン)コネクタが標準です。
プラグ(オス)がパソコン側。ソケット(プラグ)がケーブル側です。
各コネクタのピン配置は、次の様になっています。

---

---

---

上の図は、コネクタを正面から見た時のピン番号です。

プラグは、オス。ソケットは、メスのコネクタです。

メーカーカタログ等では、コネクタに『プラグ』または『ソケット』と表記する事が多です。

業界によっては、オス・メスが主流の場合もあります。(私の業界ではオス・メスが普通です。)
あまりこだわらず、関係する業界の呼び方で話をしてください。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■ピンアサイン

PC/AT互換機のCOMポートピンアサイン D-SUB 9pin
Pin No.	信号名		備考
1	DCD		キャリア検出
2	RXD		受信データ
3	TXD		送信データ
4	DTR		データターミナルレディ
5	GND		信号グランド
6	DSR		データセットレディ
7	RTS		リクエストツーセンド
8	CTS		クリアツーセンド
9	RI		被呼表示

モデムのCOMポートピンアサイン D-SUB 25pin
Pin No.	信号名		備考
2	TXD		送信データ
3	RXD		受信データ
4	RTS		リクエストツーセンド
5	CTS		クリアツーセンド
6	DSR		データセットレディ
7	GND		信号グランド
8	DCD		キャリア検出
20	DTR		データターミナルレディ
22	RI		被呼表示

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■ストレートケーブル と クロスケーブル

ストレート接続 D-SUB 9pin
オス			メス
信号名	Pin No.		Pin No.	信号名
DCD	1	→	1	DCD
RXD	2	→	2	RXD
TXD	3	→	3	TXD
DTR	4	→	4	DTR
GND	5	→	5	GND
DSR	6	→	6	DSR
RTS	7	→	7	RTS
CTS	8	→	8	CTS
RI	9	→	9	RI

上図がストレートケーブル結線です。

一般的にストレートケーブルは、1番ピンは1番ピンへ、2番ピンは2番ピンへと全てのピンが相手コネクタの同じピン番号へ接続されています。

クロス接続 D-SUB 9pin
メス			メス
信号名	Pin No.		Pin No.	信号名
DCD	1		未接続
RXD	2	→	3	TXD
TXD	3	→	2	RXD
DTR	4	→	6	DSR
GND	5	→	5	GND
DSR	6	→	4	DTR
RTS	7	→	8	CTS
CTS	8	→	7	RTS
RI	9		未接続

上図がクロスケーブル結線です。

クロスケーブルは、様々な種類があります。
上図は、一般的な結線ですが、標準と言う訳ではありません。

RS-232Cには、端末仕様(ターミナル仕様)とモデム仕様の2種類の仕様があります。

端末仕様とモデム仕様の違いは、次表の用に入出力方向の違いです。

信号の入出力
信号名			端末仕様	モデム仕様
TXD			出力	入力
RXD			入力	出力
RTS			出力	入力
CTS			入力	出力
DSR			入力	出力
GND			-	-
DCD			入力	出力
DTR			出力	入力
RI			入力	出力

端末仕様とモデム仕様を接続する場合は、ストレートケーブルを利用します。

端末仕様と端末仕様を接続するなら、クロスケーブルを利用します。
モデムは通常は受け身です。このため、モデム仕様同士を接続する事は、特殊な場合を除き、ほとんどありません。
クロスケーブルを使用するのは、端末仕様同士を接続する場合と考えて良いと思います。

ここで、ハードウェアには、１つの結線上には、出力が一つと言う決まりがあります。
一つの結線に出力が２つ以上ある場合は、出力同士がぶつかりダメージを与える場合があります。

入力は、出力の容量に問題ない範囲で、いくつでも接続できます。
入力とは信号を受けるだけなので、他の機器に影響を与えません。
出力の容量を超える数の入力を接続すると、信号が極端に下がり、正常に信号が伝わらなかったり、場合によっては、出力側にダメージを与える場合があります。

機器を接続する場合には、そのルール通りに接続します。

端末仕様とモデム仕様を接続するなら、上図の様にストレートケーブルを利用すれば、ルール通りの接続です。

端末仕様と端末仕様を接続するなら、クロスケーブルを利用して、ルール通りにします。

機器の使用によって、特別なケーブルを利用する事が多々あります。

その場合でも、上記の入出力ルールが適用されます。

ルールを守らない場合、出力同士がぶつかりハードウェアにダメージを与えるかもしれませんので、注意してください。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■調歩同期方式(非同期・ASYNC)

調歩同期方式は、非同期方式やASYNCとも呼ばれます。

この通信方式は、通信データの1キャラクタ(1バイト)毎に同期を取る通信方法です。

RS-232Cでは、最もポピュラーな方式で、専用ICが有ったり、初めから調歩同期様のモジュールが内蔵されたワンチップマイコンも多数有ります。
簡単に制御できるので、多くの通信で採用されています。

1バイト毎に同期を取るためのビットが付加されるので、大量のデータを伝送するには向きません。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■通信書式

上図は、通信書式です。
左から順番に通信ラインに出力していきます。最初はスタートビット次にデータビット・パリティビット・ストップビットと続きます。
これで1バイトが送信できます。上図では、一枡を1ビットで表現しています。つまり、0または1がそれぞれの枡に入ります。

スタートビット

---

スタートビットは常に０です。スタートビットは、通信データがこれから開始されると言った意味を持っています。
ハードウェアはアイドル状態の通信ラインを監視しています。０を確認すると、その時点でタイミングをリセットして、一定の間隔でデータ取り込み処理が開始されます。

データビット

---

データビットは任意にビット数を設定できます。通信を行う機器間で予め規定しておきます。
ほとんどの場合、７ビットまたは８ビットです。

パリティビット

---

通信の信頼性を確保するためパリティビットを設定することができます。
パリティビットは、奇数・偶数または無し等を使用することができます。ハードウェアで自動的に計算されますので、計算方法等は気にする必要はありません。
ハードウェアがパリティの誤りに気付くと、パリティエラーを発生させます。

ストップビット

---

ストップビットは常に1です。ストップビットは1バイトの通信が終了すると言った意味を持っています。また、ビット数は、1ビット、1.5ビット、2ビット等があります。
ハードウェアは、1バイト通信が終了するとストップビットを確認します。ストップビットが出力されない場合、通信が上手く行えなかったとして、フレーミングエラーを発生させます。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■通信速度

通信速度は、ビットレートとも呼ばれているシリアル通信にとって、重要なパラメータです。
単位はbpsで、ビットパーセック(bit / 秒)の略です。

1秒間に何bitのデータを送信/受信する事ができるかを表しています。

よくボーレートと表現する場合がありますが、意味が少し違います。
ボーレートは、モデム等で1秒間に行う変調/復調の数を表しています。昔のモデムは、ボーレート＝ビットレートだったため、今でもボーレート＝ビットレートと表現されることがあります。最近のモデムは良くできており、ボーレートとビットレートが等しくありません。モデムで変調する場合、最近のモデムは、周波数変調と振幅変調を組み合わせて、1回の変調で複数bitを送信できます。このため、ボーレート2400でもビットレートで9600bpsでたりします。

この説明をご覧になって、『ボーレート≠通信速度』だとご理解頂けた方は、これから、『ボーレート』と聞く度に、違和感を感じることでしょう。知らない方が良かったかも・・・(^^

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■通信プロトコル

1バイトの通信なら簡単ですが、高度な通信を行うためには通信プロトコルが必要になってきます。
これまで説明した通信は、ほとんどハードウェアが自動的に行ってくれます。通信プロトコルは、ソフトウェアの担当です。
通信プロトコルも様々で、広く使用されているプロトコルからローカルな特殊プロトコルまであります。
RS-232C通信のプロトコルは、独自のプロトコルが主流です。マイコン等で通信を行う場合は、特殊な機器との通信がほとんどなので、皆さん勝手気ままにプロトコルを定めています。

プロトコルとは、ソフトウェアで行う通信手順です。
例えば、通信の開始には必ずSTXを送りましょう。とか、最後にBCCをつけましょうとか…。RS-232Cハードウェアでの書式では、1バイトの送信方法しか規定していませんが、通信プロトコルでは複数バイトのバイトデータの並び等を規定します。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■通信テキストの考え方

通信テキストは、特に決まりはありません。各業者さんがそれぞれの立場で自由に定義するのが通例です。
既に存在する機器に接続する場合には、その機器で定められた通信プロトコルに従ってください。

ここでは、初めて通信テキストを作る際の注意点などを説明します。
また、インターネットが当たり前の現代では、モデムを使った同期通信も特殊な場合を除き利用されなくなりました。したがって、主流である調歩同期通信(非同期通信)について説明します。

シリアル通信では、１本のデータ線を使って情報を送受信します。データの最小単位が１バイトです。
１バイトでは、256種類の情報しか送れませんので、複数のバイトを組み合わせてデータを送信します。

複数バイトを送受信する時に利用するのが、通信テキストです。
情報を送信する場合、通信テキストに格納します。通信テキストは、通信パケットと呼ばれる事もあります。

テキストとパケットの明確な違いは、ハッキリとは決まっていません。
各業者さんによって、自由な解釈で名付けられています。
ざっくり考えると、通信テキストは、その１文で一つの意味をなしており、通信パケットは、いくつかのパケットを合わせて一つの情報を表す。つまり、巨大な情報を小さく分割して送信する場合に、通信パケットと呼んでいる様な感じです。

なぜ通信テキストを利用するかというと、シリアル通信が他の通信に比べ、不安定だからです。

つまり、送受信に失敗する可能性がとても大きいと言う事です。

場合によっては、通信テキストの途中から受信してしまう事もありますし、ノイズや接触不良によりテキストの一部分が破壊されるかもしれません。

この様な事情から、通信テキストを定義する場合は、いくつかのノウハウがあります。
主なノウハウは、次です。

• 開始と終了
• 制御コードとキャラクタコード
• BCC
• 再送手順(リトライ)

開始と終了

通信テキストは、複数のバイトから出来ています。

シリアル通信の性質上、途中から受信される事も十分あり得ます。

このため、テキストの開始と終了を明確にし、開始～終了までのテキストを確実に受信できた事を保証します。

人気のある方法では、制御コードの『STX』からテキストを始め『ETX』で終了する方法です。

STXは、スタートオブテキスト。ETXは、エンドオブテキストの意味です。

受信側は、最初STXの受信待ちになります。STXを受信する以前に、別のコードを受信した場合、全て無視します。

STXを受信すると、受信ステータスをリセットし、次に続くコードをテキストデータとしてバッファリングし、ETXを受信するまで受信処理を続けます。

ETXを受信した時点で、テキストが完成です。完成したテキストの処理を行うと共に、次のテキストのSTX待ちに成ります。

これは、あくまでも考え方であり、実際のコードは、機器メーカーの仕様によりまちまちです。

制御コードとキャラクタコード

RS-232C/RS-485等のシリアル通信では、ASCIIコードを利用するのが一般的です。

ASCIIコードには、制御コードと文字コードの２種類のコードがあります。

16進数で、00～1Fが制御コードで、20～7Fが文字コードです。場合によっては、80以降のコードも文字コードとして利用する事があります。

制御コードは、テキストの開始・終了等を示す特殊なデータとして利用します。

前述したSTXやETXです。

STX～ETX間は、文字コードを使います。数値を表現したい場合は、バイナリデータを使うのではなく、十進数または十六進数に変換して、文字コード‘0’～‘9’および‘A’～‘F’で表現します。

バイナリデータを文字データに変換するので、データ量が倍以上に成ってしまいますが、STX～ETX間には、バイナリーデータを含めません。【重要】

これは、バイナリーデータを使うと、制御コードとデータの区別が付かなくなるためです。

例えば、何らかの障害でテキスト途中から受信が開始された場合、テキスト中にバイナリデータが存在すると、運が悪ければ、STXコードがデータに含まれるかもしれません。そうなると、誤動作の原因に成ります。

そういった、誤動作の可能性を少しでも減らす為に、STX～ETX間には、バイナリーデータを含めないのが通例です。

また、ラインモニタなどを使い、通信テキストを人間の目で確認する場合も、バイナリデータより文字コードの方が圧倒的に見やすい事も理由の一つです。

BCC

受信したテキストの信頼性を保証するために、BCC(ブロックチェッキングコード)を利用します。

別章で説明していますので、そちらを確認してください。

再送手順(リトライ)

シリアル通信では、テキスト送受信の失敗が前提としてシステムを設計します。

テキストの送受信が失敗した場合、再送信を行い、リカバリーするのが一般的です。

一般的な手順

• 送信側：テキスト送信
• 受信側：テキスト受信
• 受信側：テキストの検証
• 受信側：レスポンス送信
• 送信側：レスポンス受信

レスポンスに対する処理

• 正常レスポンスの場合
  処理の完了です。必要であれば、次のテキスト送信処理に移ります。
  
  
• 異常レスポンスの場合
  今送信したテキストと同じ内容を再送信します。
  
  
• 一定時間待ってもレスポンスが返らない場合
  今送信したテキストと同じ内容を再送信します。
  
  

レスポンスのタイムアウトは、３秒程度。リトライ回数は、最大３回まで一般的です。
しかし、高速性を要求されるシステムや、データの重要性が要求されるシステムなどでは、システムに応じてタイムアウトやリトライ回数は大きく異なります。

最大の再送回数を越えた場合は、重大エラーとして特別なエラー処理を行います。再送信の結果、リカバリー出来たのであれば、ログに残す程度でエラーとはせず、そのまま処理を続けるのが一般的です。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■通信ライン(半二重と全二重)

冒頭でシリアル通信とパラレル通信の違いは通信線の数で、シリアル通信は1本と説明しましたが、これは１バイトデータを送る場合の通信ラインの数です。通常、通信には上りと下りが有ります。
2つの機器が通信を行う場合、一方通行の通信なら1本の通信ラインで大丈夫ですが、双方向通信を行うのであれば、1本または2本必要となります。

双方向通信で、1本の通信ラインだけで通信する方式を半二重通信と呼びます。2本の通信ラインを使用して上りと下りの通信に別々の回線を使用するのであれば、全二重通信です。
RS-232Cは、ほぼ間違いなく全二重通信です。TX(送信)とRX(受信)の信号線が独立しています。このため、上りと下りのデータを同時に送受信することがハードウェア的には可能です。

半二重通信は、同時に複数の装置が送信すると、通信データが破壊されてしまうため、注意が必要です。通信プロトコルで衝突が起こらないようにポーリング方式を採用したり、送信が終了すると通信ラインを開放する仕組みをハードウェアで用意する等、考慮する点が増えてきます。

こちらの動画は、全二重通信をラインモニタと呼ばれる測定器でモニタしたものです。

通信トラフィックの少ない時は、上りと下りのデータは、交互に送信されていますが、通信トラフィックが多くなると上りと下りのデータが重なってきます。

半二重通信では、１本の通信線を上りと下りで共有しますので、上りと下りのデータが重なる事はありません。
もし重なった場合、電気的に通信データが壊れてしまいます。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■RS-422とRS-485

RS-232Cと同じ通信書式(1バイトデータ)で、電気信号の異なる通信規格にRS-422とRS-485が有ります。
これらの通信規格では、２本の電線を使用して1ビットのデータを送信します。

RS-232Cでは、シグナルグランド(SG)を０Vと定めて、TX線またはRX線の電圧を変化させ信号を伝達させます。これをシングルスイングと呼びます。
シングルスイングでは、複数の信号線が共通のグランド線を共有します。このため、始めに2本のワイヤーが必要になり、信号線が増える毎にワイヤーが1本づつ増えて行きます。信号数＋グランド1本。
RS-422とRS-485では、+の信号線と-の信号線を使って信号を伝達します。+側と-側の信号は必ず逆の電気特性を出力します。例えば0-5Vの電圧を使用するのであれば、+側が5V出力している時は、-側は0Vが出力されえいます。+側が0V出力している時は、-側は5Vです。このように、２本の信号線を使い、片方を正論理、もう片方を負論理として伝送する方式をデュアルスイングと呼びます。
デュアルスイングでは、信号単位に2本のワイヤーを使用します。このため、信号数×2本のワイヤーが必要になります。

電気的には、シングルスイングよりデュアルスイングで信号を送信したほうが、より遠くへ信号を伝えることができます。

RS-232Cは、元々モデムとターミナルを接続する仕様なので、ケーブルの長さは比較的短めで規格化されています。それよりも遠くへモデムを使用せずに通信させるためには、RS-422またはRS-485を利用します。

RS-422とRS-485は、ほとんど同じ規格ですが、RS-422は1対1通信。RS-485は、n対n通信に使用されます。 また、多くの場合半二重通信を採用します。

RS-422とRS-485は、デュアルスイングで通信を行うので、1つのデータ線に2本のワイヤーを使用します。このため、半二重通信の場合は2W(ツーワイヤー)、全二重通信の場合は4W(フォーワイヤー、ヨンワイヤーとも言う)で機器間を接続します。

調歩同期通信では、RS-232CとRS-422/RS-485の違いは電気的特性のみです。

レベルコンバーターと呼ばれる機器で、電圧変換を行ってあげれば、RS-232からRS-485/RS-422へ、またはその逆の通信が可能です。
但し、RS-232Cは、高速通信には向いていませんので、通信速度が速いRS-485等を変換しても通信できない場合があります。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■ポーリング

RS-485を使用した1対n、通信では、よくポーリングプロトコルが採用されます。
ポーリングプロトコルは、マスターとスレーブ、つまり主装置と複数の端末装置を結合する場合に使用されます。
多くの場合、半二重通信を採用するので、誰かが送信している場合は、その他の装置は送信することができません。そこでマスターは、全てのスレーブへ点呼をかけます。点呼がかけられたスレーブのみが送信可能になります。送信が終了すると、回線をマスターに返還し、マスターは次のスレーブを呼び出すのです。
このように、ポーリングでは、マスターが接続されているスレーブ装置1台1台に呼びかけ、各スレーブの送信タイミングを作り出します。
点呼や応答等は、全て通信電文により行われるので、2W方式や4W方式で通信が可能になります。通信ラインを排他するための特殊なハードウェアは不要です。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■トークンリング

トークンリング方式もポーリング方式に良く似ています。
トークンリングの場合は、ポーリングと違いマスターが存在しなくても構いません。ポーリング方式では、マスターが各スレーブへ点呼を行っていましたが、トークンリングの場合は、各端末がバトンタッチを行いながら送信タイミングを作り出します。
ここで言うバトンとは、送信タイミングのことです。始めに1台だけ送信可能状態になります。送信が終了すると、次の装置へ送信タイミングを渡します。これを順番に繰り返し、全ての装置で送信タイミングをくるくる回して行く訳です。
トークンリングも同様に、全て通信電文により行われるので、2W方式や4W方式で通信が可能になります。通信ラインを排他するための特殊なハードウェアは不要です。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■BCC

BCCとは、ブロックチェッキングコードの略です。

通信には、エラーがつきものです。BCCは、通信が正常に行われているかを検査するためのコードです。
主に次の種類があります。

• サムチェック
• 水平パリティ
• 巡回符号(CRC)

チェックサムは、決められた範囲のキャラクタコードを全て加算する検査方法です。

水平パリティは、決められた範囲のキャラクタコードを全て論理演算する検査方法です。論理演算は、排他的論理和を利用するのが普通です。

巡回符号は、データバイトをローテーションしながら論理演算して行く検査方法で、チェックサムや水平パリティより強力に検査できます。

送信側でBCCを作成し送信テキストに付加します。受信側でもBCCを作成し、送信側が作成したBCCと同じか？検査します。

BCCが送信側と受信側で異なれば、通信テキストが化けている(破壊されている)事になり、再送信処理等を行います。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■モデム

モデムは、RS-232Cの電気信号を音声信号に変換する装置です。
RS-232Cの通信ライン上には、矩形波(方形波)が流れています。単純に12Vや-12Vの電圧です。これを電話回線を利用して、より遠くへ伝達させるためには、モデムが必要になります。
電話回線には、矩形波を出力することができません。電話回線には音声信号しか流せないことになっています。モデムは、RS-232Cの矩形波を音声信号に変換し、逆に音声信号をRS-232Cの矩形波に戻します。

RS-232Cには、同期方式と非同期方式があると説明したとおり、モデムも製品ごとに対応できる方式が決まっています。

モデムは簡単な装置に見えますが、なかなか奥の深い装置です。
RS-232C同士の機器を接続する場合、同じ通信速度で同じ通信書式を使用する必要がありますが、間にモデムを挿入すると、異なった通信速度や通信書式でも通信できたりします。？？？

モデムがダイアルアップを行い、相手モデムがその着信を取ると、モデム間でネゴシエーションが行われます。最初に古い通信規格で通信を行い、可能であれば上位の通信規格を試して…、その時点で最も適した通信規格をお互いに確認しあって通信が開始されます。

昔のモデムは、キャリア信号１周期に１ビットの情報を載せる単純な装置でした。このため、ボーレート＝ビットレートでした。最近のモデムでは、1周期に複数ビットの情報を載せることができます。シリアル通信とパラレル通信の中間の様な、とても奥の深いものなのです。

モデムは、RS-232Cの矩形波を音声信号に載せるため、キャリア信号を使用します。
何も信号が載っていないキャリア信号は、正弦波です。正弦波は、音声信号なので、電話回線に出力することができます。周波数はボーレートで表現されます。
信号を載せるためには、このキャリア信号に変調をかけます。変調には、周波数変調と振幅変調があります。単純なモデムでは、周波数変調を使ってキャリア信号1波形に1bitの情報を載せることができます。
高性能(最近の)なモデムでは、周波数変調と振幅変調を組み合わせて複数のbitをキャリア信号1波形に載せています。
モデム間の距離が長くなると、信号が減衰して振幅変調でエラーが発生してしまいます。このエラーをキャンセルするために、通信の開始時に基本波形をモデムは出力します。受け側のモデムは基本波形を解析して、どの程度信号が減衰しているかを計算します。計算結果により、その後に受信した波形を補正することが可能になり、正常な通信ができるわけです。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■制御線に関して

RS-232Cが初めての方の多くが誤解される制御線です。それなりの名称が付いているので、深く考えすぎて困っていらっしゃる方が多いと思います。

RS-232Cには、データ線の他に制御線があります。

この制御線は、元々モデムを制御するために使われていたようですが、現在では違う目的で利用する事が多です。

私の場合、モデム制御は、ATコマンドを利用するので制御線をアレコレ考えて制御した事は、あまりありません。

また、最近では、アナログモデムを利用する機会もほとんど無くなったので、なおさらです。

モデム以外の機器にRS-232Cで接続する場合は、本来の目的とは異なった意味で制御線を利用する事がほとんどです。

モデム以外で制御線(DCD,DTR,DSR,RTS,CTS,RI)を使う場合、決まった使い方はありません。

機器によって独自仕様で利用される事がほとんどで、制御線の意味は無視されているのが現状です。

一番わかりやすい例として『RI』。これは電話の呼び出し音が鳴っている事を示す制御信号ですが、モデムやFAX以外で呼び出し音が鳴る事は無い訳で、『RI』と言う信号名は、無意味になり、全く異なった用途で使うしか無い訳です。

RS-232C初心者は、その信号名に暗示を掛けられ、信号名からその制御を想像し、混乱してしまいがちです。

初心者の皆さん。RS-232CをモデムやFAX制御以外で利用する場合、本来の制御線の意味は忘れてください。

そして、接続先の機器の独自仕様を確認してください。そこに、その機器に関する制御線の利用方法が書かれていると思います。

もし、書かれていなければ、制御線は無視しましょう。利用されていないと言う事です。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■通信速度の限界

通信速度には、限界があります。

オシロスコープ等で、実際の電気信号を確認すると、通信速度が上がるにつれ通信の波形が崩れてきます。

ナイフで切り分けたチーズの様です。

通信速度が遅ければ、チーズはエッジの効いた矩形波(四角のパルス信号)ですが、通信速度が速くなると、電子レンジでチンした様なとろけたチーズの様な形になります。
通信速度をどんどん上げると、いずれ信号の判別が出来ないほどに、とろけてしまいます。

大量のデータを送るために、通信速度を限界まで上げたい場合は、必ずオシロスコープ等で電気信号を確認してください。

何となくのギリギリで動かしていると、季節の変わり目でトラブったりするかもしれません。

RS-232Cでは、19200bps程度が安心して利用できる速度の様に思います。それ以上速ければ、波形を確認し、ケーブルや距離なども吟味してください。

RS-422やRS-485等では、もっと通信速度を上げる事が出来ます。

デュアルスイングでデータを送信するので、距離も通信速度もRS-232Cと比べものにならないくらい優秀です。

しかし、限界があるので、最後の最後は波形確認は欠かせないと思います。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■ターミネーター(終端抵抗)

RS-422やRS-485等では、ターミネーター(終端抵抗)が必要になる場合があります。

ターミネーターの役目は、信号の反射を抑える事です。

これもオシロスコープで確認するとわかりやすいです。

伝送距離が長くなったり、通信速度が上がってくると、信号の反射が影響してきます。

反射って何？

私は、初め、反射の意味が分かりませんでした。(^^;

反射とは、いろんなところで起きています。

例えば、鏡は光を反射させるデバイス。山びこは、音が山や谷にぶつかり反射する現象。誰も居ない体育館や風呂場で大声を出すと、エコーがかかる。等々・・・

電気信号も、電線の一番端まで来ると、反射が起き、電線を折り返して戻ってきます。

山びこと同じ現象が起きるのです。

電気信号の反射なので、一瞬です。

ですから、伝送距離が長かったり、通信速度が速くないと、反射は観測できません。

伝送距離が長いほど、また、通信速度が速いほど、反射信号が観測しやすくなり、当然、影響が出てきます。

反射がひどいと、オリジナル信号と反射して戻ってきた信号が混ざり合い、オリジナル信号が崩れてしまいます。よって相手機器に電文が正常に伝わりません。

エコーがかかりすぎたカラオケで、何を歌っているのか分からなくなる様な感じです。

その反射を押さえるのがターミネーターです。電線の終端に抵抗器を取り付け反射を抑えます。

音の場合で考えると、体育館や風呂場では、反射が起きますが、放送室やコンサートホールでは、反射が起きにくくなっています。放送室などでは、音を吸収する素材で壁を作っているので、反射が置きにくいのです。

堅い材質だと音を反射し、柔らかい材質だと音を吸収します。

電気信号では、電線の一番端っこで反射が起きるので、端っこを無くしてしまえば反射を抑える事が出来ます。

つまり、電線を無限の長さにしてしまうのです。電線が無限に続くので信号が反射しないのです。

理論的には、それで反射が押さえられるのですが、現実では無限長の電線なんて無理です。

そこで、考え出されたのがターミネーター(終端抵抗)です。

もし、電線を無限に伸ばしたとしたら・・・

電線が無限に伸びた場合の抵抗値を計算し、その抵抗をケーブルの終端に付ける事で、擬似的な無限長の電線を作る事が出来ます。

反射は、電線の終端で起きますので、ターミネータを付けた擬似的な無限長の電線では、反射が起きないのです。

イメージとしては、地平線が見える大草原で大声を出しても、壁や山・谷が無いので声は何処までも進み、反射しないと言う事です。

電線の終端が無いので信号は無限に進み(実際は終端抵抗で減衰して無くなってしまう。)、反射が起きないと言う事になります。

終端抵抗の必要性は、実際の信号をオシロスコープ等で確認するとよく分かります。

反射により信号が崩れているなら、終端抵抗は必須ですが、信号が綺麗なら終端抵抗は不要です。

注意としては、観測ポイントにより波形が変わることがあるので、様々な場所で観測するべきです。

しかし、様々な場所で観測する労力？を考えると、無条件に終端抵抗を付けた方が安上がりと考えるべきかもしれませんね！

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■規格に対する誤解

RS-232/RS-422/RS-485 では、最大通信速度や最大伝送距離等の規格があります。

でも、これらの規格は、当てにしないでください。

その時の環境によって大きく変わってきます。目安程度に考えていた方が無難です。

２台以上の機器を接続する場合、それぞれの機器が正常に動作していても、通信が正常に行われない場合があります。

最大通信速度の範囲内だし、伝送距離も問題が無い。それでも通信異常が発生する。

相手機器を調べても問題なさそうだし、もちろん、あなたの機器にも問題が無い・・・

これは、アナログ的な要因が多いのですが、実際に起こります。

もう、どんな優秀なプログラマーが最高のデバッガーを使ったとしても、原因は分かりません。

こんな状況に陥ったら、考えるだけ時間を無駄にしてしまいます。

セオリー通り、測定器で確認しましょう。

まずは、オンラインモニタ(コミュニケーションアナライザ)で確認。

たいていの場合は、これで、アッサリと原因が分かります。

それでも分からなければ、オシロスコープを使って電気信号を観測します。

規格内の通信速度でも、波形が崩れすぎていたり、反射がひどくてオリジナル波形が見えなかったり・・・

工事ミスで、信号が反転していた事もありました。

とにかく、規格内だから！と過信すると、痛い目に遭います。

測定器に頼りましょう。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■今後のRS-232C

USBが世に出て、PCのインタフェースからCOMポートが消えた時、私はRS-232Cはもう終わった！と思いました。

他のサイトでは、『RS-232Cは古い規格なので、もうすぐ無くなる』とか、Q and A サイトでRS-232Cの質問があると、『なぜ今更RS-232C？』等と逆に責め立てられたり・・・

そんな、ヒドイ扱いを受けていますが、RS-232Cは、まだ元気です！

たぶん、これからも、無くなる事は無いでしょう。

その理由は・・・

シンプルな通信規格である事です。

シンプルなので、簡単に導入できます。特にマイコン関連です。

初めからワンチップマイコンに組み込まれていて、RS-232ドライバ、またはRS-485ドライバを付ければ、すぐに通信できてしまう、お手軽さ！

USBですと、こうは行きません。USBでは、ベンダーID等を取得したり、PC用のドライバを開発したり、ドライバのために証明書を購入したり・・・

とにかく通信以外の手続きが多すぎる！

イーサーネットやWifi等も、プロトコルスタックがどーのこーの・・・と、面倒過ぎます。

そんな手続きや厳格な通信規格などをさほど気にする事無く、通信できてしまう手軽さは、他の通信には無いメリットです。

例えるなら、ある場所に行くのに自転車で行くのか？乗用車で行くのか？新幹線でで行くのか・・・？

そんな感じです。目的地に合わせて、自転車だったり自動車だったり、時には新幹線を使ったりもしますよね？

RS-232Cって、すぐ近所のコンビニに出かける様な、手軽ですぐに繋がる軽い通信なんです。

どんなにUSBやIP通信が増えたとしても、RS-232Cが無くなる事は無いと思います。

また、工場などでは、今でも現役でバリバリ使われています。

古い装置は、当然の様にRS-232Cが標準規格なので、新しい装置も古い装置と連携する場合は、RS-232Cを実装しなくてはなりません。

また、一品物(量産ではなく１台限りの特注装置)では、USB等の規格は重すぎます。要求仕様を満たすのであれば、手間のかからないRS-232Cを採用した方が開発費がグッと安く上がります。

そんなこんなで、RS-232Cは、永遠に不滅です！

なんちゃって！(^^;

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■制御コード一覧

ASCIIコードの 00～1F(HEX) は、制御コードとして利用しています。

HEX値	制御コード
0x00	NUL
0x01	SOH
0x02	STX
0x03	ETX
0x04	EOT
0x05	ENQ
0x06	ACK
0x07	BEL
0x08	BS
0x09	HT
0x0A	LF
0x0B	VT
0x0C	FF
0x0D	CR
0x0E	SO
0x0F	SI
0x10	DEL
0x11	XON
0x12	DC2
0x13	XOF
0x14	DC4
0x15	NAK
0x16	SYN
0x17	ETB
0x18	CAN
0x19	EM
0x1A	SUB
0x1B	ESC
0x1C	FS
0x1D	GS
0x1E	RS
0x1F	US
0x20	SP

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■通信の検査方法

RS-232C / RS-422 / RS-485 等のシリアル通信システムを組み上げた後は、正常に動作しているか検査します。

シリアル通信の試験に必須となるのが、コミュニケーションアナライザ・オンラインモニタ・シリアル通信モニタ等です。

各試験を行う時、全ての通信をラインモニタを利用して記録します。

通常は、試験仕様書等を作ると思いますので、その仕様書の項目毎に通信ログを整理して保存しておくと良いでしょう。

後にシステムに不具合が発生した場合に、残したログを確認すると、わざわざ現場まで出張しなくても回避できる事もしばしばです。

それ以外にも、納品して時間が経つと、開発者の記憶も薄れてきます。そういった場合に通信ログがとても役に立ちます。

通信の試験としては、次の様な項目があります。

• 全通信テキスト検査
• パラメータ検査
• レスポンス検査
• 耐久試験
• 通信速度検査
• リトライ検査
• 回線切断検査

全通信テキスト検査

利用する通信プロトコルにもよりますが、大抵のプロトコルでは、通信テキストにいくつかの種類があります。

そのプロトコルで利用する全ての通信テキストが送受信できるか試験します。

システムの都合上、通常ルートで全てのテキストを送受信できない場合は、シミュレータ等を利用します。シミュレータは、本番用のプログラムを作る際に、同時に作り込んで行きます。本番用のプログラムと同じサブルーチンを利用すれば、比較的簡単に作成する事が出来ます。
シミュレーターのイメージとしては、通信テキストのパラメーターが自由に設定でき、任意のタイミングで送信が出来るような感じです。

本番用とは別にもう一本プログラムを作成しなくてはならないので、面倒に思えるかもしれませんが、シミュレーターがあれば、試験がとても楽になります。効率が上がるので、結果的に工数削減に繋がります。
また、本番システムの信頼性も向上します。

デバッガ等を利用して、本番プログラムから無理矢理送受信させる事もできますが、実運用とは異なった状況での試験になりますので、本当の意味での試験とは言えません。落とし穴もあります。

急がば回れ・・・と思い、出来るだけ試験用のシミュレーターを作成しましょう。

万が一、後で障害が発生した場合もシミュレーターが役に立つ事が多です。

パラメータ検査

信テキストには、多くの場合、データ部分、つまりパラメーターが存在します。

このパラメータを最大値～通常値～最小値。そして、最大値超・最小値超の値を設定してシステムが正常に動作できるか？パラメータ異常を検出できるか？そして、異常でもリカバリー出来るか？等を検査します。

レスポンス検査

全通信テキストの送受信時に正しいレスポンスが返るかを検査します。

パラメータ検査とも組み合わせて、異常テキスト時のレスポンスも確認します。

耐久試験

長時間、連続稼働しても正常通信が出来るかを確認します。

ターゲットシステムがPC等であれば、パフォーマンスモニタ等を利用して、ハンドルやメモリリーク等も同時に確認します。

長ければ長いほど信頼性が上がります。PCのハンドルやメモリが徐々に増えているようであれば、リークが考えられますので、連続稼働するとシステムがダウンする恐れがあります。

通信速度検査

実際に利用する通信速度より速い通信速度で正常動作するか確認します。

例えば、実運用が 9600bps なら、19200bpsで検査します。

ラインモニタを利用して、通信エラーが出ていないか？検査します。

通信速度は十分余裕を持たせ、ギリギリエラーが出ない速度より十分遅い速度で実運用すると安心です。

リトライ検査

シミュレーターを利用して異常テキストを送信したり、異常レスポンスを返したりして、擬似的な通信異常を発生させます。

この時に、リトライ処理が行われ、失われた情報をリカバリー出来るかを検査します。

回線切断検査

通信中に通信ケーブルを抜き差しして、システムが安定動作するかを確認します。

通信ケーブルは、何度も色々なタイミングで抜き差ししてください。

思わぬ異常テキストが発生し、弱いシステムだと簡単にダウンする事があります。

---

以上が、定番の通信試験です。

システムによっては、これ以外にも色々とありますが、臨機応変にできる限りシステムをいじめ抜いてください。それが強いシステムへの道です。

繰り返しになりますが、ラインモニタ等を利用して、必ず試験結果を残してください。

もし、システム納品後に障害が発生した場合、記録した試験結果がとても役に立ちます。

『保険あるある』→保険を掛けると事故が起きない。保険を掛けない人に限って事故が起きる・・・
の様に、記録を残せば障害が起きる事がほとんど無くなり、記録を残さなければ、障害が頻繁に発生します。

記録を残す事で、考えが整理でききちんとした試験が出来るからでは？記録が残る以上、手抜きも出来ませんし・・・(^^;

通信の試験にラインモニタは、必須です。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■送信した内容と異なる内容を受信する

ターゲットAから送信し、ターゲットBで受信すると違う通信テキストだった。

こういった場合は、切り分け試験をします。

ラインモニタで観測点Aと観測点Bをモニタします。

次の様な原因が考えられます。

• 通信ケーブルが破損している
• 通信ケーブルの配線が間違っている
• 通信速度が速すぎて、信号が減衰し、テキストが化けている
• 通信ケーブルが長すぎて、信号が減衰し、テキストが化けている
• 反射が起き通信テキストが化けている
• コネクタの接触不良
• バグ
• その他

デバッガ等を駆使しても、絶対に分からない原因も多いので、ラインモニタを利用するのが定番です。

観測点Aと観測点Bでラインモニタの表示が異なるなら、ハード的な要因です。ソフト屋さんだけで調査するのでは無く、ハード屋さんと一緒に調査すると解決の近道です。

ラインモニタの表示が同じなら、ソフト的な要因が高いです。デバッガを駆使して調査を続けましょう。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■なんだかレスポンスが遅い？

デバッガだけで調査しても良いですが、モニタすると確認が楽ですし、なんと言っても早いです。

ラインモニタで通信ラインをモニタしてみます。

通信異常が発生すると、リトライ処理が発生しレスポンスが遅くなります。

ラインモニタでは、無通信状態には、アイドルタイマーが起動します。このアイドルタイマーが頻繁に発生していないか？確認しましょう。

ラインモニタを眺めながら、レスポンスが遅い？と感じている操作を行うと、意外とあっさり原因が分かります。

ラインモニタで何の問題も無ければ、ソフトウェアの問題です。通信をこれ以上確認する必要はありません。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■相手機器から通信異常が発生する

これもラインモニタを利用するのが定番です。

それぞれのターゲットのコネクタ部分で通信をモニタしてみます。

まずは、本当に通信異常が発生しているかを確認します。

正常通信なのに異常が発生するのであれば、相手機器の問題。

『送信した内容と異なる内容を受信する』同様にハードウェアの問題も考えられます。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■こちらから送信したコマンドと異なる動作を相手機器が行う

意図している通信テキストが正しく送信されているかを確認します。

こちらの機器のコネクタにラインモニタを接続し、問題となっている操作を行います。

正しい通信テキストが送信されているか？またパラメータは正しいか？を確認してください。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■相手機器から応答が無い

相手機器のコネクタにラインモニタを接続して確認します。

テキストが送信されていなかったり、ケーブルが断線していたり、相手機器のバグだったりと原因は様々ですが、通信テキストを確認する事で、すぐに原因が分かります。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■まれに通信異常が発生する

ラインモニタをセットし、通信異常が発生するまで待ちます。

場合によっては、数日～数ヶ月かかる場合もあります。

異常が発生した時点で、モニタを停止し、ログした通信記録を確認して行きます。

時間がかかりますが、ラインモニタを利用するしか手がありません。

デバッガ等で通信エラーにブレークポイントを掛ける方法も考えられますが、ブレークしても、それ以前の通信データが分かりませんので、あまり意味が無かったりします。

またブレークポイントでプログラムが停止しますので、状態が逃げる事もしばしばです。

多の装置から大きなノイズが出ていたり、その他の突発的な原因で通信エラーが出るのであれば、完全に防ぐ事はできません。

防ぐ事が前提ですが、どうしても防げない通信エラーは、リトライ処理でリカバリー出来ているのなら、『よし！』とします。

シリアル通信なので、通信異常はつきものです。問題は、その後のリカバリーです。

ページ先頭へジャンプ　｜　 デバッグ・不具合調査の方法

■まれに誤動作が起きる

『まれに通信異常が発生する』同様にラインモニタを仕掛け、誤動作が発生するまでモニタを続けます。

誤動作が発生したらモニタを停止し通信テキストを確認します。

シミュレーターを利用して通信テキストを一つ一つ確認して行く方法もありますが、その確認は、システムの最終試験で行っているはずなので、繰り返しても正常動作する事が多です。

何かのタイミングで発生する特殊なエラーの場合が多いので、ラインモニタを仕掛けて、気長に待つのが最終手段です。

まずは、通信テキストに異常があるのか？これを確認してください。

これで、自機器か？相手機器か？を切り分ける事が出来ます。

基本的に通信異常が発生しても、誤動作はダメです。

通信異常が発生しているのであれば、リカバリー処理を見直して、誤動作が起きないように調整しましょう。

シリアル通信は、異常が起きる事が前提です。異常が起きても、その後のリカバリーで問題ないシステムを作り上げてください。

福福電子工房 HOME