JP4524932B2 - リング型ネットワークにおけるノード間のタイミング同期方法、及びそのノード - Google Patents
リング型ネットワークにおけるノード間のタイミング同期方法、及びそのノード Download PDFInfo
- Publication number
- JP4524932B2 JP4524932B2 JP2001035897A JP2001035897A JP4524932B2 JP 4524932 B2 JP4524932 B2 JP 4524932B2 JP 2001035897 A JP2001035897 A JP 2001035897A JP 2001035897 A JP2001035897 A JP 2001035897A JP 4524932 B2 JP4524932 B2 JP 4524932B2
- Authority
- JP
- Japan
- Prior art keywords
- synchronization
- frame
- node
- nodes
- time
- 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 - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、リング型ネットワークシステムにおいて、ノード間のタイミングを同期させる方法に関する。
【０００２】
【従来の技術】
複数のノードをネットワークに接続する形態として、バス型やリング型のネットワークシステムがある。
【０００３】
バス型は、共通の経路であるバスに複数ノードを並列に接続した形態で、あるノードの送信したフレームがほぼ同時に全ノードに到達するという特徴がある。
図９は、４つのノード５０ａ〜５０ｄをネットワーク５１にバス型に接続した例で、ノード５０ａが送信するフレームは、ほぼ同時にノード５０ｂ〜５０ｄに到達する。
【０００４】
図１０は、全ノードの同期を取るために、ノード５０ａが同期用のフレームを送信したときに、そのフレームが他のノードにどう届き、どういう同期がどうとれるかを表した図である。この同期用フレームは、プロトコルヘッダに同期用フレームを表すコードが格納されたブロードキャストフレームである。ノード５０ａが送信した同期用のフレーム５２は、ほぼ同時に自分を含めた全ノードに受信されるので、この受信タイミングを同期ポイントとして同期をとれば、全ノードの同期はほぼ一致する。
【０００５】
一方、図１１の示すようなリング型は、複数ノードをデイジーチェインで環状に接続する形態で、あるノードの送信したフレームは下流のノードの中継でリングを１周するので、ノード毎の中継遅延の影響で全ノードに同時に到達しないという特徴がある。なお、フレームは、リングを１周まわったところで、最初に送信したノードが削除する。
【０００６】
図１１は、４つのノード６０ａ〜６０ｄをネットワーク６１でリング型に接続した例で、ノード６０ａが送信するフレームは、ノード６０ｂ，ノード６０ｃ，ノード６０ｄの順に中継されてネットワーク６１を１周まわり、ノード６０ａに戻ったところで削除される。
【０００７】
図１２は、図１１のノード６０ａ〜６０ｄの構成の一例を示す図であり、同図ではノード６０ａを例にするが、他のノードの構成も同様である。
同図において、フレーム処理部６３は、受信したフレームの判定を行ない、これを下流に送信する事によりフレームを中継する。ＣＰＵ６２は、ノード６０ａ全体を制御する中央処理装置であり、フレーム処理部６３も制御する。
【０００８】
図１３は、全ノードの同期を取るために、ノード６０ａが同期用のフレームを送信したときに、そのフレームが他のノードにどう届き、どういう同期がどうとれるかを表した図である。ノード６０ａが送信した同期用フレーム６４ａは、まずノード６０ｂに受信され、図１２のフレーム処理部６３でフレームの判定を行ない、これを下流に送信する事により中継される。ここでは、フレーム受信してからの送信するまでのフレーム処理部６３の遅延を２μ秒とすると、次のノード６０ｃが中継された同期用フレーム６４ｂを受信するのは、ノード６０ｂが同期用フレーム６４ａを受信した時点より２μ秒遅れる。同様にノード６０ｄが同期用フレーム６４ｃを受信するのは、ノード６０ｃより２μ秒、すなわち、ノード６０ｂより４μ秒遅れる。ノード６０ａが同期用フレーム６４ｄを受信するのは、ノード６０ｂより６μ秒遅れる。この為、各ノードがそれぞれ同期用フレームの受信認識のタイミングを同期ポイントとすると、４つのノードしか無いにもかかわらず、６μ秒もの同期のずれが生じることになる。
【０００９】
【発明が解決しようとする課題】
上述したように、ノード間で同期をとる場合、フレームの受信タイミングがほぼ一致するバス型に比べ、リング型ではフレームの受信タイミングの遅れが同期タイミングの遅れに繋がり、リングの下流のノードほど同期が遅れていく。
【００１０】
例えば、１ノードで２μ秒の遅れになるとすれば、１００ノードで２００μ秒の遅れになる。最上流のノードと最下流のノードでそれぞれＸ軸，Ｙ軸のモーターを制御させ、最上流のノードと最下流のノードの間にあるノードにセンサー類を配置すると、軸間の同期のずれは２００μ秒になる。このずれが問題になる様な高速制御に適用する際は、モーターを制御するノードを接近させる（間にノードを挟まない）ように制約を設け、エンジニアリングや設置の際に注意しなければならない。
【００１１】
本発明の課題は、リング型ネットワークにおける上述したノード間の同期のずれを解消し、タイミングが一致した同期がとれ、高速制御にも問題なく適用できるリング型ネットワークにおけるノード間のタイミング同期方法、及びそのノードを提供することである。
【００１２】
【課題を解決するための手段】
本発明による第１のタイミング同期方法は、リング型ネットワークシステムにおける同期方法であって、送信元のノードは、特定のコマンドフレームを送信し、他のノードは、該特定のコマンドフレームを受信すると、該コマンドフレームを中継すると共にバイパスモードに移行し、リングを一巡した前記特定のコマンドフレームを受信した前記送信元のノードは、同期用フレームを送信し、前記バイパスモード状態にある他のノードは、該同期用フレームをバイパスすると共に、該同期用フレームの受信タイミングで同期をとるものである。
【００１３】
上記第１のタイミング同期方法では、同期の基準となるノード（送信元のノード）が、自ノード以外の全ノードの中継経路上のフレーム処理が一時的にバイパス状態になる命令を持つコマンドフレームを他のノードに送信し、その後に同期用フレームを送信する。各ノードは、この同期用フレームをバイパスすると共に、この同期用フレーム受信時を同期タイミングにする。
【００１４】
このように一時的にフレーム処理をバイパスする事により、各ノードのフレーム処理部で発生していた中継遅延は無くなる。すると、全モジュールがほぼ同時に同期用フレームを受信する事ができ、このフレーム受信を同期のタイミングにすることにより、バス型と同等の精度でモジュール間の同期をとることができる。同期を取った後はバイパス状態を解除する必要があるが、同期用フレームの受信をフレーム処理部で認識する頃には、中継し終わっているので、同期用フレームの受信をもってバイパス状態を解除すれば、次のフレームから本来のリング型のネットワークで送受信できる。
【００１５】
または、上記バイパス状態の解除の条件に、一定時間以上バイパス状態が継続したことを加えるようにしてもよい。
全モジュールがフレーム処理部をバイパス状態にした後に、同期用フレームが消失等、何らかの原因で、受信されなければ、バイパス状態を解除する事はできない。しかし上記解除条件を加えることにより、遅くとも一定時間経過後にはバイパス状態が解除され、その次のフレームから本来のリング型のネットワークで送受信できる。
【００２８】
【発明の実施の形態】
以下、図面を参照して、本発明の実施の形態について説明する。
図１（ａ）、（ｂ）は、第１の実施例を説明する為の図である。
【００２９】
本実施例では、ノード２ａ〜２ｄの４つのノードを、ネットワーク１によってリング型に接続している。
また、図２に示す様に、各ノード２ａ〜２ｄは、フレーム処理部３、ＣＰＵ４、スイッチ５を有する。尚、図１では、ＣＰＵ４、スイッチ５は省略し、ノード２ａ〜２ｄ内にフレーム処理部３を示し、またスイッチ５の切換／選択（フレーム処理部３側か、バイパス側かの切換／選択；選択されていない側はバツ印（×）を示す）を記述している。
【００３０】
ここでは、ノード２ａのタイミングにノード２ｂ〜２ｄを同期させる場合を例にして説明する。
まず、通常時には、図１（ａ）に示すように、各ノード２ａ〜２ｄのスイッチ５は、フレーム処理部３側になっている（これを通常モードと呼ぶ）。
【００３１】
同期をとる際には、ノード２ａは、ネットワーク１を介してノード２ｂ〜２ｄに対して、バイパスモード（スイッチ５がバイパス側に切換えられ、受信したフレームはフレーム処理部３を介さずに中継させる状態）に移行させるための特定の命令フレームを送信する。
【００３２】
ノード２ｂ〜２ｄは、受信したフレームをそのフレーム処理部３で解析し、上記命令フレームであると認識すると、当該命令フレーム中継後にスイッチ５をバイパス側に切り替える。これにより、命令フレームがネットワークを一巡してノード２ａに戻ったときには、図１（ｂ）に示す状態になる。すなわち、ノード２ａ以外のノード２ｂ〜２ｄのスイッチ５は、バイパス側に切り替わっている（すなわち、各ノード２ｂ〜２ｄはバイパスモードになっている）。ノード２ｂ〜２ｄの全てスイッチ５がバイパス側になると、バス型と同様で中継遅延の影響の無いネットワークになる。
【００３３】
ノード２ａは、上述の命令フレームがネットワーク１を１周して戻ってきた事をそのフレーム処理部３で認識したら、続いて同期用フレームを送信する。ノード２ｂ〜２ｄは、この同期用フレームをバイパスして中継すると共に、フレーム処理部３により同期用フレームの受信を認識する。フレーム処理部３はＣＰＵ４に同期用フレーム受信を通知する。また、ノード２ａのフレーム処理部３は、この同期用フレームがネットワーク１を１周して自ノードに戻ってきた事を認識すると、ＣＰＵ４に同期用フレーム受信を通知する。
【００３４】
上記の通り、同期用フレームはバイパスされるので、全てのノード２ａ〜２ｄにおいて、上記ＣＰＵ４に同期用フレーム受信が通知されるタイミングはほぼ同時であるので、各ノード２ａ〜２ｄのＣＰＵ４が、このタイミングを同期タイミングとすることにより、リング型ネットワークにおいてもノード間の同期のずれが生じることなく、タイミングが一致した同期がとれ、高速制御にも問題なく適用できるようになる。
【００３５】
また、ノード２ｂ〜２ｄのＣＰＵ４は、上記同期用フレーム受信が通知された後、スイッチ５を切り替え制御して、元の状態である図１（ａ）の状態に戻す。
尚、ＣＰＵ４により通常モード／バイパスモードに切換え制御される構成は、スイッチ５に限るものではなく、一時的に同期用フレームをバイパスさせる状態にできるものであれば何でもよい。
【００３６】
ノード２ａのＣＰＵ４は、上記ネットワーク１を１周して戻ってきた同期用フレーム受信が通知された後、当該同期用フレームを削除する。
以上の動作を表したタイムチャートが図３である。
【００３７】
ノード２ａの送信したスイッチ切り替え用の命令フレーム（コマンドフレーム）６ａは、ノード２ｂに受信され、命令フレーム６ｂとして中継される。同様に、ノード２ｃ、２ｄで中継され、命令フレーム６ｄがノード２ａに戻ってくる。この命令フレーム６ａ〜６ｃの受信でノード２ｂ〜２ｄ内のスイッチ５がバイパス側に切り替わる。
【００３８】
尚、命令フレーム６ａ〜６ｄは、その内容が変わるわけではないが、ヘッダ部の送信元／送信先（中継元／中継先）情報が変わるので、一応区別して符号を変えているだけである。
【００３９】
この状態で、次に、ノード２ａは同期用フレーム７を送信する。ノード２ａ〜２ｄはバイパスモードになっているので、この同期用フレーム７はバイパスされて、中継遅延無しでネットワーク１を１周する。また、この同期用フレーム７はバイパスされると共に、各ノード２ｂ〜２ｄのフレーム処理部３で受信される。各フレーム処理部３は、同期用フレームを受信した旨をＣＰＵ４に通知する。上記のように、各ノード２ａ〜２ｄが同期用フレーム７を受信するタイミングはほぼ同時なので、上記通知を受けたタイミングでＣＰＵ４が同期をとれば、全ノードでほぼタイミングが一致した同期をとることができる。
【００４０】
なお、ノード２ｂ〜２ｄは、同期用フレーム７の受信を以てスイッチ５を切り替えて通常モードに戻す。あるいはこれに限るものではなく、例えばバイパスモード中に何らかのフレームを受信すると通常モードに戻るようにしてもよい。このようにすると、何らかの異常で同期用フレーム７を受信できなくとも、次のフレームの受信で元の状態に戻ることができる。
【００４１】
次に、第２の実施例について説明する。
第１の実施例では、上記バイパスモードからスイッチ５を切り替えて通常モードに戻す条件を、同期用フレーム７の受信としている。または任意の（次の）フレーム受信としている。しかしながら、例えば、次のフレーム受信までに（すなわち、何れかのノードが何等かのフレームを送信するまでに）時間が掛かったり、あるいは例えばノード２ａが命令フレーム６ａを送信後に故障する等した場合には、他の全てのノード２ｂ〜２ｄがバイパス状態で同期用フレーム７の受信を待つ為、任意の（次の）フレームを送信するノードがなくなる。
【００４２】
第２の実施例では、上記の状況発生を考慮して、各ノード内にバイパスモード（バイパス状態）の継続時間を計時するタイマーを設け（通常、ＣＰＵ４のタイマ機能を利用できる）、これが一定時間以上、例えば１００μ秒以上続いた場合に、スイッチを元に戻すことを特徴とする。
【００４３】
これを行うと、何らかの異常で同期用フレーム７や任意のフレームを受信できなくとも、自動的に通常モードに戻ることができる。
次に、第３の実施例について説明する。
【００４４】
第３の実施例では、上記第１の実施例、第２の実施例とは異なり、各ノードの構成自体は、従来とほぼ同じでよい。すなわち、各ノード１０の構成は、図４に示すように、フレーム処理部１３とＣＰＵ１２を有しているが、バイパス路やスイッチ５は有していない。よって、スイッチ切り替え用の命令フレームを用いることも、各ノードがバイパスモードに移行することもないので、各ノードが同期用フレームを受信するタイミングはズレる。これは、後に説明する第４の実施例以降でも同様である。
【００４５】
しかしながら、従来と異なるのは、このズレを修正して、全てのノードでタイミングが一致した同期がとれるようにしている点である。
すなわち、第３の実施例では、各ノードで同期用フレームを受信した時点を同期タイミングとするのではなく、同期用フレーム受信時から任意の時間（本例では同期予定時間）遅らせた時点を同期タイミングとする。
【００４６】
第３の実施例の説明においても、４つのノードがリング型に接続したネットワークシステムを例にして説明する（特に図示しないが、ノード１０ａ〜ノード１０ｄがネットワーク１１に接続された構成とする）。また、ノード１０ａのタイミングにノード１０ｂ〜１０ｄを同期させる場合を例にして説明する。
【００４７】
各ノード１０ａ〜ノード１０ｄの構成は、上記の通り、図４に示す。
フレーム処理部１３は、リングの上流から来るフレームを処理して下流に中継すると共に、ＣＰＵ１２とデータや制御信号のやりとりを行なっている。
【００４８】
まず、ノード１０ａは、ネットワークを介してノード１０ｂ〜１０ｄに同期用フレームを送信する。
この同期用フレームは、そのプロトコルヘッダに同期用フレームを表すコードが格納され、データ部には同期予定時間が格納された、ブロードキャストフレームである。この同期予定時間は、同期用フレーム受信から同期タイミングまでの時間を表わし、本実施例では初期状態では１００μ秒とする。
【００４９】
第３の実施例の動作を表すものとして、図５のタイムチャートを示す。
ノード１０ａは、同期予定時間１００μ秒の同期用フレーム１４ａを送信する。ノード１０ｂは、このフレームを受信すると、予め設定されている自己の中継遅延時間を同期予定時間から引いた値を、新たな同期予定時間とする同期用フレーム１４ｂを作成して、これを次の（下流の）ノード１０ｃに送信する。本実施例ではノード１０ｂ〜１０ｄの中継遅延時間を何れも２μ秒とする。すると、ノード１０ｂでは、受信した際の同期予定時間が１００μ秒なので、２μ秒を引いて、９８μ秒を新たな同期予定時間とする同期用フレーム１４ｂを中継送信する。同様にノード１０ｃでは、受信したフレームの同期予定時間が９８μ秒なので、これを９６μ秒とする同期用フレーム１４ｃを中継送信する。同様にノード１０ｄでは、受信したフレームの同期予定時間が９６μ秒なので、これを９４μ秒とするフレーム１４ｄを中継送信する。ノード１０ａは、ノード１０ｄが中継した同期用フレーム１４ｄを受信すると、これを削除する。
【００５０】
そして、各ノード１０ａ〜１０ｄは、各々が同期用フレームを受信した時点から、この受信した同期用フレームの同期予定時間経過した時点を、同期タイミングとする。これにより、全ノードでほぼタイミングが一致した同期をとることができる。
【００５１】
すなわち、上記の例において、各ノードが同期用フレームを受信したタイミングと同期予定時間を示すと、ノード１０ａが同期用フレーム１４ａを送信したタイミングを原点とすると、ノード１０ｂは原点から０μ秒経過した時点で同期予定時間１００μ秒の同期用フレーム１４ａを受信し、ノード１０ｃは原点から２μ秒経過した時点で同期予定時間９８μ秒の同期用フレーム１４ｂを受信し、ノード１０ｄは原点から４μ秒経過した時点で同期予定時間９６μ秒の同期用フレーム１４ｃを受信し、ノード１０ａは原点から６μ秒経過した時点で同期予定時間９４μ秒の同期用フレーム１４ｄを受信する。よって、同期用フレームを受信したタイミングから同期予定時間経過時点は、全ノードとも、原点から１００μ秒経過した時点となる。よって、この時点を同期タイミングとすれば、全ノードでほぼタイミングが一致した同期をとることができる。
【００５２】
次に、第４の実施例について説明する。
上述した第３の実施例では、同期予定時間の初期値を１００μ秒としており、最後に同期用フレームを受信した時点（ネットワーク１１を一巡した同期用フレームをノード１０ａが受信した時点）から同期タイミングまで９４μ秒掛かっている。勿論、これは一例であるが、第３の実施例では、同期予定時間の初期値を多めに設定しておく必要がある。これは、当該ネットワークシステムは稼働開始後であっても随時ノード数を増減させる事が出来るため、ノード数が増加することを考慮しているからである。そうでないと、同期用フレームがネットワーク１１を一巡する前に同期予定時間を過ぎてしまう可能性もある。
【００５３】
これに対して、第４の実施例では、現在、フレームがネットワークを一巡するのに要する時間を、実測することにより、ノードの個数が変わっても最短の同期予定時間を設定可能にするものである。尚、第３の実施例においても、そのネットワークシステムではノードの個数があまり変わらないことが分かっている場合には、同期予定時間の初期値を多めに設定しておく必要はないことは言うまでもない。
【００５４】
第４の実施例は、上記同期予定時間を、同期用フレームを送信する前に、任意のフレームがネットワークを１周するのに掛かる時間を実測値して決定／設定するものである。
【００５５】
第４の実施例のノードの構成は、基本的には図４と同様であり、その処理内容が異なるので、ここでは図４に括弧内に示すように符号のみを変えて説明していくものとする。すなわち、ノード２０ａ〜２０ｄがネットワークに接続され、各ノードはフレーム処理部２３とＣＰＵ２２を有するものとして説明する。
【００５６】
ノード２０ａは、同期用フレームを送信する前に、何等かのフレーム（内容が無いテスト用フレームでよい）を送信して、このフレームがネットワークを一巡する時間を計測する。これは、例えばＣＰＵが通常備えるタイマ機能を用いて、ＣＰＵ２２が、フレーム送信時にタイマーを起動し、１周まわって戻ってきたフレームを受信したときタイマーを停止し、その値を保持すれば良い。この値は、例えば第３の実施例で述べた例のように各ノードでの遅延時間が２μ秒であるとした場合には、ノード２０ｂ〜２０ｄの遅延時間の合計である６μ秒となる。そして、この６μ秒にオフセット値を加えた値を同期予定時間にする。本例ではオフセット値を例えば４μ秒とすると、同期予定時間は１０μ秒になる。
【００５７】
上記オフセット値（例えば４μ秒）は、例えば、ノード２０ａの同期用フレーム受信からのオフセット時間（同期用フレーム受信から同期ポイントまでのＣＰＵのオーバーヘッド時間）を用いる。この時間は、ノードの個数に依存しない。従って、同期用フレーム受信から同期ポイントまでにＣＰＵのオーバーヘッド時間を必要とする場合でも、そのオーバーヘッド時間をオフセット値にすれば、ノードの個数に関係無く最短の時間の同期ポイントを設定する事が出来る。
【００５８】
第４の実施例の動作を表すものとして、図６のタイムチャートを示す。
同図には、上記同期予定時間を決定後の動作を示す。よって、図６に示す動作は、同期予定時間が１０μ秒である以外は、上記第３の実施例の図５と同じであるので、説明は省略する。
【００５９】
次に、第５の実施例について説明する。
第５の実施例においても、そのノードの構成は、基本的には図４と同様であり、その処理内容が異なるので、ここでは図４に括弧内に示すように符号のみを変えて説明していくものとする。すなわち、ノード３０ａ〜３０ｄがネットワークに接続し、各ノードはフレーム処理部３３とＣＰＵ３２を有し、リングの上流から来るフレームをフレーム処理部３３で処理して下流に中継すると共に、ＣＰＵ３２との間でデータや制御信号のやりとりを行なっているものとして説明する。
【００６０】
第５の実施例においては、ノード３０ａは、ネットワーク３１を介してノード３０ｂ〜３０ｄに、同期用フレームを２回送信する。
この同期用フレームは、プロトコルヘッダには同期用フレームを表すコードがあり、データ部には、このフレームが１周目か２周目かを判断する為の周回数ビット、および、同期予定時間が入った、ブロードキャストフレームである。
【００６１】
この同期予定時間は、初期値は０μ秒であり、１周目を巡回中に各ノードにおいて中継遅延時間が累積加算されていき、２周目においてはこの累積加算された結果としての同期予定時間（以下の例では８μ秒）が格納された同期用フレームが、ネットワーク３１を一巡する。そして、詳しくは以下に説明するが、各ノードは、１周目の同期予定時間（一時的に保持しておく）と２周目の同期予定時間とを用いて、同期タイミングを判断する。
【００６２】
第５の実施例の動作を表すものとして、図７のタイムチャートを示す。
ノード３０ａは、同期予定時間０μ秒、周回数ビットを１周目を示す値（図では白四角で示す）とした同期用フレーム３４ａを送信する。ノード３０ｂは、このフレーム３４ａを受信すると、その同期予定時間を保持するとともに、予め設定されている自ノードの中継遅延時間を同期予定時間に加えてから中継送信する。本例ではノード３０ａ〜３０ｄの中継遅延時間を一律２μ秒とする。すると、ノード３０ｂでは、受信した際の同期予定時間が０μ秒なので、この値を保持すると共に２μ秒を加えて２μ秒を新たな同期予定時間とする同期用フレーム３４ｂを中継送信する。同様にノード３０ｃでは、受信したフレームの同期予定時間が２μ秒なので、これを保持するとともに、４μ秒とした同期用フレーム３４ｃを中継送信する。同様にノード３０ｄでは、受信したフレームの同期予定時間が４μ秒なので、これを保持するとともに、６μ秒とした同期用フレーム３４ｄを中継送信する。ノード３０ａは、ノード３０ｄが中継した同期用フレーム３４ｄを受信すると、その同期予定時間６μ秒を保持すると共に、周回数ビットを２周目を示す値（図では黒四角で示す）とし且つ自ノードの中継遅延時間２μ秒を加えて同期予定時間が８μ秒とした同期用フレーム３５ａを送信する。
【００６３】
ノード３０ｂは、このフレーム３５ａを受信すると、その同期予定時間を保持してから中継送信する。本例では、同期予定時間が８μ秒なので、これを保持するとともに、今度は同期予定時間を更新することなく、同期用フレーム３５ｂを中継送信する。このように２周目では同期予定時間を更新せずに中継するので、ノード３０ｃ、３０ｄにおいても、受信したフレームの同期予定時間が８μ秒なので、これを保持すると共に中継送信する。そして、ノード３０ａは、ノード３０ｄが中継した同期用フレーム３５ｄを受信すると、その同期予定時間８μ秒を保持すると共に受信フレーム３５ｄを削除する。
【００６４】
なお、同期用フレームを受信した際のノードの動作が１周目と２周目とで違うが、これは、受信した同期用フレーム上の周回数ビットの状態でどちらの動作を行うか判断する。
【００６５】
上述した動作により、各ノードには、１周目と２周目にそれぞれ受信した同期用フレームに格納される同期予定時間が保持される。
ここで、各ノードが２周目の同期用フレームを受信したタイミングと同期予定時間を示すと、ノード３０ａが１周目の同期用フレーム３４ａを送信したタイミングを原点とすると、ノード３０ｂは、原点から８μ秒後に２周目の同期用フレーム３５ａを受信する。また、保持される同期予定時間は、１周目が０μ秒で２周目が８μ秒である。ノード３０ｃは、原点から１０μ秒後に同期用フレーム３５ｂを受信する。また、保持される同期予定時間は、１周目が２μ秒で２周目が８μ秒である。ノード３０ｄは、原点から１２μ秒後に同期用フレーム３５ｃを受信する。また、保持される同期予定時間は、１周目が４μ秒で２周目が８μ秒である。ノード３０ａは、原点から１４μ秒後に同期用フレーム３５ｄを受信する。また、保持される同期予定時間は、１周目が６μ秒で２周目が８μ秒である。
【００６６】
つまり、２周目の同期用フレームを受信したタイミングに、２周目と１周目の同期予定時間の差分（本例ではそれぞれ８μ秒，６μ秒，４μ秒，２μ秒）を加えた時間は、全ノードとも１６μ秒になる。
【００６７】
よって、この時点（すなわち、原点から１６μ秒後）を同期タイミングとすれば、全ノードでほぼタイミングが一致した同期をとることができる。すなわち、各ノードは、２周目の同期用フレームを受信した時点から、２周目と１周目の同期予定時間の差分の時間経過したときが、同期タイミングであると判断する。本例では、２周目の同期用フレームを受信した時点から、ノード３０ｂは８−０＝８μ秒後、ノード３０ｃは８−２＝６μ秒後、ノード３０ｄは８−４＝４μ秒後、ノード３０ａは８−６＝２μ秒後を、それぞれ、同期タイミングとすることにより、結果、いずれのノードにおいても、原点から１６μ秒後が同期タイミングとなり、全ノードでほぼタイミングが一致する。
【００６８】
次に、第６の実施例について説明する。
第６の実施例においても、そのノードの構成は、基本的には図４と同様であり、その処理内容が異なるので、ここでは図４に括弧内に示すように符号のみを変えて説明していくものとする。すなわち、ノード４０ａ〜４０ｄがネットワークに接続し、各ノードはフレーム処理部４３とＣＰＵ４２を有し、リングの上流から来るフレームをフレーム処理部４３で処理して下流に中継すると共に、ＣＰＵ４２との間でデータや制御信号のやりとりを行なっているものとして説明する。
【００６９】
第６の実施例は、上記第５の実施例における各ノードの中継遅延時間の累積値に、オフセットを加えたものを同期予定時間とするものである。これは、第４の実施例と同様に、同期用フレーム受信から同期ポイントまでに、ＣＰＵのオーバーヘッド等で余裕が必要な場合に対応するものである。
【００７０】
本例ではオフセットとして４μ秒を、ノード４０ａの本来の中継遅延時間である２μ秒に加えて、６μ秒を新たな中継遅延値とする。この状態でノード４０ａに同期をとる際のタイムチャートを図８に示す。
【００７１】
ノード４０ａが送信する同期用フレーム４４ａの１周目の動きは、上記第５の実施例と同じである。１周まわった同期用フレーム４４ｄを受信したノード４０ａは、それを２周目に変更して中継する際に、受信した同期予定時間である６μ秒に上記新たな中継遅延値である６μ秒を加える。すると２周目の同期用フレーム４５ａの同期予定時間は１２μ秒になる。これ以降の動作も上記第５の実施例と同じであるが、同期ポイントがオフセットの分だけ遅れたタイミングになる。
【００７２】
上述した動作により、各ノードには、１周目と２周目にそれぞれ受信した同期用フレームに格納される同期予定時間が保持される。
ここで、各ノードが２周目の同期用フレームを受信したタイミングと同期予定時間を示すと、ノード４０ａが１周目の同期用フレーム４４ａを送信したタイミングを原点とすると、ノード４０ｂは、原点から８μ秒後に２周目の同期用フレーム４５ａを受信する。また、保持される同期予定時間は、１周目が０μ秒で２周目が１２μ秒である。ノード４０ｃは、原点から１０μ秒後に同期用フレーム４５ｂを受信する。また、保持される同期予定時間は、１周目が２μ秒で２周目が１２μ秒である。ノード４０ｄは、原点から１２μ秒後に同期用フレーム４５ｃを受信する。また、保持される同期予定時間は、１周目が４μ秒で２周目が１２μ秒である。ノード４０ａは、原点から１４μ秒後に同期用フレーム４５ｄを受信する。また、保持される同期予定時間は、１周目が６μ秒で２周目が１２μ秒である。
【００７３】
つまり、２周目の同期用フレームを受信したタイミングに、２周目と１周目の同期予定時間の差分（本例ではそれぞれ１２μ秒，１０μ秒，８μ秒，６μ秒）を加えた時間は、全ノードとも２０μ秒になる。
【００７４】
この時点を同期タイミングとすれば、全ノードでほぼタイミングが一致した同期をとることができる。また、このタイミングは、上記の通り、第５の実施例のタイミングにオフセットである４μ秒を加えたものであり、ノード４０ａにおいて２周目の同期用フレーム４５ｄを受信してから同期ポイントまでに、ＣＰＵのオーバーヘッド等で余裕が必要な場合にも対応することができる。
【００７５】
上述の第１の実施例〜第６の実施例のいずれの同期方法を用いても、ノード毎に中継遅延のあるリング型ネットワークにおいても、同期ずれをほぼ０にすることができる。
【００７６】
例えば、上記第１の実施例で、ノード２ａ，２ｂ，２ｃにそれぞれＸ，Ｙ，Ｚ軸のモーターを制御させた場合、従来技術では、Ｘ軸とＹ軸間で２μ秒、Ｘ軸とＺ軸間で４μ秒、の誤差が発生する。さらに、ノード２ａ，２ｂ，２ｃの間にノードを４９個ずつ入れれば、追加ノードの中継遅延の影響で軸間の誤差は大きなり、Ｘ軸とＹ軸間で１００μ秒、Ｘ軸とＺ軸間で２００μ秒になる。このため、Ｘ，Ｙ，Ｚ軸間のノードを減らさなければ同期ずれによる障害が発生するかもしれない。また、この事をエンジニアリングや設置の際に注意しなければならない。
【００７７】
しかし、本発明の同期方法を使えば、中継遅延の影響を除くことが出来るので、Ｘ，Ｙ，Ｚ軸のモーターを繋げるノードとノードの間に別のノードがいくつ有っても同期ずれはなくなり、エンジニアリングや設置の際の自由度が増すとともに、不注意な配置が原因の同期ずれによる障害を未然に防ぐことが出来る。
【００７８】
【発明の効果】
以上、詳細に説明したように、本発明のリング型ネットワークにおけるノード間のタイミング同期方法によれば、ノード毎に中継遅延のあるリング型ネットワークにおいても、同期ずれをほぼ０にすることができ、全ノードでほぼタイミングが一致した同期をとることができる。特に、当該リング型ネットワークを例えば制御システムに適用する場合でも、同期ずれによる障害を未然に防ぐことができ、高速制御にも問題なく適用できる。
【図面の簡単な説明】
【図１】（ａ）、（ｂ）は、第１の実施例を説明する為の図である。
【図２】図１の各ノードの概略構成図である。
【図３】第１の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図４】第３の実施例（または第４〜第６の実施例）におけるノードの概略構成図である。
【図５】第３の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図６】第４の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図７】第５の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図８】第６の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図９】バス型のネットワークシステムの一例を示す図である。
【図１０】バス型において全ノードの同期を取るタイムチャート図である。
【図１１】リング型のネットワークシステムの一例を示す図である。
【図１２】図１１における各ノードの概略構成図である。
【図１３】リング型において全ノードの同期を取るタイムチャート図である。
【符号の説明】
１ ネットワーク
２ａ〜２ｄ ノード
３ フレーム処理部
４ ＣＰＵ
５ スイッチ
６ａ〜６ｄ 命令フレーム
７ 同期用フレーム
１０（１０ａ〜１０ｄ） ノード
１２ ＣＰＵ
１３ フレーム処理部
１４ａ〜１４ｄ 同期用フレーム
２０（２０ａ〜２０ｄ） ノード
２２ ＣＰＵ
２３ フレーム処理部
２４ａ〜２４ｄ 同期用フレーム
３０（３０ａ〜３０ｄ） ノード
３２ ＣＰＵ
３３ フレーム処理部
３４ａ〜３４ｄ 同期用フレーム（１周目）
３５ａ〜３５ｄ 同期用フレーム（２周目）
４０（４０ａ〜４０ｄ） ノード
４２ ＣＰＵ
４３ フレーム処理部
４４ａ〜４４ｄ 同期用フレーム（１周目）
４５ａ〜４５ｄ 同期用フレーム（２周目）
【発明の属する技術分野】
本発明は、リング型ネットワークシステムにおいて、ノード間のタイミングを同期させる方法に関する。
【０００２】
【従来の技術】
複数のノードをネットワークに接続する形態として、バス型やリング型のネットワークシステムがある。
【０００３】
バス型は、共通の経路であるバスに複数ノードを並列に接続した形態で、あるノードの送信したフレームがほぼ同時に全ノードに到達するという特徴がある。
図９は、４つのノード５０ａ〜５０ｄをネットワーク５１にバス型に接続した例で、ノード５０ａが送信するフレームは、ほぼ同時にノード５０ｂ〜５０ｄに到達する。
【０００４】
図１０は、全ノードの同期を取るために、ノード５０ａが同期用のフレームを送信したときに、そのフレームが他のノードにどう届き、どういう同期がどうとれるかを表した図である。この同期用フレームは、プロトコルヘッダに同期用フレームを表すコードが格納されたブロードキャストフレームである。ノード５０ａが送信した同期用のフレーム５２は、ほぼ同時に自分を含めた全ノードに受信されるので、この受信タイミングを同期ポイントとして同期をとれば、全ノードの同期はほぼ一致する。
【０００５】
一方、図１１の示すようなリング型は、複数ノードをデイジーチェインで環状に接続する形態で、あるノードの送信したフレームは下流のノードの中継でリングを１周するので、ノード毎の中継遅延の影響で全ノードに同時に到達しないという特徴がある。なお、フレームは、リングを１周まわったところで、最初に送信したノードが削除する。
【０００６】
図１１は、４つのノード６０ａ〜６０ｄをネットワーク６１でリング型に接続した例で、ノード６０ａが送信するフレームは、ノード６０ｂ，ノード６０ｃ，ノード６０ｄの順に中継されてネットワーク６１を１周まわり、ノード６０ａに戻ったところで削除される。
【０００７】
図１２は、図１１のノード６０ａ〜６０ｄの構成の一例を示す図であり、同図ではノード６０ａを例にするが、他のノードの構成も同様である。
同図において、フレーム処理部６３は、受信したフレームの判定を行ない、これを下流に送信する事によりフレームを中継する。ＣＰＵ６２は、ノード６０ａ全体を制御する中央処理装置であり、フレーム処理部６３も制御する。
【０００８】
図１３は、全ノードの同期を取るために、ノード６０ａが同期用のフレームを送信したときに、そのフレームが他のノードにどう届き、どういう同期がどうとれるかを表した図である。ノード６０ａが送信した同期用フレーム６４ａは、まずノード６０ｂに受信され、図１２のフレーム処理部６３でフレームの判定を行ない、これを下流に送信する事により中継される。ここでは、フレーム受信してからの送信するまでのフレーム処理部６３の遅延を２μ秒とすると、次のノード６０ｃが中継された同期用フレーム６４ｂを受信するのは、ノード６０ｂが同期用フレーム６４ａを受信した時点より２μ秒遅れる。同様にノード６０ｄが同期用フレーム６４ｃを受信するのは、ノード６０ｃより２μ秒、すなわち、ノード６０ｂより４μ秒遅れる。ノード６０ａが同期用フレーム６４ｄを受信するのは、ノード６０ｂより６μ秒遅れる。この為、各ノードがそれぞれ同期用フレームの受信認識のタイミングを同期ポイントとすると、４つのノードしか無いにもかかわらず、６μ秒もの同期のずれが生じることになる。
【０００９】
【発明が解決しようとする課題】
上述したように、ノード間で同期をとる場合、フレームの受信タイミングがほぼ一致するバス型に比べ、リング型ではフレームの受信タイミングの遅れが同期タイミングの遅れに繋がり、リングの下流のノードほど同期が遅れていく。
【００１０】
例えば、１ノードで２μ秒の遅れになるとすれば、１００ノードで２００μ秒の遅れになる。最上流のノードと最下流のノードでそれぞれＸ軸，Ｙ軸のモーターを制御させ、最上流のノードと最下流のノードの間にあるノードにセンサー類を配置すると、軸間の同期のずれは２００μ秒になる。このずれが問題になる様な高速制御に適用する際は、モーターを制御するノードを接近させる（間にノードを挟まない）ように制約を設け、エンジニアリングや設置の際に注意しなければならない。
【００１１】
本発明の課題は、リング型ネットワークにおける上述したノード間の同期のずれを解消し、タイミングが一致した同期がとれ、高速制御にも問題なく適用できるリング型ネットワークにおけるノード間のタイミング同期方法、及びそのノードを提供することである。
【００１２】
【課題を解決するための手段】
本発明による第１のタイミング同期方法は、リング型ネットワークシステムにおける同期方法であって、送信元のノードは、特定のコマンドフレームを送信し、他のノードは、該特定のコマンドフレームを受信すると、該コマンドフレームを中継すると共にバイパスモードに移行し、リングを一巡した前記特定のコマンドフレームを受信した前記送信元のノードは、同期用フレームを送信し、前記バイパスモード状態にある他のノードは、該同期用フレームをバイパスすると共に、該同期用フレームの受信タイミングで同期をとるものである。
【００１３】
上記第１のタイミング同期方法では、同期の基準となるノード（送信元のノード）が、自ノード以外の全ノードの中継経路上のフレーム処理が一時的にバイパス状態になる命令を持つコマンドフレームを他のノードに送信し、その後に同期用フレームを送信する。各ノードは、この同期用フレームをバイパスすると共に、この同期用フレーム受信時を同期タイミングにする。
【００１４】
このように一時的にフレーム処理をバイパスする事により、各ノードのフレーム処理部で発生していた中継遅延は無くなる。すると、全モジュールがほぼ同時に同期用フレームを受信する事ができ、このフレーム受信を同期のタイミングにすることにより、バス型と同等の精度でモジュール間の同期をとることができる。同期を取った後はバイパス状態を解除する必要があるが、同期用フレームの受信をフレーム処理部で認識する頃には、中継し終わっているので、同期用フレームの受信をもってバイパス状態を解除すれば、次のフレームから本来のリング型のネットワークで送受信できる。
【００１５】
または、上記バイパス状態の解除の条件に、一定時間以上バイパス状態が継続したことを加えるようにしてもよい。
全モジュールがフレーム処理部をバイパス状態にした後に、同期用フレームが消失等、何らかの原因で、受信されなければ、バイパス状態を解除する事はできない。しかし上記解除条件を加えることにより、遅くとも一定時間経過後にはバイパス状態が解除され、その次のフレームから本来のリング型のネットワークで送受信できる。
【００２８】
【発明の実施の形態】
以下、図面を参照して、本発明の実施の形態について説明する。
図１（ａ）、（ｂ）は、第１の実施例を説明する為の図である。
【００２９】
本実施例では、ノード２ａ〜２ｄの４つのノードを、ネットワーク１によってリング型に接続している。
また、図２に示す様に、各ノード２ａ〜２ｄは、フレーム処理部３、ＣＰＵ４、スイッチ５を有する。尚、図１では、ＣＰＵ４、スイッチ５は省略し、ノード２ａ〜２ｄ内にフレーム処理部３を示し、またスイッチ５の切換／選択（フレーム処理部３側か、バイパス側かの切換／選択；選択されていない側はバツ印（×）を示す）を記述している。
【００３０】
ここでは、ノード２ａのタイミングにノード２ｂ〜２ｄを同期させる場合を例にして説明する。
まず、通常時には、図１（ａ）に示すように、各ノード２ａ〜２ｄのスイッチ５は、フレーム処理部３側になっている（これを通常モードと呼ぶ）。
【００３１】
同期をとる際には、ノード２ａは、ネットワーク１を介してノード２ｂ〜２ｄに対して、バイパスモード（スイッチ５がバイパス側に切換えられ、受信したフレームはフレーム処理部３を介さずに中継させる状態）に移行させるための特定の命令フレームを送信する。
【００３２】
ノード２ｂ〜２ｄは、受信したフレームをそのフレーム処理部３で解析し、上記命令フレームであると認識すると、当該命令フレーム中継後にスイッチ５をバイパス側に切り替える。これにより、命令フレームがネットワークを一巡してノード２ａに戻ったときには、図１（ｂ）に示す状態になる。すなわち、ノード２ａ以外のノード２ｂ〜２ｄのスイッチ５は、バイパス側に切り替わっている（すなわち、各ノード２ｂ〜２ｄはバイパスモードになっている）。ノード２ｂ〜２ｄの全てスイッチ５がバイパス側になると、バス型と同様で中継遅延の影響の無いネットワークになる。
【００３３】
ノード２ａは、上述の命令フレームがネットワーク１を１周して戻ってきた事をそのフレーム処理部３で認識したら、続いて同期用フレームを送信する。ノード２ｂ〜２ｄは、この同期用フレームをバイパスして中継すると共に、フレーム処理部３により同期用フレームの受信を認識する。フレーム処理部３はＣＰＵ４に同期用フレーム受信を通知する。また、ノード２ａのフレーム処理部３は、この同期用フレームがネットワーク１を１周して自ノードに戻ってきた事を認識すると、ＣＰＵ４に同期用フレーム受信を通知する。
【００３４】
上記の通り、同期用フレームはバイパスされるので、全てのノード２ａ〜２ｄにおいて、上記ＣＰＵ４に同期用フレーム受信が通知されるタイミングはほぼ同時であるので、各ノード２ａ〜２ｄのＣＰＵ４が、このタイミングを同期タイミングとすることにより、リング型ネットワークにおいてもノード間の同期のずれが生じることなく、タイミングが一致した同期がとれ、高速制御にも問題なく適用できるようになる。
【００３５】
また、ノード２ｂ〜２ｄのＣＰＵ４は、上記同期用フレーム受信が通知された後、スイッチ５を切り替え制御して、元の状態である図１（ａ）の状態に戻す。
尚、ＣＰＵ４により通常モード／バイパスモードに切換え制御される構成は、スイッチ５に限るものではなく、一時的に同期用フレームをバイパスさせる状態にできるものであれば何でもよい。
【００３６】
ノード２ａのＣＰＵ４は、上記ネットワーク１を１周して戻ってきた同期用フレーム受信が通知された後、当該同期用フレームを削除する。
以上の動作を表したタイムチャートが図３である。
【００３７】
ノード２ａの送信したスイッチ切り替え用の命令フレーム（コマンドフレーム）６ａは、ノード２ｂに受信され、命令フレーム６ｂとして中継される。同様に、ノード２ｃ、２ｄで中継され、命令フレーム６ｄがノード２ａに戻ってくる。この命令フレーム６ａ〜６ｃの受信でノード２ｂ〜２ｄ内のスイッチ５がバイパス側に切り替わる。
【００３８】
尚、命令フレーム６ａ〜６ｄは、その内容が変わるわけではないが、ヘッダ部の送信元／送信先（中継元／中継先）情報が変わるので、一応区別して符号を変えているだけである。
【００３９】
この状態で、次に、ノード２ａは同期用フレーム７を送信する。ノード２ａ〜２ｄはバイパスモードになっているので、この同期用フレーム７はバイパスされて、中継遅延無しでネットワーク１を１周する。また、この同期用フレーム７はバイパスされると共に、各ノード２ｂ〜２ｄのフレーム処理部３で受信される。各フレーム処理部３は、同期用フレームを受信した旨をＣＰＵ４に通知する。上記のように、各ノード２ａ〜２ｄが同期用フレーム７を受信するタイミングはほぼ同時なので、上記通知を受けたタイミングでＣＰＵ４が同期をとれば、全ノードでほぼタイミングが一致した同期をとることができる。
【００４０】
なお、ノード２ｂ〜２ｄは、同期用フレーム７の受信を以てスイッチ５を切り替えて通常モードに戻す。あるいはこれに限るものではなく、例えばバイパスモード中に何らかのフレームを受信すると通常モードに戻るようにしてもよい。このようにすると、何らかの異常で同期用フレーム７を受信できなくとも、次のフレームの受信で元の状態に戻ることができる。
【００４１】
次に、第２の実施例について説明する。
第１の実施例では、上記バイパスモードからスイッチ５を切り替えて通常モードに戻す条件を、同期用フレーム７の受信としている。または任意の（次の）フレーム受信としている。しかしながら、例えば、次のフレーム受信までに（すなわち、何れかのノードが何等かのフレームを送信するまでに）時間が掛かったり、あるいは例えばノード２ａが命令フレーム６ａを送信後に故障する等した場合には、他の全てのノード２ｂ〜２ｄがバイパス状態で同期用フレーム７の受信を待つ為、任意の（次の）フレームを送信するノードがなくなる。
【００４２】
第２の実施例では、上記の状況発生を考慮して、各ノード内にバイパスモード（バイパス状態）の継続時間を計時するタイマーを設け（通常、ＣＰＵ４のタイマ機能を利用できる）、これが一定時間以上、例えば１００μ秒以上続いた場合に、スイッチを元に戻すことを特徴とする。
【００４３】
これを行うと、何らかの異常で同期用フレーム７や任意のフレームを受信できなくとも、自動的に通常モードに戻ることができる。
次に、第３の実施例について説明する。
【００４４】
第３の実施例では、上記第１の実施例、第２の実施例とは異なり、各ノードの構成自体は、従来とほぼ同じでよい。すなわち、各ノード１０の構成は、図４に示すように、フレーム処理部１３とＣＰＵ１２を有しているが、バイパス路やスイッチ５は有していない。よって、スイッチ切り替え用の命令フレームを用いることも、各ノードがバイパスモードに移行することもないので、各ノードが同期用フレームを受信するタイミングはズレる。これは、後に説明する第４の実施例以降でも同様である。
【００４５】
しかしながら、従来と異なるのは、このズレを修正して、全てのノードでタイミングが一致した同期がとれるようにしている点である。
すなわち、第３の実施例では、各ノードで同期用フレームを受信した時点を同期タイミングとするのではなく、同期用フレーム受信時から任意の時間（本例では同期予定時間）遅らせた時点を同期タイミングとする。
【００４６】
第３の実施例の説明においても、４つのノードがリング型に接続したネットワークシステムを例にして説明する（特に図示しないが、ノード１０ａ〜ノード１０ｄがネットワーク１１に接続された構成とする）。また、ノード１０ａのタイミングにノード１０ｂ〜１０ｄを同期させる場合を例にして説明する。
【００４７】
各ノード１０ａ〜ノード１０ｄの構成は、上記の通り、図４に示す。
フレーム処理部１３は、リングの上流から来るフレームを処理して下流に中継すると共に、ＣＰＵ１２とデータや制御信号のやりとりを行なっている。
【００４８】
まず、ノード１０ａは、ネットワークを介してノード１０ｂ〜１０ｄに同期用フレームを送信する。
この同期用フレームは、そのプロトコルヘッダに同期用フレームを表すコードが格納され、データ部には同期予定時間が格納された、ブロードキャストフレームである。この同期予定時間は、同期用フレーム受信から同期タイミングまでの時間を表わし、本実施例では初期状態では１００μ秒とする。
【００４９】
第３の実施例の動作を表すものとして、図５のタイムチャートを示す。
ノード１０ａは、同期予定時間１００μ秒の同期用フレーム１４ａを送信する。ノード１０ｂは、このフレームを受信すると、予め設定されている自己の中継遅延時間を同期予定時間から引いた値を、新たな同期予定時間とする同期用フレーム１４ｂを作成して、これを次の（下流の）ノード１０ｃに送信する。本実施例ではノード１０ｂ〜１０ｄの中継遅延時間を何れも２μ秒とする。すると、ノード１０ｂでは、受信した際の同期予定時間が１００μ秒なので、２μ秒を引いて、９８μ秒を新たな同期予定時間とする同期用フレーム１４ｂを中継送信する。同様にノード１０ｃでは、受信したフレームの同期予定時間が９８μ秒なので、これを９６μ秒とする同期用フレーム１４ｃを中継送信する。同様にノード１０ｄでは、受信したフレームの同期予定時間が９６μ秒なので、これを９４μ秒とするフレーム１４ｄを中継送信する。ノード１０ａは、ノード１０ｄが中継した同期用フレーム１４ｄを受信すると、これを削除する。
【００５０】
そして、各ノード１０ａ〜１０ｄは、各々が同期用フレームを受信した時点から、この受信した同期用フレームの同期予定時間経過した時点を、同期タイミングとする。これにより、全ノードでほぼタイミングが一致した同期をとることができる。
【００５１】
すなわち、上記の例において、各ノードが同期用フレームを受信したタイミングと同期予定時間を示すと、ノード１０ａが同期用フレーム１４ａを送信したタイミングを原点とすると、ノード１０ｂは原点から０μ秒経過した時点で同期予定時間１００μ秒の同期用フレーム１４ａを受信し、ノード１０ｃは原点から２μ秒経過した時点で同期予定時間９８μ秒の同期用フレーム１４ｂを受信し、ノード１０ｄは原点から４μ秒経過した時点で同期予定時間９６μ秒の同期用フレーム１４ｃを受信し、ノード１０ａは原点から６μ秒経過した時点で同期予定時間９４μ秒の同期用フレーム１４ｄを受信する。よって、同期用フレームを受信したタイミングから同期予定時間経過時点は、全ノードとも、原点から１００μ秒経過した時点となる。よって、この時点を同期タイミングとすれば、全ノードでほぼタイミングが一致した同期をとることができる。
【００５２】
次に、第４の実施例について説明する。
上述した第３の実施例では、同期予定時間の初期値を１００μ秒としており、最後に同期用フレームを受信した時点（ネットワーク１１を一巡した同期用フレームをノード１０ａが受信した時点）から同期タイミングまで９４μ秒掛かっている。勿論、これは一例であるが、第３の実施例では、同期予定時間の初期値を多めに設定しておく必要がある。これは、当該ネットワークシステムは稼働開始後であっても随時ノード数を増減させる事が出来るため、ノード数が増加することを考慮しているからである。そうでないと、同期用フレームがネットワーク１１を一巡する前に同期予定時間を過ぎてしまう可能性もある。
【００５３】
これに対して、第４の実施例では、現在、フレームがネットワークを一巡するのに要する時間を、実測することにより、ノードの個数が変わっても最短の同期予定時間を設定可能にするものである。尚、第３の実施例においても、そのネットワークシステムではノードの個数があまり変わらないことが分かっている場合には、同期予定時間の初期値を多めに設定しておく必要はないことは言うまでもない。
【００５４】
第４の実施例は、上記同期予定時間を、同期用フレームを送信する前に、任意のフレームがネットワークを１周するのに掛かる時間を実測値して決定／設定するものである。
【００５５】
第４の実施例のノードの構成は、基本的には図４と同様であり、その処理内容が異なるので、ここでは図４に括弧内に示すように符号のみを変えて説明していくものとする。すなわち、ノード２０ａ〜２０ｄがネットワークに接続され、各ノードはフレーム処理部２３とＣＰＵ２２を有するものとして説明する。
【００５６】
ノード２０ａは、同期用フレームを送信する前に、何等かのフレーム（内容が無いテスト用フレームでよい）を送信して、このフレームがネットワークを一巡する時間を計測する。これは、例えばＣＰＵが通常備えるタイマ機能を用いて、ＣＰＵ２２が、フレーム送信時にタイマーを起動し、１周まわって戻ってきたフレームを受信したときタイマーを停止し、その値を保持すれば良い。この値は、例えば第３の実施例で述べた例のように各ノードでの遅延時間が２μ秒であるとした場合には、ノード２０ｂ〜２０ｄの遅延時間の合計である６μ秒となる。そして、この６μ秒にオフセット値を加えた値を同期予定時間にする。本例ではオフセット値を例えば４μ秒とすると、同期予定時間は１０μ秒になる。
【００５７】
上記オフセット値（例えば４μ秒）は、例えば、ノード２０ａの同期用フレーム受信からのオフセット時間（同期用フレーム受信から同期ポイントまでのＣＰＵのオーバーヘッド時間）を用いる。この時間は、ノードの個数に依存しない。従って、同期用フレーム受信から同期ポイントまでにＣＰＵのオーバーヘッド時間を必要とする場合でも、そのオーバーヘッド時間をオフセット値にすれば、ノードの個数に関係無く最短の時間の同期ポイントを設定する事が出来る。
【００５８】
第４の実施例の動作を表すものとして、図６のタイムチャートを示す。
同図には、上記同期予定時間を決定後の動作を示す。よって、図６に示す動作は、同期予定時間が１０μ秒である以外は、上記第３の実施例の図５と同じであるので、説明は省略する。
【００５９】
次に、第５の実施例について説明する。
第５の実施例においても、そのノードの構成は、基本的には図４と同様であり、その処理内容が異なるので、ここでは図４に括弧内に示すように符号のみを変えて説明していくものとする。すなわち、ノード３０ａ〜３０ｄがネットワークに接続し、各ノードはフレーム処理部３３とＣＰＵ３２を有し、リングの上流から来るフレームをフレーム処理部３３で処理して下流に中継すると共に、ＣＰＵ３２との間でデータや制御信号のやりとりを行なっているものとして説明する。
【００６０】
第５の実施例においては、ノード３０ａは、ネットワーク３１を介してノード３０ｂ〜３０ｄに、同期用フレームを２回送信する。
この同期用フレームは、プロトコルヘッダには同期用フレームを表すコードがあり、データ部には、このフレームが１周目か２周目かを判断する為の周回数ビット、および、同期予定時間が入った、ブロードキャストフレームである。
【００６１】
この同期予定時間は、初期値は０μ秒であり、１周目を巡回中に各ノードにおいて中継遅延時間が累積加算されていき、２周目においてはこの累積加算された結果としての同期予定時間（以下の例では８μ秒）が格納された同期用フレームが、ネットワーク３１を一巡する。そして、詳しくは以下に説明するが、各ノードは、１周目の同期予定時間（一時的に保持しておく）と２周目の同期予定時間とを用いて、同期タイミングを判断する。
【００６２】
第５の実施例の動作を表すものとして、図７のタイムチャートを示す。
ノード３０ａは、同期予定時間０μ秒、周回数ビットを１周目を示す値（図では白四角で示す）とした同期用フレーム３４ａを送信する。ノード３０ｂは、このフレーム３４ａを受信すると、その同期予定時間を保持するとともに、予め設定されている自ノードの中継遅延時間を同期予定時間に加えてから中継送信する。本例ではノード３０ａ〜３０ｄの中継遅延時間を一律２μ秒とする。すると、ノード３０ｂでは、受信した際の同期予定時間が０μ秒なので、この値を保持すると共に２μ秒を加えて２μ秒を新たな同期予定時間とする同期用フレーム３４ｂを中継送信する。同様にノード３０ｃでは、受信したフレームの同期予定時間が２μ秒なので、これを保持するとともに、４μ秒とした同期用フレーム３４ｃを中継送信する。同様にノード３０ｄでは、受信したフレームの同期予定時間が４μ秒なので、これを保持するとともに、６μ秒とした同期用フレーム３４ｄを中継送信する。ノード３０ａは、ノード３０ｄが中継した同期用フレーム３４ｄを受信すると、その同期予定時間６μ秒を保持すると共に、周回数ビットを２周目を示す値（図では黒四角で示す）とし且つ自ノードの中継遅延時間２μ秒を加えて同期予定時間が８μ秒とした同期用フレーム３５ａを送信する。
【００６３】
ノード３０ｂは、このフレーム３５ａを受信すると、その同期予定時間を保持してから中継送信する。本例では、同期予定時間が８μ秒なので、これを保持するとともに、今度は同期予定時間を更新することなく、同期用フレーム３５ｂを中継送信する。このように２周目では同期予定時間を更新せずに中継するので、ノード３０ｃ、３０ｄにおいても、受信したフレームの同期予定時間が８μ秒なので、これを保持すると共に中継送信する。そして、ノード３０ａは、ノード３０ｄが中継した同期用フレーム３５ｄを受信すると、その同期予定時間８μ秒を保持すると共に受信フレーム３５ｄを削除する。
【００６４】
なお、同期用フレームを受信した際のノードの動作が１周目と２周目とで違うが、これは、受信した同期用フレーム上の周回数ビットの状態でどちらの動作を行うか判断する。
【００６５】
上述した動作により、各ノードには、１周目と２周目にそれぞれ受信した同期用フレームに格納される同期予定時間が保持される。
ここで、各ノードが２周目の同期用フレームを受信したタイミングと同期予定時間を示すと、ノード３０ａが１周目の同期用フレーム３４ａを送信したタイミングを原点とすると、ノード３０ｂは、原点から８μ秒後に２周目の同期用フレーム３５ａを受信する。また、保持される同期予定時間は、１周目が０μ秒で２周目が８μ秒である。ノード３０ｃは、原点から１０μ秒後に同期用フレーム３５ｂを受信する。また、保持される同期予定時間は、１周目が２μ秒で２周目が８μ秒である。ノード３０ｄは、原点から１２μ秒後に同期用フレーム３５ｃを受信する。また、保持される同期予定時間は、１周目が４μ秒で２周目が８μ秒である。ノード３０ａは、原点から１４μ秒後に同期用フレーム３５ｄを受信する。また、保持される同期予定時間は、１周目が６μ秒で２周目が８μ秒である。
【００６６】
つまり、２周目の同期用フレームを受信したタイミングに、２周目と１周目の同期予定時間の差分（本例ではそれぞれ８μ秒，６μ秒，４μ秒，２μ秒）を加えた時間は、全ノードとも１６μ秒になる。
【００６７】
よって、この時点（すなわち、原点から１６μ秒後）を同期タイミングとすれば、全ノードでほぼタイミングが一致した同期をとることができる。すなわち、各ノードは、２周目の同期用フレームを受信した時点から、２周目と１周目の同期予定時間の差分の時間経過したときが、同期タイミングであると判断する。本例では、２周目の同期用フレームを受信した時点から、ノード３０ｂは８−０＝８μ秒後、ノード３０ｃは８−２＝６μ秒後、ノード３０ｄは８−４＝４μ秒後、ノード３０ａは８−６＝２μ秒後を、それぞれ、同期タイミングとすることにより、結果、いずれのノードにおいても、原点から１６μ秒後が同期タイミングとなり、全ノードでほぼタイミングが一致する。
【００６８】
次に、第６の実施例について説明する。
第６の実施例においても、そのノードの構成は、基本的には図４と同様であり、その処理内容が異なるので、ここでは図４に括弧内に示すように符号のみを変えて説明していくものとする。すなわち、ノード４０ａ〜４０ｄがネットワークに接続し、各ノードはフレーム処理部４３とＣＰＵ４２を有し、リングの上流から来るフレームをフレーム処理部４３で処理して下流に中継すると共に、ＣＰＵ４２との間でデータや制御信号のやりとりを行なっているものとして説明する。
【００６９】
第６の実施例は、上記第５の実施例における各ノードの中継遅延時間の累積値に、オフセットを加えたものを同期予定時間とするものである。これは、第４の実施例と同様に、同期用フレーム受信から同期ポイントまでに、ＣＰＵのオーバーヘッド等で余裕が必要な場合に対応するものである。
【００７０】
本例ではオフセットとして４μ秒を、ノード４０ａの本来の中継遅延時間である２μ秒に加えて、６μ秒を新たな中継遅延値とする。この状態でノード４０ａに同期をとる際のタイムチャートを図８に示す。
【００７１】
ノード４０ａが送信する同期用フレーム４４ａの１周目の動きは、上記第５の実施例と同じである。１周まわった同期用フレーム４４ｄを受信したノード４０ａは、それを２周目に変更して中継する際に、受信した同期予定時間である６μ秒に上記新たな中継遅延値である６μ秒を加える。すると２周目の同期用フレーム４５ａの同期予定時間は１２μ秒になる。これ以降の動作も上記第５の実施例と同じであるが、同期ポイントがオフセットの分だけ遅れたタイミングになる。
【００７２】
上述した動作により、各ノードには、１周目と２周目にそれぞれ受信した同期用フレームに格納される同期予定時間が保持される。
ここで、各ノードが２周目の同期用フレームを受信したタイミングと同期予定時間を示すと、ノード４０ａが１周目の同期用フレーム４４ａを送信したタイミングを原点とすると、ノード４０ｂは、原点から８μ秒後に２周目の同期用フレーム４５ａを受信する。また、保持される同期予定時間は、１周目が０μ秒で２周目が１２μ秒である。ノード４０ｃは、原点から１０μ秒後に同期用フレーム４５ｂを受信する。また、保持される同期予定時間は、１周目が２μ秒で２周目が１２μ秒である。ノード４０ｄは、原点から１２μ秒後に同期用フレーム４５ｃを受信する。また、保持される同期予定時間は、１周目が４μ秒で２周目が１２μ秒である。ノード４０ａは、原点から１４μ秒後に同期用フレーム４５ｄを受信する。また、保持される同期予定時間は、１周目が６μ秒で２周目が１２μ秒である。
【００７３】
つまり、２周目の同期用フレームを受信したタイミングに、２周目と１周目の同期予定時間の差分（本例ではそれぞれ１２μ秒，１０μ秒，８μ秒，６μ秒）を加えた時間は、全ノードとも２０μ秒になる。
【００７４】
この時点を同期タイミングとすれば、全ノードでほぼタイミングが一致した同期をとることができる。また、このタイミングは、上記の通り、第５の実施例のタイミングにオフセットである４μ秒を加えたものであり、ノード４０ａにおいて２周目の同期用フレーム４５ｄを受信してから同期ポイントまでに、ＣＰＵのオーバーヘッド等で余裕が必要な場合にも対応することができる。
【００７５】
上述の第１の実施例〜第６の実施例のいずれの同期方法を用いても、ノード毎に中継遅延のあるリング型ネットワークにおいても、同期ずれをほぼ０にすることができる。
【００７６】
例えば、上記第１の実施例で、ノード２ａ，２ｂ，２ｃにそれぞれＸ，Ｙ，Ｚ軸のモーターを制御させた場合、従来技術では、Ｘ軸とＹ軸間で２μ秒、Ｘ軸とＺ軸間で４μ秒、の誤差が発生する。さらに、ノード２ａ，２ｂ，２ｃの間にノードを４９個ずつ入れれば、追加ノードの中継遅延の影響で軸間の誤差は大きなり、Ｘ軸とＹ軸間で１００μ秒、Ｘ軸とＺ軸間で２００μ秒になる。このため、Ｘ，Ｙ，Ｚ軸間のノードを減らさなければ同期ずれによる障害が発生するかもしれない。また、この事をエンジニアリングや設置の際に注意しなければならない。
【００７７】
しかし、本発明の同期方法を使えば、中継遅延の影響を除くことが出来るので、Ｘ，Ｙ，Ｚ軸のモーターを繋げるノードとノードの間に別のノードがいくつ有っても同期ずれはなくなり、エンジニアリングや設置の際の自由度が増すとともに、不注意な配置が原因の同期ずれによる障害を未然に防ぐことが出来る。
【００７８】
【発明の効果】
以上、詳細に説明したように、本発明のリング型ネットワークにおけるノード間のタイミング同期方法によれば、ノード毎に中継遅延のあるリング型ネットワークにおいても、同期ずれをほぼ０にすることができ、全ノードでほぼタイミングが一致した同期をとることができる。特に、当該リング型ネットワークを例えば制御システムに適用する場合でも、同期ずれによる障害を未然に防ぐことができ、高速制御にも問題なく適用できる。
【図面の簡単な説明】
【図１】（ａ）、（ｂ）は、第１の実施例を説明する為の図である。
【図２】図１の各ノードの概略構成図である。
【図３】第１の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図４】第３の実施例（または第４〜第６の実施例）におけるノードの概略構成図である。
【図５】第３の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図６】第４の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図７】第５の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図８】第６の実施例において全ノードの同期をとる動作を表したタイムチャート図である。
【図９】バス型のネットワークシステムの一例を示す図である。
【図１０】バス型において全ノードの同期を取るタイムチャート図である。
【図１１】リング型のネットワークシステムの一例を示す図である。
【図１２】図１１における各ノードの概略構成図である。
【図１３】リング型において全ノードの同期を取るタイムチャート図である。
【符号の説明】
１ ネットワーク
２ａ〜２ｄ ノード
３ フレーム処理部
４ ＣＰＵ
５ スイッチ
６ａ〜６ｄ 命令フレーム
７ 同期用フレーム
１０（１０ａ〜１０ｄ） ノード
１２ ＣＰＵ
１３ フレーム処理部
１４ａ〜１４ｄ 同期用フレーム
２０（２０ａ〜２０ｄ） ノード
２２ ＣＰＵ
２３ フレーム処理部
２４ａ〜２４ｄ 同期用フレーム
３０（３０ａ〜３０ｄ） ノード
３２ ＣＰＵ
３３ フレーム処理部
３４ａ〜３４ｄ 同期用フレーム（１周目）
３５ａ〜３５ｄ 同期用フレーム（２周目）
４０（４０ａ〜４０ｄ） ノード
４２ ＣＰＵ
４３ フレーム処理部
４４ａ〜４４ｄ 同期用フレーム（１周目）
４５ａ〜４５ｄ 同期用フレーム（２周目）
Claims (3)
- リング型ネットワークシステムを構成する複数のノード間でのタイミング同期方法であって、
送信元のノードは、所定のコマンドフレームを送信し、
他のノードは、該所定のコマンドフレームを受信すると、該コマンドフレームを中継すると共にバイパスモードに移行し、
リングを一巡した前記所定のコマンドフレームを受信した前記送信元のノードは、同期用フレームを送信し、
前記バイパスモード状態にある他のノードは、該同期用フレームをバイパスすると共に、該同期用フレームの受信タイミングで同期をとることを特徴とするリング型ネットワークにおけるノード間のタイミング同期方法。 - 前記他のノードは、前記同期用フレームを受信後、または前記バイパスモードに移行してから所定時間経過しても前記同期用フレームを受信しなかった場合、前記バイパスモードから通常モードに移行することを特徴とする請求項１記載のリング型ネットワークにおけるノード間のタイミング同期方法。
- リング型ネットワークシステムにおけるノードにおいて、
フレームの送受信および解析を行うフレーム処理手段と、
該フレーム処理手段により所定のコマンドフレームを受信された場合、該コマンドフレームを中継後に、フレーム処理手段を介さずに受信フレームを出力するバイパスモードに切り替える制御手段とを備え、
前記バイパスモードに移行後に受信した同期用フレームをバイパスすると共に該同期用フレームの受信タイミングで同期を取ることを特徴とするリング型ネットワークにおけるノード。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001035897A JP4524932B2 (ja) | 2001-02-13 | 2001-02-13 | リング型ネットワークにおけるノード間のタイミング同期方法、及びそのノード |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001035897A JP4524932B2 (ja) | 2001-02-13 | 2001-02-13 | リング型ネットワークにおけるノード間のタイミング同期方法、及びそのノード |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002247059A JP2002247059A (ja) | 2002-08-30 |
| JP4524932B2 true JP4524932B2 (ja) | 2010-08-18 |
Family
ID=18899265
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001035897A Expired - Fee Related JP4524932B2 (ja) | 2001-02-13 | 2001-02-13 | リング型ネットワークにおけるノード間のタイミング同期方法、及びそのノード |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4524932B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1841139B1 (en) | 2006-03-28 | 2012-03-14 | Yamaha Corporation | Audio network system having lag correction function of audio samples |
| ATE531163T1 (de) | 2006-03-29 | 2011-11-15 | Yamaha Corp | Audionetzwerksystem |
| CN101636972B (zh) | 2007-04-04 | 2011-12-07 | 三菱电机株式会社 | 通信系统、管理装置、通信装置以及计算机程序 |
| JP2012104868A (ja) * | 2009-03-06 | 2012-05-31 | Panasonic Corp | 通信システム、通信装置およびその通信方法 |
| JP5238570B2 (ja) * | 2009-03-25 | 2013-07-17 | 株式会社東芝 | 鉄道車両用伝送システム |
| JP5915379B2 (ja) * | 2012-05-25 | 2016-05-11 | 富士通株式会社 | 伝送装置および伝送方法 |
| JP6213538B2 (ja) * | 2015-09-24 | 2017-10-18 | 横河電機株式会社 | 信号処理回路 |
| JP6404975B2 (ja) * | 2017-03-21 | 2018-10-17 | ファナック株式会社 | スレーブ、シリアル通信システム、および、シリアル通信システムの通信方法 |
-
2001
- 2001-02-13 JP JP2001035897A patent/JP4524932B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002247059A (ja) | 2002-08-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8179923B2 (en) | System and method for transmitting real-time-critical and non-real-time-critical data in a distributed industrial automation system | |
| US8321612B2 (en) | Method and device for synchronizing two bus systems by transmission of a time associated trigger signal from one system to another | |
| JP2500973B2 (ja) | 交換接続システム | |
| JP6859914B2 (ja) | 通信システム、通信装置および通信方法 | |
| US7508824B2 (en) | Method and system for transmitting data via switchable data networks | |
| JP4524932B2 (ja) | リング型ネットワークにおけるノード間のタイミング同期方法、及びそのノード | |
| KR20090067152A (ko) | 클러스터 커플러 유닛, 클러스터 동기화 방법 및 네트워크 | |
| US20060083264A1 (en) | System and method for time synchronizing nodes in an automotive network using input capture | |
| CN104067256A (zh) | 用于支持相同的物理连接上的两种不同的协议的系统和方法 | |
| US20100260176A1 (en) | Communication module having a communication interface element and communication interface element | |
| JP2014103621A (ja) | 自動制御システム、接点情報収集分配装置および自動制御システムの子局 | |
| US6145008A (en) | Conflict free time-triggered method and apparatus for the transmission of messages in a distributed real-time computer system | |
| CN113508560A (zh) | 控制系统、装置以及控制方法 | |
| CN101512985A (zh) | 时间触发网络中的集群耦合器 | |
| US20100119085A1 (en) | Audio Signal Processing System | |
| WO2006044140A2 (en) | System and method for time synchronizing nodes in an automotive network | |
| JP2006109258A (ja) | 通信方法及び通信装置 | |
| WO2006044139A2 (en) | System and method for time synchronizing nodes in an automotive network using input capture | |
| JPH08141957A (ja) | ロボットの制御装置 | |
| JPS586637A (ja) | ル−プ式デ−タウエイシステムの回線制御方法 | |
| TWI821680B (zh) | 分散控制系統及具備有此之半導體檢查裝置 | |
| JP2581449B2 (ja) | 無瞬断切替方式 | |
| JPH02205133A (ja) | 伝送システム | |
| JP2862581B2 (ja) | パケット交換スイッチの転送制御方式 | |
| JPH085379B2 (ja) | 電子連動装置 |
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: 20071016 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20080919 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20080919 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20080919 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100121 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100209 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100305 |
|
| 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: 20100511 |
|
| 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: 20100524 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130611 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4524932 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: 20130611 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: 20130611 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| 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 |
|
| LAPS | Cancellation because of no payment of annual fees |