シリアル通信について

この記事はとりあえず「初心者向け」にカテゴライズしてみたものの、、
PLC初心者が通信処理を作るのは少し敷居が高いかもしれません。
初心者であればなんとなくでも雰囲気を感じ取ってもらえれば十分と思います。

PLCで通信処理といえばシリアル通信(RS-232とかRS-485とか)を使って機器を制御することが現状でも良く使われます。
※RS-232はもはや化石レベルと言っても過言ではないので一般的な民生機器で使うことはほとんどありませんが、制御の現場ではまだまだ現役です。いわゆる”枯れた技術”というのは容易かつ確実に使えるため生き残るべくして生き残っている、とも言えます。

通信が使われる機器

当然といえば当然ですが、、単純なデジタルやアナログ入出力の組み合わせで制御しにくい機器に通信が使われる傾向があります。入出力信号が多くなればその分だけ配線が必要になりますが、通信制御にすると最低3本の配線で済むためハード的にメリットがあります。(ソフト的にはデメリットになるパターンも多い。。なぜなら面倒くさいから。)
ロボットやモーター、高圧電源、温調器や測定器などの機器制御には通信が使われることが多いです。もちろんデジタル・アナログの入出力だけで制御可能なものも存在します。目的・用途によりけりです。
※通信といってもフィールドネットワーク(CC-LinkとかDeviceNetとか)に対応している機器も多いのですがここでは割愛

シリアル通信とは

シリアル通信は調歩同期式の信号でデータを送受信します。ちょっとややこしいので詳しい解説はWikiのRS-232とかUARTとかに任せます(笑)
(ざっくり言えば1Bitあたりの時間を決めて信号Lo/Hiでデータを送出するかたち。同期用のクロック信号が不要。)

対象の機器に合わせたデータを送受信することで制御が可能になります。当然ですがてきとーなデータを送信しても機器は応答してくれませんので、機器側の通信規約＝プロトコルに合わせる必要があります。

またシリアル通信には特有の通信設定が存在します。
※仕様・規格で決められているので覚えるしかありません。
通信設定には以下の項目があり、互いにこの設定を合わせないと通信出来ません。

• Baud Rate / ボーレート ≒ 通信速度(bps = bit per second)
  9600bps、19200bps、38400bpsあたりが代表的
  (Baudと表現するのは厳密には誤りらしい。。)
• Data Length / データ長
  通常は7Bit or 8Bit
  (5Bitや6Bitも設定上は存在するがほとんど使われない)
• Parity Bit / パリティビット
  通常はパリティ無し(None) or 奇数パリティ(Odd) or 偶数パリティ(Even)
  (他にマークパリティ(Mark、常に1)やスペースパリティ(Space、常に0)も存在する)
• Stop Bit / ストップビット
  通常は1Bit or 2Bit
  (設定として1.5Bitもあるが見たことない)

上記の他にStart Bit / スタートビットが必ず1Bit付加されて通信データが構成されます。
RS-232でデータ8Bit、奇数パリティ、ストップビット1Bitの設定でデータ0xF0を送受信する際の信号は下図のようになります。
※負論理(=Active Lo)なのでLoレベルがビット=1、Hiレベルがビット=0を示します

①スタートビット(1Bit固定)が1(Active Lo)でデータ開始
　9600bpsなら時間は約104us
②データを下位側から8Bit分を順に送出
　図の場合は順に00001111→0xF0
③奇数パリティなので②＋③でビット1となる個数が奇数
　図の場合は1
④ストップビット(1Bit分)が0でデータ終了
⇒①～④を連続的に行うことで任意のデータ送受信が成立

※RS-232の場合、上図のような信号が送信用と受信用で別々にあります。
※RS-422/485の場合は232と違って2線の差動信号(電圧の差で0/1を判別。耐ノイズ性が向上。)なので上図とは信号が異なりますが、考え方は同じです。

通信データについて

実際の機器では1Byteのデータだけで送受信が済むことはほとんどありませんので、任意Byteのデータを連結させて通信データとなります。
(1回の送信又は受信データのまとまりを伝文とかフレーム、メッセージなどと呼びます)

どのようなデータを送受信しなければならないかは対象機器の仕様次第ですが、、
いくつかの傾向・パターンというものは存在します。

アスキー(Ascii)かバイナリ(Binary)か

ぶっちゃけ、、
機器制御のシリアル通信ではアスキーが多数派(?)です。
アスキーコードが通信データ＝文字として認識可能→通信データのOK/NGが判別しやすい、というのがアスキーが使われる理由の1つです。
※それに合わせてどのメーカのPLCでもアスキーコード⇔数値変換の命令があります。(使いやすいかどうかは別問題ですが。)

アスキーの場合は
　コマンド/応答文字列＋数値文字列＋デリミタ
　ヘッダ＋コマンド/応答文字列＋数値文字列＋チェックサム＋デリミタ
という感じのパターンがわりと多いです。

・ヘッダ ⇒ 伝文の開始を示すデータ。SOH(0x01)やSTX(0x02)が比較的多い。
・コマンド/応答文字列 ⇒ “READ”, “WRITE”, “OK”, “ERR” 等の文字列。
・数値文字 ⇒ そのままです。0～9とA～F(16進数の場合)の組合せ。
・デリミタ ⇒ 伝文の終了を示すデータ。一般的にはCR(0x0D)やCR+LF(0x0D+0x0A)が多い。
・チェックサム ⇒ 少しややこしいです。
たいていは、、
〇文字目～●文字目までのアスキーコードデータを全て足した下位1Byte
といったパターンが多いです。(それを16進数2文字にするとか。)
※OMRONの機器はチェックサムではなくBCC(ブロック・チェック・キャラクタ)等の名称でExOR(排他的論理和)を使うものが多いイメージ。
※チェックサムのようなデータを付加する目的はデータの誤りを検出するためです。パリティビットは1データ(7or8Bit)単位で検出するのに対し、チェックサムは伝文単位で検出する考え方。

ちなみにアスキーコードは0～127(0x00～0x7F)です。そのうち0～31(0x00～0x1F)は文字として表現できませんので、制御コードが割り当てられています。
上記のヘッダやデリミタには制御コードのいずれかが使われるのが一般的です。


バイナリの場合はコマンド/応答コードとデータを組み合わせるしかありませんが、、
伝文の長さが固定のものもあれば可変のものもあります。
(可変の場合は伝文のどこかにデータ長を示すデータが含まれることが多い)
数値データだけなのでシンプルといえばシンプルですが、データを見ただけでは意味が分からないことが多いです。
またバイナリの場合は”△△Bus”のような名称でプロトコルが公開されているものもあります。(メジャーかマイナーかは別として。)

応答かイベントか

通信による機器制御では大半のもの(おそらく9割以上!?)が
　①コマンド送信(→機器側で受信)
　②応答受信(←機器側から送信)
というパターンになります。
何もせずに機器側からデータ送信されることはほとんどありません。
が、ゼロではありません。

なかには機器側が何かしらの状態変化を検知するとイベントとしてデータを送信するものもあれば、一定時間毎に特定のモニタデータを送信するものもあります。

少し変わったものだと
　①コマンド送信(→機器側で受信)
　②受付応答受信(←機器側から送信)
　③動作完了通知受信 or 読出データ受信(←機器側から送信)
といったパターンも存在します。(たぶんレアケース)
※この場合②ではACK(0x06 肯定応答)やNAK(0x15 否定応答)が使われるパターンが多い

またバーコードリーダーのようなものは送信不要で受信だけ(読出完了毎に機器側からデータを送信)のものもあります。

どのようなデータを送受信すべきかは機器の仕様次第ですが、、
シリアル通信での制御はたいてい上記いずれかのパターンになることがほとんどです。

PLCでの通信処理

PLCでシリアル通信をする場合、大きく分けて以下の３パターンがあります。

1. 自前でゴリゴリ通信処理を作る
2. 通信プロトコルの支援機能を使う
3. 機器側がPLC内のデバイスを読み書きしてくれる

※いずれのパターンでもボーレートやパリティ等の通信設定は必須
(シリアル通信ユニットのパラメータ設定関連の部分に必ずある)


まず自前で通信処理を作る場合についてです。
PLC的には「無手順」と呼ばれる方式で使うパターンです。
送信データをラダーでゴリゴリ記述して専用命令で送信、、
専用命令で受信してデータを解析(アスキー⇒数値変換等)、、
と、ある意味一番手間がかかる方法ではありますが小回りの利くものが作れます。但しセンスの無い作り方をすると後でバグ修正や機能追加があった場合に痛い目をみるのでご注意を。。


次に支援機能を使う場合についてです。
(三菱だと通信プロトコル支援機能、OMRONだとプロトコルマクロと呼ばれるヤツ)
各社それぞれ専用エディタがありヘッダやデリミタ、固定データ、必要に応じてデバイス(変換方式を指定)をあらかじめ通信ユニットに登録する方法です。送信のみ、受信のみ、送信＆受信のパターンを設定することが可能で、プログラム側からは番号を指定して処理を呼び出すだけという方式になります。
※PLCと制御対象の機器が同じメーカーだったり比較的良く使われる機器だと最初からプロトコルのライブラリが準備されているものもあります
通信処理そのもののプログラム自体は少なくて済むのですが、プロトコルを作成するのにそこそこの手間がかかります。
またこの機能を使うにあたり、、過去の経験上大きく問題が2つありました。
作成したプロトコルに不備があると通信出来ないだけでなく、PLC自体の電源OFF→ONしないと復旧できない事態に陥る場合があります。(〇MRONでしたが当時ユニットリスタートの存在を知らず度々電源OFFしてた。。ユニットリスタートで復旧できるかは不明ですが。)
前章(応答かイベントか)で挙げた送信・受信・受信というパターンの場合はかなり作りにくくなるので小細工が必要になることがあります。


最後に機器側が自動的に通信する場合についてです。
これは機器側がこの機能に対応している場合にしか使えません。多くの場合機器側のマニュアルに「PLCリンク」といった名称で説明されていると思います。
これは機器側がMCプロトコルやFINSコマンド、上位リンクといったPLC内のデバイスを読み書きするプロトコルに対応しているので、機器側が自動的に設定されたデバイスを読み書きしてくれます。PLC側は通信処理のプログラムが不要でCC-LinkやDeviceNetなどのユニットと同じような使い方で機器の制御が可能になります。
機器側がこの機能に対応している場合は是非使いましょう。通信処理を作る工数を10とした場合、この方式なら工数1以下なので雲泥の差です。

通信確認時によくあるトラブル

通信処理を作れば実機で確認することになりますが、、何かしらハマることが多いのが通信です。
ハマらずに済むのはリピート機や過去に実績のあるソフトをそのまま使うときで、初めて使う機器の場合は高確率でハマることが多いイメージがあります。
とりあえず過去に経験したものをいくつか挙げてみます。。

通信線がつながっていない。
通信線はたいていD-Sub 9pinコネクタを使いますが、どこで何を間違えたのかオス-オス又はメス-メスのコネクタとなって接続できないことが意外にありました。。
世の中にはオス/メスの変換器があるので一組持っておくとすぐに試すことが出来ます。

通信出来ない。(その1)
ボーレートやパリティ等の通信設定を間違えている。
PLC側はパラメータ設定したつもりが実はされていなかった、とか。
機器側の設定を変更し忘れていた、とか。

通信出来ない。(その2)
送受信の配線を間違えている。
RS-232の場合は9pinコネクタのうち2ピン/3ピンが受信/送信と決まっていますが逆に配線されているパターン。世の中にはストレート/クロスの変換器があるので１つ持っておくと即座に原因切り分けが出来ます。
RS-485の場合はTxD+/TxD-又はRxD+/RxD-の+/-を間違えているパターンが多いかも。機器によっては+/-ではなくSDA/SDBやRDA/RDBなどと表記してあり不要な誤解を招くことがあるので注意が必要です。

通信出来ない。(その3)
OMRON限定。PLCのシリアル通信ユニット側の配線を間違えている。
RS-232の場合は通常2ピン/3ピン/5ピンで受信/送信/GNDですがOMRONのシリアル通信ユニットはピン配が違います。2ピン=送信、3ピン=受信、9ピン=GNDです。

送信データと同じデータを受信している。
三菱でRS-485(2線式)を使うとき限定。無手順で何も考えずにRS-485を使うと送信したデータをそのまま受信します。通信ユニットに「エコーバック許可/禁止」というパラメータ設定があるので禁止にしておくと回避できたハズです。(CH2限定。古いユニットだとこの機能自体が無いので自前で無視する処理が必要になる。)
232⇔485のコンバータを使うチカラワザもあります。。

通信データがなんか変。
ここまでくるとほぼほぼソフトのバグの可能性が高いです。
(ボーレートが合っていて、データ長かパリティの設定を間違えている可能性もゼロではない)
送信すると異常応答が返ってくる等で気付くパターンも多いので、PLCをモニタして送受信データを確認していくことになります。
厄介なのは稀に(もしくは不定期に)データがおかしくなることがあるパターン。。
こういうものはラインモニタを使って調査するのが常套手段と思います。
※通信データそのものは電気信号なので人間には見えませんが、それを可視化するためのモニタツール(＝ラインモニタ)が市販されています。

通信処理は実機でトラブると思うようにデバッグ出来なかったり余計なプレッシャーがかかったりしてドハマりすることがあります。
通信処理は可能な限り机上でデバッグしておくと実機確認の際にスムーズに進められるのでオススメです。この場合は机上でPLCの通信ユニットとPCをRS-232で接続し、PC側に機器の代わりとなる通信プログラムを使ってデバッグします。(ハイパーターミナルやTera Term等を使うことも可能ですが制御コードやバイナリデータがあると面倒です。機器エミュレータを専用ツールとして作ってしまえば便利なのですが、作れるかどうかは別の問題ですね。。)