三菱 MC プロトコルの ASCII と BIN、間違えても例外は出ない ― 型と桁の罠を出荷前に潰す

三菱電機の PLC と通信する MC プロトコルでは、ASCII と BIN のどちらの型で送るかを取り違えても、通信は例外を出さずに成功します。誤りが表面化するのは、PLC がそのデータを実際に使い始めてからです。

MC プロトコルには、通信フレームそのものを ASCII コード形式にするかバイナリコード形式にするか選べる仕様があります(三菱電機の MC プロトコル リファレンスマニュアルに定められている接続設定です)。ただし、この記事で扱う ASCII と BIN は、その選択とは別の層の話です。同じ PLC の中でも、デバイスに格納されるデータそのものが、文字列項目は ASCII、件数カウンタなどの数値項目は符号付き BIN(1 ワード)というように、項目ごとに型が決まっています。この型を実装側が取り違えても、通信は成功したまま、PLC は受け取ったビット列を黙ってそのまま解釈します。

ASCII と BIN が同じ PLC の中に混在する

PLC のデバイスに何を書き込むか、PLC から何を読み出すかは、項目ごとに型が決まっています。私たちが保守する複数の生産ライン向けシステムでも、文字列を扱う項目(型式名称や部品名称など)は ASCII、数量やカウンタなど数値を扱う項目は符号付き BIN(1 ワード)という組み合わせが実際に混在しています。

型を取り違えても、通信自体は成功します。PLC 側は受け取ったビット列を、その項目にあらかじめ割り当てられた型としてそのまま解釈するからです。呼び出し側のライブラリも PLC も型チェックをしていないため、例外は一切発生しません。気づくのは、PLC 側の表示や後続処理が想定と違う値を示し始めてからです。

だから、新しい ZR や D の項目を通信仕様に追加するときは、私たちは必ず通信仕様書でその項目が ASCII か BIN かを確認してから実装します。コードレビューだけでは防げません。型の情報はコードでなく仕様書側にしかないからです。

1 ワードのずれが後続のワードを破壊する

型と並んで気づきにくいのが桁数のずれです。型式名称や号機のような項目は、PLC の ZR レイアウト上で「N ワード固定」で並んでいます。この桁数を 1 ワードでも間違えると、後続のワードまで巻き込んで破壊します。

エンコーディングの細部も同じ性質を持っています。ワードのバイトオーダーはリトルエンディアンで、1 ワード(16 bit)の下位バイトが 1 文字目にあたります。文字列の長さが奇数のときは、末尾に \x00 を 1 バイト補填してからワードに変換し、読み出すときはその \x00 を rstrip で取り除きます。全角文字は半角と違って「1 ワード 1 文字」で消費するため、同じ文字数でも必要なワード数が変わります。ここを見落とすと、桁数の計算そのものがずれます。

実際に、桁数の食い違いが実装と図面の間で起きたことがあります。ある生産指示システムで、簡略型式と型式名称の桁数が、PLC の ZR レイアウト・D ヘッダ・見本の Excel という 3 か所でそれぞれ違う値になっていました。

この不一致は、確定した桁数(簡略 2 桁・型式名称 11 桁)に統一することで解消しました。統一する前は、どの資料を信じるかによって書き込む桁数が変わってしまう状態だったということです。

「他製品と同じはず」で通信ライブラリをコピーすると事故る

三菱 PLC 向けの通信ライブラリ(type3e.py など)は、pip で配布されるライブラリではなく、製品ごとにバンドルされたコピーであることが少なくありません。同じ由来のコードでも、製品間で中身が少しずつ食い違っています。私たちが保守する製品群でも、あるタイムアウト値がクラス変数として固定されていたり、一括読み込みの符号解釈が isSigned=True に固定されていたり、ZR の読み取りだけが通常の経路を通らず特殊な扱いになっていたりと、製品ごとに異なる差分を確認しています。

「他の製品でも同じライブラリを使っているから、動作も同じはず」という仮定は、この種のバンドルコピーには通用しません。流用するときは、コピー元と流用先で実際にコードを読み比べて、差分を確認してから使う必要があります。

新しい項目を追加する前に確認する3点

型・桁・ライブラリという3つの罠は、どれも実装を書く前に確認しておかないと、現場で初めて表面化するという共通点があります。私たちは新しい通信項目を追加するとき、実装に入る前に次の3点を確認しています。1点目は、その項目が ASCII か BIN かを通信仕様書の該当行で確認することです。コードやコメントに残る過去の実装は根拠にしません。2点目は、桁数(ワード数)を仕様書・ZR/D のレイアウト・見本データという複数の資料で突き合わせ、食い違っていれば確定値を1つに決めてから実装することです。3点目は、通信ライブラリをコピーする前に、コピー元と流用先の実装差分(タイムアウト値・符号解釈・特殊経路の有無)を実際に読み比べることです。

この3点は、いずれも実装を書く前の確認作業です。実装してから気づくと、桁の破壊もライブラリの差分も、再現性のある不具合として現場に出てしまいます。

まとめ

次に ZR や D の新しい項目を通信仕様に足すとき、その項目が ASCII か BIN かを確認した結果を、実装より先に仕様書の該当行にメモしておくと、レビューの入り口になります。

型が違っても、桁がずれても、MC プロトコルの通信は例外という形では教えてくれません。この2つの不一致は、通信仕様書や PLC 側の解釈というコードの外側にあるため、通常のコードレビューだけでは見つけられないからです。通信ライブラリの差異は性質が異なり、コードの中に存在するのに「同じライブラリだから同じはず」という思い込みが、コードを読み比べる作業自体を省かせてしまいます。私たちがこの3点を実装前に確認する運用に落とし込んだのは、見つけにくさの理由がそれぞれ違うからです。

出典:

• 三菱電機の MC プロトコル リファレンスマニュアル(通信フレームの ASCII コード形式 / バイナリコード形式に関する仕様)
• 私たちが保守する PLC 連携システムの実装レビュー記録(社内一次情報)

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)