JP4883194B2

JP4883194B2 - プログラマブルコントローラおよびコントローラシステム

Info

Publication number: JP4883194B2
Application number: JP2010020642A
Authority: JP
Inventors: 実岡; 益久平田; 仁太郎出来
Original assignee: Omron Corp
Current assignee: Omron Corp
Priority date: 2003-10-02
Filing date: 2010-02-01
Publication date: 2012-02-22
Anticipated expiration: 2024-09-22
Also published as: JP2010097624A

Description

この発明は、プログラマブルコントローラおよびコントローラシステムに関するものである。

生産工場（製造現場）に設置されるファクトリーオートメーション（ＦＡ）の制御装置として、プログラマブルコントローラ（ＰＬＣ）が用いられている。このＰＬＣは、複数のユニットから構成される。すなわち、電源供給源の電源ユニット，ＰＬＣ全体の制御を統率するＣＰＵユニット，ＦＡの生産装置や設備装置の適所に取り付けたスイッチやセンサなどの入力機器からの信号を入力する入力ユニット，アクチュエータなどの出力機器に制御出力を出す出力ユニット，通信ネットワークに接続するための通信ユニットなどの各種のユニットを適宜組み合わせて構成される。

ＰＬＣのＣＰＵユニットにおける制御は、入力ユニットで入力した入力機器からの信号をＣＰＵユニットのＩ／Ｏメモリに取り込み（ＩＮリフレッシュ）、予め登録されたユーザプログラム記述言語（例えばラダー言語）で組まれたユーザプログラムに基づき論理演算をし（演算実行）、その演算実行結果をＩ／Ｏメモリに書き込んで出力ユニットに送り出し（ＯＵＴリフレッシュ）、その後、通信ユニットを介して通信ネットワーク上の他のＰＬＣとデータ送受信を行ったり、ＣＰＵユニットに備えられた通信ポートを介して外部の機器とデータ送受信などを行ったりする（周辺処理）ことをサイクリックに繰り返し処理するようになる。なお、ＩＮリフレッシュとＯＵＴリフレッシュとを、一括して行なう（Ｉ／Ｏリフレッシュ）場合もある。なお、ＯＵＴリフレッシュによって、出力ユニットは、ＣＰＵユニットから出力信号を得る。そして、出力ユニットは、その出力信号に基づいて出力機器を動作させる。

一般に、ユーザは、ＰＬＣの入力機器や出力機器によって制御される制御機器（制御コンポーネント）や内部接点のそれぞれを特定しやすいように、それぞれに変数名を付与する。変数名の例を挙げると、あるスイッチに対して「Ｓｗｉｔｃｈ１」という変数名を付与し、別のスイッチには「Ｓｗｉｔｃｈ２」という変数名を付与する。他の例では、動作開始のために他のＰＬＣから取り込む内部接点に対して「ＲＥＡＤＹ」という変数名を付与し、動作停止のために他のＰＬＣから取り込む内部接点に「ＳＴＯＰ」という変数名を付与する。そしてユーザは、プログラミングツールを利用してユーザプログラムを作成・編集するが、その際、接点を変数名によって記述することができる。

一方、ＰＬＣがユーザプログラムを実行する際には、ＣＰＵユニット内のデータメモリの特定エリアに入力機器からの状態や内部接点の状態やユーザプログラム実行結果を格納する。そしてデータメモリはメモリ割付けされていて、メモリアドレスとデータ（入力機器からの入力信号、内部接点、ユーザプログラム実行結果）とが一対一に対応付けられている。つまり、ＰＬＣがユーザプログラムを実行する際には、変数名に基づくのではなく、メモリの物理アドレスに基づくのである。なお、変数名で記述されたユーザプログラムは、ＰＬＣのＣＰＵユニットのユーザメモリに格納される際にコンパイルされる。コンパイルによってユーザプログラム中の変数名は物理アドレスに変換される。ＣＰＵユニットが実際に実行するのはコンパイル後のプログラムであって、接点は物理アドレスで表されたプログラムである。

さらに、近年では、複数のＰＬＣをネットワークを介して接続し、ＰＬＣ間でデータの送受を行ないながら、協働，同期運転等を行ない、ＦＡ全体の制御を行なうようにした分散コントローラシステムも用いられている。これに伴い、複数のＰＬＣが接続されたネットワークでは、ＰＬＣ間のデータの送受も盛んに行なわれる。

一般に、ＰＬＣ間でデータを送受する場合は、送受信する２つのＰＬＣのＣＰＵユニットにあるデータメモリのアドレスを指定して行なう。このアドレス指定は、前述のメモリ割付けによって、予め、どの機器の接点がどのメモリアドレスに対応しているかを把握することで実現できる。この場合、ユーザにとっては、物理アドレスを用いてユーザプログラムを作成することになる。そのため、プログラム作成者であるユーザは、送受信対象のＰＬＣのデータアドレスの割付等の内部構造，プログラム構造を知っていなければならず、煩雑である。さらに、一旦ユーザプログラムを作成した後で、アクセス先の物理アドレスが変更された場合には、ユーザプログラムを修正しなければならず、煩雑である。さらには、ユーザが、係るユーザプログラムの修正を行なうためには、相手先の物理アドレス等が変更になったか否かの監視を行なわなければならないという問題を有する。

係る問題を解決するため、例えば特許文献１に開示された発明のように、変数名でデータのアクセスを可能にし、また通信手段上では公的な変数名を使用してデータのアクセスをすることが可能なプログラマブルコントローラが提供されている。

この特許文献１に開示された発明では、コントローラ（ＣＰＵユニット）は、他のコントローラから変数アクセス要求があった際に、機能名である変数名を物理アドレス（実アドレス）に変換する変数名変換手段を備えた。これにより、各ＰＬＣは、変数名を用いて他のＰＬＣにデータの送受を行なうことができ、ユーザにとって非常に便利になり、データの移動に伴うプログラムの変更を不要にすることが可能となる。

特開平１１−１８４５０８号公報

上述した従来の技術では、変数名と実アドレスの変換を伴う通信の処理をコントローラで処理していたため、コントローラに負荷が集中する。係る変数名と実アドレスの変換処理に対応しつつ、上述したＦＡの制御を司るために行なうサイクリックな処理をスムーズに行なうためには、コントローラのリソース・性能を高める必要がある。分散コントローラシステムを構成するＰＬＣの個数が増えると、ＰＬＣ間の変数名を用いたデータの送受が増えるので、コントローラのリソースをさらに増加させる必要がある。サイクリック通信能力（データ量，ノード数など）がコントローラに依存するため、分散コントローラシステムの能力に限界がある。

この発明は、プログラマブルコントローラ間で通信する場合、事前の通信設定が変数名を用いてできる利便性を保ち、また、通信処理をするためにコントローラ（ＣＰＵユニット）のリソースを増やさないようにしたプログラマブルコントローラおよび通信ユニットならびにコントローラシステムおよびデータ処理方法ならびに変数解決方法を提供することを目的とする。

（１）本発明に係るプログラマブルコントローラは、プログラミングされたプログラムに基づいて記憶手段のデータを演算実行するコントローラと、ネットワークを介して他のプログラマブルコントローラの通信ユニットとの間で前記コントローラの記憶手段のデータを通信する通信ユニットとをシステムバスを介して連結したプログラマブルコントローラであって、前記コントローラは、データが格納されるメモリの実アドレスとそのデータに対応する変数名とを関連付けて記憶する変数テーブルを有し、前記通信ユニットは、前記他の通信ユニットとの間で通信対象にするデータの前記変数名と、送受信属性と、通信対象の相手局アドレスと、相手局における変数名とを関連付けた情報を記憶する通信設定情報記憶手段と、通信対象にするデータの前記変数名とバッファ領域とを関連付けて記憶するテーブルと、所定のタイミングで、前記テーブルに記憶された変数名に対応する実アドレスを、前記コントローラに問い合わせることにより取得し、その変数名と取得した実アドレスとを関連づけたテーブルを記憶保持する変数解決手段と、前記他のプログラマブルコントローラの相手局アドレスの通信ユニットに対し、通信するデータを特定するための識別情報の取得要求をする手段と、その要求に応じて相手局アドレスの通信ユニットから送られてきた前記識別情報と、その識別情報で特定されるデータ対応する前記変数解決手段によって取得した実アドレスとを関連づけて記憶し、通信時に前記識別情報とともに送られてきたデータをシステムバスを介して前記コントローラに提供可能にする手段と、を有する構成とした。
ここで、提供可能とは、実施形態で示したように通信ユニットは共有ＲＡＭに書き込み、コントローラ（ＣＰＵユニット）が任意のタイミングで共有ＲＡＭからデータを取得するようにしても良いし、通信ユニットがコントローラに対してデータを転送しても良く、要は、最終的に取得したデータがコントローラ側に渡されるようになっていればよい。なお、識別情報は、実施形態ではサイクリック通信ＩＤに対応する。

このプログラマブルコントローラは、プログラマブルコントローラ間で通信するための事前の通信設定をする際、通信ユニットに対して変数名を用いて通信設定をすることができる。通信ユニットはＣＰＵユニットから変数名に関する情報を確実かつ正確に取得することができる。また、通信ユニット側で変数名と実アドレスとの関係付けの情報を記憶するので、コントローラ間でデータ通信する場合等の通信ユニット側で処理できる範囲が増えて、ＣＰＵユニットの負荷を削減できる。なお、ここでのコントローラは実施形態のＣＰＵユニットに相当する。またテーブルは、通信対象となるデータの変数名に関する情報を持つものであり、第２〜第４実施形態の通信バッファテーブルおよび第５，第６実施形態のアセンブリテーブルを含む。この発明は、第２〜第６の各実施形態のプログラマブルコントローラ（オリジネータ側）に対応し、また第２〜第６の各実施形態の変化例におけるプログラマブルコントローラ（オリジネータ側）に対応する。

そして、前記通信設定情報は、前記通信対象にする変数名と、送受信属性と、通信対象のデータの送信元アドレスと、送信元における変数名とを関連付けた情報であり、前記通信ユニットは、さらに、送信元アドレスの通信ユニットに対し、通信するデータを特定するための識別情報の取得要求をする手段と、その要求に応じて送信元アドレスの通信ユニットから送られてきた識別情報と前記変数解決手段によって取得した実アドレスとを関連づけて記憶し、通信時に前記識別情報とともに送られてきたデータを、前記コントローラに提供可能にする手段とを有する構成とすることができる。この構成は、第２〜第４の実施形態のプログラマブルコントローラ（オリジネータ側）に対応し、また第２〜第４の実施形態の変化例におけるプログラマブルコントローラ（オリジネータ側）に対応する。

さらに、前記通信ユニットのテーブルを、通信対象にする変数名とその変数名をグループ化したアセンブリ名とバッファの領域とを関連付けて記憶するアセンブリテーブルとし、前記通信ユニットの前記通信設定情報を、前記通信対象の前記アセンブリ名と、送受信属性と、通信対象データの送信元アドレスと、送信元におけるアセンブリ名と、を関連付けた情報とした構成とすることができる。この構成は、第５、第６の実施形態のプログラマブルコントローラ（オリジネータ側）に対応し、第５、第６の実施形態の変形例のプログラマブルコントローラ（オリジネータ側）に対応する。

（２）本発明に係るプログラマブルコントローラは、プログラミングされたプログラムに基づいて記憶手段のデータを演算実行するコントローラと、ネットワークを介して他のプログラマブルコントローラの通信ユニットとの間で前記コントローラの記憶手段のデータを通信する通信ユニットとをシステムバスを介して連結したプログラマブルコントローラであって、前記コントローラは、データが格納されるメモリの実アドレスとそのデータに対応する変数名とを関連付けて記憶する変数テーブルを有し、前記通信ユニットは、前記他の通信ユニットとの間で通信対象にするデータの前記変数名とバッファ領域とを関連付けて記憶するテーブルと、所定のタイミングで、前記テーブルに記憶された変数名に対応する実アドレスを前記コントローラに問い合わせることにより取得し、その変数名と取得した実アドレスとを関連づけたテーブルを記憶保持する変数解決手段と、前記他の通信ユニットから通信対象にするデータの前記変数名と送受信属性とを含む通信設定情報を受取ることによって、他の通信ユニットとの間で通信するデータを特定するための識別情報を生成し、生成した識別情報を前記他の通信ユニットへ送信する通信確立処理手段と、前記他のプログラマブルコントローラの通信ユニットから前記識別情報とともに送られてきたデータをシステムバスを介して前記コントローラに提供可能にする手段と、を有した構成とした。
このプログラマブルコントローラは、プログラマブルコントローラ間で通信するための事前の通信設定をする際、通信ユニットに対して変数名を用いて通信設定をすることができる。また、通信確立処理をする際に、通信ユニットはＣＰＵユニットに対し変数名に関する情報を確実に確認することができ、通信確立のミスを防止できる。また、通信ユニットは、通信ユニット側で変数名と実アドレスとの関係付けの情報を記憶するので、その情報を用いてコントローラ間でデータ通信する処理の一部を行うことができるので、ＣＰＵユニットの負荷を削減できる。なお、ここでのコントローラは実施形態のＣＰＵユニットに相当する。またテーブルは、通信対象となるデータの変数名に関する情報を持つものであり、第２〜第４の実施形態の通信バッファテーブルおよび第５，第６の実施形態のアセンブリテーブルを含む。この発明は、第２〜第６実施形態におけるターゲット側のプログラマブルコントローラに対応し、第２〜第６の実施形態の変形例におけるターゲット側のプログラマブルコントローラに対応する。

そして、前記通信確立処理手段が受取る前記通信設定情報には、前記通信対象にする変数名と、送受信属性とが含まれていて、前記通信確立処理手段は、前記通信設定情報を受け取ることによって、他の通信ユニットとの間でデータ通信するためのコネクション識別情報を生成し、生成した識別情報を前記他の通信ユニットへ送信するものであり、前記通信ユニットは、前記他の通信ユニットから前記識別情報とともに送られてきたデータを、前記コントローラに提供可能にする手段を備えた構成とすることができる。この構成は、第２〜第４の実施形態のターゲット側のプログラマブルコントローラに対応する。

また、前記通信ユニットのテーブルを、通信対象にする変数名と、その変数名をグループ化したアセンブリ名と、バッファ領域とを関連付けて記憶するアセンブリテーブルとし、前記通信ユニットの通信設定情報を、通信対象のアセンブリ名と、送受信属性と、通信対象データの送信元アドレスと、送信元におけるアセンブリ名とを関連付けた情報とするような構成とすることもできる。この構成は、第５、第６の実施形態のターゲット側のプログラマブルコントローラに対応する。

（３）本発明に係るプログラマブルコントローラは、プログラミングされたプログラムに基づいて記憶手段のデータを演算実行するコントローラと、ネットワークを介して他のプログラマブルコントローラの通信ユニットとの間で前記コントローラの記憶手段のデータを通信する通信ユニットとをシステムバスを介して連結したプログラマブルコントローラであって、前記コントローラは、データが格納されるメモリの実アドレスとそのデータに対応する変数名とを関連付けて記憶する変数テーブルを有し、前記通信ユニットは、前記他の通信ユニットとの間で通信対象にするデータの前記変数名とバッファ領域とを関連付けて記憶するテーブルと、前記他の通信ユニットから通信対象にする前記変数名と送受信属性とを含む通信設定情報を受取ることによって、他のプログラマブルコントローラの通信ユニットとの間で通信するデータを特定するための識別情報を生成し、生成した識別情報を前記他の通信ユニットへ送信する通信確立処理手段と、を有し、前記通信ユニットは、通信確立処理手段が通信設定情報を受取った後のタイミングで、前記通信設定情報に含まれた変数名に対応する実アドレスを前記コントローラに問い合わせることにより取得し、その変数名と取得した実アドレスとを関連づけたテーブルを記憶保持する変数解決手段と、前記他のプログラマブルコントローラの通信ユニットから前記識別情報とともに送られてきたデータをシステムバスを介して前記コントローラに提供可能にする手段と、を備えた構成とした。
このプログラマブルコントローラは、ユーザが変数名を使用してプログラミングしたり、変数名を使用してコントローラの通信ユニット同士に関わる通信設定をすることを前提としている。そして、変数と実アドレスとを関連付けた情報は、コントローラがテーブルに記憶している。そして、通信ユニットは、通信確立処理手段が通信設定情報を受取った後のタイミングで、変数名に関する情報をＣＰＵユニットに問い合わせる。これにより、通信確立処理をする際に、通信ユニットはＣＰＵユニットに対し変数名に関する情報を確実かつ正確に確認することができる。また、通信ユニットは、通信ユニット側で変数名と実アドレスとの関係付けの情報を記憶するので、その情報を用いてコントローラ間でデータ通信する処理の一部を行うことができるので、ＣＰＵユニットの負荷を削減できる。なお、ここでのコントローラは実施形態のＣＰＵユニットに相当する。またテーブルは、通信対象となるデータの変数名に関する情報を持つものであり、第２〜第４の実施形態の通信バッファテーブルおよび第５，第６の実施形態のアセンブリテーブルを含む。この発明は、第２〜第６の実施形態の変形例におけるターゲット側のプログラマブルコントローラに対応する。

そして、このプログラマブルコントローラは、前記通信確立処理手段が受取る前記通信設定情報には、前記通信対象にする前記変数名と、送受信属性とが含まれていて、前記通信確立処理手段は、前記通信設定情報を受け取ることによって、他の通信ユニットとの間でデータ通信するコネクション識別情報を生成し、生成した識別情報を前記他の通信ユニットへ送信するものであり、前記通信ユニットは、前記他の通信ユニットから前記識別情報とともに送られてきたデータを、前記コントローラに提供可能にする手段を備えた構成とすることができる。この発明は、第２〜第４の実施形態の変形例におけるターゲット側のプログラマブルコントローラに対応する。

また、このプログラマブルコントローラは、前記通信ユニットのテーブルを、通信対象にする変数名と、その変数名をグループ化したアセンブリ名と、バッファの領域とを関連付けて記憶するアセンブリテーブルとし、前記通信ユニットの前記通信設定情報を、前記通信対象の前記アセンブリ名と、送受信属性と、通信対象データの送信元アドレスと、送信元におけるアセンブリ名とを関連付けた情報とするような、構成にできる。この発明は、第５，第６の実施形態の変形例におけるターゲット側のプログラマブルコントローラに対応する。

（４），（５）本発明に係るコントローラシステムは、複数のプログラマブルコントローラが、ネットワークを介して接続されて構成されるコントローラシステムであって、前記複数のプログラマブルコントローラは、オリジネータ側となる（１）のプログラマブルコントローラと、ターゲット側となる（２）或いは（３）のプログラマブルコントローラをそれぞれ少なくとも１つずつ以上含み、前記複数のプログラマブルコントローラ間のデータの送受は、前記識別情報を用いてデータを特定して行なう構成とした。

（６）本発明に係るコントローラシステムは、オリジネータ側となる（１）のプログラマブルコントローラとターゲット側となる（２）或いは（３）のプログラマブルコントローラが、ネットワークを介して複数台接続されて構成されるコントローラシステムであって、ある通信対象についての通信設定情報は、その通信対象の送信側の通信ユニットと、受信側の通信ユニットのうち、一方に格納し、その格納する前記通信設定情報は、前記通信対象にする自局側の前記変数名と、相手局側の変数名と、送信／受信の区別情報と、通信相手局を特定するアドレス情報と、を関連付けた情報であり、前記通信設定情報を備えた通信ユニットは、前記通信設定情報を備えていない通信ユニットに対し、少なくとも相手局変数名とともに通信確立要求を発行する機能を有し、前記通信設定情報を備えていない通信ユニットは、前記通信確立要求に対し要求を許可するか否かを判断し、許可する場合には通信する際に使用するコネクションＩＤとともに許可通知を発行する機能を備え、前記通信ユニット間での通信は、前記コネクションＩＤを用いて通信対象を特定し行なう構成とした。

（７）さらに、前記コネクションＩＤは、同一の通信条件を有する複数の通信対象をグループ化したグループに設定され、そのコネクションＩＤを用いることにより、複数の通信対象を一括して通信可能とした構成とすることもできる。

上述のいずれのコントローラシステムにおいては、互いのプログラマブルコントローラ間でデータ送受信をするために通信確立をし、双方でデータを共有することができる。その通信を行う際、通信ユニットは変数名と実アドレスとの関係付けの情報を持つので、通信ユニットでできる処理範囲が増えて、ＣＰＵユニットの負荷を削減できる。

本発明では、プログラマブルコントローラ間で通信するための事前の通信設定をする際、通信ユニットに対して変数名を用いて通信設定をすることができる。通信ユニットはＣＰＵユニットから変数名に関する情報を確実かつ正確に取得することができる。また、プログラマブルコントローラ間で通信する際、通信ユニット側で処理できる範囲が増えて、ＣＰＵユニットの負荷を削減できる。

本発明が適用されるネットワークシステムの一例を示す図である。本発明の第１実施形態におけるコントローラ（ＣＰＵユニット）と通信ユニットの内部構造を示す図である。本発明の第１実施形態の動作原理を説明する図である。コントローラ（ＣＰＵユニット）−通信ユニット間のシーケンス図である。別の実施形態を示す図である。通信設定ツールの入力画面の一例を示す図である。通信設定ツールの入力画面の一例を示す図である。本発明の第２実施形態の動作原理を説明する図である。本発明の第２実施形態により作成されるコネクションテーブルのデータ構造の一例を示す図である。本発明の第２実施形態の変形例の動作原理を説明する図である。本発明の第３実施形態の動作原理を説明する図である。本発明の第３実施形態の動作原理を説明する図である。本発明の第３実施形態により作成されるコネクションテーブルのデータ構造の一例を示す図である。本発明の第３実施形態により作成されるコネクションテーブルのデータ構造の一例を示す図である。本発明の第３実施形態の変形例の動作原理を説明する図である。本発明の第３実施形態の変形例の動作原理を説明する図である。本発明の第４実施形態の動作原理を説明する図である。本発明の第４実施形態の動作原理を説明する図である。本発明の第４実施形態により作成されるコネクションテーブルのデータ構造の一例を示す図である。本発明の第４実施形態の変形例の動作原理を説明する図である。本発明の第４実施形態の変形例の動作原理を説明する図である。本発明の第５実施形態の動作原理を説明する図である。本発明の第５実施形態により作成されるコネクションテーブルのデータ構造の一例を示す図である。本発明の第５実施形態の変形例の動作原理を説明する図である。本発明の第６実施形態の動作原理を説明する図である。本発明の第６実施形態により作成されるコネクションテーブルのデータ構造の一例を示す図である。

図１は、本発明に係るプログラマブルコントローラを用いて構築されるネットワークシステムの一例を示している。この例では、２つのＰＬＣで分散コントロールシステムを構築した状態を示している。すなわち、第１ＰＬＣ１０ａと第２ＰＬＣ１０ｂは、ネットワーク１５を介して接続されている。

図１に示した例では、第１ＰＬＣ１０ａは、ユーザプログラムを演算実行したり、Ｉ／Ｏリフレッシュや周辺処理をサイクリックに実行する第１ＣＰＵユニット１１ａと、他のノードと通信を行なう第１通信ユニット１２ａと、入出力機器を接続するＩ／Ｏユニット１３ａと、その他のユニット１４ａ等を備えている。これらのユニットは、システムバスを介して接続される。その他のユニット１４ａは、例えば、ＰＬＣを構成する各ユニットに対して電源供給をする電源ユニットや、マスタスレーブ通信を行なうためのマスタユニット等がある。また、同種のユニットを複数連結することもある。また、第２ＰＬＣ１０ａは、ユーザプログラムを演算実行したり、Ｉ／Ｏリフレッシュや周辺処理をサイクリックに実行する第２ＣＰＵユニット１１ｂと、他のノードと通信を行なう第２通信ユニット１２ｂと、入出力機器を接続するＩ／Ｏユニット１３ｂと、その他のユニット１４ｂ等を備えている。これらのユニットは、システムバスを介して接続される。その他のユニット１４ｂは、ＰＬＣを構成する各ユニットに対して電源供給をする電源ユニットや、マスタスレーブ通信を行なうためのマスタユニット等がある。また、同種のユニットを複数連結することもある。そして、図１では、第１ＰＬＣ１０ａと第２ＰＬＣ１０ｂは、ともに４つのユニットを連結して形成された状態を示したが、各ＰＬＣを構成するユニット数は必ずしも等しいとは限らず、必要に応じて連結するユニットを増減する。

このシステムは、第１ＰＬＣ１０ａに接続された第１，第２スイッチＳＷ１，ＳＷ２の入力信号に従って、第２ＰＬＣ１０ｂに接続されたモータＭの動作を制御する。つまり、第１スイッチＳＷ１がＯＮになると、モータＭが回転駆動し、第２スイッチ２がＯＮになるとモータＭが停止する。ここでは、第２ＰＬＣ１０ｂの第２ＣＰＵニット１１ｂが、第１ＰＬＣ１０ａ（第１ＣＰＵユニット１１ａ）に対して第１，第２スイッチＳＷ１，ＳＷ２のＩＯ情報（ＯＮ／ＯＦＦデータ）の読み出し要求を行ない、第１ＰＬＣ１０ａからのレスポンスによりＩＯ情報を取得し、モータＭに対する動作制御行なう。

図２は、第１，第２ＣＰＵユニット１１ａ，１１ｂの内部構造、および第１，第２通信ユニット１２ａ，１２ｂの内部構造を示している。これらの各ユニットは、第１ＰＬＣ１０ａと第２ＰＬＣ１０ｂと間でデータを送受信する処理に関与する。各ＣＰＵユニット１１ａ，１１ｂのハードウェア構成は等しいため、代表して１つ示している。同様に、各通信ユニット１１ａ，１１ｂのハードウェア構成は等しいため、代表して１つ示している。

第１ＣＰＵユニット１１ａと第２ＣＰＵユニット１１ｂは、コントローラと称されるものである。第１，第２ＣＰＵユニット１１ａ，１１ｂは、共にユーザプログラムを格納する不揮発性記憶手段たるフラッシュＲＯＭ２１と、そのユーザプログラムを実行するＭＰＵ２２と、そのＭＰＵ２２が演算実行中にワークメモリとして使用したり、ＩＯ情報を格納したりするための揮発性記憶手段たるＳＲＡＭ２３と、他のユニットと通信をするためのインタフェース回路２４とを備えている。ＣＰＵユニット全体の基本動作等を行なうためのメインファームプログラムや、各種のパラメータ（設定情報）は、フラッシュＲＯＭ２１に記憶される。また、インタフェース回路２４は、システムバス２６に接続される。

第１，第２通信ユニット１２ａ，１２ｂは、各種プログラムや各種パラメータ等が格納される不揮発性記憶手段たるフラッシュＲＯＭ３１と、そのフラッシュＲＯＭ３１に格納されたプログラムを実行するＭＰＵ３２と、揮発性記憶手段たるＳＲＡＭ３３と、対応するＣＰＵユニットとデータを供給するための共有ＲＡＭ３４と、システムバス２６に接続され、他のユニットと通信を行なうインタフェース回路３５と、ネットワーク１５に接続された他のノードとの間で実際にデータの送受処理を行なう通信コントローラ３６と、ネットワーク１５に接続される通信インタフェース回路３７と、を備えている。

ここで本発明では、第１，第２ＣＰＵユニット１１ａ，１１ｂは、共に機能に着目して設定されたラベルである変数名（Ｔａｇ，論理名とも称されることがある）でプログラミングされたユーザプログラムを実行し、変数名（Ｔａｇ）でアクセスできるようになっている。それら第１，第２ＣＰＵユニット１１ａ，１１ｂに接続された第１，第２通信ユニット１２ａ，１２ｂに対するサイクリック通信は、後述するコネクションＩＤを用いて行なえるようにしている。

本実施形態では、係るコネクションＩＤを用いたサイクリック通信を可能にするため、変数名（Ｔａｇ）と実アドレス（ＰＬＣ内部のローカルな物理アドレス）を対応づけた変数テーブルを、第１，第２ＣＰＵユニット１１ａ，１１ｂに持たせるとともに、どの変数名に対応するデータをサイクリック通信の対象にするかの通信設定情報を第１，第２通信ユニット１２ａ，１２ｂに登録するようにした。変数テーブルや通信設定情報は、ユーザが通信設定ツール３０を利用して作成し、各ユニットに格納する。さらに、第１，第２通信ユニット１２ａ，１２ｂは、システム起動時に、登録された変数名の実アドレスを、ＣＰＵユニット（コントローラ）に問い合わせることにより自主的に変数名と実アドレスとの関係を解決し、内部にテーブルとして保持するようにした。

上記した処理を実行するための具体的な処理機能について、図３以降の図面を参照にしつつ説明する。図３は、本発明の第１実施形態を示している。図３に示すように、第１，第２ＣＰＵユニット１１ａ，１１ｂは、変数名とデータ種類（型）と実アドレスとを関連づけた変数テーブルを記憶保持する。この変数テーブルは、フラッシュＲＯＭ２１に格納される。なお、実アドレスで特定されるデータは、ＳＲＡＭ２３に格納される。

図３の場合、第１ＣＰＵユニット１１ａは、２つのスイッチをそれぞれ特定する変数名（Ｓｗｉｔｃｈ１，２）と、２つのスイッチのＯＮ／ＯＦＦを示すＩＯデータを格納する実アドレス（ＤＭ１００，ＤＭ１０１）とが関連づけられた変数テーブルを備える。第２ＣＰＵユニット１１ｂは、モータＭの駆動（ＲＥＡＤＹ），停止（ＳＴＯＰ）を意味する変数名と、その変数名に対応するデータを格納する実アドレス（ＤＭ２００，ＤＭ２０１）とが関連づけられた変数テーブルを備える。そして、第１ＣＰＵユニット１１ａのＤＭ１００のメモリエリアに格納されたデータが、最終的に第２ＣＰＵユニット１１ｂのＤＭ２００のメモリエリアに格納される。第１ＣＰＵユニット１１ａのＤＭ１０１のメモリエリアに格納されたデータが、最終的に第２ＣＰＵユニット１１ｂのＤＭ２０１のメモリエリアに格納される。そして、第２ＣＰＵユニット１１ｂは、実アドレスがＤＭ２００，ＤＭ２０１のメモリエリアに格納されたデータに基づき、モータＭの動作を制御する。

第１，第２通信ユニット１２ａ，１２ｂは、自己のユニットでどの変数名のデータをサイクリック通信対象にするかを特定する通信設定情報を備えている。この通信設定情報は、フラッシュＲＯＭ３１に格納される。通信設定情報は、サイクリック通信対象となるデータを特定する変数名と送信／受信を区別する種別情報とを関連付けたデーブル構造をとる。さらに、受信データの場合には、その受信データが格納されている送信元のノードアドレスと、そのノードにおいて使用される変数名と、受信間隔とを関連付けたデータ構造となる。

具体例をあげて説明すると、ノードアドレスが＃１の第１通信ユニット１２ａに格納される通信設定情報は、変数名が「Ｓｗｉｔｃｈ１」で、送受信種別が「送信」となる。これは、他のノードからサイクリック通信を受けた場合に、変数名がＳｗｉｔｃｈｉ１に対応するデータを送信することを意味する。同様に、ノードアドレスが＃２の第２通信ユニット１２ｂに格納される通信設定情報は、その第２通信ユニット１２ｂに接続された第２ＣＰＵユニット１１ｂで使用される、変数名が「ＲＥＡＤＹ」で、送受信種別が「受信」となる。この「ＲＥＡＤＹ」は受信データであり、「ＲＥＡＤＹ」に対応するデータは第１ＣＰＵユニット１１ａに格納された変数名「Ｓｗｉｔｃｈ１」のデータである。そこで、第２通信ユニット１２ｂに格納する通信設定情報は、上記の「ＲＥＡＤＹ」，「受信」に加え、「ＲＥＡＤＹ」に対応するデータが格納された第１ＣＰＵユニット１１ａ（第１ＰＬＣ１０ａ）のノードアドレス（＃１）と、その第１ＣＰＵユニット１１ａにおける変数名「Ｓｗｉｔｃｈ１」と、受信間隔（５ｍｓ）とを関連付けたデータとなっている。この第２通信ユニット１２ａに格納された通信設定情報は、「自己が接続されている第２ＣＰＵユニット１１ｂで変数名が「ＲＥＡＤＹ」と設定されたデータは、ノードアドレス（＃１）に「Ｓｗｉｔｃｈ１」という変数名で格納されているとともに、第２ＣＰＵユニット１１ｂでは、そのデータを５ｍｓ間隔で収集したい」ということを意味する。

また、第２通信ユニット１１ｂが記憶保持する通信設定情報として、必要とする受信対象のデータが記憶保持された送信元のノードのアドレス（＃１）、ならびにそのノードにおける変数名（Ｓｗｉｔｃｈ１）というように他のノードの情報を有しているが、係る他のノード情報は、通信設定ツール３０から設定される。すなわち、通信設定ツール３０は、第１通信ユニット１２ａに対しても通信設定情報の登録を行なう。さらに、通信設定ツール３０を操作するユーザは、第２ＣＰＵユニット１１ｂで使用する変数名「ＲＥＡＤＹ」のデータと、第１ＣＰＵユニット１１ａで使用する変数名「Ｓｗｉｔｃｈ１」のデータが同一のデータであることがわかっているので、第２通信ユニット１２ｂに登録する際に第１通信ユニット１２ａのノードアドレス等を関連づけて登録することができる。なお、通信設定ツール３０を用いた設定処理については、後述する。

そして、各通信ユニット１２ａ，１２ｂのＭＰＵ３２は、それぞれ自己のフラッシュＲＯＭ３１に格納された通信設定情報と、第１，第２ＣＰＵユニット１１ａ，１１ｂに格納された変数テーブルとに基づいてテンポラリ内部テーブルを生成し、そのテンポラリ内部テーブルを揮発性メモリであるＳＲＡＭ３３に格納する。このテンポラリ内部テーブルは、接続された各ＣＰＵユニット１１ａ，１１ｂで使用される変数名と、その変数名に対応するデータのデータ種別と、その変数名のデータを記録すべきＣＰＵユニットの実アドレスとを関連付けたテーブルである。

なお、図３に示した例では、変数名が「Ｓｗｉｔｃｈ１」，「ＲＥＡＤＹ」についての通信設定情報ならびにテンポラリ内部テーブルについて示したが、「Ｓｗｉｔｃｈ２」，「ＳＴＯＰ」についての通信設定情報ならびにテンポラリ内部テーブルももちろん設定される。

次に、各通信ユニットが主体的になって行なう名前解決（変数と実アドレスの紐付け）の具体的な処理手順・機能を図３，図４を用いて説明する。まず、各通信ユニット１２ａ，１２ｂは、それぞれ独立して非同期に変数の解決（変数名と実アドレスの解決）を行なう。すなわち、各通信ユニット１２ａ，１２ｂは、ＭＰＵ３２内のユニット管理部３２ａがユニット起動等の変数の解決を行なう条件になったことを認識すると、変数解決処理を起動する。

（０）すると、それに伴いＭＰＵ３２内のユニット変数管理部３２ｂが、変数情報ストレージ処理部３２ｃを介して、あらかじめ通信設定ツールによりフラッシュＲＯＭ３１に格納されている通信設定情報を読み出す。

次いで、読み出した通信設定情報に基づいて実際に変数解決処理を行なう。すなわち、（１）ユニット変数管理部３２ｂは、読み出した通信設定情報から変数名を抽出し、同一システムバス２６上のＣＰＵユニットに対し、解決要求メッセージを送信する。つまり、システムバス２６経由で変数名（例えば「ＲＥＡＤＹ」や「Ｓｗｉｔｃｈ１」）のデータが格納された実アドレスを要求するメッセージを送信する。

（２）係る解決要求を受けたＣＰＵユニットの変数テーブル管理部２２ａ（ＭＰＵ２２の一機能として実装される）は、自己が保有するローカルの変数テーブル内を検索し、受け取った変数名と同じ変数名を探し、そのエントリに格納されている物理アドレス情報（実アドレス）・変数のサイズ情報（変数の型）を読出し、要求への応答にその情報を付加し、メッセージとして返信する。この返信により、各通信ユニットは、解決要求をした変数が登録されるＣＰＵユニットのＳＲＡＭ２３における実アドレスを知ることができる。

（３）各通信ユニットは、係る返信メッセージを受け取ると、テンポラリ内部テーブルを作成し、ＳＲＡＭ３３に格納する。つまり、受け取った変数の実アドレスとサイズ情報に、自己が有するその変数の変数名を関連づけたテーブルを作成し、テンポラリ内部テーブルとしてＳＲＡＭ３３に格納する。なお、係るテーブルを最終的に作成するのは返信メッセージを受信した後の所定タイミングになるが、予め実アドレス等を空欄にしたテーブル（変数名は格納）を作成し、実アドレス等を受信した際に対応する領域にその実アドレス等を格納するようにしても良い。

（４）次いで、各通信ユニットは、通信情報設定を検索し、「受信」属性を持つ変数を検索し、存在する場合には、その変数の付加情報に基づき、サイクリック通信要求を送信する。図３の例では、第２通信ユニット１２ｂ（＃２）に「ＲＥＡＤＹ」という変数が存在し、「受信」属性を持っていることがわかる。さらに、変数「ＲＥＡＤＹ」の付加情報には、「通信ユニット＃１につながるコントローラ１の変数「Ｓｗｉｔｃｈ１」を５ｍs周期で受信したい」と書かれている。従って第２通信ユニット１２ｂ（＃２）は、第１通信ユニット１２ａ（＃１）宛てに、「変数：Ｓｗｉｔｃｈ１／５ｍｓ」というサイクリック通信要求を送信する。

（５）係るサイクリック通信要求を受信した第１通信ユニット１２ａは、要求された変数が、自ユニット内のテンポラリ内部テーブルに存在するかどうかをチェックし、存在する場合には、サイクリック通信ＩＤ（コネクションＩＤ：この例ではＩＤ＝１）を付加した正常応答を返信する。

（６）同時に、要求を受けた通信ユニットは、ローカルのＣＰＵユニットとメモリ情報を交換（Ｉ／Ｏリフレッシュ）するために、テンポラリ内部テーブルに格納されている「解決済みの実アドレス」を、システムバス上のＩ／Ｏリフレッシュ情報として使用する。つまり、システムバス管理部３２ｄが共有ＲＡＭ３４のサイクリックリフレッシュ転送テーブルにセットする。このサイクリックリフレッシュ転送テーブルのデータ構造は、サイクリック通信ＩＤ（コネクションＩＤ）と、実アドレスと、サイクリック受信対象となる実際のデータを書き込むデータ領域とを関連づけたテーブルであり、このデータ領域にサイクリック通信により得られたデータを書き込む。これにより、変数の解決が完了する。

その後は、第１通信ユニット１２ａから第２通信ユニット１２ｂ宛てに、５ｍｓ周期で、Ｓｗｉｔｃｈ１の最新値が送信される。なお、係る送信は、第１通信ユニット１２ａ画自発的に行なっても良いし、第２通信ユニット１２ｂからの要求に対するレスポンスとして返信することにより実行しても良い。

この時、第１通信ユニット１２ａと第２通信ユニット１２ｂ間で送信されるパケットには、サイクリック通信ＩＤ＝１が付加される。各通信ユニット１２ａ，１２ｂは、サイクリック通信ＩＤと、そのＩＤとともに送受信されるデータが格納されるべきＣＰＵユニットのＳＲＡＭの実アドレスと、送受信するデータを一時的に格納するバッファメモリ領域が関連づけられたサイクリックリフレッシュ転送テーブルを備えている。そこで、第２通信ユニット１２ｂは、受信したパケットに格納されたサイクリック通信ＩＤに基づき、受信した最新値をサイクリックリフレッシュ転送テーブルの対応するデータ領域に書き込む。なお、このデータ領域への書き込みであるが、サイクリック通信により受信したデータを直接サイクリックフレッシュ転送データに格納して良いし、一旦、ＳＲＡＭ３３に格納し、そのＳＲＡＭ３３に格納したデータを転送するようにしても良い。

そして、第２ＣＰＵユニット１１ｂは、ＩＯリフレッシュにより、共有ＲＡＭ３４をアクセスし、サイクリックリフレッシュ転送テーブルに格納されたデータを取得し、対応する実アドレスで規定される自己のＳＲＡＭ２３に格納する。

このように、変数の解決を行なった後のノード間の通信では、ネットワーク上にユニークに存在するサイクリック通信ＩＤ（コネクションＩＤ）をキーにデータの送受を行なう。そして、ＣＰＵユニットと通信ユニット間のローカルな世界でのデータ送受は、各ノードの通信ユニットに設けたサイクリック通信ＩＤとＣＰＵユニットに格納すべき実アドレスを関係づけたサイクリックリフレッシュ転送テーブルに従って処理する。これにより、各ＰＬＣは、送受信する相手のノードで使用される送受信対象のデータが格納される実アドレスを知らなくても、データの送受ができる。

ところで、オンラインエディット等により、ＣＰＵユニット側で変数の割付が変更された場合には、変数テーブル管理部が、通信ユニットに対し「変更要求」を通知する。そして、その通知に基づき、通信ユニット側は変数解決処理を行ない、テンポラリ内部テーブルを更新する。これにより、変数の割付が行なわれても、そのまま処理を実行できる。

また、上記した実施形態では、２台のＰＬＣ１０ａ，１０ｂでネットワークが構成された例を示したが、本発明これに限ることはなく、３台以上でも同様の手順で変数の解決を行ない、その後、上記と同様にサイクリック通信ＩＤとともにサイクリック通信対象のデータを送受信することができる（図５参照）。

なお、同一のデータを複数のノードで受信対象になっている場合には、サイクリック通信する周期は等しくする。そして、同一のデータを使用する複数のノードが存在する場合に、その複数のノードに対して同時に通信設定ツール３０を用いて通信設定情報を設定するようにすれば問題はない。また、例えば新たにＰＬＣを追加した場合に、その追加したＰＣＬで受信データとして設定されたれたものがすでに他のＰＬＣの通信設定情報にも設定される場合には、基本的にそれを利用する。

図５を用いて、すでに２台で動作しているネットワークに、３台目のＰＬＣが参加する場合を例に説明する。係る事態は、例えば、ＰＬＣ３の立ち上がりが遅れた場合、通信設定が後から個別になされた場合などに生じる。

まず、上述した（１）〜（４）の処理を実行し、通信設定情報で「受信」属性を持つ変数について、サイクリック通信要求を送信する。上記「受信」属性をもつ変数のデータを格納する通信ユニットが、当該要求を受信するので、以下に示す処理を実行する。

（５）′サイクリック通信要求を受信した通信ユニット（図の例では第１通信ユニット１２ａ）では、受信した要求（図示の場合、追加された第３通信ユニット１２ｃからの要求）を解析し、要求されている変数が既に他のユニットにサービスしているかどうかを検索する。つまり、具体的には、テンポラリ内部テーブルを参照し、Ｓｗｉｔｃｈ１が存在するかどうかを確認する。Ｓｗｉｔｃｈ１が存在するので、そのサービス周期を要求値と比較する。この例では５ｍｓと同じであるので、第２通信ユニット（＃２）１２ｂにサービスしている処理と共有できると判断し、そのＩＤを読出し、ＩＤ＝１で送信することを要求した第３通信ユニット＃３に応答する。

（６）その後、第１通信ユニット１２ａ（＃１）は、５ｍｓ周期で、ＩＤ＝１としてＳｗｉｔｃｈ１の最新値をネットワーク上にブロードキャストで送出する（送信先ユニット番号を指定しない）。各通信ユニットは、ブロードキャストを受信した際にＩＤ番号を確認し、自身が要求してＯＫとなったＩＤと一致するかどうかを確認し、一致すればユニット内部に取り込み、上記の同様の処理を行なう。

また、要求されたサイクリック通信時間が異なる場合には、第１ユニット１２ａは新たにサイクリック通信ＩＤ（例えば、ＩＤ＝２）を生成した上で、第３通信ユニット１２ｃに応答し、それ以降ＩＤ＝１の送信とは別にＩＤ＝２として要求された周期で送信する。一例を示すと、例えば、第３通信ユニット１２ｃ（＃３）が、第１通信ユニット１２ａにＳｗｉｔｃｈ１を要求するが、サイクリック通信時間が７ｍｓである場合には、ユニット#３の通信設定は、ＳＴＡＲＴ：受信：＃１／Ｓｗｉｔｃｈ１：７ｍｓとなる。すると、Ｓｗｉｔｃｈ１が既にサービスされているものの、要求周期が異なるため、第１通信ユニットは新たにＩＤを生成した上（ＩＤ＝２、等）で、第３通信ユニット１２ｃに応答し、それ以降ＩＤ＝１の送信とは別にＩＤ＝２として７ｍｓ周期で送信する。このようにＩＤを変えることにより、同一のデータでありながら、各通信ユニットにとって適した周期でサイクリック通信を行なうことができる。

また、本発明は、以下のような処理としてもよい。すなわち、多くの制御システムにおいては、より高速にデータが更新される方が都合がよい場合が多い。したがって、サイクリック通信の要求周期が、既にサービスしている周期よりも大きい場合には、一番周期の小さいサービスで共有するという処理も可能となる。そうすると、第１通信ユニット１２ａの送信処理も効率化できるとともに、通信回線利用効率もあがるため、システム全体としてはメリットがでることが多い。

そこで、前述の処理（５）′において、要求された変数が共有できるが、サイクリック周期が異なる場合には、周期を比較し、既に存在するサービスの周期が小さい場合には、応答として「ＯＫ，ＩＤ＝１，５ｍｓ」と、サービスできる周期を付加する。その後は、第２，第３通信ユニットの２台に対し、ＩＤ＝１で５ｍｓ周期で最新値が送信されることになる。

次に、通信設定ツール３０を用いた設定処理について説明する。上記した変数解決をするための前提とし、通信設定ツール３０を用いて各通信ユニットに対して通信設定情報を格納する必要がある。この設定処理は、例えば図６（ａ）,（ｂ）に示すように、通信設定ツール３０の表示画面に、通信設定情報テーブルと同様の表形式の入力画面を出力表示する。そして、ユーザは、その表中の空欄に所望のデータを入力する（図は、書物データを入力後の状態を示している）。そして、入力したデータを確定すると、そのデータをネットワークを介して各通信ユニットにダウンロードする。これにより、通信ユニットのフラッシュＲＯＭ３１に格納する。

なお、図示省略するが、送信側の通信ユニットに対しても、上記と同様の入力画面を用意し、ダウロードしても良いし、この受信側の通信設定ツール３０の設定例の画面中の「通信ユニットＮｏ（ノードアドレス）と、受信Ｔａｇ名を抽出し、送信側の通信ユニットの通信設定情報を生成し、登録するようにしても良い。

さらに、通信設定ツール３０は、同一のデータに対して異なる通信周期を指定した場合の対応として、以下のような機能を持つ。すなわち、例えば、受信通信ユニット＃３の通信設定内容を入力した場合、通信ユニットＮｏ．，受信Ｔａｇ名と同じものが、既に入力された通信ユニットにおいて設定されたものがあるか否か検索する。そして、同じエントリが存在する場合には、その通信周期を比較し、周期が異なる設定が存在する場合には、それらをツール画面に表示し、設定者に確認を求める。その場合、図７に示すように、最速の周期にあわせるように促すメッセージを表示するようにする。

上述のようにこの実施形態においては、通信設定情報について、どの変数名を他のノードとの間の通信（サイクリック通信他）の対象にするかの情報は通信ユニットに登録するようにし、その通信ユニットは、システム起動時等の所定のタイミングで、通信設定情報に登録された変数の実アドレス（プログラマブルコントローラ内部のローカルな物理アドレス）を、コントローラに問い合わせることにより自主的に解決し、内部にテーブルとして保持するようにした。これにより、通信ユニットとコントローラとの間のデータの受渡が可能となる。つまり、実アドレスと相違し、変数名は同じシステムにおいては頻繁に変わることがない。従って、通信ユニットに設定した後で、コントローラ側で変更される可能性が少ないので、一度通信設定情報を通信ユニットに登録すると、その変数名について再設定する必要がなくなる。

さらに、通信ユニットは、通信を行なう他のノードとの間で、通信する際のデータを特定する識別情報（実施形態では、通信ＩＤ）を共有し、データの通信はその識別情報を付加して行なうことにより、通信ユニット間でのデータの送受が行なえる。

そして、通信ユニットは、他の通信ユニットとデータ送受するための識別情報と、自己が接続されたコントローラにおけるその識別情報で特定されるテータの格納エリア（実アドレス）がわかっているため、各プログラマブルコントローラで異なる変数名を使用していても、通信ユニットがその関係を認識し、コントローラとの間でデータの受渡しができ、それにより、コントローラ（プログラマブルコントローラ）間で同一データの共有が可能となる。

このように、変数名と通信の結びつき管理を通信ユニットが行なうため、コントローラでは管理が不要となり、負荷分散になる。そして、通信ユニットが複数になった場合にも、各通信ユニットが係る管理を行なうので、コントローラに求められるリソースは増やさなくてすむ。よって、通信能力（データ量、ノード数など）がコントローラに依存しないので、ユニットを増やせば能力も増大する。

図８は、本発明の第２実施形態を示している。上述の第１実施形態は、通信設定ツール３０を用いて各通信ユニットに対してそれぞれ通信設定情報を設定し、それに基づいて通信ユニットとＣＰＵユニット１１間での名前解決を行ない、最終的にサイクリック通信ＩＤ（コネクションＩＤ）を設定した。すなわち、各通信ユニットは、接続されるＣＰＵユニットとの間で名前解決する変数名に関する通信設定情報を備えるようにした。換言すると、上述の第１実施形態は、ＰＬＣ間のデータ送受信を実現するために、データを送信する側のＰＬＣの通信ユニットに送信用の通信設定情報を格納するいっぽう、データを受信する側のＰＬＣの通信ユニットに受信用の通信設定情報を格納する例であった。つまり、１つのコネクションＩＤを決定する際に用いる通信設定情報を送信側と受信側に分け、それぞれのユニットに格納した。

これに対し、本実施形態では、１つのコネクションＩＤを設定するのに関係する通信設定情報を一方の通信ユニットに対してのみ格納するようにした。そして、互いに通信する通信ユニット同士で、片方の通信ユニットに送受信両方の通信設定情報を入れるようにした。図８に示す例では、通信設定情報は、ノードアドレスが＃１の第１通信ユニット１２ａに格納される。この通信設定情報が格納されたユニットをオリジネータとし、通信設定情報が格納されないユニットをターゲットと称する。また、第１，第２ＣＰＵユニット１１ａ，１１ｂは、共に変数テーブルを備えている。この変数テーブルは、ユーザが作成したプログラムにおいて使用された変数名と、その変数名に対応するデータの型と、そのデータが格納されるメモリアドレスとを関連づけたテーブルである。この変数テーブルについては、第１実施形態と同様である。ただし、本実施形態では、第２ＣＰＵユニット１０ｂに接続されたモータＭのステータスについての情報も管理するようにしている。このステータスは、例えば、動作中と停止中の２つの状態を示すものである。

これに伴い、モータＭが接続された第２ＰＬＣ１０ｂを構成する第２ＣＰＵユニット１１ｂは、モータＭのステータスを意味する変数名が「ＳＴＡＴＵＳ」で、型が「ｗｏｒｄ」で、そのモータＭのステータスを格納するメモリアドレスが「ＤＭ２５０」で有ることを関連づけた変数テーブルを備えている。もちろん、第１実施形態と同様に、「ＲＥＡＤＹ」，「ＳＴＯＰ」についても、変数名テーブルに格納されており、これら２つの変数名が意味する内容は、第１実施形態と同様である。

また、第１ＰＬＣ１０ａを構成する第１ＣＰＵユニット１１ａは、モータＭのステータスを監視するようになっている。それに合わせて、第１ＣＰＵユニット１１ａの変数テーブルは、変数名「Ｓｗｉｔｃｈ１」と「Ｓｗｉｔｃｈ２」に加え、モータのステータスを入力するための変数名「Ｍ＿ＳＴ」についての関連データも記述されている。

さらに、第１の通信ユニット１２ａは、他の通信ユニットと送受信するデータを一時記憶するための通信バッファテーブルを備えている。第２の通信ユニットも同様に通信バッファテーブルを備えている。この通信バッファテーブルは、テーブル番号と、変数名と、送受信するデータを格納するエリアとを関連づけたテーブル構造となっている。そして、この通信バッファテーブルは、例えば、共有ＲＡＭ３４に格納される。この通信バッファテーブルは、実際の動作の際には、異なるＰＬＣ同士の通信ユニット間のデータ通信に用いられ、また同一ＰＬＣ内の通信ユニットとＣＰＵユニットとの間のデータ転送に用いられる。この通信バッファテーブルに記憶された情報は、通信ユニット内の不揮発性メモリにバックアップされる。そして通信ユニットのＭＰＵ３２は、電源投入時等の所定のタイミングで不揮発性のメモリからバックアップした情報を読み出し、それを共有ＲＡＭ３４に格納する。

以下、接続されたＣＰＵユニットと通信ユニット間で行なわれる名前解決と、通信ユニット間で実際にデータを送受信する際に利用するコネクションＩＤの決定の処理手順を説明しつつ、各ユニットの機能を説明する。

（０）まず、ユーザは、通信設定ツール３０を操作して、第１ＣＰＵユニット１１ａに格納する変数テーブルを作成し、その作成した変数テーブルを第１ＣＰＵユニット１１ａにダウンロードする。同様に、ユーザは、通信設定ツール３０を操作して、第２ＣＰＵユニット１１ｂに格納する変数テーブルを作成し、その作成した変数テーブルを第２ＣＰＵユニット１１ｂにダウンロードする。

また、ユーザは、通信設定ツール３０を操作して、第１通信ユニット１２ａに格納する通信バッファテーブルを作成し、その作成した通信バッファテーブルを第１通信ユニット１２ａにダウンロードする。同様に、ユーザは、通信設定ツール３０を操作して、第２通信ユニット１２ｂに格納する通信バッファテーブルを作成し、その作成した通信バッファテーブルを第２通信ユニット１２ｂにダウンロードする。

ユーザは、プログラミングツール（ハードウェアとしては、通信設定ツール３０と同一のパソコンの場合もあるし、異なる場合もある）を用いて各ＣＰＵユニットが実行するユーザプログラムを作成する。ツール３０で作成されたユーザプログラムは、ＣＰＵユニットにダウンロードする際にコンパイルされる。コンパイルの際にプログラム中に用いられている変数名は実アドレスに変換されるので、ＣＰＵユニットは、実アドレスで記述されたユーザプログラムを実行する。なお、ユーザプログラムに用いる変数は、予めユーザがＰＬＣ制御に用いるデータ（接点の意味を含む）と対応付けて決めるものであるので、ユーザは、各ＣＰＵユニットにおける変数（変数名）とデータ（接点の意味を含む）との対応情報を知っている。また、ユーザは、各ＣＰＵユニットにおけるメモリ割付情報、つまり、データ（接点の意味を含む）と、そのデータのＣＰＵユニットのメモリの記憶エリア（実アドレス）との対応情報を知っている。さらに、ユーザは、ＰＬＣ間でデータの送受信を行なう場合、どのＣＰＵユニットに格納されたデータを、別のどのＣＰＵユニットに送るべきかを知っている。さらにユーザは、ＰＬＣ間で送受信対象となっているデータが、送信するＣＰＵユニットおよび受信するＣＰＵユニットにおいてどのような変数名に対応するかを知っている。そこで、係る情報に基づいて、ユーザが各ＣＰＵユニットにダウンロードする変数テーブルや、各通信ユニットにダウンロードする通信バッファテーブルを作成することができる。

さらに、ユーザは、通信設定ツール３０を操作し、一方の通信ユニット（この例では、第１通信ユニット１１ａ（オリジネータ側））の通信設定情報を作成し、第１通信ユニット１２ａ（＃１）へ格納する。ここで設定する通信設定情報は、自局で使用される変数名と、相手局で使用される変数名と、通信相手のノードアドレスと、通信の向き（ＯＵＴ／ＩＮ）と、データを送受信する際の周期と、データサイズと、を関連づけたテーブルとなる。

（１）変数テーブルと、通信バッファテーブルを各ユニットにダウンロードすると、各通信ユニット１２ａ，１２ｂは、名前解決処理を実行可能となる。例えば、通信ユニットは、リセットされることを契機として名前解決を行なう。具体的には、リセットされると、各通信ユニット１２ａ，１２ｂは、オリジネータ／ターゲットを問わず例えば通信バッファテーブルに格納された変数名に基づいて、その変数名に対応するデータが格納される実アドレスが何であるかについて、接続されたＣＰＵユニットへ問合せをする。すなわち、例えば第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａに対し、変数名が「Ｓｗｉｔｃｈ１」のデータが格納されているメモリの実アドレスの問い合わせをする。

（２）第１ＣＰＵユニット１１ａは、問い合わせを受けた変数名をキーにして変数テーブルをアクセスし、該当する実アドレス（ＤＭ１００）を取得すると共に、問い合わせに対するレスポンスとして、取得した実アドレスを第１通信ユニット１２ａに返信する。第１通信ユニット１２ａは、同様に「Ｓｗｉｔｃｈ２」，「Ｍ＿ＳＴ」に対応する実アドレスについても問い合わせを行ない、第１ＣＰＵユニット１１ａからレスポンスとして対応する実アドレスを取得する。

なお、図示の例では、１つずつ問い合わせをしているが、一括して問い合わせをしても良い。図示省略するが、この実アドレスの返信の際に、データサイズ（型）も返信するようにしてもよい。この点は、他の実施の形態及び変形例でも同じである。

同様に、第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂに対し、変数名が「ＲＥＡＤＹ」，「ＳＴＯＰ」，「ＳＴＡＴＵＳ」に対応するデータが格納されているメモリの実アドレスの問い合わせをする。そして、第２ＣＰＵユニット１１ｂは、問い合わせを受けた変数名をキーにして変数テーブルをアクセスし、該当する実アドレス，型（サイズ）を取得すると共に、問い合わせに対するレスポンスとして、取得した実アドレス，型（サイズ）を第２通信ユニット１２ｂに返信する。図８では、第２通信ユニット１２ｂが「ＲＥＡＤＹ」について名前解決の問い合わせをし、第２ＣＰＵユニット１１ｂから「ＤＭ２００／１Ｗ」と返信がされている。

なお、この名前解決処理を実行するタイミングは、上述したリセットに基づくものに限定されず、自由に設定することができ、少なくとも通信バッファテーブルと変数テーブルが格納されたならば、作成することができる。この点は、他の実施の形態及び変形例でも同じである。

各通信ユニットが取得した実アドレスとデータサイズとの情報について簡単に説明すると、実アドレスは、通信確立後に通信ユニット間で通信される場合、通信ユニットがＣＰＵユニットとの間のデータ交換に必要な情報であり、オリジネータ／ターゲット問わず両方で用いる。データサイズは、通信確立をする際に、オリジネータ側が通信確立要求をするとき、またはターゲット側が通信確立処理をする際に必要な情報である。この点は、他の実施の形態及び変形例でも同じである。

また、この第２実施形態では、オリジネータ側の通信ユニット１２ａは、自局において通信対象となる変数名の情報が通信設定情報にすべて含まれた状態で記憶している。よって、このオリジネータ側の第１通信ユニット１２ａが名前解決処理を行う際、上述のように通信バッファテーブルに記憶された変数名に基づく代わりに、通信設定情報に含まれた変数名に基づいて行うことができる。つまり、第１通信ユニット１２ａは、通信設定情報に含まれた「Ｓｗｉｔｃｈ１」、「Ｓｗｉｔｃｈ２」、「Ｍ＿ＳＴ」のそれぞれの変数名に対応する実アドレスを第１ＣＰＵユニット１１ａに問い合わせを行ない、それぞれに対応する実アドレスを取得する。もちろん必要に応じて、図示のように同時にデータのサイズに関する情報を取得してもよい。

（３）第１通信ユニット１２ａは、名前解決した情報を記憶しておく。記憶エリアは、例えば、テンポラリ内部テーブルを用いることができる。なお、通信設定情報を備えたオリジネータ側では、通信設定情報中に「向き」まで特定されているため、図８に示すようにテンポラリ内部テーブルは完成する。テンポラリ内部テーブルは、通信バッファテーブル番号，変数名，実アドレス，データサイズ，向き（ＩＮ／ＯＵＴ）を関連づけたテーブルである。これにより、名前解決は終了する。なお、通信設定情報にデータサイズも格納するようにしたため、テンポラリ内部テーブルのサイズの欄に格納するデータは、その通信設定情報のサイズの欄から取得するようにしたが、本発明はこれに限ることはなく、第１ＣＰＵユニット１１ａから返信される実アドレスと共にデータの型（サイズ）を加えることにより、第１ＣＰＵユニットに格納された変数テーブル中のデータを利用してテンポラリ内部テーブルのデータサイズを作成することができる。さらに、通信設定情報を作成する際に、ユーザがデータサイズを書き込むのではなく、変数テーブルのデータを利用して作成するようにしても良い。この点は、他の実施の形態及び変形例でも同じである。

（３）′第２通信ユニット１２ｂは、名前解決した情報を記憶しておく。記憶エリアは、例えば、テンポラリ内部テーブルを用いることができる。ターゲット側の第２通信ユニット１２ｂは、通信設定情報を持っていないため、データ送信の向き（送信：ＯＵＴ，受信：ＩＮ）の区別等は不明である。しかし、第２通信ユニット１２ｂは、通信バッファテーブルに格納された情報から第１の通信ユニット１２ａと通信するデータの自局の変数名はわかっているため、変数名の実アドレスを第２ＣＰＵユニット１１ｂに問い合わせることにより、その変数名と実アドレスの対応付けを認識できる。従って、第２通信ユニット１２ｂは、通信バッファテーブルに格納された全ての変数名について、処理（１），（２）を実行することにより、通信バッファテーブルのテーブル番号と、変数名と、実アドレスと、サイズ（型に基づき設定）とを関連づけることができ、その関連づけたデータをテンポラリ内部テーブルに格納する。これにより、通信の向きが空欄のテンポラリ内部テーブルが作成される。尚、図８は、後述する全ての処理を実行し最終的に作成される「向き」も格納したテンポラリ内部テーブルの状態を示している。この（３）′の処理を実行することにより、第２通信ユニット１２ｂ側でも名前解決が終了する。

（４）次に、コネクションＩＤの設定処理手順について説明する。ノード番号の小さいオリジネータから順番に、ターゲットへ通信確立要求をする。この通信確立要求は、ツール３０からの通信確立命令が出されたことに基づき、各通信ユニットが順次処理対象のデータの通信相手となる通信ユニットに対して通信確立要求を発行することになる。この通信確立要求は、相手局変数名，データサイズ，向き並びに周期の情報を相手ノードに送る。これに自己局の変数名を含めても良い。もちろん、通信確立要求のフレームのヘッダには、送信元情報として、自己のノードアドレス（＃１）と相手のノードアドレス（＃２）が格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。また、この通信確立要求は、コネクションＩＤを設定する単位で行なわれる。従って、本実施形態では、変数名ごとにコネクションＩＤを競ってするため、変数名ごとに１つずつ処理を実行する。

図８の例では、ノードアドレス＃１の第１通信ユニット１２ａは、まず、第２通信ユニット１２ｂに対し「ＲＥＡＤＹ／１Ｗ／ＯＵＴ／５ｍｓ」を内容とする通信確立要求を発行する。

（５）この通信確立要求を受信したターゲットは、要求内容をチェックする。すなわち、テンポラリ内部テーブルをアクセスし、通信確立要求された変数名の有無をチェックする。そして、変数名が存在している場合には、ターゲットは、サイズが一致するか否かをチェックし、一致する場合には、通信確立要求と共に送られてきた「向き情報」と反対の向きをテンポラリ内部テーブルに格納する。従って、上記の通信確立要求を受けた第２通信ユニット１２ｂが要求内容を正しいと認定した場合、第２通信ユニット１２ｂは、空欄となっていたテンポラリ内部テーブルのＲＥＡＤＹに対応する「向き」の欄に、「ＩＮ」を入力する。

なお、変数名の有無のチェックは、上記のようにテンポラリ内部テーブルに基づいて行なっても良いが、本発明はこれに限るものではなく、通信バッファテーブルに基づいて行なっても良い。さらに、テンポラリ内部テーブルと通信バッファテーブルの両方に基づいて変数名の有無をダブルチェックするようにしてもよい。

（６）さらに、ターゲットは、実周期と要求周期とを比較し、対応可能か否かをチェックする。対応可能な場合には、ターゲットは、コネクションＩＤを特定し、通信設定ツール３０の表示装置に「要求条件ＯＫ」の旨と「通信確立内容」とをモニタ表示させる。そして、ターゲットは、通信確立要求の発行元であるオリジネータに対して「要求条件ＯＫ」の旨と、コネクションＩＤを通知する。このとき、実周期を同時に送るようにしても良い。ターゲット側の実周期は、ターゲットのシステムメモリに格納されているため、ターゲットは、それを読み出してコネクションＩＤ等と一緒に通知する。

コネクションＩＤは、オリジネータのノードアドレスと、ターゲットのノードアドレスと、シリアル番号との組み合わせから構成される。シリアル番号は、処理した順に付与する。従って、例えば上述した「ＲＥＡＤＹ」についての通信確立要求が最初に発行されてきた場合、ターゲットは、「＃１＃２−００１」というコネクションＩＤを設定する。

一方、ターゲットが、要求された周期では対応できない場合には、通信設定ツール３０の表示装置に「要求周期では対応不可。実周期＊＊ｓｅｃでよいか？」等の確認メッセージを表示し、ユーザへ確認を促す。この確認メッセージに対してユーザ入力が「よい」とされた場合には、ターゲット側で対応可能な実周期を、（６）の要求許可通知とともに通知する。実周期はターゲットである第２通信ユニット１２ｂに予め設定されている。要求許可通知に含まれる情報を念のため詳しく挙げると、許可通知（ＯＫ／ＮＧ）、コネクションＩＤ、自己局ノードアドレス（ターゲット側ノードアドレス）、相手局ノードアドレス（オリジネータ側ノードアドレス）、周期である。（一部は図示を省略しているが）。また、通信確立要求は、変数名ごとに１つずつ行なわれるため、上述した（４）から（６）の処理は、さらに「ＳＴＯＰ」，「ＳＴＡＴＵＳ」についてそれぞれ順に実行される。また、各通信確立要求を受けたターゲットから要求許可通知が発行されると、オリジネータとターゲットでは、図９に示すデータ構造からなるコネクションテーブルが作成される。このコネクションテーブルは、１つのコネクションＩＤが付与されるごとに、逐次作成され、更新される。

上述した手順により通信確立した後は、コネクションＩＤを利用して通信ユニット間で、Ｓｗｉｔｃｈ１のＯＮ／ＯＦＦ情報やＳｗｉｔｃｈ２のＯＮ／ＯＦＦ情報、モータのステータス情報などの各種データを通信する。例えば、第１通信ユニット１２ａ（＃１）が、Ｓｗｉｔｃｈ２のデータを第２通信ユニット１２ｂ（＃２）へ送信するときについて説明する。第１通信ユニット１２ａのＭＰＵは、テンポラリ内部テーブルを参照して、送信データを第１ＣＰＵユニット１１ａから読み出す処理を行う。テンポラリ内部テーブルは、通信ユニットにおける通信対象データ（送信データ）とＣＰＵユニットの実アドレスとの対応情報を持っている。第１通信ユニット１２ａは、テンポラリ内部テーブルに基づいて通信対処データに対応するＣＰＵユニット１１ａのメモリの実アドレスを取得する。第１通信ユニット１２ａと第１ＣＰＵユニット１１ａとの間のデータ送受はシステムバス２６を介して行われる。詳しく言うと、第１通信ユニット１２ａと第１ＣＰＵユニット１２ｂとの間では、ＩＯリフレッシュまたは周辺処理などのタイミングで第１ＣＰＵユニット１２ｂの実アドレスＤＭ１００に格納されているデータを、通信バッファに格納し更新する。この点は後述の各実施形態でも同様である。

第１通信ユニット１２ａは、取得した通信対象データを通信バッファに記憶する。通信バッファの格納領域は通信バッファテーブルにて一義に決まる。そして、第１通信ユニット１２ａは、通信対象データを送信するために、コネクションテーブルを参照して、メッセージフレームを生成する。つまり、コネクションＩＤ「＃１＃２−００２」と、通信バッファテーブルのテーブル番号「２」のデータエリアに格納されたデータとをメッセージフレームに含ませて、ノードアドレス＃２の第２通信ユニット１２ｂへ送信する。第２通信ユニット１２ｂは、自己宛のコネクションＩＤ「＃１＃２−００２」のメッセージを受信したら、コネクションテーブルから記憶すべき通信バッファテーブルのテーブル番号「１２」を認識し、そのテーブル番号「１２」に対応する通信バッファのメモリエリアに受信したデータを格納する。ここで言う第１通信ユニット１２ａが行うデータ送信は、第１通信ユニット１２ａが自発的に送信動作をするようにしてもよいし、第２通信ユニット１２ｂが第１通信ユニット１２ａへデータ要求をし、それに応じて第１通信ユニット１２ａが送信動作をするようにしてもよい。その通信サイクルは、通信確立の際に定めた定周期（例えば５ｍｓ）となる。この点は後述の各実施形態でも同様である。

なお、第２通信ユニット１２ｂと第２ＣＰＵユニット１１ｂとの間では、所定タイミングで通信バッファテーブルに格納されたデータが第２ＣＰＵユニット１１ｂの実アドレスＤＭ２０１に格納される。すなわち、第２通信ユニット１２ｂは、テンポラリ内部テーブルにより通信バッファテーブルのテーブル番号「１２」に格納されたデータの実アドレスがＤＭ２０１であることがわかるので、第２ＣＰＵユニット１１ｂのＩＯリフレッシュまたは周辺処理などのタイミングで第２ＣＰＵユニット１１ｂのデータ更新を行なう。

図１０は、第２実施形態の変形例を示している。上述した第２実施形態は、各通信ユニットとＣＰＵユニット間における名前解決処理を、コネクションＩＤの設定処理を行なう前に、予め各ユニット間同士で事前に行なうようにした。これに対し、この変形例では、ターゲット側の名前解決は、コネクションＩＤの設定を行なう一連の処理手順の中で行なうようにした。

（０）すなわち、ユーザは、通信設定ツール３０を操作し、第１ＣＰＵユニット１１ａ用の変数テーブルと、第２ＣＰＵユニット１１ｂ用の変数テーブルと、第１通信ユニット用の通信バッファテーブルと、第２通信ユニット用の通信バッファテーブルを作成し、それぞれのテーブルを対応するユニットにダウンロードする。さらに、ユーザは、通信設定ツール３０を操作し、通信設定情報を作成し、第１通信ユニット１２ａへ格納する。この変形例においても、第１通信ユニット１２ａは、送信側と受信側の区別無く、オリジネータとなり、送受信両方の通信設定情報を保持する。

（１）次に、オリジネータ側の第１通信ユニット１２ａは、通信設定情報に格納された自局変数名について、第１ＣＰＵユニット１１ａへ名前解決要求をする。この名前解決要求は、自局変数名に対応するデータが格納される第１ＣＰＵユニット１１ａにおけるメモリの実アドレスを問い合わせることである。なお、オリジネータ側となる通信ユニットにおける名前解決要求の実行の変化例として、通信設定情報の中に設定された変数名に代えて、通信バッファテーブルの中の記憶された変数名に基づいて名前解決要求を実行することも可能である。この点は後述の各実施形態の変形例でも同じである。また、名前解決要求する単位は、変数名ごとに１つずつ行なうようにしても良いし、複数の変数名について一括して行なうようにしても良い。この点も後述の実施形態の変形例でも同じである。

（２）第１ＣＰＵユニット１１ａは、受信した名前解決要求に応じて変数テーブルを参照し、対応する実アドレス（メモリアドレス）を返信する。このとき、第１ＣＰＵユニット１１ａは、データサイズも併せて返信してもよい。

（３）オリジネータ側の第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａから返信されてきた情報（実アドレス，型：データサイズ）と、自己が保有する通信設定情報とに基づいてテンポラリ内部テーブルを作成する。作成されるテンポラリ内部テーブルのデータ構造は、第２実施形態と同様である。

（４）通信設定ツール３０からの通信確立命令を受けて、オリジネータ側の第１通信ユニット１２ａ（＃１）は、通信設定情報に格納された変数名について、テンポラリ内部テーブルに基づいて、ターゲット側の第２通信ユニット１２ｂ（＃２）へ通信確立要求をする。通信確立要求とともに送る情報は、相手局変数名／サイズ／向き／周期を含む。この通信確立要求に自己局の変数名を含めても良い。また、通信確立要求のフレームのヘッダには、自己のノードアドレスと相手のノードアドレスが格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。この通信確立要求は、一つずつ行なう。図では、テンポラリ内部テーブルに格納された「ＲＥＡＤＹ」について通信確立要求をしている。最終的には、第１通信ユニット１２ａは、通信設定情報に格納された全ての変数名について通信確立要求をする。

（５）通信確立要求を受信した第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂに対し、受信した変数名について名前解決要求をする。図示の例では、第２通信ユニット１２ｂは、変数名「ＲＥＡＤＹ」についての実アドレスを問い合わせる要求をしている。

（６）第２ＣＰＵユニット１１ｂは、名前解決要求に応じて変数テーブルを参照し、変数名に対応する実アドレスと型（サイズ）とを取得し、第２通信ユニット１２ｂへ返信する。図では、第２ＣＰＵユニット１１ｂは、問い合わせのあった「ＲＥＡＤＹ」に対し、「ＤＭ２００／１Ｗ（１ｗｏｒｄの意味）」を返信している。

（７）第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂから取得したメモリアドレスと型（サイズ）に基づき、第１通信ユニット１２ａから受信した通信確立要求の内容をチェックする。具体的なチェック項目は、「要求された変数名を持つか？」，「その変数名のデータが通信バッファに設定あるか？」，「サイズが合致しているか？」，「実周期と要求周期とを比較し、対応可能か？」等がある。第２通信ユニット１２ｂは、全ての条件を具備した場合、通信確立要求を許可する決定をし、要求周期以外の条件が１つでも合致しない場合には、通信確立要求を許可しない決定をする。また、要求周期が対応不可の場合には、ツールで「要求周期では対応不可。実周期＊＊ｓｅｃでよいか？」等のメッセージを表示し、ユーザへ確認を促す。ユーザ入力が「よい」を受け付けた場合には、提示した実周期で通信することを条件に通信確立要求を許可する決定をする。

そして、要求内容が正しく、通信確立要求を許可する場合には、第２通信ユニット１２ｂは、テンポラリ内部テーブルを作成する。このテンポラリ内部テーブルのデータ構造は、第２実施形態と同様である。ここでは、受信した通信確立要求の内容と、名前解決処理で取得した変数名と実アドレスの対応関係から、現在コネクションＩＤの設定の処理対象となっている変数名について一度に作成する。つまり、第２実施形態のように、一旦「向き」が空欄となった不完全なテンポラリ内部テーブルを作成するのではなく、その変数名について関連する全ての情報が格納されたテンポラリ内部テーブルを作成する。あわせて、第２通信ユニット１２ｂは、通信設定ツール３０に、「要求条件ＯＫ」の旨と「通信確立内容」とをモニタ表示する。

（８）通信確立要求を許可する場合、第２通信ユニット１２ｂは、コネクションＩＤを特定し、特定したコネクションＩＤと、「確立要求許可通知」とを第１通信ユニット１２ａに返信する。このとき、第２通信ユニット１２ｂは、実周期を合わせて送信しても良い。

以下、第２実施形態と同様に、第１通信ユニット１２ａと第２通信ユニット１２ｂは、ともにコネクションテーブルを作成する。さらに、上記の（４）から（８）の処理を、各変数名ごとに繰り返し実行し、全ての変数名（ＲＥＡＤＹ、ＳＴＯＰ、ＳＴＡＴＵＳ）についての確立要求を行ない、コネクションＩＤを設定する。従って、図示の例では、ＲＥＡＤＹ、ＳＴＯＰ、ＳＴＡＴＵＳを別々に通信確立要求を行なうため、上記の（４）から（８）の処理は、合計３回実行される。通信確立したのちは、コネクションＩＤを利用して通信ユニット間で通信することは、第２実施形態と同様であるため、その説明を省略する。

図１１，図１２は、本発明の第３実施形態を示している。この第３実施形態は、第２実施形態と同様に１つのコネクションＩＤを設定するための通信設定情報は、一方の通信ユニットに設定する。ただし、通信設定情報を設定する通信ユニットは、データを受信する側のみとする。これにより、第２実施形態のように、１つの通信ユニットに送信するデータと受信するデータが存在する場合、各通信ユニットが、それぞれ受信データに基づく通信設定情報を持つことになる。例えば、図１１に示すように、第１通信ユニット１２ａは、自局変数名が「Ｍ＿ＳＴ」についての通信設定情報を備える。また、図１２に示すように、第２通信ユニット１２ｂは、自局変数名が「ＲＥＡＤＹ」，「ＳＴＯＰ」についての通信設定情報を備える。

（０）第１ＣＰＵユニット１１ａの変数テーブル、第２ＣＰＵユニット１１ｂの変数テーブル、第１通信ユニット１２ａの通信バッファテーブル、および、第２通信ユニット１２ｂの通信バッファテーブルのそれぞれの準備処理機能は、第２実施形態と同様である。

さらに、ユーザは、通信設定ツール３０を操作し、受信側の通信ユニットに格納する通信設定情報を作成し、該当する通信ユニットへ格納する。つまり、第１通信ユニット１１ａの通信設定情報は、自局変数名が「Ｍ＿ＳＴ」について作成し、第２通信ユニット１２ａの通信設定情報は、自局変数名が「ＲＥＡＤＹ」，「ＳＴＯＰ」の２つについて作成する。ここで作成する通信設定情報は、自局で使用される変数名と、相手局で使用される変数名と、通信相手のノードアドレスと、通信の向き（ＩＮ）と、データを送受信する際の周期と、データサイズと、を関連づけたテーブルとなる。本実施形態では、通信設定情報は、受信側に設定されるため、通信の向きは必ずＩＮとなるので、省略するようにしても良い。

また、通信設定情報が設定された通信ユニットがオリジネータとなり、設定されない通信ユニットがターゲットとなるのも第２実施形態と同様である。従って、本実施形態では、「Ｍ＿ＳＴ」の通信設定情報については、第１通信ユニット１２ａがオリジネータとなり、第２通信ユニット１２ｂがターゲットとなる。「ＲＥＡＤＹ」，「ＳＴＯＰ」の通信設定情報については、第２通信ユニット１２ｂがオリジネータとなり、第１通信ユニット１２ａがターゲットとなる。このように、通信設定情報ごとにオリジネータとターゲットが決まる。

（１）変数テーブルと、通信バッファテーブルを各ユニットにダウンロードすると、各通信ユニット１２ａ，１２ｂは、名前解決処理を実行可能となる。例えば、通信ユニットは、リセットされることを契機として名前解決を行なう。第２実施形態と同様な処理であるが、具体的に説明する。各通信ユニット１２ａ，１２ｂは、例えばリセットのタイミング（電源リセットや動作リセットなど）で、オリジネータ／ターゲットを問わず通信バッファテーブルに格納された変数名に基づいて、その変数名に対応するデータがＣＰＵユニットのメモリのどのアドレス（実アドレス）に格納されるかについて、ＣＰＵユニットへ問合せをする。すなわち、第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａに対し、例えば変数名「Ｓｗｉｔｃｈ１」の名前解決処理を行うべく、実アドレスの問い合わせをする。同様に、第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ａに対し、変数名「ＲＥＡＤＹ」の名前解決処理を行うべく、格納先となるメモリの実アドレスの問い合わせをする。

（２）第１ＣＰＵユニット１１ａは、問い合わせを受けた変数名をキーにして変数テーブルをアクセスし、該当する実アドレス（ＤＭ１００）を取得すると共に、問い合わせに対するレスポンスとして、取得した実アドレスを第１通信ユニット１２ａに返信する。第１通信ユニット１２ａは、同様に「Ｓｗｉｔｃｈ２」，「Ｍ＿ＳＴ」に対応する実アドレスについても問い合わせを行ない、第１ＣＰＵユニット１１ａからレスポンスとして対応する実アドレスを取得する。なお、図示の例では、１つずつ問い合わせをしているが、一括して問い合わせをしても良い。図示省略するが、この実アドレスの返信の際に、データサイズ（型）も返信する。

同様に、第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂに対し、変数名が「ＲＥＡＤＹ」，「ＳＴＯＰ」，「ＳＴＡＴＵＳ」に対応するデータが格納されているメモリの実アドレスの問い合わせをする。そして、第２ＣＰＵユニット１１ｂは、問い合わせを受けた変数名をキーにして変数テーブルをアクセスし、該当する実アドレス，型を取得すると共に、問い合わせに対するレスポンスとして、取得した実アドレス，型を第２通信ユニット１２ｂに返信する。図では、「ＲＥＡＤＹ」の問い合わせに対し、第２ＣＰＵユニット１１ｂは、「ＤＭ２００／１Ｗ」を返信する。

なお、オリジネータ側は通信設定情報を持っているため、特にＣＰＵユニットからのレスポンスとしてデータサイズは不要である。そこで、名前解決の問い合わせの際に通信設定情報を持ったオリジネータ側であるか否かを確認し、オリジネータ側でない場合にのみデータサイズも要求するようにしても良いが、処理が煩雑となるので、オリジネータ側か否かを問わず名前解決の問い合わせに対するレスポンスは、実アドレスと型（サイズ）にしている。

なお、この名前解決処理を実行するタイミングは、上述したリセットに基づくものに限定されず、自由に設定することができ、少なくとも通信バッファテーブルと変数テーブルが格納されたならば、作成することができる。

（３）各通信ユニット１２ａ，１２ｂは、名前解決した情報を記憶しておく。記憶エリアをテンポラリ内部テーブルとした場合は、図１１，図１２に示すようなテンポラリ内部テーブルが完成する。テンポラリ内部テーブルの完成により名前解決処理は終了する。なお、本実施形態では、受信側をオリジネータ側としたため、通信設定情報が設定されたデータの向きは必ず「ＩＮ」となる。

また、ターゲット側の通信ユニットは、通信設定情報を持っていないため、直接的にはデータ送信の向き（送信：ＯＵＴ，受信：ＩＮ）の区別等は不明である。しかし、第２通信ユニット１２ｂは、通信バッファテーブルに格納された情報から第１の通信ユニット１２ａと通信するデータの自局の変数名はわかっているため、変数名の実アドレスを第２ＣＰＵユニット１１ｂに問い合わせることにより、その変数名と実アドレスの対応付けを認識できる。従って、第２通信ユニット１２ｂは、通信バッファテーブルに格納された全ての変数名について、処理（１），（２）を実行することにより、通信バッファテーブルと、変数名と、実アドレスと、サイズ（型に基づき設定）の欄にデータとを関連づけることができ、その関連づけたデータをテンポラリ内部テーブルに格納する。さらに、通信バッファテーブルに存在した変数名について、通信設定情報が設定されていない場合、その変数名は、送信側のデータであると推定できるので、「向き」はＯＵＴとみなせる。これにより、全てのデータが関連づけられたテンポラリ内部テーブルが作成される。なお、第２実施形態と同様に、通信設定情報を有していないターゲット側の通信ユニットは、通信の向きが空欄のテンポラリ内部テーブルが作成されるようにしてもよい。

（４）次に、コネクションＩＤの設定処理手順について説明する。この手順は基本的には第２実施形態と同様である。図１１，図１２に示す第３実施形態では、最初にノードアドレスが＃１と小さい第１通信ユニット１２ａが実行する。すなわち、図１１に示すように、第１通信ユニット１２ａは、第２通信ユニット１２ｂに対し「ＳＴＡＴＵＳ／１Ｗ／ＩＮ／５ｍｓ」を内容とする通信確立要求を発行する。この通信確立要求に自己局の変数名を含めても良い。また、通信確立要求のフレームのヘッダには、自己のノードアドレスと相手のノードアドレスが格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。

（５）この通信確立要求を受信したターゲット（第２通信ユニット１２ｂ）は、要求内容をチェックする。すなわち、テンポラリ内部テーブルをアクセスし、通信確立要求された変数名の有無をチェックする。そして、変数名が存在している場合には、ターゲットは、サイズが一致するか否かをチェックする。さらに、一致する場合には、名前解決の際に行なった処理（３）で、テンポラリ内部テーブルの「向き」の欄に仮登録した場合には、格納されている「向き」が通信確立要求と共に送られてきた「向き情報」（ＩＮ）と反対のＯＵＴであることを確認し、テンポラリ内部テーブルの内容を確定する。また、処理（３）で作成したテンポラリ内部テーブルの「向き」の欄が空欄の場合、第２通信ユニット１２ｂは、空欄となっていたテンポラリ内部テーブルのＳＴＡＴＵＳに対応する「向き」の欄に、受信した向きと逆の「ＯＵＴ」を入力する。

（６）さらに、ターゲットは、実周期と要求周期とを比較し、対応可能か否かをチェックする。対応可能な場合には、ターゲットは、コネクションＩＤを特定し、通信設定ツール３０の表示装置に「要求条件ＯＫ」の旨と「通信確立内容」とをモニタ表示させる。そして、ターゲットは、通信確立要求の発行元であるオリジネータに対して「要求条件ＯＫ」の旨と、コネクションＩＤを通知する。このとき、実周期を同時に送るようにしても良い。ターゲット側の実周期は、ターゲットのシステムメモリに格納されているため、ターゲットは、それを読み出してコネクションＩＤ等と一緒に通知する。なお、ターゲットが、要求された周期では対応できない場合には、第２実施形態と同様の手順で対応する。

コネクションＩＤは、オリジネータのノードアドレス−ターゲットのアドレスーシリアル番号から構成される。シリアル番号は、処理した順に付与する。従って、例えば上述した「ＳＴＡＴＵＳ」についての通信確立要求が最初に発行されてきた場合、ターゲットである第２通信ユニット１２ｂは、ＳＴＡＴＵＳのデータについて「＃１＃２−００１」というコネクションＩＤを設定する。

また、各通信確立要求を受けたターゲットからコネクションＩＤとともに要求許可通知が発行されると、オリジネータとターゲットでは、図１３に示すデータ構造からなるコネクションテーブルが作成される。このコネクションテーブルは、１つのコネクションＩＤが付与されるごとに、逐次作成され、更新される。

通信確立要求は、コネクションＩＤの単位、つまり、変数名ごとに１つずつ行なわれるが、第１通信ユニット１２ａがオリジネータとなっているデータは、自局変数名が「Ｍ＿ＳＴ」の１つであるため、上述した「ＳＴＡＴＵＳ」についてのコネクションＩＤの設定終わると第１通信ユニット１２ａの通信設定情報にコネクションＩＤの設定処理は完了する。そこで、図１２に示すように、次に小さい番号のノードアドレス＃２の第２通信ユニット１２ｂが、通信確立要求を発行する。

（４）具体的には、まず第２通信ユニット１２ｂは、通信設定情報の先頭に格納された自局変数名「ＲＥＡＤＹ」についての通信要求を発行する。つまり、図１２に示すように、第２通信ユニット１２ｂは、第１通信ユニット１２ａに対し「Ｓｗｉｔｃｈ１／１Ｗ／ＩＮ／５ｍｓ」を内容とする通信確立要求を発行する。この通信確立要求に自己局の変数名を含めても良い。また、通信確立要求のフレームのヘッダには、自己のノードアドレスと相手のノードアドレスが格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。

（５）この通信確立要求を受信したターゲット（第１通信ユニット１２ａ）は、要求内容をチェックする。すなわち、テンポラリ内部テーブルをアクセスし、通信確立要求された変数名の有無をチェックする。そして、変数名が存在している場合には、ターゲットは、サイズが一致するか否かをチェックする。さらに、一致する場合には、名前解決の際に行なった処理（３）で、テンポラリ内部テーブルの「向き」の欄に仮登録した場合には、格納されている「向き」が通信確立要求と共に送られてきた「向き情報」（ＩＮ）と反対のＯＵＴであることを確認し、テンポラリ内部テーブルの内容を確定する。また、処理（３）で作成したテンポラリ内部テーブルの「向き」の欄が空欄の場合、第１通信ユニット１２ａは、空欄となっていたテンポラリ内部テーブルのＳｗｉｔｃｈ１に対応する「向き」の欄に、受信した向きと逆の「ＯＵＴ」を入力する。

コネクションＩＤは、オリジネータのノードアドレス−ターゲットのアドレスーシリアル番号から構成される。シリアル番号は、処理した順に付与する。従って、例えば上述した「Ｓｗｉｔｃｈ１」についての通信確立要求が最初に発行されてきた場合、ターゲットである第１通信ユニット１２ａは、Ｓｗｉｔｃｈ１のデータについて「＃２＃１−００１」というコネクションＩＤを設定する。

第２通信ユニット１２ｂは、次に、自局変数名「ＳＴＯＰ」についてのコネクションＩＤの設定処理を行なうべく、第１通信ユニット１２ａに対し、「Ｓｗｉｔｃｈ２／１Ｗ／ＩＮ／５ｍｓ」を内容とする通信確立要求をする。この通信確立要求に基づき、上述した（５），（６）の処理を実行することにより、第１通信ユニット１２ａは、「Ｓｗｉｔｃｈ２」についてのコネクションＩＤを設定する。

これにより、各通信確立要求を受けたターゲットからコネクションＩＤとともに要求許可通知が発行されると、オリジネータとターゲットでは、最終的に図１４に示すデータ構造からなるコネクションテーブルが作成される。

本実施形態では、受信側がオリジネータとなっているため、通信確立要求をするデータの向きは、「ＩＮ」であるため、実際に送信する内容には「ＩＮ」を省略しても良い。その場合にターゲット側の通信ユニットでは、通信確立要求を受けた場合には、省略された向きは「ＩＮ」であり、ターゲット側での向きは「ＯＵＴ」となることを認識して処理をすることになる。

すべてのオリジネータの通信設定情報について通信確立をした後は、図１４のコネクションテーブルのコネクションＩＤを利用して、オリジネータ側の通信ユニットとターゲット側の通信ユニットとの間で、該当するデータの送受信が行われる。

図１５，図１６は、第３実施形態の変形例を示している。上述した第３実施形態は、各通信ユニットとＣＰＵユニット間における名前解決処理を、コネクションＩＤの設定処理を行なう前に、予め各ユニット間同士で事前に行なうようにした。これに対し、この変形例では、ターゲット側の名前解決は、コネクションＩＤの設定を行なう一連の処理手順の中で行なうようにした。

（０）第１ＣＰＵユニット１１ａの変数テーブル、第２ＣＰＵユニット１１ｂの変数テーブル、第１通信ユニット１２ａの通信バッファテーブル、および、第２通信ユニット１２ｂの通信バッファテーブルのそれぞれの準備処理機能は、上述の第３実施形態と同様である。

次に、名前解決処理とコネクションＩＤの設定処理とを行なうが、これらの処理はノードアドレスの小さい通信ユニットから順に処理を行なう。従って、この実施形態では、第１通信ユニットがオリジネータになっているものについて行なわれる。そこで、係る処理を図１５を用いて説明する。

（１）オリジネータ側の第１通信ユニット１２ａは、通信設定情報に格納された自局変数名（Ｍ＿ＳＴ）について、第１ＣＰＵユニット１１ａへ名前解決要求をする。具体的には、第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａに対し、変数名が「Ｍ＿ＳＴ」のデータが格納されている実アドレスを問い合わせる。なお、オリジネータ側となる通信ユニットにおける名前解決要求の実行は、通信設定情報に格納された変数名に代えて、通信バッファテーブルの中に記憶された変数名に基づいて行うことも可能である。また、名前解決要求する単位は、変数名ごとに１つずつ行なうようにしても良いし、複数の変数名について一括して行なうようにしても良い。

（２）第１ＣＰＵユニット１１ａは、受信した名前解決要求に応じて変数テーブルを参照し、対応する実アドレス（ＤＭ１５０）を返信する。このとき、第１ＣＰＵユニット１１ａは、型（サイズ）も併せて返信してもよい。

（３）オリジネータ側の第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａから返信されてきた情報と、自己が保有する通信設定情報とに基づいてテンポラリ内部テーブルを作成する。つまり、「Ｍ＿ＳＴ」に関するテンポラリ内部テーブルが作成される。また、通信設定情報に通信バッファテーブルのテーブル番号が記述されていない場合には、第１通信ユニット１２ａは、通信バッファテーブルも参照し、テーブル番号を取得することにより、テンポラリ内部テーブルが作成される。作成されるテンポラリ内部テーブルのデータ構造は、第３実施形態と同様である。

（４）通信設定ツール３０からの通信確立命令を受けて、オリジネータ側の第１通信ユニット１２ａ（＃１）は、通信設定情報に格納された変数名について、テンポラリ内部テーブルに基づいて、ターゲット側の第２通信ユニット１２ｂ（＃２）へ通信確立要求をする。通信確立要求とともに送る情報は、相手局変数名／サイズ／向き／周期を含む。この通信確立要求に自己局変数名を含めても良い。また、通信確立要求のフレームのヘッダには、自己のノードアドレスと相手のノードアドレスが格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。この通信確立要求は、一つずつ行なう。図では、テンポラリ内部テーブルに格納された自局変数名「Ｍ＿ＳＴ」に対応し、「ＳＴＡＴＵＳ／１Ｗ／ＩＮ／５ｍｓ」を内容とする通信確立要求をする。もちろん通信の向きである「ＩＮ」は、省略しても良い。

（５）通信確立要求を受信した第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂに対し、受信した変数名についての名前解決要求をする。図示の例では、第２通信ユニット１２ｂは、変数名「ＳＴＡＴＵＳ」についての実アドレスを問い合わせる要求をしている。

（６）第２ＣＰＵユニット１１ｂは、名前解決要求に応じて変数テーブルを参照し、変数名に対応するメモリアドレスと型（サイズ）とを取得し（ＤＭ２５０／１Ｗ）、第２通信ユニット１２ｂへ返信する。

（７）第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂから取得したメモリアドレスと型（サイズ）に基づき、第１通信ユニット１２ａから受信した通信確立要求の内容をチェックする。ここでの処理は、第２の実施形態の変形例と同様である。具体的なチェック項目は、「要求された変数名を持つか？」，「その変数名のデータが通信バッファに設定あるか？」，「サイズが合致しているか？」，「実周期と要求周期とを比較し、対応可能か？」等がある。第２通信ユニット１２ｂは、全ての条件を具備した場合、通信確立要求を許可する決定をし、要求周期以外の条件が1つでも合致しない場合には、通信確立要求を許可しない決定をする。また、要求周期が対応不可の場合には、ツールで「要求周期では対応不可。実周期＊＊ｓｅｃでよいか？」等のメッセージを表示し、ユーザへ確認を促す。ユーザ入力が「よい」を受け付けた場合には、提示した実周期で通信することを条件に通信確立要求を許可する決定をする。

そして、要求内容が正しく、通信確立要求を許可する場合には、第２通信ユニット１２ｂは、その変数名（ＳＴＡＴＵＳ）についてのテンポラリ内部テーブルを作成する。このテンポラリ内部テーブルのデータ構造は、第３実施形態と同様である。ここでは、受信した通信確立要求の内容と、名前解決処理で取得した変数名と実アドレスの対応関係から、現在処理対象となっている変数名について一度に作成する。つまり、「ＳＴＡＴＵＳ」について関連する全ての情報が格納されたテンポラリ内部テーブルを作成する。あわせて、第２通信ユニット１２ｂは、通信設定ツール３０に、「要求条件ＯＫ」の旨と「通信確立内容」とをモニタ表示する。

通信確立要求は、コネクションＩＤの単位である変数名ごとに１つずつ行なわれる。そして、第１通信ユニット１２ａがオリジネータとなっているデータは、自局変数名がＭ＿ＳＴの１つであるため、上述した「ＳＴＡＴＵＳ」についてのコネクションＩＤの設定終わると第１通信ユニット１２ａの通信設定情報にコネクションＩＤの設定処理は完了する。そこで、図１６に示すように、次に小さい番号のノードアドレス＃２の第２通信ユニット１２ｂが、通信確立要求を発行する。

（１）まず、第２通信ユニット１２ｂが通信設定情報の変数名について、第２ＣＰＵユニット１１ｂへ名前解決要求をする。つまり、まず変数名が「ＲＥＡＤＹ」について問い合わせをする。もちろん第２通信ユニット１２ｂは、「ＲＥＡＤＹ」に加え「ＳＴＯＰ」に対する名前解決要求を一括して要求してもよい。

（２）第２ＣＰＵユニット１１ｂは、受信した名前解決要求に応じて変数テーブルを参照し、対応する実アドレス（ＲＥＡＤＹについては、ＤＭ２００）を返信する。このとき、第２ＣＰＵユニット１１ｂは、型（サイズ）も併せて返信してもよい。

（３）オリジネータ側の第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂから返信されてきた情報と、自己が保有する通信設定情報とに基づいて「ＲＥＡＤＹ」と「ＳＴＯＰ」についてのテンポラリ内部テーブルを作成する。

（４）通信設定ツール３０からの通信確立命令を受けて、オリジネータ側の第２通信ユニット１２ｂ（＃２）は、通信設定情報に格納された変数名について、テンポラリ内部テーブルに基づいて、ターゲット側の第１通信ユニット１２ａ（＃１）へ通信確立要求をする。通信確立要求とともに送る情報は、相手局変数名／サイズ／向き／周期を含む。この通信確立要求は、一つずつ行なう。図では、テンポラリ内部テーブルに格納された自局変数名「ＲＥＡＤＹ」に対応する「Ｓｗｉｔｃｈ１／１Ｗ／ＩＮ／５ｍｓ」を内容とする通信確立要求をする。ここで「ＩＮ」を省略しても良い。この通信確立要求に自己局の変数名を含めても良い。また、通信確立要求のフレームのヘッダには、自己のノードアドレスと相手のノードアドレスが格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。

（５）通信確立要求を受信した第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａに対し、受信した変数名についての名前解決要求をする。図示の例では、第１通信ユニット１２ａは、変数名「Ｓｗｉｔｃｈ１」についての実アドレスを問い合わせる要求をしている。

（６）第１ＣＰＵユニット１１ａは、名前解決要求に応じて変数テーブルを参照し、変数名に対応するメモリアドレスと型（サイズ）とを取得し（ＤＭ１００／１Ｗ）、第１通信ユニット１２ａへ返信する。

（７）第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａから取得したメモリアドレスと型（サイズ）に基づき、第２通信ユニット１２ｂから受信した通信確立要求の内容をチェックする。このチェック処理の具体的な内容は、上述した第２通信ユニット１２ｂで行なったものと同様であるため、ここではその説明を省略する。

そして、要求内容が正しく、通信確立要求を許可する場合には、テンポラリ内部テーブルを作成する。このテンポラリ内部テーブルのデータ構造は、第３実施形態と同様である。ここでは、受信した通信確立要求の内容と、名前解決処理で取得した変数名と実アドレスの対応関係と、通信バッファテーブルのテーブル番号から、現在コネクションＩＤの設定の処理対象となっている変数名について一度に作成する。つまり、まず、「Ｓｗｉｔｃｈ１」について関連する全ての情報が格納されたテンポラリ内部テーブルを作成する。あわせて、第２通信ユニット１２ｂは、通信設定ツール３０に、「要求条件ＯＫ」の旨と「通信確立内容」とをモニタ表示する。

（８）通信確立要求を許可する場合、第２通信ユニット１２ｂは、コネクションＩＤを特定し、特定したコネクションＩＤと、「確立要求許可通知」とを第１通信ユニット１２ａに返信する。このとき、第２通信ユニット１１ｂは、実周期を合わせて送信しても良い。

また、コネクションＩＤの設定処理は、１つのデータごとに行なわれるため、Ｓｗｉｔｃｈ１についてのコネクションＩＤの設定処理が完了したならば、次は「Ｓｗｉｔｃｈ２」についてコネクションＩＤの設定処理を行なう。つまり、上述した（４）から（８）までの処理を繰り返し実行する。これにより、「Ｓｗｉｔｃｈ２」についてのテンポラリ内部テーブルも作成される。

そして、第３実施形態と同様に、第１通信ユニット１２ａと第２通信ユニット１２ｂは、ともにコネクションテーブルを作成する。ここで作成される最終的なコネクションテーブルは、図１４と同じになる。そして、全ての変数について通信確立した後は、コネクションＩＤを利用して通信ユニット間で通信する。

図１７，図１８は、本発明の第４実施形態を示している。この第４実施形態では、第３実施形態とは逆に、送信側をオリジネータ側に設定している。従って、図１７に示すように、第１通信ユニット１２ａは、自局変数名が「Ｓｗｉｔｃｈ１」，「Ｓｗｉｔｃｈ２」についての通信設定情報を備える。また、図１８に示すように、第２通信ユニット１２ｂは、自局変数名が「ＳＴＡＴＵＳ」についての通信設定情報を備える。

（０）第１ＣＰＵユニット１１ａの変数テーブル、第２ＣＰＵユニット１１ｂの変数テーブル、第１通信ユニット１２ａの通信バッファテーブル、および、第２通信ユニット１２ｂの通信バッファテーブルのそれぞれの準備処理機能は、上述の第２，第３実施形態と同様である。

さらに、ユーザは、通信設定ツール３０を操作し、送信側の通信ユニットに格納する通信設定情報を作成し、該当する通信ユニットへ格納する。つまり、第１通信ユニット１１ａの通信設定情報は、自局変数名が「Ｓｗｉｔｃｈ１」，「Ｓｗｉｔｃｈ２」の２つについて作成し、第２通信ユニット１２ａの通信設定情報は、自局変数名が「ＳＴＡＴＵＳ」について作成する。ここで作成する通信設定情報は、自局で使用される変数名と、相手局で使用される変数名と、通信相手のノードアドレスと、通信の向き（ＯＵＴ）と、データを送受信する際の周期と、データサイズと、を関連づけたテーブルとなる。本実施形態では、通信設定情報は、受信側に設定されるため、通信の向きは必ずＯＵＴとなるので、省略するようにしても良い。

本実施形態では、「Ｓｗｉｔｃｈ１」，「Ｓｗｉｔｃｈ２」の通信設定情報については、第１通信ユニット１２ａがオリジネータとなり、第２通信ユニット１２ｂがターゲットとなる。「ＳＴＡＴＵＳ」の通信設定情報については、第２通信ユニット１２ｂがオリジネータとなり、第１通信ユニット１２ａがターゲットとなる。このように、通信設定情報ごとにオリジネータとターゲットが決まる。

（１）および（２）変数テーブルと通信バッファテーブルとを各ユニットにダウンロードした後、各通信ユニット１２ａ，１２ｂにおける名前解決処理は、第２、第３の実施形態と同様である。つまり、オリジネータ側の通信ユニット１２ａ、ターゲット側の通信ユニット１２ｂともに、それぞれ保有する通信バッファテーブルの変数名に基づいて、同一のプログラマブルコントローラ内のＣＰＵニットに対して名前解決の要求を出し、対応する実アドレスとサイズとを取得する。

（３）の処理も第２、第３の実施形態とほぼ同じ処理となる。ただし、本実施形態では、受信側をオリジネータ側としたため、通信設定情報が設定されたデータの向きは必ず「ＯＵＴ」となる。また、通信バッファテーブルに存在した変数名について、通信設定情報が設定されていない場合、その変数名は、送信側のデータであると推定できるので、「向き」はＩＮとみなせる。この（３）の処理により、全てのデータが関連づけられたテンポラリ内部テーブルが作成される。なお、第２実施形態と同様に、通信設定情報を有していないターゲット側の通信ユニットは、通信の向きが空欄のテンポラリ内部テーブルが作成されるようにしてもよい。

（４）の処理も第２、第３の実施形態とほぼ同じ処理となる。この第４実施形態では、最初にノードアドレスが＃１と小さい第１通信ユニット１２ａが実行する。すなわち、図１７に示すように、第１通信ユニット１２ａは、第２通信ユニット１２ｂに対し「ＲＥＡＤＹ／１Ｗ／ＯＵＴ／５ｍｓ」を内容とする通信確立要求を発行する。この通信確立要求に自己局の変数名を含めても良い。また、通信確立要求のフレームのヘッダには、自己のノードアドレスと相手のノードアドレスが格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。

（５）の処理も第２、第３の実施形態とほぼ同じ処理となる。つまり、この通信確立要求を受信したターゲット（第２通信ユニット１２ｂ）は、要求内容をチェックする。すなわち、テンポラリ内部テーブルをアクセスし、通信確立要求された変数名の有無をチェックする。そして、変数名が存在している場合には、ターゲットは、サイズが一致するか否かをチェックする。さらに、一致する場合には、名前解決の際に行なった処理（３）で、テンポラリ内部テーブルの「向き」の欄に仮登録した場合には、格納されている「向き」が通信確立要求と共に送られてきた「向き情報」（ＯＵＴ）と反対のＩＮであることを確認し、テンポラリ内部テーブルの内容を確定する。また、処理（３）で作成したテンポラリ内部テーブルの「向き」の欄が空欄の場合、第２通信ユニット１２ｂは、空欄となっていたテンポラリ内部テーブルの「ＲＥＡＤＹ」，「ＳＴＯＰ」に対応する「向き」の欄に、受信した向きと逆の「ＩＮ」を入力する。

なお、第２、第３の実施形態と同様に、変数名の有無のチェックは、上記のようにテンポラリ内部テーブルに基づいて行なっても良いが、本発明はこれに限るものではなく、通信バッファテーブルに基づいて行なっても良い。さらに、テンポラリ内部テーブルと通信バッファテーブルの両方に基づいて変数名の有無をダブルチェックするようにしてもよい。

（６）さらに、ターゲットは、実周期と要求周期とを比較し、対応可能か否かをチェックする。この処理についても第２、第３の実施形態とほぼ同じ処理となる。ただし、例えば上述した「ＲＥＡＤＹ」についての通信確立要求が最初に発行されてきた場合、ターゲットである第２通信ユニット１２ｂは、ＲＡＤＹのデータについて「＃１＃２−００１」というコネクションＩＤを設定する。

第１通信ユニット１２ｂは、次に、自局変数名「Ｓｗｉｔｃｈ２」についてのコネクションＩＤの設定処理を行なうべく、第２通信ユニット１２ａに対し、「ＳＴＯＰ／１Ｗ／ＯＵＴ／５ｍｓ」を内容とする通信確立要求をする。この通信確立要求に基づき、上述した（５），（６）の処理を実行することにより、第２通信ユニット１２ｂは、「ＳＴＯＰ」についてのコネクションＩＤ（＃１＃２−００２）を設定する。

また、各通信確立要求を受けたターゲットからコネクションＩＤとともに要求許可通知が発行されると、オリジネータとターゲットでは、図１９に示すデータ構造からなるコネクションテーブルが作成される。このコネクションテーブルは、１つのコネクションＩＤが付与されるごとに、逐次作成され、更新される。図１９は、完成された状態を示しており、第１通信ユニット１２ａに基づくコネクションＩＤの設定処理では、コネクションテーブルの２番目までが作成される。

第１通信ユニット１２ａの通信設定情報に格納された全ての変数名についてコネクションＩＤの設定処理を完了すると、図１８に示すように、次に小さい番号のノードアドレス＃２の第２通信ユニット１２ｂが、通信確立要求を発行する。

（４）具体的には、まず第２通信ユニット１２ｂは、通信設定情報に格納された自局変数名「ＳＴＡＴＵＳ」についての通信要求を発行する。つまり、図１８に示すように、第２通信ユニット１２ｂは、第１通信ユニット１２ａに対し「Ｍ＿ＳＴ／１Ｗ／ＯＵＴ／５ｍｓ」を内容とする通信確立要求を発行する。ここでもＯＵＴの記述は省略しても良い。

（５）この通信確立要求を受信したターゲット（第１通信ユニット１２ａ）は、要求内容をチェックする。すなわち、テンポラリ内部テーブルをアクセスし、通信確立要求された変数名の有無をチェックする。そして、変数名が存在している場合には、ターゲットは、サイズが一致するか否かをチェックする。さらに、一致する場合には、名前解決の際に行なった処理（３）で、テンポラリ内部テーブルの「向き」の欄に仮登録した場合には、格納されている「向き」が通信確立要求と共に送られてきた「向き情報」（ＯＵＴ）と反対のＩＮであることを確認し、テンポラリ内部テーブルの内容を確定する。また、処理（３）で作成したテンポラリ内部テーブルの「向き」の欄が空欄の場合、第１通信ユニット１２ａは、空欄となっていたテンポラリ内部テーブルの「Ｍ＿ＳＴ」に対応する「向き」の欄に、受信した向きと逆の「ＩＮ」を入力する。

（６）さらに、ターゲットは、実周期と要求周期とを比較し、対応可能か否かをチェックする。この処理についても第２、第３の実施形態と同様の手順で対応する。この実施形態では、例えば上述した「Ｍ＿ＳＴ」についての通信確立要求が最初に発行されてきた場合、ターゲットである第１通信ユニット１２ａは、Ｍ＿ＳＴのデータについて「＃２＃１−００１」というコネクションＩＤを設定する。

これにより、各通信確立要求を受けたターゲットからコネクションＩＤとともに要求許可通知が発行されると、オリジネータとターゲットでは、最終的に図１９に示すデータ構造からなるコネクションテーブルが作成される。そして、全ての変数について通信確立した後は、コネクションＩＤを利用して通信ユニット間で通信する。

本実施形態では、送信側がオリジネータとなっているため、通信確立要求をするデータの向きは、「ＯＵＴ」であるため、実際に送信する内容には「ＯＵＴ」を省略しても良い。その場合にターゲット側の通信ユニットでは、通信確立要求を受けた場合には、省略された向きは「ＩＮ」であり、ターゲット側での向きは「ＩＮ」となることを認識して処理をすることになる。

図２０，図２１は、第４実施形態の変形例を示している。上述した第４実施形態は、各通信ユニットとＣＰＵユニット間における名前解決処理を、コネクションＩＤの設定処理を行なう前に、予め各ユニット間同士で事前に行なうようにした。これに対し、この変形例では、ターゲット側の名前解決は、コネクションＩＤの設定を行なう一連の処理手順の中で行なうようにした。

（０）第１ＣＰＵユニット１１ａの変数テーブル、第２ＣＰＵユニット１１ｂの変数テーブル、第１通信ユニット１２ａの通信バッファテーブル、および、第２通信ユニット１２ｂの通信バッファテーブルのそれぞれの準備処理機能は、上述の第３、第４実施形態と同様である。

次に、名前解決処理とコネクションＩＤの設定処理とを行なう。これらの処理はノードアドレスの小さい通信ユニットから順に処理を行なう。従って、上記の各処理は、第１通信ユニットがオリジネータになっているものについて行なわれる。そこで、係る処理を図２０を用いて説明する。

（１）第１通信ユニット１２ａが通信設定情報の変数名について、第１ＣＰＵユニット１１ａへ名前解決要求をする。つまり、まず変数名が「Ｓｗｉｔｃｈ１」について問い合わせをする。なお、オリジネータ側となる通信ユニットにおける名前解決要求の実行は、このように通信設定情報の中に格納された変数名に基づいておこなうことに代えて、通信バッファテーブルに記憶された変数名に基づいて行うことも可能である。オリジネータ側の通信ユニットにおける名前解決要求する単位は、変数名ごとに１つずつ行なうようにしても良いし、複数の変数名「Ｓｗｉｔｃｈ１」「Ｓｗｉｔｃｈ２」に対する名前解決要求を一括して要求してもよい。

（２）第１ＣＰＵユニット１１ａは、受信した名前解決要求に応じて変数テーブルを参照し、対応する実アドレス（ＤＭ１００）と型（サイズ）を返信する。第１ＣＰＵユニット１１ａは、型（サイズ）については返信しなくてもよい。

（３）オリジネータ側の第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａから返信されてきた情報と、自己が保有する通信設定情報とに基づいてテンポラリ内部テーブルを作成する。つまり、「Ｓｗｉｔｃｈ１」，「Ｓｗｉｔｃｈ１」に関するテンポラリ内部テーブルが作成される。また、通信設定情報に通信バッファテーブルのテーブル番号が記述されていない場合には、第１通信ユニット１２ａは、通信バッファテーブルも参照し、テーブル番号を取得することにより、テンポラリ内部テーブルが作成される。作成されるテンポラリ内部テーブルのデータ構造は、第４実施形態と同様である。

（４）通信設定ツール３０からの通信確立命令を受けて、オリジネータ側の第１通信ユニット１２ａ（＃１）は、通信設定情報に格納された変数名について、テンポラリ内部テーブルに基づいて、ターゲット側の第２通信ユニット１２ｂ（＃２）へ通信確立要求をする。通信確立要求とともに送る情報は、相手局変数名／サイズ／向き／周期を含む。この通信確立要求は、一つずつ行なう。図では、テンポラリ内部テーブルに格納された自局変数名「Ｓｗｉｔｃｈ１」に対応し、「ＲＥＡＤＹ／１Ｗ／ＯＵＴ／５ｍｓ」を内容とする通信確立要求をする。もちろん通信の向きである「ＯＵＴ」は、省略しても良い。なお、この通信確立要求に自己局の変数名を含めても良い。また、通信確立要求のフレームのヘッダには、自己のノードアドレスと相手のノードアドレスが格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。

（５）通信確立要求を受信した第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂに対し、受信した変数名についての名前解決要求をする。図示の例では、第２通信ユニット１２ｂは、変数名「ＲＥＡＤＹ」についての実アドレスを問い合わせる要求をしている。

（６）第２ＣＰＵユニット１１ｂは、名前解決要求に応じて変数テーブルを参照し、変数名に対応するメモリアドレスと型（サイズ）とを取得し（ＤＭ２００／１Ｗ）、第２通信ユニット１２ｂへ返信する。

（７）第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂから取得したメモリアドレスと型（サイズ）に基づき、第１通信ユニット１２ａから受信した通信確立要求の内容をチェックする。ここでの処理は第２の実施形態の変形例、第３の実施形態の変形例と同様であるので、説明を省略する。そして、要求内容が正しく、通信確立要求を許可する場合には、第２通信ユニット１２ｂは、その変数名（ＲＥＡＤＹ）についてのテンポラリ内部テーブルを作成する。このテンポラリ内部テーブルのデータ構造は、第４実施形態と同様である。ここでは、受信した通信確立要求の内容と、名前解決処理で取得した変数名と実アドレスの対応関係から、現在処理対象となっている変数名について一度に作成する。つまり、「ＲＥＡＤＹ」について関連する全ての情報が格納されたテンポラリ内部テーブルを作成する。あわせて、第２通信ユニット１２ｂは、通信設定ツール３０に、「要求条件ＯＫ」の旨と「通信確立内容」とをモニタ表示する。

通信確立要求は、コネクションＩＤの単位である変数名ごとに１つずつ行なわれる。そこで、「ＲＥＡＤＹ」についてのコネクションＩＤの設定処理が完了したならば、次は「ＳＴＯＰ」についてのコネクションＩＤの設定処理を行なう。つまり、上述した（４）から（８）までの処理を繰り返し実行する。これにより、「ＳＴＯＰ」についてのテンポラリ内部テーブルも作成され、コネクションＩＤも設定される。これに伴い、コネクションテーブルも作成される。

第１通信ユニット１２ａがオリジネータとなっているデータは、自局変数名がＳｗｉｔｃｈ１とＳｗｉｔｃｈ２の２つであるため、上述した２つの変数名についてのコネクションＩＤの設定終わると第１通信ユニット１２ａの通信設定情報にコネクションＩＤの設定処理は完了する。そこで、図２１に示すように、次に小さい番号のノードアドレス＃２の第２通信ユニット１２ｂが、通信確立要求を発行する。

（１）第２通信ユニット１２ｂが通信設定情報の変数名について、第２ＣＰＵユニット１１ｂへ名前解決要求をする。つまり、変数名が「ＳＴＡＴＵＳ」について問い合わせをする。

（２）第２ＣＰＵユニット１１ｂは、受信した名前解決要求に応じて変数テーブルを参照し、対応する実アドレス（ＤＭ２５０）を返信する。このとき、第２ＣＰＵユニット１１ｂは、型（サイズ）も併せて返信してもよい。

（３）オリジネータ側の第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂから返信されてきた情報と、自己が保有する通信設定情報とに基づいて「ＳＴＡＴＵＳ」についてテンポラリ内部テーブルを追加作成する。「ＲＥＡＤＹ」と「ＳＴＯＰ」についてのテンポラリ内部テーブルは、図２０を用いて説明した第１通信ユニットからの通信確立要求に基づく処理を実行中にすでに作成される。これにより、第２通信ユニット１２ｂが扱う全ての変数について、テンポラリ内部テーブルが作成される。

（４）通信設定ツール３０からの通信確立命令を受けて、オリジネータ側の第２通信ユニット１２ｂ（＃２）は、通信設定情報に格納された変数名について、テンポラリ内部テーブルに基づいて、ターゲット側の第１通信ユニット１２ａ（＃１）へ通信確立要求をする。通信確立要求とともに送る情報は、相手局変数名／サイズ／向き／周期を含む。この通信確立要求は、一つずつ行なう。図では、テンポラリ内部テーブルに格納された自局変数名「ＳＴＡＴＵＳ」に対応する「Ｍ＿ＳＴ／１Ｗ／ＯＵＴ／５ｍｓ」を内容とする通信確立要求をする。ここで「ＯＵＴ」を省略しても良い。この通信確立要求に自己局の変数名を含めても良い。また、通信確立要求のフレームのヘッダには、自己のノードアドレスと相手のノードアドレスが格納されている。

（５）通信確立要求を受信した第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａに対し、受信した変数名についての名前解決要求をする。図示の例では、第１通信ユニット１２ａは、変数名「Ｍ＿ＳＴ」の実アドレスを問い合わせる要求をしている。

（６）第１ＣＰＵユニット１１ａは、名前解決要求に応じて変数テーブルを参照し、変数名に対応するメモリアドレスと型（サイズ）とを取得し（ＤＭ１５０／１Ｗ）、第１通信ユニット１２ａへ返信する。

そして、要求内容が正しく、通信確立要求を許可する場合には、テンポラリ内部テーブルを作成する。このテンポラリ内部テーブルのデータ構造は、第４実施形態と同様である。ここでは、受信した通信確立要求の内容と、名前解決処理で取得した変数名と実アドレスの対応関係と、通信バッファテーブルのテーブル番号から、現在コネクションＩＤの設定の処理対象となっている変数名について一度に作成する。つまり、まず、「Ｍ＿ＳＴ」について関連する全ての情報が格納されたテンポラリ内部テーブルを作成する。あわせて、第１通信ユニット１２ａは、通信設定ツール３０に、「要求条件ＯＫ」の旨と「通信確立内容」とをモニタ表示する。

（８）通信確立要求を許可する場合、第１通信ユニット１２ａは、コネクションＩＤを特定し、特定したコネクションＩＤと、「確立要求許可通知」とを第２通信ユニット１２ｂに返信する。このとき、第１通信ユニット１１ａは、実周期を合わせて送信しても良い。

そして、第４実施形態と同様に、第１通信ユニット１２ａと第２通信ユニット１２ｂは、ともにコネクションテーブルを作成する。ここで作成される最終的なコネクションテーブルは、図１９と同じになる。そして、全ての変数について通信確立した後は、コネクションＩＤを利用して通信ユニット間で通信する。

以上、第２〜第４の実施形態でも第２〜第４の実施形態の変形例を説明したが、いずれの実施形態においても次のようにするのが好ましい。

まず、オリジネータが発行する通信要求に、自己局ノードアドレス（オリジネータ側ノードアドレス）、自己局の変数名（オリジネータ側の変数名）、相手局ノードアドレス（ターゲット側ノードアドレス）、相手局変数名（ターゲット側の変数名），データサイズ（通信対象データのサイズ），向き（送信なのか受信なのか）並びに周期を含めるようにする。

いっぽう、ターゲットがオリジネータに対して送る要求許可通知に、許可通知（ＯＫ／ＮＧ）、コネクションＩＤ、自己局ノードアドレス（ターゲット側ノードアドレス）、相手局ノードアドレス（オリジネータ側ノードアドレス）、周期に加え、自己局の変数名（ターゲット側の変数名）、相手局変数名（ターゲット側の変数名），データサイズ（通信対象データのサイズ）、向き（送信なのか受信なのか）を含めるようにする。このうち自己局の変数名（ターゲット側の変数名）と相手局変数名（ターゲット側の変数名）とについては、もともとオリジネータがふたつの関係付けを記憶しているので、どちらかを省略してもよい。また、データサイズ（通信対象データのサイズ）もオリジネータが記憶している情報なので省略してもよい。

そして、オリジネータがターゲットから通信許可を受取れば、通信設定情報のなかの周期を通信許可された周期に上書きして記憶する。こうすることで、ユーザはオリジネータの通信設定情報を確認することで、オリジネータとして関わる通信内容を把握することができる。ここでの通信設定情報にかかるすべての情報をテーブルとして持つようにしてもよい。

また、ターゲットが、オリジネータからの通信要求、ターゲットでの通信確立処理を通じて取得した情報をひとまとめに記憶するのが好ましい。例えば、新たに通信設定情報を記憶できる記憶領域を用意し、そこにコネクションＩＤ、自己局ノードアドレス（ターゲット側ノードアドレス）、自己局の変数名（ターゲット側の変数名）、相手局ノードアドレス（オリジネータ側ノードアドレス）、相手局変数名（オリジネータ側の変数名）、データサイズ（通信対象データのサイズ）、向き（送信なのか受信なのか）、並びに周期（通信許可した周期）の情報を含む情報を別途記憶しておくとよい。こうすると、ユーザはターゲットとして関わる通信設定内容をその記憶情報を確認することで、変数名に基づいて通信内容を知ることができる。

なお、第3、第４の実施形態およびその変化例のように、1つの通信ユニットがオリジネータの立場とターゲットの立場の両方をとることがある。この場合であっても、ひとつの通信ユニットがオリジネータとして通信確立後の通信設定情報と、ターゲットとしての通信確立後の通信設定情報を併せ持つので、ユーザはそれらの記憶することで、変数名に基づいて通信内容を知ることができる。

図２２は、本発明の第５実施形態を示している。上記した各実施の形態は、コネクションＩＤは、１つの変数名に対して１つ設定した。本実施の形態ではそれと相違し、複数の変数名をグループ化し、複数のデータを同時に送受信できるようにした。グループ化するデータは、通信相手が共通で、周期が同じで、通信の向きが同じものである。通信確立要求は、オリジネータ側から行なうため、上記のグループ化の条件に従い、ターゲットが共通で、周期が同じ「ＯＵＴデータ」同士は、グループ化することができる。また、ターゲットが共通で、周期が同じで「ＩＮデータ」同士は、グループ化することができる。

例えば、第２実施形態の場合、「Ｓｗｉｔｃｈ１」と「Ｓｗｉｔｃｈ２」は、ターゲットが＃２の第２通信ユニット１２ｂで同じであり、周期も５ｍｓで一致した「ＯＵＴ」データであるためグループ化できる。Ｍ＿ＳＴは、グループ化の条件を満たす他のデータがないため、単独でコネクションＩＤを設定し、通信することになる。以下、本実施形態の特徴であるグループ化して送信するデータについての名前解決処理とコネクションＩＤの設定処理について説明する。

（０）ユーザは、通信設定ツール３０を操作し、グループ化するデータを管理するためのアセンブリテーブルを作成し、各通信ユニットに格納する。アセンブリテーブルは、第２実施形態等における通信バッファテーブルと同様のもので、アセンブリ名と、バッファエリアと、対応変数とを関連づけたテーブル構造となっている。対応変数の欄には、グループ化する変数名を格納する。バッファエリアは、変数名に対応するデータを格納するエリアであり、このバッファエリアの大きさによりグループ化できるデータ数が決定される。

ユーザは、通信設定ツール３０を操作し、オリジネータである第１通信ユニット１２ａに格納する通信設定情報も作成し、格納する。通信設定情報は、自局アセンブリ名と、相手局を特定するノードアドレスと、相手局アセンブリ名と、データサイズと、向きと、周期と、を関連づけたテーブル構造となる。データサイズは、グループ化する各データのデータサイズの総和となる。

もちろん、ユーザは、通信設定ツール３０を操作し、各変数テーブルを作成し、対応するＣＰＵユニットに格納するし、グループ化されないデータについての通信バッファテーブルや通信設定情報も作成し、対応する通信ユニットに格納する。

（１）通信ユニットが変数名と、実アドレスの対応付けする名前解決処理は、各変数名ごとに行なうため、第２実施形態などと同様に行なう。つまり、通信ユニットは、アセンブリテーブルに格納された変数名を取得し、接続されたＣＰＵユニットに対し取得した変数名の実アドレスを問い合わせる。この問い合わせる際の変数名の数は、任意であり、１個ずつ問い合わせても良いし、一括して問い合わせても良い。

（２）各ＣＰＵユニットは、問い合わせを受けると、変数テーブルを参照し、変数名に対する実アドレス並びに、型（サイズ）を返信する。これら（１），（２）の処理は、各通信ユニットとＣＰＵユニットとの間で適宜のタイミングで実行される。

（３）オリジネータ側の第１通信ユニット１２ａは、名前解決した情報を記憶しておく。記憶エリアは、例えば、テンポラリ内部テーブルを用いることができる。なお、通信設定情報を備えたオリジネータ側では、通信設定情報中に「向き」まで特定されているため、図２２に示すようにテンポラリ内部テーブルは完成する。テンポラリ内部テーブルは、アセンブリテーブルのバッファエリアを特定する情報（図では、Ｂｆ１）と、自局アセンブリ名と、グループ全体のデータサイズと、グループ化された変数名と、実アドレスと、向きを関連づけたテーブルとなる。図から明らかなように、グループ単位で１連のテーブルが作成される。

（３）′ターゲット側の第２通信ユニット１２ｂは、名前解決した情報を記憶しておく。記憶エリアは、例えば、テンポラリ内部テーブルを用いることができる。なお、通信設定情報を備えていないターゲット側では、「向き」を特定できないため、この処理が実行されて作成されるテンポラリ内部テーブルは、向きが空欄となる。

（４）次に、コネクションＩＤの設定処理手順について説明する。ノード番号の小さいオリジネータから順番に、ターゲットへ通信確立要求をする。この通信確立要求は、ツール３０からの通信確立命令が出されたことに基づき、各通信ユニットが順次処理対象のデータの通信相手となる通信ユニットに対して通信確立要求を発行することになる。

この通信確立要求は、グループ化されたものについては、アセンブリ単位で行なう。つまり、通信確立要求は、相手局アセンブリ名，データサイズ，向き並びに周期の情報を相手ノードに送る。もちろん、送信フレームのヘッダには、送信元情報として、自己のノードアドレス（＃１）が格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。

従って、図２２に示す第５実施形態では、最初にノードアドレスが＃１と小さい第１通信ユニット１２ａが実行する。すなわち、第１通信ユニット１２ａは、第２通信ユニット１２ｂに対し「Ｔ＿ＡＳｙ１／２Ｗ／ＯＵＴ／５ｍｓ」を内容とする通信確立要求を発行する。もちろん、グループ化されていないデータについては、第２実施形態等と同様に変数名ごとに通信確立要求をする。

（５）この通信確立要求を受信したターゲット（第２通信ユニット１２ｂ）は、要求内容をチェックする。すなわち、テンポラリ内部テーブルをアクセスし、通信確立要求されたアセンブリ名の有無をチェックする。そして、アセンブリ名が存在している場合には、ターゲットは、サイズが一致するか否かをチェックする。そして、一致する場合には、第２通信ユニット１２ｂは、空欄となっていたテンポラリ内部テーブルの「ＲＥＡＤＹ」，「ＳＴＯＰ」に対応する「向き」の欄に、受信した向きと逆の「ＩＮ」を入力する。

なお、アセンブリ名の有無のチェックは、上記のようにテンポラリ内部テーブルに基づいて行なっても良いが、本発明はこれに限るものではなく、アセンブリテーブルに基づいて行なっても良い。さらに、テンポラリ内部テーブルとアセンブリテーブルの両方に基づいてアセンブリ名の有無をダブルチェックするようにしてもよい。

コネクションＩＤは、オリジネータのノードアドレス−ターゲットのアドレスーシリアル番号から構成される。シリアル番号は、処理した順に付与する。従って、例えば上述した「Ｔ＿Ａｓｙ１」についての通信確立要求が最初に発行されてきた場合、ターゲットである第２通信ユニット１２ｂは、Ｔ＿Ａｓｙ１のデータについて「＃１＃２−００１」というコネクションＩＤを設定する。

通信確立要求を受けたターゲットからコネクションＩＤとともに要求許可通知が発行されると、オリジネータとターゲットでは、図２３（ａ）に示すデータ構造からなるコネクションテーブルが作成される。このコネクションテーブルは、１つのコネクションＩＤが付与されるごとに、逐次作成され、更新される。

また、本実施形態では、グループ化できないデータについては、上述した第２実施形態等で説明した方式に従い変数名単位でコネクションＩＤを設定する。この設定されたコネクションＩＤは、コネクションテーブルにより管理されるが、図２３（ａ）に示したグループ化したアセンブリ名を用いたコネクションテーブルと別に形成する。また、グループ化できない１つの変数名についての情報をアセンブリテーブルに登録することにより、図２３（ｂ）に示すように、同一のコネクションテーブルで一元管理ができる。この場合に、Ｂｆ２は、例えば、Ｍ＿ＳＴのみのデータが格納されるようになる。

全てのデータについてコネクションＩＤが設定されたならば、第１通信ユニット１２ａと、第２通信ユニット１２ｂとの間では、コネクションＩＤを用いてデータの送受を行なう。従って、グループ化されたものについては、一括してデータが送信されることになる。

図２４は、第５実施形態の変形例を示している。上述した第５実施形態は、各通信ユニットとＣＰＵユニット間における名前解決処理を、コネクションＩＤの設定処理を行なう前に、予め各ユニット間同士で事前に行なうようにした。これに対し、この変形例では、ターゲット側の名前解決は、コネクションＩＤの設定を行なう一連の処理手順の中で行なうようにした。

（０）すなわち、ユーザは、通信設定ツール３０を操作し、第１ＣＰＵユニット１１ａ用の変数テーブルと、第２ＣＰＵユニット１１ｂ用の変数テーブルと、第１通信ユニット用のアセンブリテーブルと、第２通信ユニット用のアセンブリテーブルを作成し、それぞれのテーブルを対応するユニットにダウンロードする。さらに、ユーザは、通信設定ツール３０を操作し、通信設定情報を作成し、第１通信ユニット１２ａへ格納する。各テーブルや通信設定情報の内容は、第５実施形態と同様である。

（１）次に、オリジネータ側の第１通信ユニット１２ａは、通信設定情報に格納された自局変数名について、第１ＣＰＵユニット１１ａへ名前解決要求をする。この名前解決要求は、自局変数名に対応するデータが格納される第１ＣＰＵユニット１１ａにおけるメモリの実アドレスを問い合わせることである。ここでは、Ｓｗｉｔｃｈ１とＳｗｉｔｃｈ２がグループ化されているが、名前解決の問い合わせは、１つずつ順に行なっても良いし、一括して行なっても良い。なお、オリジネータ側の通信ユニットにおける名前解決要求の実行は、このように通信設定情報の中に格納された変数名に基づいて行なうことに代えて、アセンブリテーブル内に記憶された変数名に基づいて行うことも可能である。

（２）第１ＣＰＵユニット１１ａは、受信した名前解決要求に応じて変数テーブルを参照し、対応する実アドレス（メモリアドレス）を返信する。このとき、第１ＣＰＵユニット１１ａは、型も併せて返信する。

（３）オリジネータ側の第１通信ユニット１２ａは、第１ＣＰＵユニット１１ａから返信されてきた情報（実アドレス，型）と、自己が保有する通信設定情報とに基づいてテンポラリ内部テーブルを作成する。作成されるテンポラリ内部テーブルのデータ構造は、第５実施形態と同様であり、グループ単位で作成される。

（４）通信設定ツール３０からの通信確立命令を受けて、オリジネータ側の第１通信ユニット１２ａ（＃１）は、通信設定情報に格納されたアセンブリ名について、テンポラリ内部テーブルに基づいて、ターゲット側の第２通信ユニット１２ｂ（＃２）へ通信確立要求をする。通信確立要求とともに送る情報は、相手局アセンブリ名／サイズ／向き／周期を含む。従って、具体的には、第１通信ユニット１２ａは、第２通信ユニット１２ｂに対し「Ｔ＿ＡＳｙ１／２Ｗ／ＯＵＴ／５ｍｓ」を内容とする通信確立要求を発行する。この通信確立要求に自己局の変数名を含めても良い。また、通信確立要求のフレームのヘッダには、自己のノードアドレスと相手のノードアドレスが格納されている。

（５）通信確立要求を受信した第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂに対し、受信した変数名について名前解決要求をする。このとき、通信確立要求の内容は、グループ単位であるため、アセンブリ名で特定される変数名は複数ある。そこで、アセンブリテーブルを参照し、対応する変数名を取得し、取得した変数名の１個ずつについて、第２ＣＰＵユニット１１ｂへ名前解決を要求する。図示の例では、第２通信ユニット１２ｂは、１つめの変数名「ＲＥＡＤＹ」についての実アドレスを問い合わせる要求をしている。もちろん、アセンブリ中の全ての変数名について一括して名前解決を要求して良い。

（６）第２ＣＰＵユニット１１ｂは、名前解決要求に応じて変数テーブルを参照し、変数名に対応する実アドレスと型（サイズ）とを取得し、第２通信ユニット１２ｂへ返信する。図では、第２ＣＰＵユニット１１ｂは、問い合わせのあった「ＲＥＡＤＹ」に対し、「ＤＭ２００／１Ｗ（１ｗｏｒｄの意味）」を返信している。名前解決の要求を１個ずつ行なう場合には、（５），（６）を所定回数繰り返し実行し、アセンブリ名に属する全ての変数名について名前解決を行なう。

（７）第２通信ユニット１２ｂは、第２ＣＰＵユニット１１ｂから取得したメモリアドレスと型（サイズ）に基づき、第１通信ユニット１２ａから受信した通信確立要求の内容をチェックする。具体的なチェック項目は、第５実施形態と同様であるためここでは省略する。

そして、要求内容が正しく、通信確立要求を許可する場合には、第２通信ユニット１２ｂは、テンポラリ内部テーブルを作成する。このテンポラリ内部テーブルのデータ構造は、第５実施形態と同様である。ここでは、受信した通信確立要求の内容と、名前解決処理で取得した変数名と実アドレスの対応関係から、現在コネクションＩＤの設定の処理対象となっているアセンブリ名について一度に作成する。あわせて、第２通信ユニット１２ｂは、通信設定ツール３０に、「要求条件ＯＫ」の旨と「通信確立内容」とをモニタ表示する。

以下、第５実施形態と同様に、第１通信ユニット１２ａと第２通信ユニット１２ｂは、ともにコネクションテーブルを作成する。さらに、アセンブリ名が複数存在する場合、上記の（４）から（８）の処理を、各アセンブリ変数名ごとに繰り返し実行し、全てのアセンブリ名についての確立要求を行ない、コネクションＩＤを設定する。通信確立したのちは、コネクションＩＤを利用して通信ユニット間で通信することは、第５実施形態と同様であるため、その説明を省略する。

図２５は、本発明の第６実施形態を示している。本実施の形態は、第３実施形態と同様に受信側をオリジネータに設定した場合を前提とし、第５実施形態と同様にグループ化に適用したものである。グループ化される条件は、第５実施形態と同様である。ただし、受信側をオリジネータに設定したため、実際には、ターゲットが共通で、周期が同じで「ＩＮデータ」同士が、グループ化されることになる。以下、本実施形態の特徴であるグループ化して送信するデータについての名前解決処理とコネクションＩＤの設定処理について説明する。

（０）ユーザは、通信設定ツール３０を操作し、グループ化するデータを管理するためのアセンブリテーブルを作成し、各通信ユニットに格納する。アセンブリテーブルは、第５実施形態と同様のデータ構造をとる。ただし、第５実施形態とはオリジネータとターゲットの関係が逆になるため、アセンブリ名が異なる。つまり、第５実施形態ならびに第６実施形態では、オリジネータとターゲットのアセンブリ名の対応付けが容易に理解しやすくするため、ターゲットのアセンブリ名は、オリジネータのアセンブリ名の前に「Ｔ＿」を付加したものを用いている。そのため、第２通信ユニット１２ｂのアセンブリテーブルに格納するアセンブリ名は「Ａｓｙ」の後ろに適当な番号を付加した名称となり、第１通信ユニット１２ａのアセンブリテーブルに格納するアセンブリ名は、「Ｔ＿」から始まるようになっている。

ユーザは、通信設定ツール３０を操作し、オリジネータである第２通信ユニット１２ｂに格納する通信設定情報も作成し、第２通信ユニット１２ｂに格納する。通信設定情報は、自局アセンブリ名と、相手局を特定するノードアドレスと、相手局アセンブリ名と、データサイズと、向きと、周期と、を関連づけたテーブル構造となる。データサイズは、グループ化する各データのデータサイズの総和となる。なお、この第６実施形態では、受信側をオリジネータとしたため、通信設定情報における向きは、必ず「ＩＮ」となる。そこで、第３実施形態と同様に、通信設定情報における向きの欄は、省略しても良い。

（１）通信ユニットが変数名と、実アドレスの対応付けする名前解決処理は、コネクションＩＤの設定処理に先立ち実行する。つまり、第５実施形態と同様に、通信ユニットは、アセンブリテーブルに格納された変数名を取得し、接続されたＣＰＵユニットに対し取得した変数名の実アドレスを問い合わせる。この問い合わせる際の変数名の数は、任意であり、１個ずつ問い合わせても良いし、一括して問い合わせても良い。

（３）オリジネータ側の第２通信ユニット１２ａは、名前解決した情報を記憶しておく。記憶エリアは、例えば、テンポラリ内部テーブルを用いることができる。なお、通信設定情報を備えたオリジネータ側では、通信設定情報中に「向き」まで特定されているため、図２５に示すようにテンポラリ内部テーブルは完成する。テンポラリ内部テーブルは、アセンブリテーブルのバッファエリアを特定する情報（図では、Ｂｆ１１）と、自局アセンブリ名と、グループ全体のデータサイズと、グループ化された変数名と、実アドレスと、向きを関連づけたテーブルとなる。図から明らかなように、グループ単位で１連のテーブルが作成される。

（３）′ターゲット側の第１通信ユニット１２ａは、名前解決した情報を記憶しておく。記憶エリアは、例えば、テンポラリ内部テーブルを用いることができる。なお、通信設定情報を備えていないターゲット側では、「向き」を直接的に特定できないため、この処理が実行されて作成されるテンポラリ内部テーブルは、「向き」の欄を空欄とする。なお、ターゲット側は送信側であるため、「向き」は「ＯＵＴ」になる。そこで、第１通信ユニット１２ａは、テンポラリ内部テーブルを作成する際に、「向き」の欄に「ＯＵＴ」を格納するようにしても良い。

（４）次に、コネクションＩＤの設定処理手順について説明する。ノード番号の小さいオリジネータから順番に、ターゲットへ通信確立要求をする。この通信確立要求は、ツール３０からの通信確立命令が出されたことに基づき、各通信ユニットが順次処理対象のデータの通信相手となる通信ユニットに対して通信確立要求を発行することになる。この通信確立要求は、グループ化されたものについては、アセンブリ単位で行なう。つまり、通信確立要求は、相手局アセンブリ名，データサイズ，向き並びに周期の情報を相手ノードに送る。もちろん、送信フレームのヘッダには、送信元情報として、自己のノードアドレスが格納されているので、受信した通信ユニットは、どのノードアドレスの通信ユニットから送られてきた通信確立要求かが分かる。

図２５の例では、通信設定情報を備えている通信ユニットの最小のノード番号は＃２であるので、第２通信ユニット１２ｂが、通信確立要求を実行する。すなわち、第２通信ユニット１２ｂは、第１通信ユニット１２ａに対し「Ｔ＿ＡＳｙ１１／２Ｗ／ＩＮ／５ｍｓ」を内容とする通信確立要求を発行する。もちろん、グループ化されていないデータについては、第３実施形態等と同様に変数名ごとに通信確立要求をする。

（５）この通信確立要求を受信したターゲット（第１通信ユニット１２ａ）は、要求内容をチェックする。すなわち、テンポラリ内部テーブルをアクセスし、通信確立要求されたアセンブリ名の有無をチェックする。そして、アセンブリ名が存在している場合には、ターゲットは、サイズが一致するか否かをチェックする。そして、一致する場合には、第１通信ユニット１２ａは、空欄となっていたテンポラリ内部テーブルの「Ｓｗｉｔｃｈ１」，「Ｓｗｉｔｃｈ２」に対応する「向き」の欄に、受信した向きと逆の「ＯＵＴ」を入力する。なお、（３）′の処理の際に、「向き」の欄に「ＯＵＴ」を格納した仮のテンポラリ内部テーブルを作成した場合には、対応する欄が「ＯＵＴ」になっていることを確認し、内容を確定する。

コネクションＩＤは、オリジネータのノードアドレス−ターゲットのアドレスーシリアル番号から構成される。シリアル番号は、処理した順に付与する。従って、例えば上述した「Ｔ＿Ａｓｙ１１」についての通信確立要求が最初に発行されてきた場合、ターゲットである第１通信ユニット１２ｂは、Ｔ＿Ａｓｙ１１のデータについて「＃２＃１−００１」というコネクションＩＤを設定する。

アセンブリテーブルに登録されたアセンブリ名が複数存在する場合、上記のアセンブリ名ごとに（４）から（６）の処理を繰り返し実行し、全てのアセンブリ名について個年ションＩＤを設定する。

通信確立要求を受けたターゲットからコネクションＩＤとともに要求許可通知が発行されると、オリジネータとターゲットでは、図２６に示すデータ構造からなるコネクションテーブルが作成される。このコネクションテーブルは、１つのコネクションＩＤが付与されるごとに、逐次作成され、更新される。

なお、具体的な図示は省略するが、この第６実施形態においても、第５実施形態の変形例と同様に、ターゲット側の名前解決はコネクションＩＤの設定処理を行なう途中で実行するようにすることもできる。また、第４実施形態及びその変形例のように、送信側をオリジネータにした場合にも、上述したグループ化の技術を適用できる。

さらにまた、図２２，図２４，図２５では、アセンブリテーブルは、アセンブリ名と、バッファエリアと、対応変数と、を関連づけ立てー部としたが、例えば、アセンブリ名とバッファエリとを対応づけたテーブルと、アセンブリ名と対応変数と対応づけたテーブルのように２つのテーブルに分けて管理しても良い。このように２つのテーブルに分割して管理することは、第２から第４実施形態ならびにその変形例で図示した通信バッファテーブルについても言える。

以上、第５、第６実施形態およびその変形例を説明したが、いずれの実施形態においても次のようにするのが好ましい。まず、オリジネータが発行する通信要求に、自己局ノードアドレス（オリジネータ側ノードアドレス）、自己局のアセンブリ名（オリジネータ側のアセンブリ名）、相手局ノードアドレス（ターゲット側ノードアドレス）、相手局のアセンブリ名（ターゲット側のアセンブリ名），データサイズ（通信対象データのサイズ），向き（送信なのか受信なのか）並びに周期を含めるようにする。

いっぽう、ターゲットがオリジネータに対して送る要求許可通知に、許可通知（ＯＫ／ＮＧ）、コネクションＩＤ、自己局ノードアドレス（ターゲット側ノードアドレス）、相手局ノードアドレス（オリジネータ側ノードアドレス）、周期に加え、自己局のアセンブリ名（ターゲット側のアセンブリ名）、相手局アセンブリ名（ターゲット側のアセンブリ名），データサイズ（通信対象データのサイズ）、向き（送信なのか受信なのか）を含めるようにする。このうち自己局のアセンブリ名（ターゲット側のアセンブリ名）と相手局アセンブリ名（ターゲット側のアセンブリ名）とについては、もともとオリジネータがふたつの関係付けを記憶しているので、どちらかを省略してもよい。また、データサイズ（通信対象データのサイズ）もオリジネータが記憶している情報なので省略してもよい。

また、ターゲットは、オリジネータからの通信要求、ターゲットでの通信確立処理を通じて取得した情報をひとまとめに記憶するのが好ましい。例えば、新たに通信設定情報を記憶できる記憶領域を用意し、そこにコネクションＩＤ、自己局ノードアドレス（ターゲット側ノードアドレス）、自己局のアセンブリ名（ターゲット側のアセンブリ名）、相手局ノードアドレス（オリジネータ側ノードアドレス）、相手局アセンブリ名（オリジネータ側のアセンブリ名）、データサイズ（通信対象データのサイズ）、向き（送信なのか受信なのか）、並びに周期（通信許可した周期）の情報を含む情報を別途記憶しておくとよい。こうすると、ユーザはターゲットとして関わる通信設定内容をその記憶情報を確認することで、変数名に基づいて通信内容を知ることができる。

なお、第５、第６の実施形態およびその変化例のように、１つの通信ユニットがオリジネータの立場とターゲットの立場の両方をとることがある。この場合であっても、ひとつの通信ユニットがオリジネータとして通信確立後の通信設定情報と、ターゲットとしての通信確立後の通信設定情報を併せ持つので、ユーザはそれらの記憶することで、アセンブリ名に基づいて通信内容を知ることができる。

１０ａ第１ＰＬＣ
１０ｂ第２ＰＬＣ
１１ａ第１ＣＰＵユニット
１１ｂ第２ＣＰＵユニット
１１ｃ第３ＣＰＵユニット
１２ａ第１通信ユニット
１２ｂ第２通信ユニット
１２ｃ第３通信ユニット
１３ａ，１３ｂＩ／Ｏユニット
１４ａ，１４ｂユニット
２１フラッシュＲＯＭ
２２ＭＰＵ
２３ＳＲＡＭ
２４インタフェース回路
２６システムバス
３１フラッシュＲＯＭ
３２ＭＰＵ
３３ＳＲＡＭ
３４共有ＲＯＭ
３５インタフェース回路
３６通信コントローラ
３７通信インタフェース回路

Claims

プログラミングされたプログラムに基づいて記憶手段のデータを演算実行するコントローラと、ネットワークを介して他のプログラマブルコントローラの通信ユニットとの間で前記コントローラの記憶手段のデータを通信する通信ユニットとをシステムバスを介して連結したプログラマブルコントローラであって、
前記コントローラは、データが格納されるメモリの実アドレスとそのデータに対応する変数名とを関連付けて記憶する変数テーブルを有し、
前記通信ユニットは、
前記他の通信ユニットとの間で通信対象にするデータの前記変数名と、送受信属性と、通信対象の相手局アドレスと、相手局における変数名とを関連付けた情報を記憶する通信設定情報記憶手段と、
通信対象にするデータの前記変数名とバッファ領域とを関連付けて記憶するテーブルと、
所定のタイミングで、前記テーブルに記憶された変数名に対応する実アドレスを、前記コントローラに問い合わせることにより取得し、その変数名と取得した実アドレスとを関連づけたテーブルを記憶保持する変数解決手段と、
前記他のプログラマブルコントローラの相手局アドレスの通信ユニットに対し、通信するデータを特定するための識別情報の取得要求をする手段と、
その要求に応じて相手局アドレスの通信ユニットから送られてきた前記識別情報と、その識別情報で特定されるデータ対応する前記変数解決手段によって取得した実アドレスとを関連づけて記憶し、通信時に前記識別情報とともに送られてきたデータをシステムバスを介して前記コントローラに提供可能にする手段と、
を有したことを特徴とするプログラマブルコントローラ。
プログラミングされたプログラムに基づいて記憶手段のデータを演算実行するコントローラと、ネットワークを介して他のプログラマブルコントローラの通信ユニットとの間で前記コントローラの記憶手段のデータを通信する通信ユニットとをシステムバスを介して連結したプログラマブルコントローラであって、
前記コントローラは、データが格納されるメモリの実アドレスとそのデータに対応する変数名とを関連付けて記憶する変数テーブルを有し、
前記通信ユニットは、
前記他の通信ユニットとの間で通信対象にするデータの前記変数名とバッファ領域とを関連付けて記憶するテーブルと、
所定のタイミングで、前記テーブルに記憶された変数名に対応する実アドレスを前記コントローラに問い合わせることにより取得し、その変数名と取得した実アドレスとを関連づけたテーブルを記憶保持する変数解決手段と、
前記他の通信ユニットから通信対象にするデータの前記変数名と送受信属性とを含む通信設定情報を受取ることによって、他の通信ユニットとの間で通信するデータを特定するための識別情報を生成し、生成した識別情報を前記他の通信ユニットへ送信する通信確立処理手段と、
前記他のプログラマブルコントローラの通信ユニットから前記識別情報とともに送られてきたデータをシステムバスを介して前記コントローラに提供可能にする手段と、
を有したことを特徴とするプログラマブルコントローラ。
プログラミングされたプログラムに基づいて記憶手段のデータを演算実行するコントローラと、ネットワークを介して他のプログラマブルコントローラの通信ユニットとの間で前記コントローラの記憶手段のデータを通信する通信ユニットとをシステムバスを介して連結したプログラマブルコントローラであって、
前記コントローラは、データが格納されるメモリの実アドレスとそのデータに対応する変数名とを関連付けて記憶する変数テーブルを有し、
前記通信ユニットは、前記他の通信ユニットとの間で通信対象にするデータの前記変数名とバッファ領域とを関連付けて記憶するテーブルと、前記他の通信ユニットから通信対象にするデータの前記変数名と送受信属性とを含む通信設定情報を受取ることによって、他のプログラマブルコントローラの通信ユニットとの間で通信するデータを特定するための識別情報を生成し、生成した識別情報を前記他の通信ユニットへ送信する通信確立処理手段と、を有し、
前記通信ユニットは、通信確立処理手段が通信設定情報を受取った後のタイミングで、前記通信設定情報に含まれた変数名に対応する実アドレスを前記コントローラに問い合わせることにより取得し、その変数名と取得した実アドレスとを関連づけたテーブルを記憶保持する変数解決手段と、
前記他のプログラマブルコントローラの通信ユニットから前記識別情報とともに送られてきたデータをシステムバスを介して前記コントローラに提供可能にする手段と、
を備えたことを特徴とするプログラマブルコントローラ。
複数のプログラマブルコントローラが、ネットワークを介して接続されて構成されるコントローラシステムであって、
前記複数のプログラマブルコントローラは、少なくとも請求項１に記載のプログラマブルコントローラと、請求項２に記載のプログラマブルコントローラをそれぞれ少なくとも１つ以上含み、
前記複数のプログラマブルコントローラ間のデータの送受は、前記識別情報を用いてデータを特定して行なうようにした
ことを特徴とするコントローラシステム。
複数のプログラマブルコントローラが、ネットワークを介して接続されて構成されるコントローラシステムであって、
前記複数のプログラマブルコントローラは、少なくとも請求項１に記載のプログラマブルコントローラと、請求項３に記載のプログラマブルコントローラをそれぞれ少なくとも１つ以上含み、
前記複数のプログラマブルコントローラ間のデータの送受は、前記識別情報を用いてデータを特定して行なうようにした
ことを特徴とするコントローラシステム。
請求項１に記載のプログラマブルコントローラおよび請求項２または３に記載のプログラマブルコントローラが、ネットワークを介して複数台接続されて構成されるコントローラシステムであって、
ある通信対象についての通信設定情報は、その通信対象の送信側の通信ユニットと、受信側の通信ユニットのうち、一方に格納し、
その格納する前記通信設定情報は、前記通信対象にする自局側の前記変数名と、相手局側の変数名と、送信／受信の区別情報と、通信相手局を特定するアドレス情報と、を関連付けた情報であり、
前記通信設定情報を備えた通信ユニットは、前記通信設定情報を備えていない通信ユニットに対し、少なくとも相手局変数名とともに通信確立要求を発行する機能を有し、
前記通信設定情報を備えていない通信ユニットは、前記通信確立要求に対し要求を許可するか否かを判断し、許可する場合には通信する際に使用するコネクションＩＤとともに許可通知を発行する機能を備え、
前記通信ユニット間での通信は、前記コネクションＩＤを用いて通信対象を特定し行なう
ことを特徴とするコントローラシステム。
前記コネクションＩＤは、同一の通信条件を有する複数の通信対象をグループ化したグループに設定され、
そのコネクションＩＤを用いることにより、複数の通信対象を一括して通信可能とした
ことを特徴とする請求項６に記載のコントローラシステム。