JP4123660B2 - Programmable controller - Google Patents

Programmable controller Download PDF

Info

Publication number
JP4123660B2
JP4123660B2 JP33552599A JP33552599A JP4123660B2 JP 4123660 B2 JP4123660 B2 JP 4123660B2 JP 33552599 A JP33552599 A JP 33552599A JP 33552599 A JP33552599 A JP 33552599A JP 4123660 B2 JP4123660 B2 JP 4123660B2
Authority
JP
Japan
Prior art keywords
output
data
module
cpu
shared mask
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP33552599A
Other languages
Japanese (ja)
Other versions
JP2000347712A (en
Inventor
哲仁 渡辺
元治 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fuji Electric FA Components and Systems Co Ltd
Original Assignee
Fuji Electric FA Components and Systems Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fuji Electric FA Components and Systems Co Ltd filed Critical Fuji Electric FA Components and Systems Co Ltd
Priority to JP33552599A priority Critical patent/JP4123660B2/en
Publication of JP2000347712A publication Critical patent/JP2000347712A/en
Application granted granted Critical
Publication of JP4123660B2 publication Critical patent/JP4123660B2/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Description

【０００１】
【発明の属する技術分野】
本発明は、プログラマブルコントローラに関し、更に詳しくはプログラマブルコントローラにおけるデータ出力の共有及び競合制御に関する。
【０００２】
【従来の技術】
図１６で示すようなシリアルリンクバス等のバス１０１に複数のＣＰＵモジュール１０２やＤＯ（出力）モジュール１０３及びＤＩ（入力）モジュール１０４を接続したマルチＣＰＵ構成のプログラマブルコントローラが知られている。
【０００３】
この様なプログラマブルコントローラにおいて、複数のＣＰＵモジュール１０２−１〜１０２−ｍが一つのＤＯモジュール１０３の出力点を共有して出力を行う場合、この出力点を共有している各ＣＰＵモジュール１０２は、ＤＯモジュール１０３の出力状態が現在ＯＮ（＝“１”）状態なのかＯＦＦ（＝“０”）状態なのかを知ることができない。例えば図１６において、ＣＰＵ１０２−１がＤＯモジュール１０３−１の一つの出力点の出力状態をＯＦＦにしても他のＣＰＵモジュール１０２−２〜１０２−ｍはこのことを知ることが出来ない。このことは、例えば共有するＤＯモジュール１０３−１を緊急停止信号として使用する場合、何れかのＣＰＵモジュール１０２−１がこのＤＯモジュール１０３−１に緊急停止信号をセットし、これを他のＣＰＵモジュール１０２−２〜１０２−ｍが認識して、しかるべき処理を行った後に緊急停止信号をリセットするようなアプリケーション等において、緊急停止信号をセットしたＣＰＵモジュール１０２−１が、その後この緊急停止信号に対して他のＣＰＵモジュール１０２−２〜１０２−ｍが何等かの対処処理を行って緊急停止状態が回避されたかどうかを知ることが出来ず、問題となる。
【０００４】
この為ＤＯモジュール１０３の出力のモニタ用に図１７のごとくＤＩモジュール１０６を別に追加して、このＤＩモジュール１０６にＤＯモジュール１０３の出力を折り返し入力する構成としていた。そしてＤＯモジュール１０３−１に“０”を出力したＣＰＵモジュール１０２−１が他のＣＰＵモジュール１０２−２〜１０２−ｍによって出力が“１”にされたかどうか等、各ＣＰＵモジュール１０２−１〜１０２−ｍは、現在のＤＯモジュール１０３−１の出力状態を知るためには、このＤＩモジュール１０６の出力を参照していた。
【０００５】
図１７はＤＩモジュール１０６によるＤＯモジュール１０３の出力の折り返し入力の例である。図１７において、バス１０１上の局アドレスとして局番０が設定されているＤＯモジュール１０３−１の各出力点１０５からの出力は局番１が設定されているＤＩモジュール１０６の入力点１０７へ折り返し入力されている。ＤＯモジュール１０３−１を共有している各ＣＰＵモジュール１０２上のタスクは、ＤＯモジュール１０３−１へデータを出力する時は局番０のＤＯモジュールをアドレス指定して出力し、またＤＯモジュール１０３−１の出力状態を得たい時は局番１のＤＩモジュールをアドレス指定してＤＩモジュール１０６からのデータを得る。
【０００６】
図１８に図１７の構成での各モジュール及びバス上での出力データの様子を示す。
プログラマブルコントローラでのデータの転送は、シリアルリンクバス１での転送速度と同一速度の一定間隔の周期で行われる。またＣＰＵモジュール１０２内の演算実行部へは、このデータ転送と同一周期で割込みが入力される。この周期をタクト周期といい図１８中縦の点線で示してある。各モジュールはこのタクト周期に同期して処理を行う。
【０００７】
ＣＰＵモジュール１０２の演算実行部２０１で行われる演算処理によって生じたＤＯモジュール１０３への出力データは、ＣＰＵモジュール１０２内のＩ／Ｏ領域の対応するアドレス領域へ格納される。するとこのデータは出力バッファを介してバス１０１上にフレームデータとして送信出力される。
【０００８】
このフレームを受信した局番０のＤＯモジュール１０３はこの受信データに基づいて各出力点の出力状態を変更する。またこのＤＯモジュール１０３の出力は局番１のＤＩモジュール１０６に折り返し入力されているので、このＤＩモジュール１０６によってＤＯモジュール１０３の出力状態はバス１０１上にフレームデータとして送信出力され、これは各ＣＰＵモジュール１０２のＩ／Ｏ領域の局番１に対応するアドレス領域に格納される。
【０００９】
図１９にＣＰＵモジュールの入出力処理の為の機能ブロック図を示す。
ＣＰＵモジュール１０２内には、データの入出力制御を行うための構成要素として演算実行部２０１、Ｉ／Ｏ領域２０２、出力バッファ２０３、入力バッファ２０４、シリアルリンク制御部２０５、出力データ転送テーブル２０６及び入力データ転送テーブル２０７を備える。
【００１０】
シリアルリンク制御部２０５は、バス１０１から送信されてきたフレームのうち自局に必要なデータを入力バッファ２０４に取込むと共に下流局のモジュールに流す。入力バッファ２０４に取込まれたデータは、タスク起動時にそのタスクに対応する入力データ転送テーブル２０７を参照してそのタスクが必要とするデータをＩ／Ｏ領域２０２に転送する。
【００１１】
Ｉ／Ｏ領域２０２は自局で実行されている複数のアプリケーションプログラムの各タスクが直接アクセスすることが出来るメモリ領域で、プログラム処理を行う演算実行部２０１は、このＩ／Ｏ領域２０２内から自己が必要とするデータを読み出す。
【００１２】
また演算実行部２０１はＤＯモジュールへデータ出力する時は、Ｉ／Ｏ領域２０２の対応するアドレス領域へ出力データを書込む。そしてタスク処理がすると、出力処理時に、出力データ転送テーブル２０６に基づいてＩ／Ｏ領域２０２から出力バッファ２０３へそのタスクに割り当てられたデータのみが転送される。そしてシリアルリンク制御部２０５は、これをフレームデータとしてバス１０１に出力する。
【００１３】
【発明が解決しようとする課題】
図１７の様にＤＯモジュール１０３−１の出力をＤＩモジュール１０６で折り返す構成にした場合、この為用に別にＤＩモジュールを追加しなければならない。
【００１４】
また各ＣＰＵモジュール１０２で実行されているアプリケーションプログラムは、ＤＯモジュール１０３−１の出力状態を知るのに、そのＤＯモジュール１０３−１の局アドレスとは別なアドレスを用いなければならない。よってアプリケーションプログラミングに処理の煩雑さを強いることになる。
【００１５】
また、各ＣＰＵモジュール１０２では、Ｉ／Ｏ領域２０２上に、ＤＯモジュール１０３−１の出力モニタ用のＤＩモジュール１０６の局アドレスを設定しなければならない。プログラマブルコントローラでは、Ｉ／Ｏ領域２０２のサイズ、即ち接続できるモジュールの総数は限定されているので、ＤＯモジュール１０３−１の出力状態のモニタのためにＤＩモジュール１０６を用いると、１つのＤＯモジュールの為に２つのアドレスを用いてしまうこととなり、資源利用効率が悪い。
【００１６】
またＣＰＵモジュール１０２では、バス１０１からのデータの入力処理において、入力データ転送テーブル２０７に従って入力バッファ２０４からＩ／Ｏ領域２０２へ入力データのコピーを行い、また出力処理では出力データ転送テーブル２０６に従ってＩ／Ｏ領域２０２から出力バッファ２０３への出力データのコピーを行っている。よって出力データ転送テーブル２０６中の局番０のＤＯモジュール１０３−１に設定されている出力データの転送元アドレスと入力データ転送テーブル２０７中の局番１のＤＩモジュール１０６に設定されている入力データ転送先アドレスを同じにすることにより、Ｉ／Ｏ領域２０２のＤＯモジュール１０３−１への出力先と同じアドレス領域にＤＩモジュール１０６を経由したＤＯモジュール１０３−１の出力状態を入力させることができる。しかしＤＯモジュール１０３−１への入力データと出力データに対してＩ／Ｏ領域２０２の同じアドレス領域を割り当てた場合、図２０に示す不具合がある。
【００１７】
図２０は、出力データ転送テーブル中２０６のＤＯモジュールへの出力データの転送元アドレスと入力データ転送テーブル中２０７のＤＩモジュールからの入力データの転送先アドレスを同じにした場合の各モジュール及びバス上での入出力の状態を示すタイミング図である。
【００１８】
図２０のタクト周期Ａにおいて、演算実行部２０１がＩ／Ｏ領域２０２にＤＯモジュール１０３への出力データとしてＯＵＴ２を出力したとする。しかし次のタクト周期Ｂでは、このＯＵＴ２の出力による折り返し出力がＩ／Ｏ領域２０２に転送される前に、１つ前の出力状態であるＯＵＴ１が入ってくる。もしＯＵＴ２がＣＰＵモジュールが緊急停止信号として出力した“１”で、またＯＵＴ１が“０”であったとき、次のタクト周期ＢでＤＯモジュールの出力状態を得ようとしてＩ／Ｏ領域２０２を参照すると、ＯＵＴ１（“０”）となってるので、アプリケーションプログラムは、ＤＯモジュールの出力が他のＣＰＵによって“０”にリセットされたものと誤認識する。
【００１９】
また一般にマルチＣＰＵ構成のプログラマブルコントローラにおいては、各ＣＰＵで担当するリソースを完全に分け機能分散した構成の場合では、入出力の共有・競合は起こらないが、本来１つのＣＰＵでシステム制御するところを、プログラム容量の増大への対処、並列処理による処理性能の向上などの理由でマルチＣＰＵを採用する場合１つの入出力モジュールを複数のＣＰＵで共有することとなる。そしてこの場合、１台の入出力モジュールに対して、複数のＣＰＵが書込み処理を行う競合書込みを行う場合がある。その場合のプログラムの開発では、ユーザは、競合制御を意識してプログラムソースを作成、変更するようなわずらわしさが有る。また、競合書込みが行われると複数のＣＰＵモジュールのプログラムで、同じ出力モジュールの同一アドレスに対する書込みが行われることとなるが、このアドレス重複が競合書込みによるものなのか、プログラム作業の誤り等によるものかチェックが容易に出来ることが要求される。
【００２０】
本発明は、上記問題点を鑑み、複数のＣＰＵモジュールがＤＯモジュールを共有している場合、そのＤＯモジュールの出力をモニタするＤＩモジュールを設けることなしに、各ＣＰＵモジュールが共有したＤＯモジュールの出力状態を知ることが可能なプログラマブルコントローラ及びアプリケーションプログラム開発装置を提供することを課題とする。
【００２１】
【課題を解決するための手段】
本発明によるプログラマブルコントローラは、複数のＣＰＵモジュールと少なくとも１つの出力モジュールを備えることを前提とする。
【００２２】
上記各ＣＰＵモジュールは、共有マスク生成手段及び出力データ送信手段を備える。
共有マスク生成手段は、出力モジュールに対して出力状態を変更するかどうかを指示する共有マスクを生成する。
【００２３】
出力データ送信手段と、上記出力モジュールに対する出力データを上記共有マスクと共に送信する。
また上記出力モジュールは、出力データ受信手段と共有及び競合制御手段を備える。
【００２４】
出力データ受信手段は、上記ＣＰＵモジュールからの上記出力データを上記共有マスクと共に受信する。
共有及び競合制御手段は、ＣＰＵモジュールからの、例えば自己を共有する複数のＣＰＵモジュールからの上記出力データと共有マスクから出力状態を決定する。
【００２５】
また上記出力モジュールは、上記出力状態を示す参照出力を上記自己を共有する複数のＣＰＵモジュールへ送信する参照出力送信手段を備え、上記ＣＰＵモジュールは、上記共有マスク生成手段が生成した共有マスクを記憶する共有マスク記憶手段と、該共有マスク記憶手段に記憶されている共有マスクと出力モジュールからの上記参照出力から該出力モジュールの出力状態を示す参照データを生成する出力状態参照データ生成手段とを更に備える構成としても良い。
【００２６】
更に上記出力データ送信手段が、上記出力データを送信する出力モジュールで該出力データに対し他のＣＰＵモジュールからの出力データとの共有及び競合制御を行う必要が無い時、該出力データの送信時、上記共有マスクを該出力データを送信しない構成としてもよい。この場合例えばＣＰＵモジュールに、上記共有マスクを上記出力データと共に送信したか否かを通知するデータ転送モード制御ビットを生成するデータ転送モード制御ビット生成手段を更に備え、上記出力データ送信手段が、該データ転送モード制御ビットを上記出力データと共に送信し、受信側の出力モジュールの上記共有及び競合制御手段は、該データ転送モード制御ビットが上記共有マスクが上記出力データと共に送信されていないことを示す時、該出力データのみから出力状態を決定する構成となる。
【００２７】
また、本発明によるプログラマブルコントローラのアプリケーションプログラム開発装置は、プログラム参照手段及び競合書込み命令生成手段を備える。
プログラム参照手段は、マルチＣＰＵ構成のプログラマブルコントローラを構成する全てのＣＰＵモジュールのプログラムを参照する。
【００２８】
競合書込み命令生成手段は、上記参照結果、上記プログラムに複数のＣＰＵモジュールが同じ出力モジュールの同じ出力点への出力を示す命令を含む場合、該命令を競合書込み用の命令に変換する。またこのアプリケーションプログラム開発装置は、上記競合書込み用の命令に変換する部分をユーザに通知するワーニング通知手段を備える。
【００２９】
本発明によれば、各ＣＰＵモジュールは、出力モジュールに対して出力データと共に共有マスクを送信し、出力モジュールではこの共有マスクの内容に基づいて出力の共有及び競合制御を行う。
【００３０】
また各ＣＰＵモジュールは、出力状態参照データ生成手段によって、出力モジュールの参照出力送信手段が送信した参照出力と共有マスク記憶手段が記憶する共有マスクから参照データを生成するので、この参照データから出力モジュールの出力状態を知ることが出来る。
【００３１】
更に参照データは出力モジュールからの参照出力と共有マスク記憶手段が記憶する共有マスクから生成されるので、ＣＰＵモジュールでは、出力モジュールへの出力情報と上記参照データを同一アドレス領域に格納することが出来る。
【００３２】
また、共有及び競合制御を必要としない時には、ＣＰＵモジュールが上記共有マスクを出力データと共に出力モジュールに送信しない構成とすれば、トラフィク量を少なくすることが出来る。
【００３３】
また本発明によるアプリケーションプログラム開発装置によれば、ユーザが意識しなくても競合書込みとなる書込み命令は、競合書込み命令に変換される。また競合書込み命令に変換される部分は、ユーザに通知される。
【００３４】
【発明の実施の形態】
図１は本実施形態におけるプログラマブルコントローラの概略を示す図である。本実施形態でのプログラマブルコントローラは、ＣＰＵモジュール２−１〜２−３の３つのＣＰＵモジュールが１つのＤＯモジュール３を共有しているものとする。
【００３５】
ＤＯモジュール３は、シリアルリンクバス１を介して各ＣＰＵモジュール２から送信されてきた出力データを受信すると、共有及び競合制御回路１０により、その受信データに基づいて出力点からの出力状態を変化させると共に、参照出力として各ＣＰＵモジュール２に現在の出力状態を示すデータを送信する。
【００３６】
尚本実施形態では、ＣＰＵモジュール２とＤＯモジュール３との間でのデータ転送は、本発明の出願人による特願平１０−１４８６４８号に開示されているトータルフレーム方式及びマルチキャスト方式によって行われるものとする。
【００３７】
図２はトータルフレーム方式によるデータ通信の説明図である。
本実施形態では、シリアルリンクバス１の局の内の１つをリングマスター局とし、このリングマスター局によってトータルフレーム方式及び後述するマルチキャスト方式によるデータ転送を管理する。図２ではシリアルリンクバス１に、リングマスター局、Ａ局、Ｂ局、Ｃ局、Ｄ局の順に接続されていたとする。
【００３８】
トータルフレーム方式では、ネットワーク上に唯一存在するリングマスター局により、まずトータルフレーム送信の要求を表すＲＥＱフレームが送信される。図２ではこの時のＲＥＱフレームはｒｅｑ０と表されている。
【００３９】
このＲＥＱフレームには、フレームのデミリタ部（スタートデミリタ（ＳＤ）部）にこのフレームがＲＥＱフレームであることを示すデータが設定されており、このフレームの受信局はＳＤ部を調べることによりこのフレームがＲＥＱフレームであることを認識する。
【００４０】
ＲＥＱフレームを受信した局は、そのフレーム最後に自局のデータを付加して隣の下流局へ送信する。図２の場合、Ａ局はＲＥＱフレームを受信すると、その末尾に自己の出力データＤａを付加して下流局のＢ局へ送信する。Ｂ局ではこのフレームを受信すると、その末尾に自己の出力データＤｂを付加して出力する。以下、順に各局はフレームを受取ると自己のデータをフレームの末尾に付加して下流局へ送信する。尚、本実施形態は複数のＣＰＵモジュール２を使用するマルチＣＰＵの構成であり、ＣＰＵモジュール２が他のＣＰＵモジュール２がＤＯモジュールに出力したデータを参照できるようにするため、ＤＯモジュールも自己のデータの出力を行っている。しかし、ＣＰＵモジュールを１つしか持たないプログラマブルコントローラの構成の場合には、この様な必要はない。
【００４１】
ＲＥＱフレームがシリアルリンクバス１を１巡して、これをリングマスター局が受信すると、リングマスター局はこのフレームのスタートデミリタ（ＳＤ）部に設定されているデータを２巡目のＲＥＱフレームであることを示すデータを設定変更し、またフレームの最後に自己のデータを付加して隣の下流局であるＡ局へ送信する。
【００４２】
このフレームを受信したＡ局は、受信フレームのＳＤ部を調べ、これが２巡目のＲＥＱフレームであることを認識すると、フレームのＳＤ部の次にある１巡目の時に自己が付加した自局データを削除して下流局へ中継する。図２の場合、Ａ局は２巡目のＲＥＱフレームを受信すると、１巡目で自己が付加した自局のデータＤａを削除して下流局のＢ局へ送信し、Ｂ局は受信フレームのＳＤ部の次にある自己の出力データＤｂを削除して次の下流局であるＣ局へ送信する。以下、順に各局はフレームを受取ると１巡目で付加した自己のデータをフレームから削除して下流局へ送信する。
【００４３】
この２巡回目のＲＥＱフレームがシリアルリンクバス１を巡回して、リングマスター局に戻ってくると、リングマスター局は、このフレームをシリアルリンクバス１から除去する。これによってトータルフレーム通信は完了する。
【００４４】
次にマルチキャスト方式によるデータ転送について説明する。
マルチキャスト方式は、ＣＰＵモジュール２からＤＯモジュール３に対してデータの出力を行う時用いられるデータ転送方式である。
【００４５】
マルチキャスト方式は、シリアルリンクバス１上にマルチキャスト通信用のフリートークンを巡回させ、データ伝送を要求する局（ＤＯモジュールに出力するための送信データが用意されており、また当該送信帯域の送信許可設定がされている局）はそのフリートークンを確保して代わりにマルチキャストフレームの送信を行う。マルチキャストフレームはシリアルリンクバス１上を巡回し、このマルチキャストフレームを受信したネットワーク上の局は、それを下流へ中継して巡回させると共にフレーム内の出力データの設定内容に基づいてデータの取込みを行う。
【００４６】
図３は、マルチキャスト方式による通信の説明図である。
マルチキャスト方式による通信では、まず、シリアルリンクバス１上に１つだけ存在するネットワーク管理を行うリングマスター局が、データ転送の権限を制御するフリートークンを生成し、シリアルリンクバス１上にリリースする。このフリートークンのリリースによって、マルチキャスト通信は開始される。
【００４７】
リリースされたフリートークンは、各局が順次下流局へ中継してゆき、シリアルリンクバス１上を巡回する。そしてデータの出力を行いたいＣＰＵモジュール２は、このフリートークンを受信すると、これをシリアルリンクバス１から確保し、マスター局となる。
【００４８】
マスター局は、用意してある送信データを、ＳＤ部にこのフレームがマルチキャスト通信のフレームであることを示すデータを設定したマルチキャストフレームとしてシリアルリンクバス１上に流す。図３では、マスター局は、保持したフリートークンの代わりにＡ局に対する出力データ（Ｍ→Ｄａ）とＢ局に対する出力データ（Ｍ→Ｄｂ）の２つの局に対する出力データがマルチキャストフレームとして、下流局Ｂへ送信される。
【００４９】
このマルチキャストフレームを受取った局は、そのフレーム内の出力データに設定されている出力データの格納先の局番を参照し、この出力データが自局に対するものであれば、それを取込むと共にそのフレームをそのまま下流局へ送信する。図３では、マルチキャストフレームを受信したＡ局及びＢ局はそれぞれ自局にあててマスタ局が出力した出力データ（Ｍ→Ｄａ、Ｍ→Ｄｂ）を取込むと共に、その受信フレームをそのまま隣の下流局であるリングマスター局及びマスター局へ送信する。
【００５０】
フレームが１巡すると、そのフレームを最初に送信したマスタ局は、これをシリアルリンクバス１から除去し、代わりにフリートークンを生成してシリアルリンクバス１上にリリースする。
【００５１】
そしてフリートークンがシリアルリンクバス１を１巡して戻ってくると、リングマスター局はデータ伝送要求の有無をチェックし、要求があれば当該送信データ［Ａ局に対する出力データ（ＲＭ→Ｄａ），Ｂ局に対する出力データ（ＲＭ→Ｄｂ）］の送信を行う。その後、自局が送信したデータフレームがシリアルリンクを１巡して自局に戻ってきたことでリングマスター局はフリートークンをシリアルリンク上から除去し、これによってマルチキャスト通信は終了する。
【００５２】
以下ＤＯモジュール３からＣＰＵモジュール２へデータを送信するときのデータ転送は、トータルフレーム方式により行う。またＣＰＵモジュール２からＤＯモジュール３へデータを出力するときのデータ転送は、マルチキャスト方式により行う。尚本発明では、各モジュール間でのデータ転送はこのトータルフレーム方式とマルチキャスト方式のみに限定されるものではない。また上記トータルフレーム方式及びマルチキャスト方式によるデータ転送は、各モジュールがリング型の伝送トポロジーのバスで接続されていることを前提とするが、本発明が適用されるプログラマブルコントローラにおいて各モジュールを接続するバスはリング型のトポロジーをもつシリアルバスに限定されるものではなく、モジュール間を他のトポロジーやパラレルバスで接続する構成でも良い。
【００５３】
図４にＤＯモジュール３の共有及び競合制御回路１０を詳細に示す。
同図中最下段はシリアルリンクバス１上を伝送されるフレームを示し、１タクト周期中にＤＯモジュール３から各ＣＰＵモジュール２−１〜２−３に対するトータルフレーム方式によるフレームに続いてＣＰＵモジュール２−１、２−２及び２−３からのマルチキャスト方式によるフレームが続く。尚同図中「メッセージ」はＣＰＵモジュール２間やＣＰＵモジュール２と通信モジュールなどとの間で行われるメッセージ転送用の時間帯域を示している。
【００５４】
各ＣＰＵモジュール２−１〜２−３は、ＤＯモジュール３に対する出力データと共に共有マスクを送信フレーム内に格納して、マルチキャスト方式でＤＯモジュール３に送信する。この共有マスクは各ＣＰＵモジュール２がＤＯモジュール３に対して出力状態の変更を行うかどうかを出力点毎に指定するもので、各ＣＰＵモジュール２はＤＯモジュール３の複数の出力点のうち、出力状態を変更したい出力点に対応する共有マスクのビットに“１”を、変更を行わない出力点に対応するビットに“０”を設定し、出力データと共にＤＯモジュールに送信する。
【００５５】
ＤＯモジュール３では、マルチキャスト方式のフレームを自己を共有している各ＣＰＵモジュール２−１〜２−３全てから受信すると、フレーム中の共有マスクデータ１１及び出力データ１２と、参照出力ラッチ１６内の自己の現在の出力状態との論理結果から新出力を求める。
【００５６】
ＤＯモジュール３では、ＣＰＵモジュール２からのフレームから共有マスク１１と出力データ１２を取り出すと、これらを各ＣＰＵモジュール２毎にＡＮＤ回路１３によってＡＮＤ値を取る。また各共有マスク１１−１〜１１−３の反転値と参照出力ラッチ１６の出力のＡＮＤ値をＡＮＤ回路１４によって求める。
【００５７】
そして各ＡＮＤ回路１３−１〜１３−３の出力とＡＮＤ回路１４の出力のＯＲ値をＯＲ回路１５によって求め、これをその出力点の新出力とする。またＯＲ回路１５の出力は参照出力ラッチ１６に格納されて次出力の決定に用いられると共に、トータルフレーム方式でシリアルリンクバス上に出力されて、各ＣＰＵモジュール２−１〜２−３に出力状態を通知する。これにより例えば全てのＣＰＵモジュール２からの共有マスクデータ１１−１〜１１−３が“０”だったビットに対応する出力点は、前回の出力状態の保持となる。また複数のＣＰＵモジュール２からの共有マスクデータ１１が“１”であり、その出力データ１２として“１”と“０”の両方ある場合には“１”が優先され、対応する出力点からは“１”が出力される。
【００５８】
図５はＣＰＵモジュール２の入出力処理の為の構成要素を示す機能ブロック図である。
ＣＰＵモジュール２内には、データの入出力制御を行うための構成要素として演算実行部２１、Ｉ／Ｏ領域２２、出力バッファ２３、入力バッファ２４、シリアルリンク制御部２５、出力データ転送テーブル２６、入力データ転送テーブル２７及び共有マスクデータ領域２８を備える。
【００５９】
プログラム処理を行う演算実行部２１は、演算結果からＤＯモジュールへデータ出力する必要が生じた時は、Ｉ／Ｏ領域２２のそのＤＯモジュールに対応するアドレス領域へ出力データを書込む。この出力データは、タスク処理すると出力処理時に、出力データ転送テーブル２６に基づいて、Ｉ／Ｏ領域２２から出力バッファ２３へそのタスクに割り当てられたデータのみ転送され、シリアルリンク制御部２５は、これをフレームデータとしてシリアルリンクバス１に出力する。
【００６０】
Ｉ／Ｏ領域２２は、自局で実行されている複数のアプリケーションプログラムの各タスクが直接アクセスすることが出来るメモリ領域で、ＣＰＵモジュールの内部メモリ上に構成される。演算実行部２１は、自己が必要とする他モジュールからのデータを、このＩ／Ｏ領域２２内の対応するアドレス領域から読み出し、また他モジュールへ出力する時は、対応するアドレス領域に出力データを書込む。各ＣＰＵモジュール２では、自己が対応している入力モジュールや出力モジュールを、出力データ転送テーブル２６及び入力データ転送テーブル２７でこのＩ／Ｏ領域２２中の各アドレス領域に１：１で対応付けてある。よって、例えばＩ／Ｏ領域２２が０ＨからＦＦＨまでのアドレスをもつ場合、このＣＰＵモジュール２は２５６の入出力モジュールとデータのやり取りを行うことが出来る。また各アドレス領域の各ビットの位置は、各入出力モジュールの入出力点に１：１対応しており、例えば１ワードが８ビットの場合、１つのアドレス領域で８つの入出力点に対応したデータのやり取りを行える。
【００６１】
出力バッファ２３は、出力データを出力先の局番、データのサイズ及び共有マスクと共に、出力する局毎に蓄積するバッファである。タスク処理が終了すると、出力処理時に、そのタスク処理で生じた出力データは出力データ転送テーブル２６に基づいてＩ／Ｏ領域２２から出力バッファ２３へ転送される。そして出力バッファ２３内のデータは、シリアルリンク制御部２５により、演算実行部２１による処理とは無関係にタクト周期でシリアルリンクバス１上に出力される。この様な一連の動作により、シリアルリンクバス１に接続された各モジュールは、一定周期（タクト周期）中は共通のデータを用いて動作することが可能となる。
【００６２】
入力バッファ２４は、上流局から流れてきたデータのうち、自局で必要なものを取込むバッファである。シリアルリンクバス１から受信したデータは、シリアルリンクバス１の転送周期と同一周期のタクト周期で、シリアルリンク制御部２５から入力バッファ２４に格納される。そして、タスク起動時にそのタスクに対応する入力データ転送テーブル２７が参照されてそのタスクが必要とするデータが入力バッファ２４からＩ／Ｏ領域２２に転送される。
【００６３】
シリアルリンク制御部２５は、シリアルリンクバス１から送信されてきたフレームを自己の受信バッファに取込み、それが自局に対するものでなければそのまま下流局に送り、また自局に対するものあればそれを入力バッファ２４に取込むと共に下流局のモジュールに流す。これによってシリアルリンクバス１上をフレームデータが一定方向に巡回する。またマルチキャスト用のトークンを受信するとシリアルリンク制御部２５は、出力バッファ２３内のデータをマルチキャストフレームとして、シリアルリンクバス１上にＤＭＡ転送する。
【００６４】
出力データ転送テーブル２６は、出力先となるモジュールのバス１上での局アドレスとＩ／Ｏ領域２２のアドレスとを対応付けるものである。出力データ転送テーブル２６は、タスク毎に存在し、そのタスク処理によって演算実行部２１が、ＤＯモジュールに出力する出力データをＩ／Ｏ領域２２から出力バッファ２３へ転送する際に参照される。１つのタスク処理が終了すると演算実行部２１は、出力処理時に、出力データ転送テーブル２６を参照し、Ｉ／Ｏ領域２２から出力バッファ２３へそのタスクに割り当てられたデータのみ転送する。
【００６５】
入力データ転送テーブル２７は、入力相手先となるモジュールのバス上での局アドレスとＩ／Ｏ領域２２のアドレスとを対応付けるもので、入力バッファ２４からＩ／Ｏ領域２２へのデータの転送を行う際に参照されるものである。入力データ転送テーブル２７は、各タスク毎に複数存在し、そのタスクが使用するデータの入力バッファ２４でのアドレス、Ｉ／Ｏ領域２２のアドレス及びデータサイズが格納されている。タスクが起動される際に、入力バッファ２４からＩ／Ｏ領域２２へのデータの転送を行うときには、そのタスクに対応した入力データ転送テーブル２７を使用してそのタスクが起動される前に入力バッファ２４からＩ／Ｏ領域２２にそのタスクが使用するデータのみが転送される。
【００６６】
共有マスクデータ領域２８は、Ｉ／Ｏ領域２２と同じ構成をもつ記憶領域で、ＣＰＵモジュールの内部メモリ上に構成される。演算実行部２１はこの共有マスクデータ領域２８中に共有マスクを生成する。そしてこの共有マスクは、Ｉ／Ｏ領域２２中の同じアドレスの出力データと共に出力バッファ２３へ転送され、対応するＤＯモジュール３へ送信される。
【００６７】
この共有マスクは、ＤＯモジュールへ送信後も共有マスクデータ領域２８内に保持される。そして、ＤＯモジュール３からの自己の出力状態を通知する参照出力を受信した時、そのＤＯモジュールに対応するアドレス領域内の共有マスクに基づいて入力バッファ２４からＩ／Ｏ領域２２への転送を行う。またこのＩ／Ｏ領域２２への転送入力処理が完了すると、対応する共有マスクは“０”にリセットされる。この点については後述する。
【００６８】
図６はＣＰＵモジュールで作られる共有マスクの例を示す図である。
演算実行部２１はタスク処理の結果からＤＯモジュールの出力状態を変更する必要が生じた時、出力データと共に共有マスクデータ領域２８に共有マスクデータを生成する。この共有マスクデータは、各ビットがＤＯモジュールの出力点と１：１対応した複数ビットのマスクデータで、ＤＯモジュールの各出力点のうち出力状態を変更する出力点に対応するビットに“１”、変更しない出力点に対応するビットに“０”が設定してある。
【００６９】
図６の共有マスクは８ビット構成の例で、この共有マスクのデータによって８つの出力点についての共有及び競合制御を行う。図６ではタスク処理による演算結果から、ＤＯモジュールに出力する出力データはビット０が“１”から“０”に、またビット４が“０”から“１”に変化しているため、共有マスクデータは出力状態に変更があるビット０とビット４に“１”、他の変更がないビットに“０”がセットされたものが生成され、共有マスクデータ領域２８に格納される。
【００７０】
またＣＰＵモジュール２では、ＤＯモジュール３からトータルフレームによる参照出力を受信すると、これを入力バッファ２４に格納した後、入力データ参照テーブル２７に基づいてＩ／Ｏ領域２２の対応するアドレス領域へ転送するが、この時全てのデータがＩ／Ｏ領域２２に転送されるわけではなく、Ｉ／Ｏ領域２２と同じアドレス領域の共有マスク領域２８内の共有マスクを参照して、ビット毎に転送を行うかどうかを決定して、排他的にデータ転送を行う。
【００７１】
共有マスクに“１”がセットされているビットの参照出力は、図６のビット０やビット４の様に自己がＤＯモジュールに出力の変更を指示した出力点の出力状態を示すものだが、今回の受信データはまだこの変更は反映されていないものである。よってこれをそのまま現在のＤＯモジュールの出力状態として入力バッファ２４からＩ／Ｏ領域２２へ転送すると図２０で示したような問題を生じる。よって共有マスクに“１”がセットされているビットの参照出力の転送は行わずに出力データの値をそのままＤＯモジュールの出力状態を示す値として残し、“０”がセットされているビットの参照出力のみ入力バッファ２４からＩ／Ｏ領域２２へ転送する。
【００７２】
そしてＩ／Ｏ領域２２への出力状態を示すデータの転送処理完了後、共有マスク領域２８内の対応アドレス領域の共有マスクを“０”にリセットし、次の出力データの生成に備える。
【００７３】
尚共有マスク領域２８内の共有マスクのリセットは、Ｉ／Ｏ領域２２への参照データの書き換え時に随時行っても良いし、またタスク処理による演算を行う前にＩ／Ｏ領域２２内のデータをコピーしておいたものと、演算後のＩ／Ｏ領域２２内のデータとを全アドレス領域に対して比較を行い、まとめて全ての共有マスクを生成する構成としても良い。
【００７４】
図７はＣＰＵモジュール２からＤＯモジュール３に、出力データを送信するためにシリアルリンクバス１上に送出されるマルチキャストフレームの構成例である。
【００７５】
各ＣＰＵモジュール２は出力データを送信するＤＯモジュール３宛てのマルチキャストフレームを送出する。マルチキャスト方式は、１タクト周期で複数のモジュールに対してデータを送信することが出来、１フレーム中に複数のＤＯモジュールへのデータを含めることが出来る。
【００７６】
図７では、マルチキャストフレームには、複数のＤＯモジュールに対する出力データが含まれており、この出力データは出力相手局を示す局番、データのサイズ及びマスク情報と共に各ＤＯモジュール毎に格納されている。
【００７７】
ＤＯモジュール３は、マルチキャストフレームを受信すると、受信フレーム内の各出力データに対し付されている局番と自己の局番情報を比較してゆき、一致するものがあれば対応する出力データを入力バッファに取込む。
【００７８】
図８はＣＰＵ０とＣＰＵ１の２つのＣＰＵモジュールがＤＯモジュールを共有している場合の各モジュール及びバス上での入出力状態の例を示すタイミング図である。同図は、ＣＰＵ０がＤＯモジュールの１つの出力点を“１”にセットし、これを認識したＣＰＵ１がこれを“０”にリセットする例である。尚同図及び以下の説明は説明簡略化の為、ＤＯモジュールの１つの出力点について、つまり１ビットのデータの入出力について記載されている。
【００７９】
図８において、まずタクト周期Ａでタスク処理による演算結果から、ＣＰＵ０が共有しているＤＯモジュールの１つの出力点に対し、出力状態を“０”から“１”へ変更する必要が生じたとする。演算実行部２１は、Ｉ／Ｏ領域２２のそのＤＯモジュール及び出力点に対応するアドレス領域に出力データとして“１”をセットし、また共有マスク領域２８のＩ／Ｏ領域２２のアドレスと同じアドレス領域に対応ビットを“１”にセットした共有マスクを生成し、格納する。
【００８０】
この出力データと共有マスクはマルチキャストフレーム３２−１としてＤＯモジュールに送信される。ＤＯモジュールではＣＰＵ０及びＣＰＵ０からの出力データ及び共有マスクに基づいて、タクト周期Ｂで、ＤＯモジュールは出力状態を変更する。この場合ＣＰＵ０の共有マスクは“１”、ＣＰＵ１の共有マスクは“０”なので出力状態はＣＰＵ０からの出力データが反映され、出力点の出力状態は“０”から“１”になる。
【００８１】
またこの間にＤＯモジュールからは、自己の出力状態を通知する参照出力がトータルフレーム３１−１によってＣＰＵ０及びＣＰＵ１に通知される。このトータルフレーム３１−１による参照出力は、マルチキャストフレーム３２−１によるＣＰＵ０からの出力データが反映されていないものなので、これをＤＯモジュールの出力状態としてＣＰＵ０のＩ／Ｏ領域２２に転送すると、ＣＰＵ０は自己がセットした出力“１”がＣＰＵ１によって“０”にリセットされたと誤判断してしまう。しかし、ＣＰＵ０では共有マスク領域２８に記憶されている共有マスクが“１”となっているので、このトータルフレーム３１−１による参照出力はＩ／Ｏ領域に転送されず出力状態を示す参照データはタクト周期Ａでセットされた“１”のままとなる。これによりＣＰＵ０でタクト周期Ｂの演算処理で演算実行部２１がＩ／Ｏ領域２２からＤＯモジュールの出力状態を示す参照データを読み出しても、タクト周期Ａでセットした出力が他のＣＰＵモジュールによってリセットされていると誤認識することはない。
【００８２】
トータルフレームによるデータのＩ／Ｏ領域２２への入力処理が完了すると、共有マスク領域２８内の同じアドレス領域内の共有マスクは“０”にクリアされる。これにより、演算処理によって新たにＤＯモジュールの出力状態を変更する必要が生じて、共有マスクが生成されるまでの間はトータルフレームによるＤＯモジュールからの参照出力は参照データとしてそのままＩ／Ｏ領域２２に入力される。図８では、ＣＰＵ０は、トータルフレーム３１−２、３１−３、３１−４の参照出力はそのままＩ／Ｏ領域２２にＤＯモジュールの出力状態を示す参照データとして入力される。
【００８３】
またＣＰＵ１では、ＤＯモジュールからのトータルフレーム３１−１及び３１−２による参照出力は、そのままＩ／Ｏ領域２２へ参照データとして入力される。ＣＰＵ１はタクト周期Ｃで、ＤＯモジュールの出力状態が“０”から“１”変化があったのを知ると、出力状態を“１”から“０”へリセットするようにＤＯモジュールへ指示する出力データを生成してＩ／Ｏ領域へ格納し、また対応ビットが“１”となる共有マスクを生成して共有マスク領域へ格納する。これらは、マルチキャストフレーム３２−３としてＤＯモジュールに通知される。ＤＯモジュールでは、マルチキャストフレーム３２−３内の共有マスクがＣＰＵ０からのものは“０”、ＣＰＵ１からのものは“１”なので、ＣＰＵ１からの出力データ“０”を反映させて出力状態を“１”から“０”に変更する。またこの変更された出力状態は参照出力として、トータルフレーム３１−４によってＣＰＵ０及びＣＰＵ１に通知される。
【００８４】
この様に本実施形態によるプログラマブルコントローラでは、ＤＯモジュールでは、出力データと共に送信されるＣＰＵモジュールからの共有マスクによって、各ＣＰＵモジュールからの出力の競合制御を行うことが出来る。
【００８５】
またＣＰＵモジュールでは、ＤＯモジュールから参照出力を受信すると、共有マスク領域内の対応する共有マスクを参照してＩ／Ｏ領域への転送を行うので、ＤＯモジュールへの出力データと参照データを同一アドレスに設定しても問題を生じない。
次に本発明の第２の実施形態について説明する。
【００８６】
これまでのプログラマブルコントローラでは、他のＣＰＵモジュールと共有しており競合制御の必要のあるＤＯモジュールだけでなく、共有していないＤＯモジュールに対しても、ＣＰＵモジュールは常に共有マスクデータを含む大きさのフレームをシリアルリンクバス１上に流すので、シリアルリンクバス１上の伝送効率は低下してしまう。
【００８７】
第２の実施形態のプログラマブルコントローラはこの点を考慮したもので、送信先が競合制御を必要とするか否かによって、送信フレームを変更する構成を備えている。
【００８８】
図９は、本発明の第２の実施形態でのマルチキャストフレームの構成例を示す図で、図７の第１の実施形態のフレーム構成図に対応するものである。
第２の実施形態によるフレーム構成では、フレーム内にデータ転送モード制御ビットを設けてある。同図の場合フレームの先頭部分である送信先を示す入出力モジュールの局番部分の上位のリザーブビットをデータ転送モード制御ビットに用いている。尚このデータ転送モード制御ビットは、同図の位置に限らず、特定の位置であればフレーム内の他の位置に設けたり、独立して設けることも可能である。
【００８９】
このデータ転送モード制御ビットは、共有マスクによるデータ転送制御を行うか否かを示すビットで、データ転送時に共有及び競合制御を行う場合にはこのビットに“１”を、共有及び競合制御を行う必要が無い場合にはこのビットに“０”を設定したフレームを送信する。
【００９０】
図９中（１）は、送信先のＤＯモジュールで共有及び競合制御を行わない場合のフレーム構成を示すもので、フレーム先頭部のデータ転送モード制御ビットに“０”がセットされ、またこのフレーム内には共有マスクデータは含まれておらず、局番、サイズ、出力データで構成される。また同図（２）は、共有及び競合制御を行う場合のフレーム構成を示すもので、データ転送モード制御ビットに“１”がセットされ、また図７の第１の実施形態でのフレーム構成と同様、出力データと共に共有マスクデータを持つ構成となっている。
【００９１】
データ送信を行うＣＰＵモジュールは、送信先が共有されているか否か、競合制御を必要としているかどうかによってこれら２つのフレームを使い分け、他のＣＰＵと共有している出力モジュールに出力データを送信する場合は、図９（２）に示したような構成のフレームを用い、他のＣＰＵと共有していない出力モジュールに出力データを送信する際は、同図（１）に示したような構成のフレームを用いる。この様にフレームを使い分けることにより、他のＣＰＵとデータ出力の共有及び競合制御を行う必要が無い場合は、余分な共有マスクデータをフレーム内に含まなくなるので、その分トラヒック量は減り、シリアルリンクバス１上のデータ転送効率は良くなる。
【００９２】
図１０は、第２実施形態におけるＤＯモジュール側の出力データを決定する共有及び競合制御回路４０の詳細を示す図である。図１０は、第１の実施形態の図４の構成に対応するもので、同一の構成要素には同じ番号が符されている。
【００９３】
図１０の共有及び競合制御回路４０は、図４の構成を基本に共有マスク有効モード記憶レジスタ４１、新規受信有り記憶レジスタ４２、ＮＯＴ回路４３及びＯＲ回路４４が各ＣＰＵモジュール毎に加えられ、またＡＮＤ回路は３入力のＡＮＤ回路に変更されている。このうち共有マスク有効モード記憶レジスタ４１は、受信したマルチキャストフレーム中のデータ転送モード制御ビットの値がセットされるもので、この値により共有及び競合制御回路４０は、共有及び競合制御を行う共有マスク有りモードと共有及び競合制御を行わない共有マスク無しモードを切替える。また新規受信有り記憶レジスタ４２は、新規のマルチキャストフレームを受信したことを示すレジスタで、新規にマルチキャストフレームをＣＰＵモジュールから受信するとそのＣＰＵモジュールに対応する新規受信有り記憶レジスタ４２に“１”にセットされる。そしてＯＲ回路１５の出力がＤＯ出力点から出力され、また参照出力ラッチ１６にラッチされると“０”にリセットされる。
【００９４】
共有マスク有効モード記憶レジスタ４１の値は、ＮＯＴ回路４３により反転された後ＯＲ回路４４により共有マスクデータ１１とのＯＲ値が取られる。よってＯＲ回路４４からは、共有マスク有効モード記憶レジスタ４１に“０”がセットされている時は“１”が、“１”がセットされている時は共有マスクデータ１１の値が出力されて、ＡＮＤ回路４５により出力データ１２及び新規受信有り記憶レジスタ４２内の値とＡＮＤ値が取られる。例えば図９（１）の様な競合制御を行わない場合のフレームを受信すると、対応する共有マスク有効モード記憶レジスタ４１には“０”がセットされる。また新規に受信したマルチキャストフレームが無い間は、各新規受信有り記憶レジスタ４２−１〜４２−３の値は“０”にリセットされたままなので、各ＡＮＤ回路４５−１〜４５−３の出力は“０”となり、ＤＯ出力点からの出力は、参照出力ラッチ１６にラッチされている値がＡＮＤ回路１４及びＯＲ回路１５を介して出力され続ける。
【００９５】
次に各ＣＰＵモジュールが、共有マスクデータを持たないフレーム（図９（１）のフレーム）と持つフレーム（図９（２）のフレーム）のどちらを用いるかを決定する共有マスクモジュールモード決定の仕方について説明する。
【００９６】
図１１は、共有マスクモード決定論理を示す図で、同図（ａ）は、複数のＣＰＵモジュールにより出力点の共有及び競合がある場合すなわち共有マスク有りモードを示し、同図（ｂ）は共有及び競合が無い場合すなわち共有マスクデータ無モードの例を示す。同図（ａ）はＣＰＵ０〜２の３つのＣＰＵモジュールが出力モジュールＤＯ０及びＤＯ１にデータを送信する際、データ共有を行う場合に共有マスク有りのモードの決定を例としたもので、１６点の出力点を持つ１つのＤＯモジュールに対する１６ビットの共有マスクデータをＣＰＵの使用ビットとして示している。
【００９７】
図１１（ａ）の出力モジュールＤＯ０の場合、ビット０がＣＰＵ１とＣＰＵ２、ビット１０がＣＰＵ０とＣＰＵ２、ビット１３がＣＰＵ１とＣＰＵ２、及びビット１５がＣＰＵ０とＣＰＵ１で共有マスクに“１”が設定され、これらに対応するＤＯ０の出力点が競合されていることが分る。よってＣＰＵモジュールＣＰＵ０、ＣＰＵ１及びＣＰＵ２は出力モジュールＤＯ０にデータを送信し出力点の出力状態の変更を行う時は、共有有りモードとして図９（２）に示した様な共有マスクデータを含むフレームをマルチキャストフレームとして送信する。
【００９８】
また同図（ａ）において出力モジュールＤＯ１の場合は、同一ワードにおいて、ＣＰＵ０がビット１３，１４，１５を使用し、ＣＰＵ１がビット１０，１１，１２を使用し、ＣＰＵ２がビット０，１，２を使用しており、３台のＣＰＵで共有されている。そして各ＣＰＵモジュールは出力モジュールＤＯ１にデータを送信する時は、共有マスク有りモードとして、ＣＰＵ使用ビットに対応する共有マスクデータを出力データと共に送出する。
【００９９】
また同図（ｂ）のＤＯ２の場合、ＣＰＵ０のみがＤＯ２の全ビットを使用しており、ＣＰＵ１とＣＰＵ２はＤＯ２を一切使用していない。すなわちＤＯ２はＣＰＵ０のみの制御下の出力モジュールであり、ＣＰＵ０は共有無しモードとして図９（１）に示したような共有マスクデータを含まないフレームをマルチキャストフレームとして出力モジュールＤＯ２に送信する。
【０１００】
図１２は、第２の実施形態でのＣＰＵモジュールによる共有マスクデータの制御例を示す図である。同図は図１１の出力条件で、ＣＰＵ０がＤＯ０の出力制御を行う場合の共有マスクの制御動作を例として示したものである。
【０１０１】
ＣＰＵモジュールＣＰＵ０では、出力モジュールＤＯ０に対して、図１２に示すように固定共有マスクレジスタ５１及び出力条件共有マスクレジスタ５２をＯＲ回路５３の入力に、その出力をシリアルリンク出力共有マスクレジスタ５４に接続して備えている。固定共有マスクレジスタ５１は、ＣＰＵモジュールで動作するＯＳによって操作されるもので、他のＣＰＵモジュールと競合せずにＣＰＵ０のみが用いる出力点に対応するビットに“１”がセットされる。この固定共有マスクレジスタ５１の値は、そのＤＯモジュールの出力点の共有状態の変更が無ければ、固定的にセットされたままである。出力条件共有マスクレジスタ５２は、ＣＰＵモジュールがＤＯモジュールに出力変更を行う出力点を設定するレジスタで、出力条件が整った出力点に対応するビットに“１”が出力条件判定部５５によってセットされる。シリアルリンク出力共有マスクレジスタ５４は、マルチキャストフレームに格納して送信する共有マスクデータを格納するレジスタである。
【０１０２】
ＣＰＵ０がＤＯ０を出力制御する場合の共有マスクデータ生成の制御動作処理を以下に示す。
▲１▼ＣＰＵ０は、ＤＯ０のビット１、２を他のＣＰＵモジュールと競合せずに使用するため、予めＯＳ処理によってＤＯ０用の固定共有マスクレジスタのビット１及び２に“１”をセットしておく。
▲２▼ＣＰＵ０は、競合出力点に対する出力条件判定を行い、出力条件が成立した場合出力条件判定部５５がＤＯ０出力条件成立共有マスクレジスタ５２の対応ビットに“１”をセットする。同図の場合、ビット１５に対応する出力点で出力条件が成立したのでビット１５に“１”をセットする。
▲３▼ＤＯ０用の固定共有マスクレジスタ５１と出力条件成立共有マスクレジスタ５２の値のＯＲ値を取り、結果をＤＯ０用のシリアルリンク出力共有マスクレジスタ５４にセットする。この場合ビット１，２，１５に“１”がセットされた値がシリアルリンク出力共有マスクレジスタ５４にセットされる。そしてこのシリアルリンク出力共有マスクレジスタ５４内のデータは、共有マスクデータとしてマルチキャストフレームにより出力データと共にＤＯ０に送信される。ＤＯ０では図１０に示した共有及び競合制御回路４０により、共有及び競合制御として共有マスクデータからビット１、２、１５に対応する出力点の出力をＣＰＵ０からの出力データに基づいて変更する。尚ビット１０に対応する出力点もＣＰＵ０は出力制御を行っているが、今回は出力条件が成立しなかったため、出力は前回値のまま保持される。
【０１０３】
ところで一般に、マルチＣＰＵシステムのプログラマブルコントローラにおいては、各ＣＰＵで担当するリソースを完全に分け機能分散した構成の場合では、入出力の共有・競合は起こらないが、本来１つのＣＰＵでシステム制御するところを、プログラム容量の増大への対処、並列処理による処理性能の向上などの理由でマルチＣＰＵを採用する場合入出力モジュールを複数のＣＰＵで共有することとなる。そしてこの場合、１台の入出力モジュールに対して、複数のＣＰＵが書込み処理を行う競合ＷＴ（書込み）を行う場合がある。その場合のプログラム開発においてユーザは、競合制御を意識してプログラムソースを作成、変更するようなわずらわしさが有ってはならない。また、競合ＷＴが行われると複数のＣＰＵのプログラムで、同じＤＯモジュールの同一アドレスに対する書込みが行われることとなるが、このアドレス重複が競合書込みによるものなのか、プログラム作業の誤り等によるものかチェックが容易に出来ることが要求される。
【０１０４】
これに対応するため本発明では、複数のＣＰＵで共有されている出力点への書込みに対し、競合制御を行う競合ＷＴ命令を持ち、またユーザはこの競合ＷＴ命令を意識して用いなくても、アプリケーションプログラム開発装置（以下ローダという）が自動的に競合ＷＴ命令を生成する機構を備える。
【０１０５】
図１３に基本的な競合ＷＴ命令例を示す。同図ではユーザ記述プログラム例として、基本的なＷＴ命令のラダー表示、それをコーディングした通常命令表示であるＳ（セット）、Ｒ（リセット）、Ｗ（ライト）及びそれぞれに対応する競合ＷＴ命令ＫＳ（競合セット）、ＫＲ（競合リセット）、ＫＷ（競合ライト）を示している。
【０１０６】
各ＷＴ命令の基本動作を以下に示す。

Figure 0004123660
となる。
【０１０７】
図１４にローダによる競合ＷＴ命令生成処理例を示す。
図１４（ａ）に示すように、ローダは、ローダ処理として各ＣＰＵモジュールの実行オブジェクトを生成するに際し、マルチＣＰＵシステムを構成する全てのＣＰＵモジュール（同図ではＣＰＵ０、ＣＰＵ１、ＣＰＵ２）のソースプログラムを参照し、異なるＣＰＵによって同じ入出力モジュールの同一出力点への出力、即ち同じ出力アドレスへの書込みが行われいる部分を調べる。そして、同じアドレスに対し複数のＣＰＵが書込みを行っている箇所を検出すると、そのＣＰＵのソースプログラム中のＷＴ命令を図１３に示したような競合ＷＴ命令に変換された後、実行オブジェクトを生成する。
【０１０８】
図１４（ｂ）の場合、ＣＰＵ０とＣＰＵ１のプログラム中、出力モジュールＤＯ０のビット１５に対しての書込みが競合しているため、ローダはＣＰＵ０とＣＰＵ１のソースプログラム中のビット１５に対するＷＴ命令を競合ＷＴ命令（ＫＷ）に置換えている。尚、ＣＰＵ０のＤＯ０ビット２に対する書込みとＣＰＵ１のＤＯ０のビット１０に対する書込みは他のＣＰＵと競合していないので、通常のＷＴ命令（Ｗ）のままとなっている。
【０１０９】
また、同一アドレスへの書込みは、その出力点を複数のＣＰＵモジュールが競合使用しているために発生する場合と、プログラミング作業の誤り等によるユーザの認識外の要因によって発生した場合が考えられる。よって、後者の要因によるものを排除するために、ローダは上記競合ＷＴ命令への置換を行う前にユーザに対してアドレスの重複を警告する競合ＷＴのワーニング通知を行う。
【０１１０】
図１５はローダによる競合ＷＴのワーニング通知例を示す図である。
このワーニング通知の方法としては、同図（ａ）に示すように、ソースプログラムレベルで表示し、競合が発生した出力命令部分を他の表示部分と表示色を替えたり、あるいは点滅表示したりして強調する方法がある。同図の場合、通常表示部分が白色で表示されているのに対し、競合が発生した書込み命令部分を赤色で表示してユーザに通知している。
【０１１１】
またワーニング通知の別方法としては、同図（ｂ）に示すように競合制御箇所をプログラムの行番号と命令種類をリスト形式で示す方法がある。
ユーザは、これらのワーニング通知からプログラムの誤りを検出することが出来る。以上の説明で、出力モジュールとしてデジタル出力モジュール（ＤＯモジュール）を例として説明したが、アナログ出力モジュール（ＡＯモジュール）においても、共有及び競合制御の考え方は全く同じであり、ただ共有マスクデータが出力データ、例えば１ワードに対して１ビットで対応することで実現することが出来る。例えば４ワードＡＯモジュールにおいて、１ワード目はＣＰＵ０が使用し、２ワード目はＣＰＵ１が使用し、３、４ワード目はＣＰＵ２が使用する場合は、共有が行われ共有マスク有りモードとなり、４ワードデータに対して４ビットの共有マスクデータで制御されることとなる。また出力モジュールにおける共有及び競合制御回路は、単純なＡＮＤ及びＯＲ回路でなくセレクタ及び中間値データ生成及び平均値データ生成回路などで実現することも出来る。
【０１１２】
【発明の効果】
本発明に基づくプログラマブルコントローラによれば、出力モジュールの出力状態をＣＰＵモジュールに知らせるために、新たに入力モジュールを設ける必要が無い。
【０１１３】
また、出力モジュールでは各ＣＰＵモジュールから出力データと共に送信されてくる共有マスクによって各ＣＰＵモジュールによる出力データの共有及び競合制御を行うことが出来る。
【０１１４】
更にＣＰＵモジュールでは、ＣＰＵモジュールが出力モジュールの出力状態を誤認識する等の問題を生じることが無く、出力モジュールに対する出力データと参照出力に対して同じアドレスを設定することが出来る。よって、出力モジュールにデータを出力する時も、出力状態を参照する時も同じアドレスを用いることが出来るので、プログラミングに混乱を招かない。これはアプリケーションプログラミングに拠るデータの入出力処理を簡易化することが出来、プログラムの簡略化や処理速度の向上を実現できる。
【０１１５】
また共有及び競合制御を必要としない出力データの場合には出力データと共に共有マスクを出力モジュールに送信しない構成とした場合には、単一ＣＰＵシステムと同様の通信負荷となり、システム性能を向上することが出来る。すなわち、単一ＣＰＵシステムにおいても、本発明は上記共有マスク無しモードでそのまま使用可能である。
【０１１６】
更にマルチＣＰＵのプログラマブルコントローラのプログラム開発に於て、ユーザは、競合制御を行う場合でも、通常の入出力モジュールへの書込み命令を記述すれば、ローダが複数のＣＰＵのプログラムを参照して自動的に競合制御専用の命令に変換する。またこの変換部分は、ユーザに通知されるので、ユーザは競合を意識してアドレスを重複させてたのか、誤ってアドレスを重複させたのかを容易に確認でき、マルチプロセッサシステムにおけるプログラミング開発効率及びプログラムの品質を向上することが出来る。
【図面の簡単な説明】
【図１】本実施形態におけるＤＯモジュールの概略を示す図である。
【図２】トータルフレーム方式による通信の説明図である。
【図３】マルチキャスト方式による通信の説明図である。
【図４】ＤＯモジュールの競合制御回路を詳細に示す図である。
【図５】ＣＰＵモジュールの入出力処理の為の構成要素を示す機能ブロック図である。
【図６】ＣＰＵモジュールで作られる共有マスクの例を示す図である。
【図７】マルチキャストフレームの構成例を示す図である。
【図８】２つのＣＰＵモジュールがＤＯモジュールを共有している場合の各モジュール及びバス上での入出力の状態例を示すタイミング図である。
【図９】第２の実施形態でのマルチキャストフレームの構成例を示す図である。
【図１０】第２実施形態における競合制御回路を詳細に示す図である。
【図１１】各ＣＰＵモジュールで行われる共有マスクモード決定論理を示す図である。
【図１２】第２の実施形態でのＣＰＵモジュールによる共有マスクデータの制御例を示す図である。
【図１３】基本的な競合ＷＴ（書込み）命令例を示す図である。
【図１４】ローダによる競合ＷＴ命令生成処理例を示す図である。
【図１５】競合ＷＴのワーニング通知例を示す図である。
【図１６】バスに複数のＣＰＵモジュールやＤＩモジュール及びＤＯモジュールを接続したマルチＣＰＵ構成のプログラマブルコントローラを示す図である。
【図１７】ＤＩモジュールによるＤＯモジュールの出力の折り返し入力の例を示す図である。
【図１８】各モジュール及びバス上での出力データの様子を示すタイミング図である。
【図１９】従来のＣＰＵモジュールの入出力処理の為の機能ブロック図である。
【図２０】ＤＯモジュールへの出力データの転送元アドレスとＤＩモジュールからの入力データの転送先アドレスを同じにした場合の各モジュール及びバス上での入出力の状態を示すタイミング図である。
【符号の説明】
１、１０１ シリアルリンクバス
２、１０２ ＣＰＵモジュール
３、１０３ ＤＯモジュール
１０、４０ 共有及び競合制御回路
１１ 共有マスク
１２ 出力データ
１３、１４、４５ ＡＮＤ回路
１５、４４、５３ ＯＲ回路
１６ 参照出力ラッチ
２１ 演算実行部
２２ Ｉ／Ｏ領域
２３ 出力バッファ
２４ 入力バッファ
２５ シリアルリンク制御部
２６ 入力バッファ転送テーブル
２７ 入力データ転送テーブル
２８ 共有マスクデータ領域
４１ 共有マスク有効モード記憶レジスタ
４２ 新規受信有り記憶レジスタ
４３ ＮＯＴ回路
５１ 固定共有マスクレジスタ
５２ 出力条件共有マスクレジスタ
５４ シリアルリンク出力共有マスクレジスタ[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a programmable controller, and more particularly to data output sharing and contention control in a programmable controller.
[0002]
[Prior art]
A programmable controller having a multi-CPU configuration in which a plurality of CPU modules 102, a DO (output) module 103, and a DI (input) module 104 are connected to a bus 101 such as a serial link bus as shown in FIG.
[0003]
In such a programmable controller, when a plurality of CPU modules 102-1 to 102-m share an output point of one DO module 103 and perform output, each CPU module 102 sharing this output point It cannot be determined whether the output state of the DO module 103 is currently ON (= “1”) or OFF (= “0”). For example, in FIG. 16, even if the CPU 102-1 turns off the output state of one output point of the DO module 103-1, the other CPU modules 102-2 to 102-m cannot know this. For example, when the shared DO module 103-1 is used as an emergency stop signal, any one of the CPU modules 102-1 sets an emergency stop signal in the DO module 103-1, and this is used as another CPU module. In an application or the like that 102-2 to 102-m recognizes and performs an appropriate process and resets the emergency stop signal, the CPU module 102-1 that has set the emergency stop signal thereafter uses the emergency stop signal as the emergency stop signal. On the other hand, the other CPU modules 102-2 to 102-m do not take any countermeasures to know whether or not the emergency stop state has been avoided, which is a problem.
[0004]
For this reason, the DI module 106 is separately added for monitoring the output of the DO module 103 as shown in FIG. 17, and the output of the DO module 103 is input to the DI module 106 in a folded manner. Then, the CPU module 102-1 that outputs “0” to the DO module 103-1, whether the output is set to “1” by the other CPU modules 102-2 to 102-m, etc. -M refers to the output of the DI module 106 in order to know the current output state of the DO module 103-1.
[0005]
FIG. 17 shows an example of the return input of the output of the DO module 103 by the DI module 106. In FIG. 17, the output from each output point 105 of the DO module 103-1 for which the station number 0 is set as the station address on the bus 101 is input to the input point 107 of the DI module 106 for which the station number 1 is set. ing. When outputting data to the DO module 103-1, the task on each CPU module 102 sharing the DO module 103-1, addresses and outputs the DO module with the station number 0, and also outputs the DO module 103-1. To obtain the output state, the DI module with the station number 1 is addressed and data from the DI module 106 is obtained.
[0006]
FIG. 18 shows the state of output data on each module and bus in the configuration of FIG.
Data transfer in the programmable controller is performed at a constant interval cycle at the same speed as the transfer speed in the serial link bus 1. An interrupt is input to the arithmetic execution unit in the CPU module 102 at the same cycle as this data transfer. This cycle is called a tact cycle and is indicated by a vertical dotted line in FIG. Each module performs processing in synchronization with this tact cycle.
[0007]
Output data to the DO module 103 generated by the arithmetic processing performed by the arithmetic execution unit 201 of the CPU module 102 is stored in the corresponding address area of the I / O area in the CPU module 102. Then, this data is transmitted and output as frame data on the bus 101 via the output buffer.
[0008]
The DO module 103 with the station number 0 receiving this frame changes the output state of each output point based on this received data. Since the output of the DO module 103 is input to the DI module 106 of the station number 1, the output state of the DO module 103 is transmitted and output as frame data on the bus 101 by this DI module 106. 102 is stored in an address area corresponding to station number 1 in the I / O area 102.
[0009]
FIG. 19 shows a functional block diagram for input / output processing of the CPU module.
In the CPU module 102, there are an arithmetic execution unit 201, an I / O area 202, an output buffer 203, an input buffer 204, a serial link control unit 205, an output data transfer table 206, as components for performing data input / output control An input data transfer table 207 is provided.
[0010]
The serial link control unit 205 captures data necessary for its own station from the frame transmitted from the bus 101 into the input buffer 204 and flows it to the module of the downstream station. The data fetched into the input buffer 204 is transferred to the I / O area 202 by referring to the input data transfer table 207 corresponding to the task when the task is activated.
[0011]
The I / O area 202 is a memory area that can be directly accessed by each task of a plurality of application programs being executed by the own station. The arithmetic execution unit 201 that performs program processing can be accessed from within the I / O area 202 by itself. Read the required data.
[0012]
Further, when the arithmetic execution unit 201 outputs data to the DO module, it writes the output data to the corresponding address area of the I / O area 202. When task processing is performed, only data assigned to the task is transferred from the I / O area 202 to the output buffer 203 based on the output data transfer table 206 during output processing. Then, the serial link control unit 205 outputs this to the bus 101 as frame data.
[0013]
[Problems to be solved by the invention]
When the output of the DO module 103-1 is turned back by the DI module 106 as shown in FIG. 17, a separate DI module must be added for this purpose.
[0014]
Further, the application program executed by each CPU module 102 must use an address different from the station address of the DO module 103-1, in order to know the output state of the DO module 103-1. Therefore, application programming is complicated.
[0015]
In each CPU module 102, the station address of the DI module 106 for output monitoring of the DO module 103-1 must be set on the I / O area 202. In the programmable controller, since the size of the I / O area 202, that is, the total number of modules that can be connected is limited, if the DI module 106 is used to monitor the output state of the DO module 103-1, one DO module Therefore, two addresses are used, and resource utilization efficiency is poor.
[0016]
Further, the CPU module 102 copies input data from the input buffer 204 to the I / O area 202 according to the input data transfer table 207 in the data input process from the bus 101, and in the output process, the I / O area 202 according to the output data transfer table 206. The output data is copied from the / O area 202 to the output buffer 203. Therefore, the transfer source address of the output data set in the DO module 103-1 with the station number 0 in the output data transfer table 206 and the input data transfer destination set in the DI module 106 with the station number 1 in the input data transfer table 207. By making the addresses the same, the output state of the DO module 103-1 via the DI module 106 can be input to the same address area as the output destination to the DO module 103-1 in the I / O area 202. However, when the same address area of the I / O area 202 is assigned to input data and output data to the DO module 103-1, there is a problem shown in FIG.
[0017]
FIG. 20 shows each module and bus when the transfer source address of output data to the DO module 206 in the output data transfer table is the same as the transfer destination address of input data from the DI module 207 in the input data transfer table. It is a timing diagram which shows the state of input / output in.
[0018]
Assume that the calculation execution unit 201 outputs OUT2 as output data to the DO module 103 in the I / O area 202 in the tact cycle A of FIG. However, in the next tact cycle B, OUT1 which is the previous output state enters before the return output from the output of OUT2 is transferred to the I / O area 202. If OUT2 is “1” output from the CPU module as an emergency stop signal and OUT1 is “0”, refer to the I / O area 202 to obtain the output state of the DO module in the next tact cycle B. Then, since it becomes OUT1 (“0”), the application program erroneously recognizes that the output of the DO module has been reset to “0” by another CPU.
[0019]
In general, in a programmable controller having a multi-CPU configuration, in the case of a configuration in which resources assigned to each CPU are completely divided and functions are distributed, input / output sharing and contention do not occur, but the system control is originally performed by one CPU. When a multi-CPU is employed for reasons such as dealing with an increase in program capacity and improving processing performance by parallel processing, one input / output module is shared by a plurality of CPUs. In this case, competitive writing in which a plurality of CPUs perform writing processing may be performed on one input / output module. In the program development in that case, the user has the trouble of creating and changing the program source in consideration of the competition control. In addition, when competing writing is performed, a program of a plurality of CPU modules will write to the same address of the same output module. Whether this address duplication is due to competing writing or due to an error in program work, etc. It is required that it can be easily checked.
[0020]
In the present invention, in view of the above problems, when a plurality of CPU modules share a DO module, the output of the DO module shared by each CPU module is provided without providing a DI module for monitoring the output of the DO module. It is an object of the present invention to provide a programmable controller and an application program development device capable of knowing the state.
[0021]
[Means for Solving the Problems]
The programmable controller according to the present invention is premised on including a plurality of CPU modules and at least one output module.
[0022]
Each of the CPU modules includes a shared mask generation unit and an output data transmission unit.
The shared mask generation means generates a shared mask that instructs the output module whether to change the output state.
[0023]
Output data for the output data transmitting means and the output module are transmitted together with the shared mask.
The output module includes output data receiving means and sharing and contention control means.
[0024]
The output data receiving means receives the output data from the CPU module together with the shared mask.
The sharing and contention control means determines an output state from the output data from the CPU module, for example, a plurality of CPU modules sharing the same, and the sharing mask.
[0025]
The output module further includes reference output transmission means for transmitting a reference output indicating the output state to the plurality of CPU modules sharing the self, and the CPU module stores the shared mask generated by the shared mask generating means. And a shared mask storage means for generating, and an output state reference data generating means for generating reference data indicating an output state of the output module from the shared mask stored in the shared mask storage means and the reference output from the output module. It is good also as a structure provided.
[0026]
Further, when the output data transmitting means does not need to perform sharing control and competition control with the output data from other CPU modules for the output data in the output module for transmitting the output data, when transmitting the output data, The shared mask may be configured not to transmit the output data. In this case, for example, the CPU module further includes data transfer mode control bit generating means for generating a data transfer mode control bit for notifying whether or not the shared mask is transmitted together with the output data, and the output data transmitting means includes the output data transmitting means. A data transfer mode control bit is transmitted with the output data, and the sharing and contention control means of the receiving output module indicates that the data transfer mode control bit indicates that the shared mask is not transmitted with the output data. The output state is determined only from the output data.
[0027]
An application program development device for a programmable controller according to the present invention comprises program reference means and contention write instruction generation means.
The program reference means refers to the programs of all the CPU modules constituting the programmable controller having a multi-CPU configuration.
[0028]
If the plurality of CPU modules include an instruction indicating output to the same output point of the same output module in the program as a result of the reference, the contention write instruction generation unit converts the instruction into an instruction for competitive writing. The application program development device further includes warning notification means for notifying the user of the portion to be converted into the contention write instruction.
[0029]
According to the present invention, each CPU module transmits a sharing mask together with output data to the output module, and the output module performs output sharing and contention control based on the contents of the sharing mask.
[0030]
Each CPU module generates reference data from the reference output transmitted by the reference output transmission unit of the output module and the shared mask stored in the shared mask storage unit by the output state reference data generation unit. You can know the output status.
[0031]
Further, since the reference data is generated from the reference output from the output module and the shared mask stored in the shared mask storage means, the CPU module can store the output information to the output module and the reference data in the same address area. .
[0032]
Further, when sharing and contention control are not required, the traffic volume can be reduced if the CPU module does not transmit the sharing mask to the output module together with the output data.
[0033]
Also, according to the application program development apparatus of the present invention, a write command that becomes a competitive write without being conscious of the user is converted into a competitive write command. Further, the user is notified of the part that is converted into the competitive write instruction.
[0034]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a diagram showing an outline of a programmable controller in the present embodiment. In the programmable controller in the present embodiment, it is assumed that the three CPU modules 2-1 to 2-3 share one DO module 3.
[0035]
When the DO module 3 receives the output data transmitted from each CPU module 2 via the serial link bus 1, the sharing and contention control circuit 10 changes the output state from the output point based on the received data. At the same time, data indicating the current output state is transmitted to each CPU module 2 as a reference output.
[0036]
In this embodiment, data transfer between the CPU module 2 and the DO module 3 is performed by the total frame method and the multicast method disclosed in Japanese Patent Application No. 10-148648 by the applicant of the present invention. And
[0037]
FIG. 2 is an explanatory diagram of data communication by the total frame method.
In this embodiment, one of the stations of the serial link bus 1 is a ring master station, and this ring master station manages data transfer by a total frame method and a multicast method described later. In FIG. 2, it is assumed that the ring master station, the A station, the B station, the C station, and the D station are connected to the serial link bus 1 in this order.
[0038]
In the total frame method, a REQ frame representing a total frame transmission request is first transmitted by a ring master station that exists only on the network. In FIG. 2, the REQ frame at this time is represented as req0.
[0039]
In this REQ frame, data indicating that this frame is a REQ frame is set in a delimiter portion (start delimiter (SD) portion) of the frame, and the receiving station of this frame checks this frame by examining the SD portion. Is a REQ frame.
[0040]
The station that has received the REQ frame adds its own data to the end of the frame and transmits it to the adjacent downstream station. In the case of FIG. 2, when the A station receives the REQ frame, it adds its own output data Da to the end thereof and transmits it to the B station of the downstream station. When station B receives this frame, it adds its output data Db to its end and outputs it. Thereafter, each station sequentially receives its frame and adds its own data to the end of the frame and transmits it to the downstream station. In this embodiment, a multi-CPU configuration using a plurality of CPU modules 2 is used, and the DO module can also refer to the data output from other CPU modules 2 to the DO module. Data is being output. However, this is not necessary in the case of a programmable controller configuration having only one CPU module.
[0041]
When the REQ frame makes a round on the serial link bus 1 and is received by the ring master station, the ring master station uses the data set in the start delimiter (SD) portion of this frame as the second REQ frame. The data indicating this is changed, and its own data is added to the end of the frame and transmitted to the station A which is the next downstream station.
[0042]
Upon receiving this frame, the station A checks the SD part of the received frame and recognizes that this is the second round REQ frame. Delete data and relay to downstream station. In the case of FIG. 2, when the station A receives the second REQ frame, the station A deletes its own data Da added by itself in the first round and transmits it to the station B of the downstream station. It deletes its own output data Db next to the SD part and transmits it to the next downstream station C. Thereafter, each station sequentially receives the frame and deletes its own data added in the first round from the frame and transmits it to the downstream station.
[0043]
When the second REQ frame circulates through the serial link bus 1 and returns to the ring master station, the ring master station removes the frame from the serial link bus 1. This completes the total frame communication.
[0044]
Next, data transfer by the multicast method will be described.
The multicast method is a data transfer method used when data is output from the CPU module 2 to the DO module 3.
[0045]
In the multicast method, a free token for multicast communication is circulated on the serial link bus 1 and a station requesting data transmission (transmission data to be output to the DO module is prepared, and transmission permission setting of the transmission band is set. The station that has received the free token secures the free token and transmits a multicast frame instead. The multicast frame circulates on the serial link bus 1, and the station on the network that receives the multicast frame relays it downstream and circulates, and captures data based on the setting contents of the output data in the frame. .
[0046]
FIG. 3 is an explanatory diagram of communication by the multicast method.
In communication by the multicast method, first, a ring master station that performs network management, which exists only on the serial link bus 1, generates a free token that controls the authority of data transfer and releases it on the serial link bus 1. Multicast communication is started by the release of this free token.
[0047]
The released free token is sequentially relayed to the downstream station by each station and circulates on the serial link bus 1. When the CPU module 2 that wants to output data receives this free token, it secures it from the serial link bus 1 and becomes a master station.
[0048]
The master station sends the prepared transmission data on the serial link bus 1 as a multicast frame in which data indicating that this frame is a multicast communication frame is set in the SD unit. In FIG. 3, the master station uses the output data for the two stations of the output data for the A station (M → Da) and the output data for the B station (M → Db) as a multicast frame instead of the stored free token. To B.
[0049]
The station that has received this multicast frame refers to the station number of the output data storage destination set in the output data in that frame, and if this output data is for its own station, takes it in and Is transmitted to the downstream station as it is. In FIG. 3, the A station and B station that have received the multicast frame take the output data (M → Da, M → Db) output to the own station and output from the master station, and receive the received frame as it is downstream. Transmit to the ring master station and the master station.
[0050]
When the frame has made one round, the master station that first transmitted the frame removes it from the serial link bus 1, generates a free token instead, and releases it on the serial link bus 1.
[0051]
When the free token returns once through the serial link bus 1, the ring master station checks whether there is a data transmission request, and if there is a request, the transmission data [output data for the A station (RM → Da), Output data (RM → Db)] is transmitted to station B. Thereafter, the data frame transmitted by the local station makes one round of the serial link and returns to the local station, so that the ring master station removes the free token from the serial link, and the multicast communication ends.
[0052]
Hereinafter, data transfer when data is transmitted from the DO module 3 to the CPU module 2 is performed by a total frame method. Data transfer when outputting data from the CPU module 2 to the DO module 3 is performed by a multicast method. In the present invention, data transfer between modules is not limited to the total frame method and the multicast method. The data transfer by the total frame method and the multicast method is based on the premise that the modules are connected by a ring-type transmission topology bus, but the bus connecting the modules in the programmable controller to which the present invention is applied. Is not limited to a serial bus having a ring topology, and may be configured such that modules are connected by another topology or a parallel bus.
[0053]
FIG. 4 shows the sharing and contention control circuit 10 of the DO module 3 in detail.
In the figure, the lowermost stage shows a frame transmitted on the serial link bus 1, and the CPU module 2 follows the frame by the total frame system from the DO module 3 to each of the CPU modules 2-1 to 2-3 during one tact cycle. -The frame by the multicast system from 1, 2-2 and 2-3 follows. In the figure, “message” indicates a time band for message transfer performed between the CPU modules 2 or between the CPU module 2 and the communication module.
[0054]
Each CPU module 2-1 to 2-3 stores the shared mask together with the output data for the DO module 3 in the transmission frame, and transmits it to the DO module 3 by the multicast method. This shared mask specifies for each output point whether or not each CPU module 2 changes the output state with respect to the DO module 3, and each CPU module 2 outputs the output of the plurality of output points of the DO module 3. The shared mask bit corresponding to the output point whose state is to be changed is set to “1”, the bit corresponding to the output point not to be changed is set to “0”, and the data is transmitted to the DO module together with the output data.
[0055]
When the DO module 3 receives a multicast frame from all of the CPU modules 2-1 to 2-3 that share the frame, it transmits the shared mask data 11 and output data 12 in the frame, and the reference output latch 16 A new output is obtained from the logical result of the current output state of itself.
[0056]
In the DO module 3, when the shared mask 11 and the output data 12 are extracted from the frame from the CPU module 2, these values are ANDed by the AND circuit 13 for each CPU module 2. The AND circuit 14 obtains the AND value of the inverted value of each of the shared masks 11-1 to 11-3 and the output of the reference output latch 16.
[0057]
Then, an OR value of the outputs of the AND circuits 13-1 to 13-3 and the output of the AND circuit 14 is obtained by the OR circuit 15, and this is used as a new output of the output point. The output of the OR circuit 15 is stored in the reference output latch 16 and used to determine the next output, and is also output on the serial link bus by the total frame method to be output to the CPU modules 2-1 to 2-3. To be notified. As a result, for example, the output points corresponding to the bits for which the shared mask data 11-1 to 11-3 from all the CPU modules 2 are “0” hold the previous output state. When the shared mask data 11 from the plurality of CPU modules 2 is “1” and the output data 12 includes both “1” and “0”, “1” is prioritized, and the corresponding output point “1” is output.
[0058]
FIG. 5 is a functional block diagram showing components for input / output processing of the CPU module 2.
In the CPU module 2, as components for performing data input / output control, an arithmetic execution unit 21, an I / O area 22, an output buffer 23, an input buffer 24, a serial link control unit 25, an output data transfer table 26, An input data transfer table 27 and a shared mask data area 28 are provided.
[0059]
When it becomes necessary to output data from the calculation result to the DO module, the calculation execution unit 21 that performs the program processing writes the output data to the address area corresponding to the DO module in the I / O area 22. When the task process is performed, only the data assigned to the task is transferred from the I / O area 22 to the output buffer 23 based on the output data transfer table 26 when the output process is performed. Is output to the serial link bus 1 as frame data.
[0060]
The I / O area 22 is a memory area that can be directly accessed by each task of a plurality of application programs executed in the own station, and is configured on the internal memory of the CPU module. The operation execution unit 21 reads data from other modules required by itself from the corresponding address area in the I / O area 22 and outputs the output data to the corresponding address area when outputting to other modules. Write. In each CPU module 2, input modules and output modules that it corresponds to are associated with each address area in the I / O area 22 in the output data transfer table 26 and the input data transfer table 27 in a 1: 1 ratio. is there. Therefore, for example, when the I / O area 22 has addresses from 0H to FFH, the CPU module 2 can exchange data with 256 input / output modules. The position of each bit in each address area corresponds 1: 1 to the input / output point of each input / output module. For example, when one word is 8 bits, one address area corresponds to 8 input / output points. Can exchange data.
[0061]
The output buffer 23 is a buffer for accumulating output data for each station to be output, together with an output destination station number, data size, and shared mask. When the task processing is completed, output data generated by the task processing is transferred from the I / O area 22 to the output buffer 23 based on the output data transfer table 26 during the output processing. The data in the output buffer 23 is output on the serial link bus 1 by the serial link control unit 25 at a tact cycle regardless of the processing by the arithmetic execution unit 21. Through such a series of operations, each module connected to the serial link bus 1 can operate using common data during a certain period (tact period).
[0062]
The input buffer 24 is a buffer for taking in data necessary for the own station from data flowing from the upstream station. The data received from the serial link bus 1 is stored in the input buffer 24 from the serial link control unit 25 at the same cycle cycle as the transfer cycle of the serial link bus 1. Then, when the task is activated, the input data transfer table 27 corresponding to the task is referred to, and data required by the task is transferred from the input buffer 24 to the I / O area 22.
[0063]
The serial link control unit 25 takes the frame transmitted from the serial link bus 1 into its own reception buffer, sends it to the downstream station if it is not for its own station, and inputs it if it is for its own station. The data is taken into the buffer 24 and sent to the downstream station module. As a result, the frame data circulates in a certain direction on the serial link bus 1. When receiving the multicast token, the serial link control unit 25 DMA-transfers the data in the output buffer 23 onto the serial link bus 1 as a multicast frame.
[0064]
The output data transfer table 26 associates the station address on the bus 1 of the module serving as the output destination with the address of the I / O area 22. The output data transfer table 26 exists for each task, and is referred to when the operation execution unit 21 transfers the output data output to the DO module from the I / O area 22 to the output buffer 23 by the task processing. When one task process is completed, the operation execution unit 21 refers to the output data transfer table 26 during the output process, and transfers only the data assigned to the task from the I / O area 22 to the output buffer 23.
[0065]
The input data transfer table 27 associates the station address on the bus of the module that is the input partner with the address of the I / O area 22, and transfers data from the input buffer 24 to the I / O area 22. It is what is referred to when. There are a plurality of input data transfer tables 27 for each task, and the address in the input buffer 24 of the data used by the task, the address of the I / O area 22 and the data size are stored. When data is transferred from the input buffer 24 to the I / O area 22 when the task is activated, the input buffer is used before the task is activated using the input data transfer table 27 corresponding to the task. Only data used by the task is transferred from 24 to the I / O area 22.
[0066]
The shared mask data area 28 is a storage area having the same configuration as the I / O area 22 and is configured on the internal memory of the CPU module. The operation execution unit 21 generates a shared mask in the shared mask data area 28. This shared mask is transferred to the output buffer 23 together with the output data of the same address in the I / O area 22 and transmitted to the corresponding DO module 3.
[0067]
This shared mask is held in the shared mask data area 28 even after being transmitted to the DO module. When a reference output for notifying its own output state from the DO module 3 is received, transfer from the input buffer 24 to the I / O area 22 is performed based on the shared mask in the address area corresponding to the DO module. . When the transfer input process to the I / O area 22 is completed, the corresponding shared mask is reset to “0”. This point will be described later.
[0068]
FIG. 6 is a diagram showing an example of a shared mask created by the CPU module.
The arithmetic execution unit 21 generates shared mask data in the shared mask data area 28 together with the output data when it is necessary to change the output state of the DO module from the result of the task processing. This shared mask data is a plurality of bits of mask data in which each bit has a 1: 1 correspondence with the output point of the DO module. Among the output points of the DO module, the bit corresponding to the output point whose output state is changed is “1”. The bit corresponding to the output point not changed is set to “0”.
[0069]
The shared mask shown in FIG. 6 is an example of an 8-bit configuration, and sharing and contention control are performed for eight output points based on the data of the shared mask. In FIG. 6, the output data to be output to the DO module is changed from “1” to “0” and bit 4 is changed from “0” to “1”. Data is generated in which bit 0 and bit 4 whose output states are changed are set to “1”, and other bits which are not changed are set to “0” and stored in the shared mask data area 28.
[0070]
When the CPU module 2 receives the reference output of the total frame from the DO module 3, it stores it in the input buffer 24 and then transfers it to the corresponding address area of the I / O area 22 based on the input data reference table 27. However, at this time, not all data is transferred to the I / O area 22, and transfer is performed bit by bit with reference to the shared mask in the shared mask area 28 in the same address area as the I / O area 22. Whether or not to transfer data exclusively.
[0071]
The reference output of the bit for which “1” is set in the shared mask indicates the output state of the output point where it has instructed the DO module to change the output, as in bits 0 and 4 in FIG. The received data has not yet reflected this change. Therefore, if this is directly transferred from the input buffer 24 to the I / O area 22 as the current output state of the DO module, the problem shown in FIG. 20 occurs. Therefore, the reference output of the bit for which the shared mask is set to “1” is not transferred, and the value of the output data is left as it is as a value indicating the output state of the DO module, and the reference to the bit for which “0” is set. Only the output is transferred from the input buffer 24 to the I / O area 22.
[0072]
Then, after completion of the process of transferring the data indicating the output state to the I / O area 22, the shared mask of the corresponding address area in the shared mask area 28 is reset to “0” to prepare for the generation of the next output data.
[0073]
The reset of the shared mask in the shared mask area 28 may be performed at any time when the reference data in the I / O area 22 is rewritten, and the data in the I / O area 22 may be changed before the calculation by the task process. A configuration may be adopted in which the copied data and the data in the I / O area 22 after the operation are compared with respect to all the address areas, and all the shared masks are generated collectively.
[0074]
FIG. 7 is a configuration example of a multicast frame sent out on the serial link bus 1 to transmit output data from the CPU module 2 to the DO module 3.
[0075]
Each CPU module 2 sends out a multicast frame addressed to the DO module 3 that sends output data. In the multicast method, data can be transmitted to a plurality of modules in one tact cycle, and data for a plurality of DO modules can be included in one frame.
[0076]
In FIG. 7, the multicast frame includes output data for a plurality of DO modules, and this output data is stored for each DO module together with the station number indicating the output partner station, the data size, and the mask information.
[0077]
When the DO module 3 receives the multicast frame, it compares the station number attached to each output data in the received frame with its own station number information, and if there is a match, the corresponding output data is stored in the input buffer. Capture.
[0078]
FIG. 8 is a timing diagram showing an example of an input / output state on each module and the bus when the CPU modules CPU0 and CPU1 share the DO module. This figure shows an example in which the CPU 0 sets one output point of the DO module to “1”, and the CPU 1 that recognizes this resets it to “0”. In the figure and the following description, for the sake of simplicity of explanation, one output point of the DO module, that is, input / output of 1-bit data is described.
[0079]
In FIG. 8, it is first assumed that the output state needs to be changed from “0” to “1” for one output point of the DO module shared by the CPU 0 from the calculation result of the task processing in the tact cycle A. . The operation execution unit 21 sets “1” as output data in the address area corresponding to the DO module and output point of the I / O area 22, and the same address as the address of the I / O area 22 of the shared mask area 28. A shared mask with the corresponding bit set to “1” is generated and stored in the area.
[0080]
The output data and the shared mask are transmitted to the DO module as a multicast frame 32-1. In the DO module, the DO module changes the output state in tact cycle B based on the output data from CPU0 and CPU0 and the shared mask. In this case, since the shared mask of CPU0 is “1” and the shared mask of CPU1 is “0”, the output state reflects the output data from CPU0, and the output state of the output point changes from “0” to “1”.
[0081]
During this period, the DO module notifies the CPU 0 and the CPU 1 of a reference output for notifying its own output state through the total frame 31-1. Since the reference frame output of the total frame 31-1 does not reflect the output data from the CPU 0 of the multicast frame 32-1, if this is transferred to the I / O area 22 of the CPU 0 as the output state of the DO module, the CPU 0 Erroneously determines that the output “1” set by itself has been reset to “0” by the CPU 1. However, since the shared mask stored in the shared mask area 28 is “1” in the CPU 0, the reference output by the total frame 31-1 is not transferred to the I / O area and the reference data indicating the output state is It remains “1” set in the cycle period A. As a result, even if the calculation execution unit 21 reads the reference data indicating the output state of the DO module from the I / O area 22 in the calculation processing of the tact cycle B in the CPU 0, the output set in the tact cycle A is reset by another CPU module. There is no misrecognition that
[0082]
When the input process of data to the I / O area 22 by the total frame is completed, the shared mask in the same address area in the shared mask area 28 is cleared to “0”. As a result, it is necessary to newly change the output state of the DO module by arithmetic processing, and the reference output from the DO module in the total frame is directly used as reference data in the I / O area 22 until the shared mask is generated. Is input. In FIG. 8, the CPU 0 inputs the reference outputs of the total frames 31-2, 31-3, and 31-4 as they are to the I / O area 22 as reference data indicating the output state of the DO module.
[0083]
In the CPU 1, reference outputs from the total frames 31-1 and 31-2 from the DO module are directly input to the I / O area 22 as reference data. When the CPU 1 knows that the output state of the DO module has changed from “0” to “1” in the cycle period C, the CPU 1 instructs the DO module to reset the output state from “1” to “0”. Data is generated and stored in the I / O area, and a shared mask whose corresponding bit is “1” is generated and stored in the shared mask area. These are notified to the DO module as a multicast frame 32-3. In the DO module, since the shared mask in the multicast frame 32-3 is “0” from the CPU 0 and “1” from the CPU 1, the output state “1” is reflected by reflecting the output data “0” from the CPU 1. Change from "" to "0". The changed output state is notified to the CPU 0 and the CPU 1 as a reference output by the total frame 31-4.
[0084]
As described above, in the programmable controller according to the present embodiment, the DO module can perform the competition control of the output from each CPU module by the shared mask from the CPU module transmitted together with the output data.
[0085]
Further, when the CPU module receives the reference output from the DO module, it refers to the corresponding shared mask in the shared mask area and transfers it to the I / O area. Therefore, the output data to the DO module and the reference data have the same address. No problem occurs even when set to.
Next, a second embodiment of the present invention will be described.
[0086]
In the conventional programmable controller, the CPU module always includes the shared mask data not only for the DO module which is shared with other CPU modules and needs competition control but also for the DO module which is not shared. Since this frame is sent on the serial link bus 1, the transmission efficiency on the serial link bus 1 is lowered.
[0087]
The programmable controller of the second embodiment takes this point into consideration, and has a configuration for changing the transmission frame depending on whether or not the transmission destination requires contention control.
[0088]
FIG. 9 is a diagram illustrating a configuration example of a multicast frame in the second embodiment of the present invention, and corresponds to the frame configuration diagram of the first embodiment in FIG.
In the frame configuration according to the second embodiment, a data transfer mode control bit is provided in the frame. In the case of the figure, the upper reserved bit in the station number portion of the input / output module indicating the transmission destination which is the head portion of the frame is used as the data transfer mode control bit. The data transfer mode control bit is not limited to the position shown in the figure, and can be provided at other positions in the frame or independently as long as it is a specific position.
[0089]
This data transfer mode control bit indicates whether or not to perform data transfer control using a shared mask. When sharing and contention control is performed during data transfer, this bit is set to “1”, and sharing and contention control are performed. If there is no need, a frame with this bit set to “0” is transmitted.
[0090]
(1) in FIG. 9 shows a frame configuration when sharing and contention control is not performed in the transmission destination DO module. “0” is set in the data transfer mode control bit at the head of the frame, and this frame This does not include shared mask data, and is composed of station number, size, and output data. FIG. 2B shows the frame configuration when sharing and contention control is performed. The data transfer mode control bit is set to “1”, and the frame configuration in the first embodiment of FIG. Similarly, it has a configuration having shared mask data together with output data.
[0091]
The CPU module that performs data transmission uses these two frames properly depending on whether or not the transmission destination is shared and whether or not competition control is required, and transmits output data to an output module shared with other CPUs Uses a frame configured as shown in FIG. 9 (2), and when sending output data to an output module not shared with other CPUs, the frame configured as shown in FIG. 9 (1) Is used. By using different frames in this way, when there is no need to share data and control contention with other CPUs, extra shared mask data is not included in the frame, so the traffic volume is reduced accordingly, and the serial link The data transfer efficiency on the bus 1 is improved.
[0092]
FIG. 10 is a diagram showing details of the sharing and contention control circuit 40 that determines output data on the DO module side in the second embodiment. FIG. 10 corresponds to the configuration of FIG. 4 of the first embodiment, and the same components are denoted by the same reference numerals.
[0093]
The sharing and contention control circuit 40 in FIG. 10 has a shared mask valid mode storage register 41, a new reception storage register 42, a NOT circuit 43 and an OR circuit 44 added to each CPU module based on the configuration in FIG. The AND circuit is changed to a 3-input AND circuit. Among them, the shared mask valid mode storage register 41 is set with the value of the data transfer mode control bit in the received multicast frame, and the sharing and contention control circuit 40 uses this value to share the mask for performing sharing and contention control. Switches between the presence mode and the non-shared mask mode that does not perform sharing and contention control. The new reception presence register 42 is a register indicating that a new multicast frame has been received. When a new multicast frame is received from the CPU module, the new reception presence storage register 42 corresponding to the CPU module is set to “1”. Is done. When the output of the OR circuit 15 is output from the DO output point and is latched by the reference output latch 16, it is reset to "0".
[0094]
The value of the shared mask valid mode storage register 41 is inverted by the NOT circuit 43 and then ORed with the shared mask data 11 by the OR circuit 44. Therefore, the OR circuit 44 outputs “1” when the shared mask valid mode storage register 41 is set to “0”, and outputs the value of the shared mask data 11 when “1” is set. The AND circuit 45 takes the AND value of the output data 12 and the value in the new reception presence storage register 42. For example, when a frame in which contention control is not performed as shown in FIG. 9A is received, “0” is set in the corresponding shared mask valid mode storage register 41. While there is no newly received multicast frame, the values of the respective newly received storage registers 42-1 to 42-3 remain reset to "0", so the outputs of the AND circuits 45-1 to 45-3 are output. Becomes “0”, and the value latched in the reference output latch 16 continues to be output from the DO output point via the AND circuit 14 and the OR circuit 15.
[0095]
Next, how to determine a shared mask module mode in which each CPU module determines whether to use a frame without the shared mask data (frame in FIG. 9 (1)) or a frame with the shared mask data (frame in FIG. 9 (2)). Will be described.
[0096]
FIG. 11 is a diagram showing the logic for determining the shared mask mode. FIG. 11A shows a mode in which there is output point sharing and contention by a plurality of CPU modules, that is, a mode with a shared mask, and FIG. An example where there is no conflict, that is, no shared mask data mode is shown. FIG. 5A shows an example of determining a mode with a shared mask when data sharing is performed when three CPU modules CPU0 to CPU2 transmit data to the output modules DO0 and DO1. 16-bit shared mask data for one DO module having an output point is shown as a used bit of the CPU.
[0097]
In the output module DO0 of FIG. 11A, bit 0 is set to CPU1 and CPU2, bit 10 is set to CPU0 and CPU2, bit 13 is set to CPU1 and CPU2, and bit 15 is set to "1" in the shared mask. It can be seen that the output points of DO0 corresponding to these are competing. Therefore, when the CPU modules CPU0, CPU1, and CPU2 transmit data to the output module DO0 and change the output state of the output point, the frame including the shared mask data as shown in FIG. Transmit as a multicast frame.
[0098]
In the case of the output module DO1 in FIG. 4A, in the same word, CPU0 uses bits 13, 14, and 15, CPU1 uses bits 10, 11, and 12, and CPU2 uses bits 0, 1, and 2. Is shared by three CPUs. When each CPU module transmits data to the output module DO1, the shared mask data corresponding to the CPU use bit is sent together with the output data in the shared mask presence mode.
[0099]
In the case of DO2 in FIG. 2B, only CPU0 uses all bits of DO2, and CPU1 and CPU2 do not use DO2. That is, DO2 is an output module under the control of only CPU0, and CPU0 transmits a frame that does not include shared mask data as shown in FIG. 9A as a multicast frame to output module DO2 as a multicast frame.
[0100]
FIG. 12 is a diagram illustrating a control example of shared mask data by the CPU module according to the second embodiment. This figure shows, as an example, the control operation of the shared mask when the CPU 0 performs the output control of DO0 under the output conditions of FIG.
[0101]
In the CPU module CPU0, the fixed shared mask register 51 and the output condition shared mask register 52 are connected to the input of the OR circuit 53 and the output is connected to the serial link output shared mask register 54 as shown in FIG. It is prepared. The fixed shared mask register 51 is operated by the OS running on the CPU module, and “1” is set to the bit corresponding to the output point used only by the CPU 0 without conflicting with other CPU modules. The value of the fixed shared mask register 51 is fixedly set unless the sharing state of the output point of the DO module is changed. The output condition sharing mask register 52 is a register for setting an output point at which the CPU module changes the output to the DO module. The output condition determination unit 55 sets “1” to the bit corresponding to the output point where the output condition is satisfied. The The serial link output shared mask register 54 is a register for storing shared mask data to be stored and transmitted in a multicast frame.
[0102]
The control operation process for generating the shared mask data when the CPU 0 controls the output of DO0 is shown below.
(1) CPU0 uses bits 1 and 2 of DO0 without conflicting with other CPU modules, so set "1" to bits 1 and 2 of the DO0 fixed shared mask register in advance by OS processing. deep.
(2) The CPU 0 determines the output condition for the competitive output point, and when the output condition is satisfied, the output condition determination unit 55 sets “1” to the corresponding bit of the DO0 output condition satisfaction shared mask register 52. In the case of the figure, since the output condition is satisfied at the output point corresponding to bit 15, “1” is set to bit 15.
(3) The OR value of the values of the fixed shared mask register 51 for DO0 and the output condition establishment shared mask register 52 is taken, and the result is set in the serial link output shared mask register 54 for DO0. In this case, a value in which “1” is set in bits 1, 2, and 15 is set in the serial link output shared mask register 54. The data in the serial link output shared mask register 54 is transmitted to DO0 together with the output data by the multicast frame as shared mask data. In DO0, the sharing and contention control circuit 40 shown in FIG. 10 changes the output of the output points corresponding to bits 1, 2, and 15 from the shared mask data based on the output data from the CPU0 as sharing and contention control. Note that the CPU 0 also performs output control for the output point corresponding to the bit 10, but since the output condition is not satisfied this time, the output is held at the previous value.
[0103]
In general, in a programmable controller of a multi-CPU system, in the case of a configuration in which resources assigned to each CPU are completely divided and functions are distributed, input / output sharing and contention do not occur, but the system is originally controlled by one CPU. When a multi-CPU is employed for reasons such as dealing with an increase in program capacity and improving processing performance by parallel processing, the input / output module is shared by a plurality of CPUs. In this case, contention WT (writing) in which a plurality of CPUs perform writing processing may be performed on one input / output module. In program development in that case, the user should not have the trouble of creating and changing the program source in consideration of competition control. In addition, when a conflicting WT is performed, a plurality of CPU programs will write to the same address of the same DO module. Is this address duplication due to conflicting writing or due to an error in program work, etc. It must be easy to check.
[0104]
To cope with this, the present invention has a contention WT instruction for performing contention control for writing to an output point shared by a plurality of CPUs, and the user does not need to use this contention WT instruction consciously. The application program development device (hereinafter referred to as a loader) has a mechanism for automatically generating a conflicting WT instruction.
[0105]
FIG. 13 shows a basic contention WT instruction example. In this figure, as an example of a user-written program, a basic WT instruction ladder display, S (set), R (reset), W (write), and corresponding WT instruction KS corresponding to each of them are displayed as normal instructions. (Contention set), KR (contention reset), and KW (contention write).
[0106]
The basic operation of each WT instruction is shown below.
Figure 0004123660
It becomes.
[0107]
FIG. 14 shows an example of contention WT instruction generation processing by the loader.
As shown in FIG. 14A, when the loader generates an execution object of each CPU module as a loader process, the source program of all the CPU modules (CPU0, CPU1, CPU2 in the figure) constituting the multi-CPU system. Referring to FIG. 4, the part where the output to the same output point of the same input / output module by different CPUs, that is, the writing to the same output address is performed is examined. When a location where a plurality of CPUs are writing to the same address is detected, a WT instruction in the source program of the CPU is converted into a conflicting WT instruction as shown in FIG. 13, and an execution object is generated. To do.
[0108]
In the case of FIG. 14B, since writing to the bit 15 of the output module DO0 conflicts during the programs of the CPU0 and CPU1, the loader competes with the WT instruction for the bit 15 in the source program of the CPU0 and CPU1. Replaced with WT instruction (KW). Note that writing to the DO0 bit 2 of the CPU0 and writing to the bit10 of the DO1 of the CPU1 are not competing with other CPUs, so that the normal WT instruction (W) remains.
[0109]
In addition, writing to the same address may be caused by a plurality of CPU modules competingly using the output point, or may be caused by a factor outside the user's recognition due to an error in programming work or the like. Therefore, in order to eliminate the cause of the latter factor, the loader notifies the user of a conflicting WT warning that warns the address duplication before performing the replacement with the conflicting WT instruction.
[0110]
FIG. 15 is a diagram showing a warning notification example of a conflicting WT by the loader.
As a warning notification method, as shown in (a) of the figure, the output instruction part where the conflict has occurred is displayed at the source program level, the display color is changed from the other display part, or the display is blinked. There is a way to emphasize. In the case of the figure, while the normal display portion is displayed in white, the write command portion where the conflict has occurred is displayed in red to notify the user.
[0111]
As another method of warning notification, there is a method in which the contention control location is indicated in a list format and the program line number and instruction type are shown in FIG.
The user can detect a program error from these warning notifications. In the above description, the digital output module (DO module) has been described as an example of the output module. However, in the analog output module (AO module), the concept of sharing and competition control is exactly the same, and only the shared mask data is output. It can be realized by corresponding to data, for example, one word for one word. For example, in a 4-word AO module, when the first word is used by CPU0, the second word is used by CPU1, and the third and fourth words are used by CPU2, sharing is performed and a mode with shared mask is set. The data is controlled by 4-bit shared mask data. Also, the sharing and contention control circuit in the output module can be realized by a selector, intermediate value data generation and average value data generation circuit, etc., instead of a simple AND and OR circuit.
[0112]
【The invention's effect】
According to the programmable controller based on this invention, in order to notify the CPU module of the output state of an output module, it is not necessary to newly provide an input module.
[0113]
Further, in the output module, the sharing of output data by each CPU module and the competition control can be performed by the sharing mask transmitted together with the output data from each CPU module.
[0114]
Further, in the CPU module, there is no problem that the CPU module misrecognizes the output state of the output module, and the same address can be set for the output data and the reference output for the output module. Therefore, the same address can be used when outputting data to the output module and referring to the output state, so that programming is not confused. This can simplify data input / output processing based on application programming, and can simplify the program and improve the processing speed.
[0115]
In the case of output data that does not require sharing and contention control, if the configuration is such that the sharing mask is not sent to the output module together with the output data, the communication load is the same as that of a single CPU system, and the system performance is improved. I can do it. That is, even in a single CPU system, the present invention can be used as it is in the mode without the shared mask.
[0116]
Furthermore, when developing a program for a multi-CPU programmable controller, even if the user performs contention control, if the user writes a write command to a normal input / output module, the loader automatically refers to the programs of multiple CPUs. Are converted into instructions dedicated to contention control. In addition, since this conversion part is notified to the user, the user can easily confirm whether the address has been duplicated in consideration of the conflict or whether the address has been mistakenly duplicated. The quality of the program can be improved.
[Brief description of the drawings]
FIG. 1 is a diagram showing an outline of a DO module in the present embodiment.
FIG. 2 is an explanatory diagram of communication by a total frame method.
FIG. 3 is an explanatory diagram of communication by a multicast method.
FIG. 4 is a diagram showing in detail a contention control circuit of the DO module.
FIG. 5 is a functional block diagram showing components for input / output processing of a CPU module.
FIG. 6 is a diagram illustrating an example of a shared mask created by a CPU module.
FIG. 7 is a diagram illustrating a configuration example of a multicast frame.
FIG. 8 is a timing diagram showing an example of an input / output state on each module and bus when two CPU modules share a DO module.
FIG. 9 is a diagram illustrating a configuration example of a multicast frame in the second embodiment.
FIG. 10 is a diagram showing in detail a contention control circuit in the second embodiment.
FIG. 11 is a diagram illustrating shared mask mode determination logic performed in each CPU module;
FIG. 12 is a diagram illustrating an example of control of shared mask data by a CPU module according to the second embodiment.
FIG. 13 is a diagram illustrating an example of a basic contention WT (write) instruction.
FIG. 14 is a diagram showing an example of contention WT instruction generation processing by a loader.
FIG. 15 is a diagram illustrating a warning notification example of a contention WT.
FIG. 16 is a diagram showing a programmable controller having a multi-CPU configuration in which a plurality of CPU modules, DI modules, and DO modules are connected to a bus.
FIG. 17 is a diagram illustrating an example of a return input of a DO module output by a DI module;
FIG. 18 is a timing chart showing the state of output data on each module and bus.
FIG. 19 is a functional block diagram for input / output processing of a conventional CPU module.
FIG. 20 is a timing diagram showing the input / output states on each module and bus when the transfer source address of output data to the DO module is the same as the transfer destination address of input data from the DI module.
[Explanation of symbols]
1, 101 Serial link bus
2,102 CPU module
3, 103 DO module
10, 40 Sharing and contention control circuit
11 Shared mask
12 Output data
13, 14, 45 AND circuit
15, 44, 53 OR circuit
16 Reference output latch
21 Calculation execution part
22 I / O area
23 Output buffer
24 input buffers
25 Serial link controller
26 Input buffer transfer table
27 Input data transfer table
28 Shared mask data area
41 Shared mask valid mode storage register
42 Memory register with new reception
43 NOT circuit
51 Fixed shared mask register
52 Output condition sharing mask register
54 Serial link output shared mask register

Claims (14)

複数のＣＰＵモジュールと少なくとも１つの出力モジュールを備えるプログラマブルコントローラにおいて、
前記各ＣＰＵモジュールは、
出力モジュールに対して出力状態を変更するかどうかを指示する共有マスクを生成する共有マスク生成手段と、
前記出力モジュールに対する出力データを前記共有マスクと共に送信する出力データ送信手段と、
を備え、
前記出力モジュールは、
前記ＣＰＵモジュールからの前記出力データを前記共有マスクと共に受信する出力データ受信手段と、
前記出力データと共有マスクを各ＣＰＵモジュール毎にＡＮＤを取った第１のＡＮＤ値を求め、また各前記共有マスクの反転値と現在の出力値とのＡＮＤを取った第２のＡＮＤ値を求め、当該第１のＡＮＤ値と第２のＡＮＤ値のＯＲを取ったＯＲ値から出力状態を決定する共有及び競合制御手段と、
前記出力状態を示す参照出力を自出力モジュールを共有する複数のＣＰＵモジュールへ送信する参照出力送信手段と、
を備えることを特徴とするプログラマブルコントローラ。In a programmable controller comprising a plurality of CPU modules and at least one output module,
Each of the CPU modules is
A shared mask generating means for generating a shared mask for instructing whether to change the output state to the output module;
Output data transmitting means for transmitting output data for the output module together with the shared mask;
With
The output module is
Output data receiving means for receiving the output data from the CPU module together with the shared mask;
A first AND value obtained by ANDing the output data and the shared mask for each CPU module is obtained, and a second AND value obtained by taking an AND of the inverted value of each shared mask and the current output value is obtained. Sharing and contention control means for determining an output state from an OR value obtained by ORing the first AND value and the second AND value ;
A reference output transmitting means for transmitting a reference output indicating the output state to a plurality of CPU modules sharing the output module;
A programmable controller comprising: 前記ＣＰＵモジュールは、前記共有マスク生成手段が生成した共有マスクを記憶する共有マスク記憶手段と、該共有マスク記憶手段に記憶されている共有マスクと出力モジュールから送信される前記参照出力から、当該ＣＰＵモジュール内において該出力モジュールの出力状態を示す参照データを生成する出力状態参照データ生成手段とを更に備えることを特徴とする請求項１に記載のプログラマブルコントローラ。 Before SL CPU module, a shared mask storage means for storing shared mask is the shared mask generating means to generate, from the reference output that is transmitted from the shared mask and output modules that are stored in the shared mask storage means, the The programmable controller according to claim 1, further comprising output state reference data generation means for generating reference data indicating an output state of the output module in the CPU module. 前記出力状態参照データ生成手段が生成した前記出力モジュールの出力状態を示す参照データを、該出力モジュールに対する前記出力データを格納するアドレス領域と同じ領域に格納する参照データ格納手段を更に備えることを特徴とする請求項２記載のプログラマブルコントローラ。Reference data storage means for storing the reference data indicating the output status of the output module generated by the output status reference data generating means in the same area as the address area for storing the output data for the output module. The programmable controller according to claim 2 . 前記ＣＰＵモジュール及び出力モジュールはリング状の構成をもつバスによって接続され、前記ＣＰＵモジュール及び出力モジュールは、前記バス上にフレームを巡回させて他のモジュールとのデータの転送を行うことを特徴とする請求項１乃至３のいずれか１つに記載のプログラマブルコントローラ。The CPU module and the output module are connected by a bus having a ring-like configuration, the CPU module and the output module, characterized in that by cyclically frames on the bus for transferring data with other modules The programmable controller according to any one of claims 1 to 3 . 前記ＣＰＵモジュールは前記出力モジュールに対してデータを送る場合マルチキャスト方式により、前記出力モジュールは前記ＣＰＵモジュールに対してデータを送る場合トータルフレーム方式によりデータの転送を行うことを特徴とする請求項４記載のプログラマブルコントローラ。5. The data transfer of the CPU module according to claim 4, wherein the CPU module transfers data by a multicast method when sending data to the output module, and the output module transfers data by a total frame method when sending data to the CPU module. Programmable controller. 前記出力データ送信手段は、前記出力データを送信する出力モジュールで該出力データに対し他のＣＰＵモジュールからの出力データとの共有及び競合制御を行う必要が無いとき、該出力データの送信時、前記共有マスクを送信しないことを特徴とする請求項１乃至５の何れか１つに記載のプログラマブルコントローラ。The output data transmitting means is an output module that transmits the output data, and when it is not necessary to perform sharing control and competition control with the output data from other CPU modules, the output data is transmitted when the output data is transmitted. the programmable controller according to any one of claims 1 to 5, characterized in that does not transmit a shared mask. 前記ＣＰＵモジュールは、前記共有マスクを前記出力データと共に送信したか否かを通知するデータ転送モード制御ビットを生成するデータ転送モード制御ビット生成手段を更に備え、前記出力データ送信手段は、該データ転送モード制御ビットを前記出力データと共に送信し、前記共有及び競合制御手段は、該データ転送モード制御ビットが前記共有マスクが前記出力データと共に送信されていないことを示すとき、該出力データのみから出力状態を決定することを特徴とする請求項６記載のプログラマブルコントローラ。The CPU module further comprises data transfer mode control bit generating means for generating a data transfer mode control bit for notifying whether or not the shared mask is transmitted together with the output data, and the output data transmitting means includes the data transfer A mode control bit is transmitted with the output data, and the sharing and contention control means outputs an output state only from the output data when the data transfer mode control bit indicates that the sharing mask is not transmitted with the output data. The programmable controller according to claim 6 , wherein the programmable controller is determined. 前記出力データ送信手段は、他のＣＰＵモジュールと共有及び競合する出力点を持つ出力モジュールに対する出力指示を前記出力データとして送信するとき、前記共有マスクを該出力データと共に送信することを特徴とする請求項６に記載のプログラマブルコントローラ。The output data transmitting means transmits the shared mask together with the output data when transmitting an output instruction as an output data to an output module having an output point shared and competing with another CPU module. Item 7. The programmable controller according to item 6 . 前記共有マスク生成手段は、出力モジュールの他のＣＰＵモジュールと競合しない出力点に対応するビットを常時リセットし、競合する出力点に対応するビットは出力条件成立時にセットし、前記出力データ送信手段が出力データを送信するとリセットして前記共有マスクを生成することを特徴とする請求項１乃至８の何れか１つに記載のプログラマブルコントローラ。The shared mask generating means, always resets the bit corresponding to the other output point that does not conflict with CPU module output modules, the bit corresponding to the output point of a conflict set at satisfied output condition, the output data transmission means the programmable controller according to but one of claims 1 to 8, characterized in that to generate the shared mask is reset when sending the output data. 前記ＣＰＵモジュールは、他のＣＰＵモジュールと競合する出力点へのデータの書込みがある場合、前記出力点を持つ前記出力モジュールに対して出力データの書込みと共に対応する共有マスクの書き換えを当該ＣＰＵモジュールが行う競合書込み用の書込み命令を備えることを特徴とする請求項１乃至９の何れか１つに記載のプログラマブルコントローラ。When there is data writing to an output point competing with another CPU module, the CPU module rewrites the corresponding shared mask together with the output data writing to the output module having the output point. the programmable controller according to any one of claims 1 to 9, characterized in that it comprises a write command for competition writing performed. ＣＰＵモジュールからの出力データを自己の出力状態を変更するかどうかを指示する共有マスクと共に受信する出力データ受信手段と、
前記出力データと共有マスクを各ＣＰＵモジュール毎にＡＮＤを取った第１のＡＮＤ値を求め、また各前記共有マスクの反転値と現在の出力値とのＡＮＤを取った第２のＡＮＤ値を求め、当該第１のＡＮＤ値と第２のＡＮＤ値のＯＲを取ったＯＲ値から出力状態を決定する共有及び競合制御手段と、
を備えることを特徴とするプログラマブルコントローラの出力モジュール。Output data receiving means for receiving output data from the CPU module together with a shared mask for instructing whether or not to change its output state;
A first AND value obtained by ANDing the output data and the shared mask for each CPU module is obtained, and a second AND value obtained by taking an AND of the inverted value of each shared mask and the current output value is obtained. Sharing and contention control means for determining an output state from an OR value obtained by ORing the first AND value and the second AND value ;
An output module of a programmable controller, comprising: 前記共有及び競合制御手段は、前記出力データと共に前記共有マスクが送信されてこないとき、該出力データから出力状態を決定することを特徴とする請求項１１に記載のプログラマブルコントローラの出力モジュール。12. The output module of a programmable controller according to claim 11 , wherein the sharing and contention control means determines an output state from the output data when the sharing mask is not transmitted together with the output data. 複数のＣＰＵモジュールと少なくとも１つの出力モジュールを備えるプログラマブルコントローラにおけるデータ出力の共有及び競合制御方法であって、
前記各ＣＰＵモジュールが、
出力モジュールに対して出力状態を変更するかどうかを指示する共有マスクを生成し、
前記出力モジュールに対する出力データを前記共有マスクと共に送信し、
前記出力モジュールが、
前記ＣＰＵモジュールからの前記出力データを前記共有マスクと共に受信し、 前記出力データと共有マスクを各ＣＰＵモジュール毎にＡＮＤを取った第１のＡＮＤ値を求め、また各前記共有マスクの反転値と現在の出力値とのＡＮＤを取った第２のＡＮＤ値を求め、当該第１のＡＮＤ値と第２のＡＮＤ値のＯＲを取ったＯＲ値から出力状態を決定し、
前記出力状態を示す参照出力を自出力モジュールを共有する複数のＣＰＵモジュールへ送信する、
ことを特徴とするプログラマブルコントローラに於けるデータ出力の共有及び競合制御方法。A data output sharing and contention control method in a programmable controller comprising a plurality of CPU modules and at least one output module,
Each of the CPU modules is
Generate a shared mask that tells the output module whether to change the output state,
Sending output data for the output module with the shared mask;
The output module is
The output data from the CPU module is received together with the shared mask , a first AND value obtained by ANDing the output data and the shared mask for each CPU module is obtained, and an inverted value of each shared mask and a current value are obtained. A second AND value obtained by ANDing the output value of the first AND value, and determining an output state from an OR value obtained by ORing the first AND value and the second AND value
Transmitting a reference output indicating the output state to a plurality of CPU modules sharing the output module;
A data output sharing and contention control method in a programmable controller. 前記ＣＰＵモジュールは、前記出力データに対し送信先の出力モジュールで他のＣＰＵモジュールからの出力データとの共有及び競合制御を必要とするかどうかを判断し、該判断結果、必要としない場合、前記共有マスクを前記出力モジュールに送信しないことを特徴とする請求項１３に記載のデータ出力の共有及び競合制御方法。The CPU module determines whether the output data needs sharing and contention control with output data from another CPU module in the output module of the transmission destination, and if the determination result does not require, 14. The data output sharing and contention control method according to claim 13 , wherein a sharing mask is not transmitted to the output module.
JP33552599A 1999-03-30 1999-11-26 Programmable controller Expired - Lifetime JP4123660B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP33552599A JP4123660B2 (en) 1999-03-30 1999-11-26 Programmable controller

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP11-90279 1999-03-30
JP9027999 1999-03-30
JP33552599A JP4123660B2 (en) 1999-03-30 1999-11-26 Programmable controller

Publications (2)

Publication Number Publication Date
JP2000347712A JP2000347712A (en) 2000-12-15
JP4123660B2 true JP4123660B2 (en) 2008-07-23

Family

ID=26431777

Family Applications (1)

Application Number Title Priority Date Filing Date
JP33552599A Expired - Lifetime JP4123660B2 (en) 1999-03-30 1999-11-26 Programmable controller

Country Status (1)

Country Link
JP (1) JP4123660B2 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4556809B2 (en) * 2005-08-24 2010-10-06 横河電機株式会社 Ladder program development support device
WO2011007399A1 (en) * 2009-07-17 2011-01-20 富士通テレコムネットワークス株式会社 Snmp agent device and snmp agent control method
EP3401742B1 (en) * 2017-05-09 2020-09-02 Siemens Aktiengesellschaft Automation system and method for operating same

Also Published As

Publication number Publication date
JP2000347712A (en) 2000-12-15

Similar Documents

Publication Publication Date Title
US6094532A (en) Multiprocessor distributed memory system and board and methods therefor
US4409656A (en) Serial data bus communication system
JPH0624372B2 (en) Method for diagnosing a first node to a second node in a local area network
EP0405545A2 (en) Data communication adapter and data communication terminal apparatus employing the same
JPH06295336A (en) Video display device
JPH1049507A (en) Parallel computer
JP2011008541A (en) Data processor, data processing method, and program
JP4154853B2 (en) A redundant programmable controller and an equalization method for equalizing control data.
US11204799B2 (en) Semiconductor device and systems using the same
JP2996440B2 (en) Diagnosis method of data processing system
JPS62206658A (en) Memory controller
US4958271A (en) Transfer control equipment
JP4123660B2 (en) Programmable controller
US5442631A (en) Communication control device
JP2003271574A (en) Data communication method for shared memory type multiprocessor system
JP2008146541A (en) Dma transfer system, dma controller and dma transfer method
GB2409302A (en) Data Communication Mechanism
JPS6054549A (en) Data transmitting method and device
JPH0562384B2 (en)
JP3799741B2 (en) Bus controller
JP2705955B2 (en) Parallel information processing device
JPH0399337A (en) Diagnostic method for data processing unit, data processing unit and data processing system
JPH01157143A (en) Network system with token passing bus system
JP3077992B2 (en) Data transmission equipment
JPH03204254A (en) Data receiver

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20040218

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040713

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070104

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070410

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070611

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080122

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080321

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080415

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080428

R150 Certificate of patent or registration of utility model

Ref document number: 4123660

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110516

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110516

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110516

Year of fee payment: 3

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110516

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120516

Year of fee payment: 4

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120516

Year of fee payment: 4

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120516

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130516

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130516

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140516

Year of fee payment: 6

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term