実践！ ご主人様とメイドがステッピングモーターを動かす：江端さんのDIY奮闘記 EtherCATでホームセキュリティシステムを作る（7）（3/7 ページ）

SyncManagerからスレーブのアプリケーションに届くまで

　ところで、それらのメッセージがSyncManagerからスレーブのアプリケーションに届くまでのプロセス（その逆方向も）は、壮絶に面倒くさいです。

　しかし、私の後に、この壮絶な面倒くさい説明をしてくれる方が出てくるとも思えませんので、私が私のためだけに、以下の解説を残しておきたいと思います。

　今回は、PDO用の[SM2][SM3]を使って、説明を試みます。

　まず、3つのオブジェクト（SM PDOオブジェクト、マッピングオブジェクト、アプリケーションオブジェクト）が出てきます。オブジェクトと呼ばれていますが、実体は「単純な2列のテーブル」です。

　正直、この絵を描いているうちに、次第に腹が立ってきました。

　「スレーブの中で、メッセージをグルグルと回して、遊んどるんか!」と。

　ところが、これも冷静に考えれば、結構、うまく考えられているのです。

　例えば、1バイト=8bitの信号が、

• 赤色のパトランプの点滅用に1ビット
• 青色のパトランプの点滅用に1ビット
• 4段階の調光スイッチ用に2ビット
• ステッピングモーターを動かすために4ビット

が割り当てられているとします。

　当然、これはデバイス単位でも管理しなければなりませんが、SyncManagerで、メッセージの中身を。バラバラにぶった切ることまでやると処理が遅くなってしまいます（そもそもSyncManagerは、メッセージ用紙を一時的に置いておく、単なる机ですし）。

　また、例えば、1つの出力信号を2つのアプリケーションで利用する（例えばパトランプとステッピングモーターの両方で同時に使う、など）とか、（イメージしにくいですが）1つの入力信号を2つ以上の異なる入力信号としてマスタに伝えたいような場合だってあるかもしれません。

　とすれば、どこかで、ビットの塊を切り分けて整理しておくテーブルや、アプリケーションとアクセスさせるテーブルが必要になってくるはずです。

　それぞれのオブジェクト（テーブル）の役割を、以下のように把握すれば分かりやすいと思います。

　具体的には、こんな感じです。

　よく分からないでしょう？ 大丈夫です。私も分からないです^*）。

＊）オブジェクトディクショナリの構成や、スレーブプログラムがどうやってオブジェクト（テーブル）の内容を参照するのかが、いまひとつピンとこない。

　いずれにしても、データの参照先が、テーブルでたらい回しにされて、EtherCATのフレームからスレーブのRAMにコピーされる、または、その逆が行われる、という感じに理解しておけば、十分と思っています。

　なぜなら、この辺の話は、（1）EtherCATスレーブの開発者の方の設計方法に依存する話であること、そして、（2）EtherCATマスタとしては、EtherCATスレーブの内部構造がどうであるかは「どーだっていい」からです。

　いろいろと記載致しましたが、SOEMのアプリケーションツールである”Slaveinfo.exe”を使うことによって

• マスタのどのアドレスに、スレーブ情報が割り当てられるか
• スレーブを動かす為には、マスタのアドレスのどのビットを書き換えれば良いのか

ということが分かります。

　それさえ分かれば、今回のステッピングモーターを動かすには十分なのです。

　実際のところ、FMMUやらSyncManagerの情報など、SOEMのアプリケーションプログラムやシステムのオペレータは知らなくても良いことだからです。それらの情報は、メイド（スレーブ）とご主人様（マスタ）の間で共有できていれば十分です^＊）。

＊）ただ、マスタやスレーブの製品開発をするエンジニアは、これらを知らないと何も作れませんですけど。

　さて、今回の場合は、

「PCのメモリアドレス「01257D80」から最初の2バイト（のうち最初の8ビット）が、出力用、次の2バイト（のうち最初の8ビット）が入力用」

と分かれば、それで十分です。