※非同期通信において発生する bug を修正 (v1.0→ v1.1)
世の中には通信プロトコルが沢山あり、日々いろんなプロトコルを使っている方もいるでしょう。しかし産業用機器においては新陳代謝がそれほど早くない代表的なプロトコルがあり、そこにメリットがあるような気もします。
たとえばプログラム言語が頻繁にころころ変わると既存ソフトのアップデートにも影響が出るように、
たとえば Visual .NET のシェアが高いのは、安定した下位互換性を保っていたからのように、
そういう意味では、新陳代謝が遅いプロトコルほど、ある程度のモジュールに作りこむことにメリットがあります。毎回通信を書くより、ひとたび作ってそれを拡張していったほうがテスト回数の観点で品質が安定するというメリットもあると思います。
また仮にそのプロトコルが廃れたとしても、プロトコルモジュールを作りこむ過程で構築されたプロジェクト・ソリューションが、次のプロトコルのそれに流用できる可能性もあるでしょう。
そういうわけで作成した MCプロトコルのモジュールについて示します。
MELSEC PLCのシリアル通信ユニットQJ71C24N-R4 のマルチドロップ接続(ディジチェーン)や、MELSECNETユニットQJ71BR11 同軸/光ケーブルによる MELSECNET ネットワークにも対応した PLC に対する PC-PLC間通信に 対応した Ethernet/シリアル MCプロトコル通信ライブラリです。VB.NET, C# から呼び出せます。
設定パラメータの名称は MX Component の名称を模倣。ただしパラメータの数は本家よりも圧倒的に少ない。
エラーコードについては通信可否、通信終了のみを実装。
不可に至った理由のうち CPU に由来する現象であれば 本家の場合はさらに詳細なエラーコードが実装されているが、ここではそれは省略している。
マルウェアが怖い方は、 vector からインストールください。
呼び出し
//using SimpleMC; でインポート
SimpleMC.SimpleMC ins = new SimpleMC.SimpleMC();
SimpleMC.SimpleMC.RetrunRandomWORD insRandomRec = new
SimpleMC.SimpleMC.RetrunRandomWORD();
// ins= ComInit(ins); // コンストラクタで初期化するか、このような関数でセットするか
insRandomRec = ins.ReadDeviceRandom2("D0", "D100", "D200");
MessageBox.Show(insRandomRec.Finished.ToString());
while (!insRandomRec.Finished) { }
MessageBox.Show(insRandomRec.Finished.ToString());
if (insRandomRec.DataOK) { MessageBox.Show(insRandomRec.UShortArray[2].ToString()); }
else { MessageBox.Show("Write Fault"); }
'Imports SimpleMC.SimpleMC でDLLを読み込んでください
Dim a As New SimpleMC.SimpleMC
Dim data(200) As UShort
data(0) = &HABCD
data(1) = &HFFFF
a.WriteDeviceBlock2BIT("M100", data, 16)
ライブラリによる利得
あらかじめライブラリを検証してさえいれば、アプリに組み込むときに通信に関するテストが不要になる。
MCプロトコル、Modbus TCP といったのは新陳代謝が早いわけでもないので、あらかじめ各社でモジュールとして実装している処も多いかもしれない。
どこまで実装するか
MC プロトコルは Modbus TCP に比べれば高機能なプロトコルである。当ライブラリでは実装していないが、ファイルの読み書きの機能もあるため、PLCソフトバイナリを TCP経由でアップロードするようなアプリを作っている会社もあるだろう。
そういう意味では Modbus TCP よりはおもしろいかもしれない。
どのように提供するか
.NET DLL として提供するのが実装上、最も簡易的である。
しかし提供範囲を広げるには C++ で実装すべきかもしれない。C++ で実装すれば、Python, Linux, VBA, Java といった他言語の モジュール実装プロジェクトへの展開がシームレス(楽という意味ではない)になる。
その場合、実装展開言語・OSにより、部分的にプリプロセッサでヘッダを読み分けたり、VS標準ではない、Cmakeプロジェクトだったり、.NET では考えなくていい工数が増えてくる。利用される可能性は比較的にはあがるだろう。
なお ActiveX コントロールは通信機能には関係のないが、こういうのも実装すると「より製品らしく」なるのかもしれない。
出来ないこと
- USB接続
- GX Simulator
へのアクセスはできないであろう。前者は USB解析技術という問題もあるし、いずれにせよどちらも非公開なので、グレーゾーンである。単なる興味本位ならともかく、これを実装することに、実際に利得はあまりなさそうである。
実際のPLC はフィールドネットワークやイーサネットでつながっている。その実際に対応したプロトコルが無料で公開されていることが、たいへんすばらしいことだし、懐の大きい Vendor だなと思う。
なのでグレーゾーンなものはグレーゾーンのまま実装せず、素直に vendor 公式の製品を使うべきであろう。