JP4193806B2

JP4193806B2 - 制御システム

Info

Publication number: JP4193806B2
Application number: JP2005085774A
Authority: JP
Inventors: 晴道堀田; 政樹工藤; 優相曾
Original assignee: Yamaha Corp
Current assignee: Yamaha Corp
Priority date: 2005-03-24
Filing date: 2005-03-24
Publication date: 2008-12-10
Anticipated expiration: 2025-03-24
Also published as: JP2006270520A

Description

本発明は、デジタルミキサ等の制御に用いて好適な制御システムに関する。

従来より、２本の信号線を用いて複数のデバイス間でデータをやりとりするシリアル・バスとして、Ｉ²Ｃバスが知られている。また、このＩ²Ｃバスを電子楽器内部のデバイス（例えば鍵盤、パネル操作子、表示器、音源等）間の通信に応用したもの（Ｅバス）が特許文献１に開示されている。なお、Ｉ²Ｃにおいては、各デバイスに対して「１」〜「１２７」のアドレスが付与される。従って、原理上は最大「１２７」のデバイスをＩ²Ｃバスに接続することが可能である。

特開２００２−２５１１８３号公報

しかし、現実的には、Ｉ²Ｃのデバイス数が増加すると、リピータと呼ぶバッファアンプをＩ²Ｃバスの随所に介挿する必要がある。従って、デバイス数の多い機器においてはリピータの数が多くなりコストアップを招くという問題があった。特に、デジタルミキサは電子楽器と比較すると、操作子や表示器等の数が多いため、Ｉ²Ｃバス上のデバイス数も多くせざるを得えなかった。

また、Ｉ²Ｃバスに接続される各デバイスには、バスとの接続用のバスインタフェースが必要である。このバスインタフェースから他のデバイスに対してデータを送信するためには、送信先および送信元デバイスのアドレスを指定する機能が必要であり、例えばＲＳ２３２Ｃ等のシリアル通信用のインタフェースと比較すると、構成が複雑であった。
この発明は上述した事情に鑑みてなされたものであり、Ｉ²Ｃバス等の複雑なシリアル・バスに接続するデバイス数を減少させつつ、実質的に多数のデバイス間の通信を実現できる制御システムを提供することを目的としている。

上記課題を解決するため本発明にあっては、下記構成を具備することを特徴とする。なお、括弧内は例示である。
請求項１記載の制御システムにあっては、操作パネル（１００）と、該操作パネル（１００）上に設けられた複数の制御要素とを有する制御システムであって、前記複数の制御要素は、識別情報により各々が一意に特定されるとともに、各々が該操作パネル上の複数のセクション（１０１〜１０４）のうち何れか一のセクションに属するものである、制御システムにおいて、送信先アドレスを含む第１種パケットを、前記送信先アドレスに基づいて伝送するための第１種バス（Ｅバス２１６，２１７）と、前記第１種バス（Ｅバス２１６，２１７）に接続され、前記第１種バスにおいて一意なアドレスが付与された親デバイス（２２０）と、前記第１種バス（Ｅバス２１６，２１７）に接続され、それぞれ前記第１種バスにおいて一意なアドレスが付与され、前記操作パネルの前記複数のセクションのうち何れかに対応する複数の子デバイス（２０１−Ａ〜２０４−Ａ）と、第２種パケットを伝送するための、前記複数の子デバイスにそれぞれ固有に設けられた複数の第２種バス（Ｓバス２１１〜２１４）と、前記複数の第２種バス（Ｓバス２１１〜２１４）の何れかに接続され、前記操作パネルの前記複数のセクションのうち何れかに対応する複数の孫デバイス（２０１−Ｂ，２０２−Ｂ，２０３−Ｂ，２０４−Ｂ，２０１−Ｃ，２０２−Ｃ，２０３−Ｃ，２０４−Ｃ）と、を備え、前記親デバイス（２２０）は、前記第１種パケットであって、前記子デバイスのうち何れか一つを指標する前記送信先アドレスと、前記操作パネルの制御要素のうち何れか一つを指標する前記識別情報と、当該制御要素のための制御データとを含み、前記識別情報にて指定された制御要素を前記制御データにて制御するための第１種パケットを生成するとともに前記第１種バスを介して伝送する親デバイス第１種送信手段（２２２，）と、前記第１種パケットであって、当該親デバイスを指標する前記送信先アドレスと、前記操作パネルの制御要素のうち何れか一つを指標する前記識別情報と、当該制御要素に対するユーザ操作内容を表す制御データとを含む第１種パケットを、前記第１種バスを介して前記複数の子デバイスのうち何れかから受信する親デバイス第１種受信手段と、を有し、前記各子デバイスは、当該子デバイスが対応する前記操作パネルのセクションに含まれる前記一または複数の制御要素である子デバイス制御要素（１２４−１〜ｎ）と、当該子デバイスを指標する送信先アドレス情報を含む前記第１種パケットを、前記第１種バスを介して前記親デバイスから受信する子デバイス第１種受信手段（ＳＰ２）と、前記子デバイス第１種受信手段が前記第１種パケットを受信したことに応じて、該第１種パケットの識別情報が当該子デバイス制御要素の何れかを指標していた場合に、当該子デバイス制御要素を制御する子デバイス制御手段（ＳＰ８，ＳＰ１０）と、前記子デバイス第１種受信手段が受信した前記第１種パケットの識別情報が前記子デバイス制御要素の何れかを指標するものでない場合に、当該受信した第一種パケットに含まれる識別情報および制御データと同一の識別情報および制御データを含む第２種パケットを生成し、該生成した第２種パケットが当該子デバイスに係る前記孫デバイスの何れかにて受信されるように前記第２種バスに伝送する子デバイス第２種送信手段（ＳＰ１２）と、前記子デバイス制御要素に対するユーザ操作を検出する子デバイス操作検出手段と、前記第２種バスを介して当該第２種バスに接続された一または複数の前記孫デバイスから前記第２種パケットを受信する子デバイス第２種受信手段と、前記子デバイス操作検出手段が前記ユーザ操作を検出したことに応じて、当該操作された子デバイス制御要素を指標する識別情報と、当該操作された子デバイス制御要素に対する操作内容を示す制御データと、前記親デバイスを指標する送信先アドレスとを含む前記第１種パケットを生成して、前記第１種バスを介して前記親デバイスに伝送し、また、前記子デバイス第２種受信手段が前記第２種パケットを受信したことに応じて、当該第２種パケットに含まれる識別情報および制御データと同一の識別情報および制御データと、前記親デバイスを指標する送信先アドレスとを含む前記第１種パケットを生成して、前記第１種バスを介して前記親デバイスに送信する子デバイス第１種送信手段と、を有し、前記各孫デバイスは、当該孫デバイスが対応する前記操作パネルのセクションに含まれる前記一または複数の制御要素である孫デバイス制御要素と、前記第２種バスを介して、当該第２種バスに接続されている前記子デバイスから前記第２種パケットを受信する孫デバイス第２種受信手段と、前記孫デバイス第２種受信手段が前記第２種パケットを受信したことに応じて、該受信した第２種パケットの識別情報が前記孫デバイス制御要素を指標するものであった場合に、当該第２種パケットに含まれる制御データに基づいて当該孫デバイス制御要素を制御する孫デバイス制御手段と、前記孫デバイス制御要素に対するユーザ操作を検出する孫デバイス操作検出手段と、前記孫デバイス操作検出手段が前記ユーザ操作を検出したことに応じて、当該操作された孫デバイス制御要素を指標する識別情報と、当該操作された孫デバイス制御要素に対する操作内容を示す制御データとを含む前記第２種パケットを生成して、前記第２種バスを介して前記第２種バスに接続された前記子デバイスに送信する孫デバイス第２種送信手段と、を有することを特徴とする。
さらに、請求項２記載の構成にあっては、請求項１記載の制御システムにおいて、複数の前記孫デバイスが前記第２種バスを介して一の前記子デバイスに接続されており、前記子デバイス第１種受信手段は、前記第２種バスに接続された前記複数の孫デバイスのうち何れかの孫デバイスに対応する前記孫デバイス制御要素を示す識別情報（ポート番号ｘ）を含む前記第１種パケットを受信するものであり、前記子デバイス第２種送信手段（ＳＰ１２）は、前記第２種バスに接続された前記複数の孫デバイスのうち何れか一の孫デバイスを指定する宛先情報（アドレス４３０）を前記第２種パケットに付与し、当該第２種パケットを前記第２種バスに送出するものであり、前記孫デバイス第２種受信手段は、前記第２種バスに送出された前記第２種パケットのうち、当該孫デバイスを指標する前記宛先情報が付与されたものを受信することを特徴とする。
さらに、請求項３記載の構成にあっては、請求項１記載の制御システムにおいて、前記第１種パケットは、前記第１種バスに接続されている前記親デバイスまたは前記複数の子デバイスのうち何れか一のデバイスを示す送信元アドレスを含むことを特徴とする。
さらに、請求項４記載の構成にあっては、請求項１記載の制御システムにおいて、前記複数の制御要素には、予めそれぞれポート番号が割り当てられており、前記第１種パケットの前記識別情報は、前記ポート番号により前記複数の制御要素のうちの一の制御要素を特定するものであり、前記子デバイス制御手段（ＳＰ８，ＳＰ１０）または前記子デバイス第２種送信手段（ＳＰ１２）は、前記ポート番号に基づいて、前記受信した第１種パケットの識別情報が、当該子デバイスの子デバイス制御要素のうちの何れかを指標するものであるか否かを判別することを特徴とする。
さらに、請求項５記載の構成にあっては、請求項２記載の制御システムにおいて、前記複数の制御要素には、予めそれぞれポート番号が割り当てられており、前記第１種パケットの前記識別情報は、前記ポート番号により前記複数の制御要素のうちの一の制御要素を特定するものであり、前記子デバイス第２種送信手段は、前記受信した第１種パケットの識別情報の前記ポート番号に基づき、前記宛先情報を生成することを特徴とする。

このように、各親デバイスおよび子デバイスを第１種バスを介して接続し、各子デバイスに第２種バスを介して孫デバイスを接続する構成によれば、送信先アドレスおよび送信元アドレスをデータに付加する機能を必要とする子デバイスの数を、孫デバイスの数分だけ減少させることができる。そして、データの入出力に際して送信先アドレスおよび送信元アドレスを付加する機能を要しない孫デバイスは子デバイスよりも安価に構成することができるため、装置全体の構成を簡素化しコストダウンを図ることができる。

1．実施例のハードウエア構成
1．1．操作パネル１００の構成
次に、本発明の一実施例のデジタルミキサの操作パネル１００の全体構成を図１を参照し説明する。図において操作パネル１００は、セクション１０１〜１０４の「４」セクションから構成されている。ここで、セクション１０１，１０２は入力チャンネルの音量等を調整するフェーダ等から構成されている。同様に、セクション１０４は出力チャンネルの音量等を調整するフェーダ等から構成されている。また、セクション１０３は、これら入出力チャンネルのうち選択された一のチャンネルにおける詳細なパラメータの設定等に用いられる。ここで、各入力チャンネルにおいて音量・音質調節された音声信号は、ステレオバス、ＭＩＸバス、ＣＵＥバス等のバスに出力される。

ここで、ステレオバスとは、主として客席への放音に使用される音声信号をミキシングするバスであり、ＭＩＸバスとは補助的な放音およびレコーディング等の用途に使用されるバスである。また、ＣＵＥバスとは、デジタルミキサの操作者等に対するモニタ用の音声信号をミキシングするバスである。そして、各出力チャンネルはこれらバスに対して各々割り当てられており、各バスにてミキシングされた音声信号のレベル等がセクション１０４において調節され、外部に出力されることになる。

次に、セクション１０１，１０３の詳細構成を図２を参照し説明する。まず、セクション１０１の内部において１１２−１〜ｎはセンド・オン／オフスイッチであり、各々対応する入力チャンネルを各ＭＩＸバスに出力するか否かを設定する。１２４−１〜ｎは電動フェーダであり、各入力チャンネルの音声信号のゲインを設定する。１１４−１〜ｎはセンドモードスイッチであり、各入力チャンネルから各ＭＩＸバスに出力される音声信号として、電動フェーダ１２４−１〜ｎによる音量調節前の信号または音量調節後の信号のうち一方を選択する。１１６−１〜ｎはロータリーエンコーダであり、指定されたＭＩＸバスに対するセンドレベル等を設定する。１１８−１〜ｎはＬＥＤ表示器群であり、各入力チャンネルの各種状態をＬＥＤの点灯／消灯状態によって表示する。

１２０−１〜ｎはセレクトスイッチであり、セクション１０３において詳細なパラメータを設定すべきチャンネルを選択する。１２２−１〜ｎはオン／オフスイッチであり、各々対応する入力チャンネルをステレオバスおよびＭＩＸバスに出力するか否かを設定する。１２６−１〜ｎはＣＵＥスイッチであり、各入力チャンネルの音声信号をＣＵＥバスに出力するか否かを選択する。

ここで、上述した各スイッチ、ロータリーエンコーダおよび電動フェーダの状態は、デジタルミキサ内部の制御システム（図３の回路、詳細は後述する）により、自動的に設定することも可能である。まず、上述した各スイッチはＬＥＤを内蔵したキースイッチであり、対応するパラメータのオン／オフ状態は制御システム内で把握されている。そして、このＬＥＤをオン／オフすることにより、該パラメータのオン／オフ状態が操作者に対して表示されることになる。従って、制御システムの内部にて当該パラメータのオン／オフ状態を変更し、変更結果に応じてＬＥＤをオン／オフすれば、その状態を自動的に設定することができる。

また、各ロータリーエンコーダは、無限回動する形式のものであり、操作者がこれを回動させると、所定の単位角度だけ回動される毎に、ワンショットのパルスが制御システムに出力される。これにより、制御システムにおいては、このパルス数をカウントすることにより、操作前後におけるロータリーエンコーダの回動角度を得ることができる。このロータリーエンコーダに対しては、上述した通り、指定されたＭＩＸバスに対するセンドレベル等のパラメータが割り当てられているから、制御システム内部では当該センドレベルが回動角度に応じて増減される。さらに、各ロータリーエンコーダの周囲には、十数個程度のＬＥＤが環状に配置されており、対応するパラメータの設定値の概算値がこのＬＥＤによって表示される。従って、制御システムの内部にて当該パラメータの値を変更し、変更結果に応じてこれらＬＥＤのオン／オフ状態を設定すれば、該パラメータを自動的に設定することができる。

また、操作者によって電動フェーダが操作されると、その操作位置が検出され、制御システムに通知される。これにより、制御システムにおいては、電動フェーダの操作位置に応じてパラメータ値（主として音声信号のゲイン）が設定される。一方、かかるパラメータの値は、電動フェーダの物理的な操作位置に応じて決定されるため、かかるパラメータ値をパネル上に自動的に再現するために、電動フェーダにはモータ等の駆動機構が設けられている。すなわち、パラメータ値を自動設定する場合には、制御システムの指令に基づいてモータが駆動され、電動フェーダの物理的な操作位置が設定されることになる。

ここで、セクション１０１の各操作子等はさらに３種類のサブセクション１０１−Ａ，１０１−Ｂ，１０１−Ｃに分割される。なお、「サブセクション」とは、比較的廉価なＣＰＵ１個で制御可能な範囲毎にに「セクション」を便宜上分割したものである。まず、サブセクション１０１−Ａは、電動フェーダ１２４−１〜ｎによって構成され、サブセクション１０１−Ｂはオン／オフスイッチ１１２−１〜ｎ、センドモードスイッチ１１４−１〜ｎ、およびロータリーエンコーダ１１６−１〜ｎから構成される。さらに、サブセクション１０１−Ｃは、ＬＥＤ表示器群１１８−１〜ｎ、セレクトスイッチ１２０−１〜ｎ、オン／オフスイッチ１２２−１〜ｎおよびＣＵＥスイッチ１２６−１〜ｎから構成される。以上、セクション１０１の構成について詳述したが、セクション１０２，１０４もセクション１０１と同様に構成されており、各々３種類のサブセクション１０２−Ａ，１０２−Ｂ，１０２−Ｃおよびサブセクション１０４−Ａ，１０４−Ｂ，１０４−Ｃに分類される。

次に、セクション１０３の内部において１３０はタッチスクリーンであり、ディスプレイと、その表面に配置された透明なタッチパネルとから構成されている。そして、操作者が指先またはライトペン等でタッチパネルを押下すると、その旨およびタッチパネル上の押下位置の座標とが検出される。１３２−１〜１３２−６，１３６−１〜１３６−１４，１３８−１〜１３８−１５はスイッチであり、セクション１０３に割り当てられた機能に応じて、各種パラメータのオン／オフ状態等を設定する。１３４−１〜１３４−１５はロータリーエンコーダであり、例えば上記セレクトスイッチ１２０−１〜ｎによって選択された入力チャンネルから各ＭＩＸバスへのセンドレベルを調節するために用いられる。上記セクション１０３の構成のうち、タッチスクリーン１３０はサブセクション１０３−Ａを構成し、スイッチ１３２−１〜１３２−６およびロータリーエンコーダ１３４−１〜１３４−１５はサブセクション１０３−Ｂを構成し、スイッチ１３６−１〜１３６−１４，１３８−１〜１３８−１５はサブセクション１０３−Ｃを構成する。

1．2．制御システムの全体構成
次に、本実施例のデジタルミキサの制御システムの全体構成を図３を参照し説明する。図おいて２２０は親システムであり、デジタルミキサ全体の監視および制御を行う。２０１−Ａ，２０２−Ａ，２０３−Ａ，２０４−Ａは子システムであり、各々セクション１０１〜１０４に関する監視および制御を統括するとともに、サブセクション１０１−Ａ，１０２−Ａ，１０３−Ａ，１０４−Ａに対する監視および制御を直接的に実行する。２０１−Ｂ，２０２−Ｂ，２０３−Ｂ，２０４−Ｂ，２０１−Ｃ，２０２−Ｃ，２０３−Ｃ，２０４−Ｃは孫システムであり、各子システム２０１−Ａ〜２０４−Ａの制御の下、サブセクション１０１−Ｂ，１０２−Ｂ，１０３−Ｂ，１０４−Ｂ，１０１−Ｃ，１０２−Ｃ，１０３−Ｃ，１０４−Ｃを監視および制御する。より具体的には、親システム２２０はＩ²Ｃに準拠するＥバスのコネクタを２つ備えたシステム基板であり、各子システムはＥバスのコネクタと、双方向シリアル通信を行うＳバスのコネクタとを一つずつ備えたシステム基板であり、各孫システムはＳバスのコネクタを１つ備えたシステム基板である。２１６，２１７はＥバスのケーブルであり、親システム２２０および子システム２０１−Ａ〜２０４−ＡのＥバスコネクタに接続され、それらのシステム間で信号を伝送する。２１１〜２１４はＳバスであり、各子システムと配下の孫システムのＳバスコネクタに接続され、それらのシステム間で信号を伝送する。

親システム２２０の内部において２２２はＥバスＩ／Ｏ部であり、Ｅバス２１６，２１７に対して信号を入出力するとともに、Ｅバス２１６，２１７に対するリピータ機能を有している。２２４は親システム２２０の各部を接続するＣＰＵバスである。２３４は信号処理部であり、デジタル音声信号に対して、イコライジング、ミキシング、レベル調節等の処理を実行する。上述したステレオバス、ＭＩＸバス等もこの信号処理部２３４で実行されるアルゴリズムによって実現されているものである。２３６は波形Ｉ／Ｏ部であり、外部から入力される多チャンネルのアナログ信号またはデジタル信号を親システム２２０の内部形式のデジタル信号に変換し信号処理部２３４に供給するとともに、信号処理部２３４から供給されたデジタル信号をアナログ信号または外部形式のデジタル信号に変換し出力する。

２２６はその他Ｉ／Ｏ部であり、デジタルミキサを遠隔制御する外部の制御装置等に接続される。２２８はＣＰＵであり、フラッシュメモリ２３０に記憶されたプログラム（詳細は後述する）に基づいて、親システム２２０の各部を制御する。２３２はＲＡＭであり、ＣＰＵ２２８のワークメモリとして使用される。２３８はディスプレイであり、上述したタッチスクリーン１３０の一部を成す。

1．3．子システムおよび孫システムの構成
次に、子システムの一般的構成を図４(a)を参照し説明する。図４(a)において２４２は表示器群であり、各種ＬＥＤ等から構成される。但し、本実施例にあっては、子システムによって直接的に制御されるサブセクション１０１−Ａ，１０３−Ａ等において特に表示器群２４２に該当するものはない。２４４は操作子群であり、サブセクション１０１−Ａにおいては電動フェーダ１２４−１〜ｎ、サブセクション１０３−Ａにおいてはタッチスクリーン１３０を構成するタッチパネルがこれに該当する。２４６はシリアルＩ／Ｏ部であり、Ｓバスを介して配下の孫システムとの間で各種信号を入出力する。２４８はＥバスＩ／Ｏ部であり、Ｅバスを介して親システムとの間で各種信号を入出力する。２５２はＣＰＵであり、フラッシュメモリ２５４に格納されたプログラムに基づいて子システム内の各部を制御する。２５６はＲＡＭであり、ＣＰＵ２５２のワークメモリとして使用される。

次に、孫システムの一般的構成を図４(b)を参照し説明する。図４(b)において２６２は表示器群であり、各種ＬＥＤ（単独のＬＥＤ、スイッチに内蔵されたＬＥＤ、ロータリーエンコーダの周囲のＬＥＤ）等から構成される。２６４は操作子群であり、各種スイッチおよびロータリーエンコーダ等から構成される。２６６はシリアルＩ／Ｏ部であり、Ｓバスを介して対応する子システムとの間で各種信号を入出力する。２７２はＣＰＵであり、フラッシュメモリ２７４に格納されたプログラムに基づいて、孫システム内の各部を制御する。２７６はＲＡＭであり、ＣＰＵ２７２のワークメモリとして使用される。

2．実施例の通信プロトコル
2．1．Ｅバス・プロトコル
2．1．1．物理的構成
次に、親システム２２０および子システム２０１−Ａ〜２０４−Ａ間を接続するＥバス２１６，２１７のプロトコルを説明する。まず、Ｅバス２１６の具体的構成を図５に示す。但し、図５においてはＥバス２１６（Ｉ²Ｃバス）を構成する７本のワイヤーのうち、クロック信号ＳＣＬを伝送するＳＣＬライン２１６ａと、データ信号ＳＤＡを伝送するＳＤＡライン２１６ｂとの２本の信号線のみを図示する。なお、図示していない残り５本の信号線はイニシャルクリアライン１本と、電源ライン４本である。親システム２２０のＥバスＩ／Ｏ部２２２の内部において３７１，３７２はプルアップ用の抵抗器であり、ＳＣＬライン２１６ａおよびＳＤＡライン２１６ｂを各々所定の電圧Ｖｐにプルアップする。

３６１，３６２は電界効果トランジスタ（以下、単にトランジスタという）であり、各ライン２１６ａ，２１６ｂにオープンドレイン接続されている。ここで、Ｅバス２１６にＥバスＩ／Ｏ部２２２「のみ」が接続されていたと仮定すると、トランジスタ３６１，３６２がオン状態になるとクロック信号ＳＣＬおよびデータ信号ＳＤＡは接地レベル付近の値になる。また、トランジスタ３６１，３６２がオフ状態になると、各信号ＳＣＬ，ＳＤＡは電圧Ｖｐ付近の値になる。ここで、接地レベルと電圧Ｖｐとの中間付近のある値を閾値とし、該閾値未満の電圧を論理値“０”とし、該閾値以上の電圧を論理値“１”とする。３５１，３５２はバッファであり、各信号ＳＣＬ，ＳＤＡの論理値を検出する。

従って、ＥバスＩ／Ｏ部２２２においては、トランジスタ３６１，３６２をオン／オフすることにより、クロック信号ＳＣＬおよびデータ信号ＳＤＡを各々ＳＣＬライン２１６ａおよびＳＤＡライン２１６ｂを介して送信することができ、さらに各ライン２１６ａ，２１６ｂ上の信号ＳＣＬ，ＳＤＡをバッファ３５１，３５２を介して受信することができる。同様に、子システム２０１−Ａおよび２０２−Ａにおいても、各ライン２１６ａ，２１６ｂにオープンドレイン接続されたトランジスタ３６３，３６４および３６５，３６６と、各ライン２１６ａ，２１６ｂの論理値を検出するバッファ３５３，３５４および３５５，３５６とが設けられている。各ラインに接続されたトランジスタのうち何れかがオン状態になると当該ライン上の信号は“０”になるから、これらトランジスタは各ライン２１６ａ，２１６ｂ上のワイアード・アンド回路を構成している。以上、Ｅバス２１６の構成を説明したが、Ｅバス２１７の構成もこれと同様である。そして、Ｅバス２１６，２１７は、ＥバスＩ／Ｏ部２２２内のリピータを介して相互に接続されている。

2．1．2．パケット形式
次に、ＳＣＬライン２１６ａおよびＳＤＡライン２１６ｂにおけるデータ転送時のタイミングチャートを図６に示す。Ｅバスシステムにおいては、バスが開放状態（“１”）の時のみにデータ転送を開始することができる。Ｅバスに接続されたデバイス（親システムまたは子システム）のうち、Ｅバスを介してデータを送信しようとするデバイスにおいては、各信号ＳＣＬ，ＳＤＡの何れもが“１”である旨が確認された後、データ信号ＳＤＡとして“０”が出力される。これをスタートビット（Start Bit）という。このスタートビットにより、該デバイスによってＥバスにデータが出力されようとしている旨が他のデバイスにおいて検出される。

ここで、Ｅバスに接続された各デバイス間では「１バイト（８ビット）」単位でデータ信号ＳＤＡが送受信される。また、クロック信号ＳＣＬはデータ信号ＳＤＡの各ビットが安定するタイミングで立ち下がるように、送信元デバイスによって生成される。そして、該「１バイト」のデータ信号ＳＤＡの送信が完了したとき、送信元デバイスにおいては確認用の「１ビット」のクロックパルス（ＡＣＫ）が生成される。このＡＣＫが出力されるタイミングにおいては、送信元デバイスはデータ信号ＳＤＡとして“１”を出力するが、データを受信する側の送信先デバイスにおいては、正常なデータが受信された場合には、データ信号ＳＤＡとして“０”が出力される。これら信号のワイアード・アンドの結果、ＳＤＡライン２１６ｂ上に現れるデータ信号ＳＤＡは結局は“０”になるため、送信元デバイスにおいては、送信先デバイスがデータ信号ＳＤＡを正常に受信したか否かを確認することができる。

また、各デバイスには、「７ビット」のユニークなアドレスが付与されている。そして、送信元デバイスにおいては、スタートビットが出力された後に、最初に「７ビット」の送信先アドレスと、Ｒ／Ｗビットと称するビットとが出力される。但し、本実施例においては、Ｒ／Ｗビットは常に“０”（Write）である。これに引き続いて、「７ビット」の送信元アドレスと、ダミーの“０”信号とが出力される。以上の「２バイト」によってパケットのヘッダ部３７０が構成される。これに引き続き、一または複数バイトから成るデータ部３８０が送信元デバイスから送信される。なお、本実施例においては、データ部３８０は常に「３バイト」長である。このデータ部３８０を構成する各バイトを第１データ、第２データ、第３データと呼ぶ。

ここで、本実施例におけるデバイス名およびアドレス名と、Ｉ²Ｃ規格におけるこれらの名称との関係について説明しておく。まず、本実施例における「送信元アドレス」は、Ｉ²Ｃ規格では「マスタアドレス」と呼ばれ、「送信元デバイス」は「マスタデバイス」と呼ばれる。また、「送信先アドレス」は「スレーブアドレス」と呼ばれ、「送信先デバイス」は「スレーブデバイス」と呼ばれる。「マスタデバイス」とは通信を開始させるとともにＳＣＬライン２１６ａにクロック信号ＳＣＬを出力するデバイスであり、必ずしもデータ部３８０を送信するデバイスに限られない。

すなわち、上述したＲ／Ｗビットが“０”(Write)であれば、マスタデバイスによってデータ部３８０が出力され、スレーブデバイスはこれを受信することになる。一方、Ｒ／Ｗビットが仮に“１”(Read)であれば、スレーブデバイスによってデータ部３８０が出力され、マスタデバイスはこれを受信することになる。しかし、本実施例のようなデジタルミキサにおいては、リアルタイム性が要求されるため、一のデバイスＡから他のデバイスＢに対してデータを送信する必要が生じたとき、デバイスＡがマスタデバイスとなってデバイスＢに対して直ちにデータ転送を開始する必要がある。このため、本実施例においては、マスタデバイスの出力するＲ／Ｗビットは常に“０”(Write)であり、Ｉ²Ｃ規格における「マスタデバイス」は「送信元デバイス」と同義になり、「スレーブデバイス」は「送信先デバイス」と同義になる。

次に、アービトレーションについて説明する。Ｅバスシステムにおいては、各デバイスはバスが開放状態（Ｈレベル）の時のみにデータ送信を開始することができるが、複数のデバイスが送信元デバイスとしてほぼ同時にデータ送信を開始しようとすることがある。この場合は、何れか一のデバイスに対してのみ通信を許可するアービトレーションが行われる。このアービトレーションでは、ＳＤＡラインに各デバイスのデータ出力部のトランジスタがワイヤードアンド接続されていることを利用している。具体的に説明すると、データ転送開始した際には、図４に示すようにスタートビットに続いて送信先アドレスがＳＤＡライン２１６ｂに送出されるので、データ送信しようとする複数のデバイスにおいてこのＳＤＡラインから受信したアドレスと自機がアドレス指定した送信先アドレスとが１ビットずつ対比される。この場合、同時に複数のデバイスからデータがＳＤＡライン２１６ｂに送出された場合には、これらのデータはワイヤードアンドされていることからいずれかのデバイスが“０”を送出した際にＳＤＡラインは“０”に保持されるようになる。

すると、デバイスによっては自機が指定した送信先アドレスの対比するビットが“１”であるのに対して、ＳＤＡライン２１６ｂから取り込まれたビットが“０”になる。このようにアドレスに不一致が生じた場合は、他のデバイスの優先順位が高いと判断してデータ出力がオフにされる。なお、これらデバイスの出力した送信先アドレスが一致している場合においても、送信元アドレスはデバイス毎に異なるから、必ず一のデバイスを除いた他のデバイスはデータ出力がオフにされることになる。

次に、上記各デバイスのアドレス構成を説明する。上述したように各デバイスのアドレスは「７ビット」から構成されているが、その上位「４ビット」をカテゴリＩＤといい、デバイスの種類を表す。例えば、親システム２２０のカテゴリＩＤを「０００１ｂ」（ｂは２進数）とし、子システムのカテゴリＩＤを「００１０ｂ」とするとよい。また、アドレスの下位「３ビット」をサブアドレスといい、各カテゴリ毎に「０００ｂ」〜「１１１ｂ」の範囲でユニークな番号が付与される。上述したアービトレーションにおいては送信先アドレスの先頭から“０”が長く続くほど、その送信先デバイスへの送信が優先して実行されるから、データを転送する優先順序に応じてカテゴリＩＤを決定するとよい。

2．1．3．パケット種別
(1)プロトコルの種類
先行技術文献の特開２００２−２５１１８３号公報に開示されたＥバスシステムは元々は電子楽器内部のデバイスの相互接続のために開発されたものであり、電子楽器内部にて各種スイッチ、ＪＯＧコントローラ、コンティニュアスコントローラ等の操作状態を入出力するための「標準プロトコル」、ＭＩＤＩ信号を入出力するための「ＭＩＤＩプロトコル」、および各デバイスに対する初期化処理等のコマンドを送信する「共通プロトコル」が定められている。各デバイスは、ホスト系（本実施例においては親システム２２０）を除いて、標準プロトコルまたはＭＩＤＩプロトコルのうち何れか一方のパケットのみを入出力できるようになっている。

各デバイスが標準プロトコルまたはＭＩＤＩプロトコルのうち何れを取り扱うものであるかは、カテゴリＩＤによって決定される。すなわち、同文献によれば、カテゴリＩＤが「０１０１ｂ」であるデバイスに対してＭＩＤＩプロトコルが適用される。但し、共通プロトコルのパケットは、各デバイスがカテゴリＩＤにかかわらず、入出力することが可能である。本実施例においては、特にＭＩＤＩ信号をＥバスを介して伝送することは考慮していないため、適用されるプロトコルは標準プロトコルおよび共通プロトコルの二種類のみになる。すなわち、全てのデバイスは共通プロトコルおよび標準プロトコルのパケットを入出力することになる。

(2)共通プロトコル
次に、共通プロトコルおよび標準プロトコルのパケットの構成を図７を参照し説明する。
まず、Ｅバスシステムを起動する際、親システム２２０から各子システム２０１−Ａ〜２０４−Ａに対して、「Ｃ０１：Ｅバススタート」なるパケットが送信される。このパケットにおいては、送信先アドレスは各子システムのアドレスであり、送信元アドレスは親システムのアドレスである。そして、データ部３８０の第１データは０１ｈ（ｈは１６進数）、第２および第３データは００ｈに設定される。このパケットが受信されると、各子システムにおいては、Ｅバスに係る入出力処理が準備される。ところで、このＥバススタートを送信するにあたっては、「ゼネラルコール」という送信方法を採用することができる。これは、送信先アドレスを「０００００００ｂ」とすることにより、他のデバイスに対して一斉にパケットを送信する方法である。この「ゼネラルコール」を用いてＥバススタートを送信すると、１回の送信によって全子システムを初期化することができる。

次に、親システム２２０においては、各子システムに対して、「Ｃ０２：カテゴリＩＤ・サブアドレス・リクエスト」なるパケットが送信される。これは、各子システムに対してカテゴリＩＤとサブアドレスとを返信するように求めるパケットである。このパケットにおいてもゼネラルコールを用いることができる。なお、親システム２２０においてはＥバス２１６，２１７に接続している子システムが元々認識されているため、このパケットは、各子システムが正常に動作しているか否かの確認のために主として用いられる。

次に、各子システムにおいては、このＣ０２：カテゴリＩＤ・サブアドレス・リクエストが受信されると、「Ｃ０３：カテゴリＩＤ・サブアドレス・リプライ」なるパケットが親システム２２０に対して返信される。該パケットにおいて、送信先アドレスは親システム２２０のアドレスであり、送信元アドレスは当該パケットを送信する子システムのアドレスである。該パケットにおいて第１データは「００ｈ」であり、第２データは該子システムのカテゴリＩＤ、第３データは該子システムのサブアドレスである。また、親システム２２０と子システムとの間でその他の情報、例えばエラー報告などを入出力する場合には、「Ｃ０４：その他」のパケットが用いられる。該パケットにおいて第１データは「００ｈ」〜「０Ｆｈ」の範囲であり、第２および第３データは入出力する情報に応じたパラメータである。

(3)標準プロトコル
(3．1)子システムから親システムへのデータ送信
次に、子システムから親システムに対するデータ送信用のパケットについて説明する。これらのパケットにおいては、送信先アドレスは必ず親システム２２０であり、送信元アドレスは当該パケットを送信する子システムのアドレスである。まず、子システム（またはその配下の孫システム）において、何れかのスイッチがオフ状態に設定されると、その旨がＣ１１：ＳＷＯＦＦというパケットによって、該子システムから親システム２２０に通知される。該パケットにおいて、第１データは「６ｘｈ」（但し、ｘは「０ｈ〜Ｆｈ」の範囲のポート番号、以下同）であり、第２データは「００ｈ」〜「ＦＦｈ」の範囲のスイッチ番号である。また、第３データはダミーデータ「００ｈ」である。

同様に、何れかのスイッチがオン状態に設定されると、その旨がＣ１２：ＳＷＯＮというパケットによって、該子システムから親システム２２０に通知される。該パケットにおいて、第１データは「７ｘｈ」であり、第２データは「００ｈ」〜「ＦＦｈ」の範囲のスイッチ番号であり、第３データはダミーデータ「００ｈ」である。このように、ＳＷＯＮ／ＯＦＦパケットにあっては、ポート番号の種類が最大「１６」であって、各ポート毎に最大「２５６」のスイッチ番号を指定できるため、本実施例においては、各セクション毎に最大「１６×２５６」のスイッチを設けることが可能である。

また、子システム（またはその配下の孫システム）において、何れかのＪＯＧコントローラが操作されると、その旨がＣ１３：ＪＯＧコントローラというパケットによって、該子システムから親システム２２０に通知される。なお、ＪＯＧコントローラとは、操作量の相対的な変化量によってパラメータを設定する操作子であり、本実施例のデジタルミキサにおいては、各種ロータリーエンコーダがこれに該当する。Ｃ１３：ＪＯＧコントローラにおいて、第１データは「Ｃｘｈ」であり、第２データは「００ｈ」〜「ＦＦｈ」の値によってＪＯＧコントローラの種別を示す。そして、第３データはＪＯＧコントローラの操作量の相対的な変化量を「８ビット」の分解能で示す。これにより、各子システム（またはその配下の孫システム）毎に最大「１６×２５６」のＪＯＧコントローラを設けることができる。

また、子システムにおいて、何れかのコンティニュアスコントローラが操作されると、その旨がＣ１４：コンティニュアスコントローラというパケットによって、該子システムから親システム２２０に通知される。なお、コンティニュアスコントローラとは、操作量の絶対的な値によってパラメータを設定する操作子であり、その操作量は「１６ビット」の分解能を有する。本実施例のデジタルミキサにおいては、電動フェーダがこれに該当する。また、上述したように、サブセクション１０３−Ａにおいてはタッチスクリーン１３０はライトペンまたは指先による押下のオン／オフ情報と、押下位置とが検出される。このうち、押下のオン／オフ情報は、「スイッチのオン／オフ」であるとみなされる。また、押下位置のＸ座標およびＹ座標は各々個別のコンティニュアスコントローラの操作量であるとみなされる。

Ｃ１４：コンティニュアスコントローラのパケットにおいて、第１データは「Ｅｘｈ」であり、第２データは操作量の上位「８ビット」、第３データは操作量の下位「８ビット」である。なお、本実施例においては、電動フェーダ等のコンティニュアスコントローラは子システムによって直接的に（孫システムを経由することなく）監視および制御される。コンティニュアスコントローラを識別する情報はポート番号のみであるから、本実施例において各子システムには最大「１６」のコンティニュアスコントローラを設けることができる。

(3．2)親システムから子システムへのデータ送信
次に、親システムから子システムに対するデータ送信用のパケットについて説明する。これらのパケットにおいては、送信先アドレスは何れかの子システムであり、送信元アドレスは親システム２２０のアドレスである。まず、子システム（またはその配下の孫システム）に対して、ＬＥＤの点灯状態を指定する場合は、その旨がＣ２１：ＬＥＤコントロールというパケットによって、親システム２２０から対応する子システムに通知される。該パケットにおいて、第１データは「６ｘｈ」であり、第２データは「００ｈ」〜「ＦＦｈ」の範囲のグループ番号である。ここで、「グループ」とは、輝度を同時に設定すべき一または複数のＬＥＤの集合の意味である。また、第３データは当該グループに設定される輝度であり、「００ｈ」〜「ＦＦｈ」の範囲で指定される。ここで「００ｈ」は消灯状態、「ＦＦｈ」は最大輝度の点灯状態であり、両者の間の値によって中間輝度の点灯状態が表現される。

また、ある一のＬＥＤをあるグループに含める旨を指定する場合には、その旨がＣ２２：ＬＥＤグループ設定というパケットによって、親システム２２０から該子システムに通知される。該パケットにおいて、第１データは「７ｘｈ」であり、第２データは「００ｈ」〜「ＦＦｈ」の範囲のＬＥＤ番号であり、第３データは「００ｈ」〜「ＦＦｈ」の範囲のグループ番号である。例えば、子システムがパケットＣ２１：ＬＥＤコントロールを受信し、（該子システムまたはその配下の孫システムの）あるグループの輝度が設定されると、そのグループに含まれている全てのＬＥＤは、設定された輝度で点灯ないし消灯する。また、子システムがパケットＣ２２：ＬＥＤグループ設定を受信し、あるＬＥＤをあるグループに含める設定が行われると、そのＬＥＤはそのグループに設定されている輝度で点灯ないし消灯する。なお、グループ「００ｈ」の輝度は「００ｈ」（消灯）に固定であり、また、グループ「ＦＦｈ」の起動は「ＦＦｈ」（最大輝度）に固定であり、それぞれ変更することはできない。

また、親システム２２０で実行されたシーンリコール等により、子システム（またはその配下の孫システム）の、何れかのＪＯＧコントローラに係るパラメータ値が変更され、当該パラメータに応じた表示を該子システム等において表示すべき場合には、そのパラメータ値がＣ２３：ＪＯＧコントローラというパケットによって、親システム２２０から該子システムに通知される。本実施例においては、各種ロータリーエンコーダの周囲にはＬＥＤが環状に配置されているから、これらロータリーエンコーダに対応するパラメータの設定値の概算値がこれらＬＥＤの点灯状態によって表示される。Ｃ２３：ＪＯＧコントローラにおいて、第１データは「Ｃｘｈ」であり、第２データは「００ｈ」〜「ＦＦｈ」の値によってＪＯＧコントローラの種別を示す。そして、第３データは該ＪＯＧコントローラに係るパラメータ値を「８ビット」の分解能で示す。

また、子システムに対して、何れかのコンティニュアスコントローラの操作量を設定すべき場合には、その旨がＣ２４：コンティニュアスコントローラというパケットによって、親システム２２０から該子システムに通知される。上述したように、本実施例においては、電動フェーダと、タッチスクリーン１３０のＸ座標およびＹ座標とがコンティニュアスコントローラとして扱われるが、このうち親システム２２０から操作量が設定されるものは電動フェーダのみである。Ｃ２４：コンティニュアスコントローラのパケットにおいて、第１データは「Ｅｘｈ」であり、第２データは設定すべき操作量の上位「８ビット」、第３データは該操作量の下位「８ビット」である。

2．2．Ｓバス・プロトコル
2．2．1．物理的構成
次に、子システムおよび配下の孫システム間を接続するＳバス２１１〜２１４のプロトコルを説明する。まず、先に図３において述べたように子システム２０１−Ａには二の孫システム２０１−Ｂ，２０１−Ｃが接続されているが、仮に孫システム２０１−Ｂのみが子システム２０１−Ａに対して一対一に接続されていたと仮定した場合のバス構成を図８(a)に示す。図において子システム２０１−Ａが出力する初期化信号／ＥＸＴＩＣは、接続ライン２１１−１を介して、孫システム２０１−Ｂにリセット信号／ＲＥＳＥＴとして供給される。また、孫システム２０１−Ｂの出力データ信号ＴＸＤは、接続ライン２１１−２を介して、子システム２０１−Ａに入力データ信号ＲＸＤとして供給される。逆に、子システム２０１−Ａの出力データ信号ＴＸＤは、接続ライン２１１−３を介して、孫システム２０１−Ｂに入力データ信号ＲＸＤとして供給される。

また、接続ライン２１１−４を介して、子システム２０１−Ａから孫システム２０１−Ｂに対してクロック信号ＣＬＫが出力される。また、接続ライン２１１−５，２１１−６の各々を介して、孫システム２０１−Ｂから子システム２０１−Ａに対して、ビジー信号ＢＵＳＹおよび送信要求信号ＴＸＲＥＱが出力供給される。ここで、ビジー信号ＢＵＳＹは、孫システム２０１−Ｂが内部処理等のために子システム２０１−Ａからデータを受け取れる状態にない場合に“０”に設定され、データを受信可能な場合に“１”に設定される。また、送信要求信号ＴＸＲＥＱは、孫システム２０１−Ｂから子システム２０１−Ａに対して送信すべきデータが発生し、そのデータ送信の許可を子システム２０１−Ａに求める場合に“０”に設定され、それ以外の場合に“１”に設定される。

次に、本実施例の実際の構成のように、子システム２０１−Ａに複数の孫システムが接続される場合の接続状態を図８(b)に示す。なお、本実施例では子システム２０１−Ａに「２台」の孫システムが接続されているが、ここでは説明の便宜上、３台の孫システム２０１−Ｂ，２０１−Ｃ，２０１−Ｄが接続される場合の接続状態を示す。一つの子システムに対しては最大「７台」の孫システムを接続することができ、各孫システムには各々にＳバス上のユニークなアドレス「０００ｂ」〜「１１０ｂ」が付与される。図８(b)においては、図８(a)に示した全ての接続ライン２１１−１〜２１１−６は、全ての孫システム２０１−Ｂ〜２０１−Ｄに対してパラレルに接続される。従って、子システム２０１−Ａの出力する初期化信号／ＥＸＴＩＣ、出力データ信号ＴＸＤおよびクロック信号ＣＬＫは、全ての孫システムに対してパラレルに供給されることになる。

また、このように複数の孫システムをパラレルに接続する場合には、孫システムの出力する出力データ信号ＴＸＤ、ビジー信号ＢＵＳＹおよび送信要求信号ＴＸＲＥＱは、オープンドレイン出力でなければならず、対応する接続ラインをプルアップしておく必要がある。これにより、各孫システムの出力信号のワイヤードアンド結果が子システム２０１−Ａによって受信されることになる。例えば、各孫システムはビジー状態にあるとき“０”のビジー信号を出力し、ビジー状態にないとき“１”のビジー信号を出力する。従って、子システムは、配下の何れかの孫システムがビジー状態のときに“０”のビジー信号ＢＵＳＹを受信し、配下の全ての孫システムがビジー状態にないとき“１”のビジー信号ＢＵＳＹを受信する。

2．2．2．パケット形式
次に、子システムおよび孫システム間においては、両者の出力データ信号ＴＸＤおよび入力データ信号ＲＸＤによってパケットが送受信されることにより、データが伝送される。ここで、伝送されるパケットの形式を図９(a)〜(f)を参照し説明する。何れのパケットも「１バイト」を単位として送受信されるが、図９(a)に示すように子システムから孫システムに送信されるパケットにはメッシュを付して表示し、孫システムから子システムに送信されるパケットは無地にて表示する。

まず、子システムから何れかの孫システムに対してデータを送信する場合には、図９(b)に示す形式の子システム送信パケット４００が送受信される。パケット４００の内部において４０１は先頭に設けられるステータスバイトであり、当該パケット４００を受信すべき孫システムのアドレス、データの送信方向等がここで指定される。４０２〜４０４は第１〜第３データであり、その内容は図７に示したＥバスプロトコルの第１〜第３データと同様である。

次に、子システムが何れかの孫システムからデータを受信する場合には、図９(c)に示す子システム受信パケット４１０が送受信される。パケット４１０の内部において４１１は、上記ステータスバイト４０１と同様のステータスバイトである。４１２〜４１４は第１〜第３データであり、その内容は図７に示したＥバスプロトコルの第１〜第３データと同様であるが、これらデータはステータスバイト４１１において指定された孫システムによって送信される。

ところで、ある孫システムから子システムに対してデータ送信が必要になった場合、例えば孫システムが監視および制御する操作子に何らかの操作イベントが発生した場合には、その孫システムにおいては送信要求信号ＴＸＲＥＱが“０”に設定される。しかし、子システムに受信される送信要求信号ＴＸＲＥＱは配下の全ての孫システムが出力する送信要求信号ＴＸＲＥＱのワイヤードアンド結果であるから、子システムは送信要求を発生した孫システムを直ちに特定することができない。そこで、送信要求を発生した孫システムを特定するために、図９(d)に示すアービトレーションパケット４２０が送受信される。パケット４２０の内部において４２１はステータスバイトであり、該パケット４２０がアービトレーションパケットであることを表示する。４２２はこれに対するリプライバイトであり、配下の全ての孫システムから送信される。従って、子システムによって受信されるリプライバイト４２２は、これらのワイヤードアンド結果である。

次に、図９(e)を参照し、ステータスバイト４０１，４１１，４１２の詳細を説明する。ステータスバイト４０１，４１１，４１２の上位「３ビット」はアドレス４３０を構成する。このアドレス４３０は、子システム送信パケット４００または子システム受信パケット４１０においては、特定の一の孫システムのアドレス、すなわち「０００ｂ」〜「１１０ｂ」の値である。また、アービトレーションパケット４２０においては、アドレス４３０は「１１１ｂ」に設定される。これは、全ての孫システムに対して同時に通信するためのブロードキャストの意味である。次に、ステータスバイトの上位から第４ビットは通信方向フラグ４３２であり、ステータスバイトに続く第１〜第３データを子システムが出力する場合は“０”(Write)に設定され、第１〜第３データまたはリプライバイト４２２を孫システムが出力すべき場合は“１”(Read)に設定される。ステータスバイトの下位「４ビット」はエラーチェックコード４３４を構成する。これは、子システムが出力する全てのステータスバイト毎に「１」づつカウントアップしたカウント結果の下位「４ビット」の値である。なお、アービトレーションパケットの通信方向フラグ４３２を“１”(Read)とすれば、アドレス「１１１ｂ」の逆方向“０”(Write)のパケットを別のコマンドとして用いることができる。

次に、図９(f)を参照し、アービトレーションパケット４２０内のリプライバイト４２２として、各孫システムが子システムに送信するデータの詳細を説明する。まず、孫システムが送信要求信号ＴＸＲＥＱを出力していない場合には、該孫システムの出力するリプライバイトは「１１１１１１１１ｂ」である。また、孫システムが“０”の送信要求信号ＴＸＲＥＱを出力している場合には、孫システムのアドレスに応じてリプライバイトの内容が異なる。すなわち、図９(f)に示すように、孫システムのアドレスに対応したユニークな特定位置のビットが“０”にされ、その他のビットが“１”に設定されるのである。子システムにおいては、これら孫システムが出力したリプライバイトのワイヤードアンド結果が受信されるため、受信したリプライバイト４２２の各ビットのうち“０”であるビットを検索すると、送信要求が発生した孫システムが特定できる。例えば、リプライバイト４２２が「１１１１１０１０ｂ」であったならば、アドレス「０００ｂ」および「０１０ｂ」の２つの孫システムにおいて送信要求が発生したことがわかる。

2．2．3．パケット送信の具体例
(1)子システムから孫システムへのデータ送信
次に、図１０を参照し、子システムから孫システムに対してデータ送信を行う場合の動作を、子システムに「３」台の孫システムを接続した場合を例として説明する。なお、図１０〜図１２において、ＤＡＴＡ１〜３、ＢＵＳＹ１〜３、ＴＸＲＥＱ１〜３は、図８(b)における「３」台の孫システム２０１−Ｂ，２０１−Ｃ，２０１−Ｄが各々出力するデータ信号、ビジー信号および送信要求信号である。まず、各孫システムにおいては必要に応じて様々な処理が行われているが、これらの処理が終了すると、時刻ｔ1〜ｔ3の期間に各孫システムのビジー信号ＢＵＳＹ１〜３が“１”に立ち上がる。そして、全てのビジー信号ＢＵＳＹ１〜３が立ち上がったタイミングである時刻ｔ3において、子システムに受信されるビジー信号ＢＵＳＹが“１”になるため、全ての孫システムにおいてステータスバイトの受信が可能になった旨が子システムにおいて認識される。

かかる状態において子システムが特定の孫システムに対してデータ送信すべき場合には、子システムからステータスバイト４０１の各ビットが順次送信される。また、クロック信号ＣＬＫは、各ビットが出力されるタイミングに同期して“０”に立ち下げられる。該ステータスバイトの受信が各孫システムにおいて開始されると、孫システムにおいては、ステータスバイトを受信するとともに該ステータスバイトに対応する処理を実行するために、時刻ｔ5〜ｔ7の期間にビジー信号ＢＵＳＹ１〜３が各々“０”に立ち下げられる。このうち少なくとも一の信号が“０”になると、子システムに受信されるビジー信号ＢＵＳＹは“０”になる。これにより、子システムにおいては、該ビジー信号ＢＵＳＹが再び“１”に立ち上がるまで、孫システムに対する送信が待機される。

ここで、各孫システムにおいては、ステータスバイト４０１内のアドレス４３０と、自機のアドレスとが比較され、両者の一致／不一致が判定される。図示の例にあっては、孫システム２０１−Ｃのみにおいて「一致」と判定され、他の孫システムにおいては「不一致」と判定されたとする。そして、孫システム２０１−Ｃにおいては、通信方向フラグ４３２に応じて、自機が第１〜第３データを出力するのか、子システムの出力する第１〜第３データを自機が受信するのかが判定される。また、各孫システムにおいては、エラーチェックコード４３４の結果が正当であるか否かも判定される。なお、かかる処理の詳細は後述する。

各孫システムにおいて以上のようなステータスバイト４０１に対する処理が終了すると、時刻ｔ8〜ｔ10の期間に、各ビジー信号ＢＵＳＹ１〜３が“１”に立ち上げられる。そして、最終的なビジー信号ＢＵＳＹは、最後の時刻ｔ9において“１”になる。子システムにおいては、ビジー信号ＢＵＳＹが“１”になったことが確認されると、時刻ｔ11から第１データ４０２の各ビットが順次出力される。各孫システムにおいては、この第１コマンド４０２を解釈するために、時刻ｔ12〜ｔ14の期間において、各ビジー信号ＢＵＳＹが“０”に立ち下がる。トータルのビジー信号ＢＵＳＹは、最先の時刻ｔ12に“０”に立ち下がる。

ここで、孫システム２０１−Ｃの内部においては、この第１データ４０２は有効なデータとして、その内容に応じた処理が実行される。一方、他の孫システムにおいては、該第１データ４０２の内容は無視されることになる。そして、各孫システムにおいて、「無視する」との判断、または必要な処理の実行が終了すると、時刻ｔ15〜ｔ17の期間においてビジー信号ＢＵＳＹが“１”に立ち上がる。以下、同様の処理が第２データ４０３および第３データ４０４についての実行され、以上の処理によって子システムから孫システム２０１−Ｃに対して、第１〜第３データが送信されたことになる。

(2)孫システムから子システムへのデータ送信
次に、図１１，図１２を参照し、孫システムから子システムに対してデータ送信を行う場合の動作を説明する。まず、孫システム２０１−Ｂ，２０１−Ｄが監視および制御するサブセクションにおいて、例えば何らかの操作子の操作イベントが発生する。そして、孫システム２０１−Ｂ，２０１−Ｄにおいて、これらイベントを子システムを介して親システムに送信すべく、送信要求信号ＴＸＲＥＱ１，３が図１１の時刻ｔ44，ｔ45において“０”に立ち下がったとする。トータルの送信要求信号ＴＸＲＥＱは、このうち最先の時刻ｔ44において“０”に立ち下がることになる。

送信要求信号ＴＸＲＥＱが“０”になったことが検出されると、子システムにおいては、トータルのビジー信号ＢＵＳＹが“１”であるか否かが確認され、仮にビジー信号ＢＵＳＹが“０”であれば“１”になるまで処理が待機する。図示の例では時刻ｔ44の時点でビジー信号ＢＵＳＹは“１”であるから、その直後の時刻ｔ46において、アービトレーションパケット４２０のステータスバイト４２１の出力が開始される。時刻ｔ47〜ｔ49においては、このステータスバイト４２１を受信および解釈するために、各孫システムのビジー信号ＢＵＳＹ１〜３が次々と“０”に立ち下げられる。

ここで、“０”の送信要求信号ＴＸＲＥＱ１，３を出力中の孫システム２０１−Ｂ，２０１−Ｄにおいては、ステータスバイト４２１に対して、「自機が送信要求を出力した」旨を通知するリプライバイトを返信すべきである、と判定される。一方、孫システム２０１−Ｃにおいては送信要求が発生していないため、「自機は送信要求を出力していない」旨を通知するリプライバイトを返信すべきである、と判定される。以上のような判定が終了し、リプライバイトを返信する準備が完了すると、各孫システムにおいて、時刻ｔ50〜ｔ52の期間において、ビジー信号ＢＵＳＹ１〜３が各々“１”に立ち上げられる。子システムにおいてはトータルのビジー信号ＢＵＳＹが“１”になったことが確認されると、時刻ｔ53から、クロック信号ＣＬＫの出力が開始される。

各孫システムにおいては、このクロック信号ＣＬＫの立ち下がりが検出されると、自機が“０”の送信要求信号ＴＸＲＥＱ１〜３を出力中であるか否かと、自機のアドレスとに基づいて、図９(f)に示されたリプライバイト４２２がの各ビットが順次出力される。このリプライバイト４２２の各ビットはビット毎にワイヤードアンドされ、その結果が子システムに受信されるから、受信したリプライバイト４２２のうち“０”であるビットに応じて、“０”の送信要求信号ＴＸＲＥＱを出力した孫システムは２０１−Ｂ，２０１−Ｄである旨が子システムにおいて認識されることになる。そして、リプライバイトの出力が完了すると、各孫システムのビジー信号ＢＵＳＹ１〜３が時刻ｔ57〜ｔ59の期間において各々“１”に立ち上げられる。

次に図１２において、トータルのビジー信号ＢＵＳＹが“１”である旨が子システムにおいて確認されると、送信要求があった孫システムのうち、何れか一の孫システム（ここでは孫システム２０１−Ｂであったとする）に対する子システム受信パケット４１０のステータスバイト４１１の各ビットが子システムから順次出力される（時刻ｔ60）。そして、各孫システムにおいては、ステータスバイトを受信するとともに対応する処理を実行するために、時刻ｔ61〜ｔ63の期間にビジー信号ＢＵＳＹ１〜３が各々“０”に立ち下げられる。

ここで、各孫システムにおいては、ステータスバイト４０１内のアドレス４３０と、自機のアドレスとが比較され、両者の一致／不一致が判定される。図示の例にあっては、孫システム２０１−Ｂにおいて「一致する」と判定され、他の孫システムにおいては「不一致」と判定されたとする。そして、孫システム２０１−Ｂにおいては、通信方向フラグ４３２に応じて、自機が第１〜第３データを出力するのか、子システムの出力する第１〜第３データを自機が受信するのかが判定される。ここでは、自機がデータを送信する“１”(Read)であったとする。各孫システムにおいて以上のようなステータスバイト４１１に対する処理が終了すると、時刻ｔ64〜ｔ66の期間に、各ビジー信号ＢＵＳＹ１〜３が“１”に立ち上げられる。そして、最終的なビジー信号ＢＵＳＹは、最後の時刻ｔ65において“１”になる。子システムにおいては、ビジー信号ＢＵＳＹが“１”になったことが確認されると、時刻ｔ67からクロック信号ＣＬＫの出力が開始される。

孫システム２０１−Ｂにおいて、このクロック信号ＣＬＫの立ち下がりが検出されると、先に送信要求したパケットの第１データ４１２の内容が該クロック信号ＣＬＫに同期して出力される。一方、アドレスが不一致であった他の孫システムにおいては、ダミーデータ（“１”信号）が出力される。これにより、これらのワイヤードアンド結果は、孫システム２０１−Ｂの出力した第１データ４１２の内容と同一になり、該第１データ４１２が子システムによって受信される。そして、第１データ４１２またはダミーデータの出力が完了すると、各孫システムのビジー信号ＢＵＳＹ１〜３が時刻ｔ71〜ｔ73の期間において各々“１”に立ち上げられる。以後同様に、子システムにおいて第２データ４１３および第３データ４１４に対するクロック信号ＣＬＫが順次生成されると、これに同期して孫システム２０１−Ｂから第２データ４１３および第３データ４１４が順次出力される。

以上により、孫システム２０１−Ｂから子システムに対するデータ転送が終了したため、孫システム２０１−Ｂの送信要求信号ＴＸＲＥＱ１は時刻ｔ88において“１”に立ち上げられる。但し、他の送信要求を行った孫システム２０１−Ｄについては未だデータ転送が実行されていないため、その送信要求信号ＴＸＲＥＱ３は引き続き“０”に保たれている。これにより、時刻ｔ60〜ｔ88 の期間と同様の処理が、子システムと孫システム２０１−Ｄとの間で実行されることになる。

3．実施例の動作
3．1．子システム：親システムからのデータ受信
次に、Ｅバス２１６，２１７を介して子システムが親システムからパケットを受信した場合の動作を説明する。子システムにおいてＥバス２１６，２１７を介して「５バイト」パケットが受信されると、子システムにおいては図１３(a)に示すデータ受信ルーチンが起動される。図において処理がステップＳＰ２に進むと、受信したパケットは共通プロトコルのパケットであるか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ４に進み、配下の孫システムに対して当該共通プロトコルのパケットのデータ部３８０が送信される。次に、処理がステップＳＰ６に進むと、受信した共通プロトコルのデータ部３８０に応じた処理が実行される。すなわち、「Ｃ０１：Ｅバススタート」が受信されたのであれば、子システム内部において必要な初期化処理が実行される。また、「Ｃ０２：カテゴリＩＤ・サブアドレス・リクエスト」が受信されたのであれば、「Ｃ０３：カテゴリＩＤ・サブアドレス・リプライ」のパケットが親システム２２０に返信される。

一方、ステップＳＰ２において「ＮＯ」と判定されると、処理はステップＳＰ８に進む。本実施例において、かかる場合には、受信されたパケットは必ず標準プロトコルのパケットである。ステップＳＰ８においては、データ部３８０内の第１データの内容が確認され、「(a)該パケットは「Ｃ２４：コンティニュアスコントローラ」である」、「(b)第１データ内のポート番号ｘが『０ｈ』である」、のうち何れかの条件が満たされているか否かが判定される。本実施例においては、子システムは孫システムを経由することなくコンティニュアスコントローラを直接的に監視および制御することにしている。これは、子システムが直接監視・制御している方が操作に対するレスポンスが良いためである。また、他の操作子等については、子システムが直接的に監視および制御するものに対しては、ポート番号ｘとして「０ｈ」が割り当てられている。従って、ステップＳＰ８は、受信したパケットが「孫システムを経由することなく子システムが直接的に処理すべきパケットであるか否か」を判定するステップである。なお、コンティニュアスコントローラについても、他の操作子と同様、ポート番号ｘで子システム、孫システムの振り分けをするようにしてもよい。

ステップＳＰ８において「ＹＥＳ」と判定されると、処理はステップＳＰ１０に進み、受信した標準プロトコルのデータ部３８０に基づいて、これに応じた処理が実行される。例えば、受信したパケットが「Ｃ２４：コンティニュアスコントローラ」であれば、ポート番号ｘに対応する電動フェーダの操作量が、第２データおよび第３データによって示される操作量になるまで、該電動フェーダが駆動される。一方、ステップＳＰ８において「ＮＯ」と判定されると、処理はステップＳＰ１２に進む。子システムにおいては、コンティニュアスコントローラ以外の操作子については、ポート番号ｘに応じて孫システムに割り当てられている。このため、ステップＳＰ１２においては、該ポート番号ｘに対応する孫システムに対して、Ｓバスを介してデータ部３８０が送信される。

ところで、上記ステップＳＰ４およびＳＰ１２においては、図１５(a)に示す対孫送信サブルーチンが呼び出されることにより、実際の転送処理が実行される。以下、同サブルーチンの内容を説明する。図１５(a)において処理がステップＳＰ６２に進むと、孫システムに転送すべき第１〜第３データが準備され、所定のレジスタに格納される。次に、処理がステップＳＰ６４に進むと、子システム送信パケット４００用のステータスバイト４０１が作成される。該ステータスバイト４０１において、アドレス４３０は第１〜第３データを送信すべき孫システムのアドレスであり、通信方向フラグ４３２は“０”(Write)に設定される。また、エラーチェックコード４３４は、過去に送信した最後のステータスバイトに用いたエラーチェックコードを「１」だけカウントアップした値に設定される。次に、処理がステップＳＰ６６に進むと、作成したステータスバイト４０１が各孫システムに対して送信され、ステップＳＰ６８においては第１〜第３データが順次出力される。

このように、ステップＳＰ４およびＳＰ１２（および対孫送信サブルーチン（図１５(a)））においては、親システム２２０から受信したデータ部３８０（第１〜第３データ）がそのままの形で孫システムに転送される。すなわち、本実施例によれば、予め子システムにおいてデータ変換を行うような処理は全く不要になり、子システムの負荷をきわめて軽減することができるのである。

3．2．孫システム：子システムからのデータ受信
上記対孫送信サブルーチン（図１５(a)）のステップＳＰ６６においては子システムによってステータスバイトが孫システムに送信されたが、該ステータスバイトの受信が完了すると、各孫システムにおいて図１６に示すステータスバイト受信イベントルーチンが起動される。図において処理がステップＳＰ１０４に進むと、エラーチェックコード４３４が正常であるか否かが確認される。すなわち、今回受信したエラーチェックコード４３４は、当該Ｓバスにおいて過去に送信された最後のステータスバイトに用いたエラーチェックコードを「１」だけカウントアップした値に等しいか否かが確認される。ここで「ＮＯ」と判定されると、処理はステップＳＰ１０６に進み、所定のエラー処理が実行された後に本ルーチンの処理が終了する。

一方、エラーチェックコード４３４が正常であれば、処理はステップＳＰ１０７に進み、該ステータスバイトはアービトレーションパケットのステータスバイト４２１であるか否かが判定される。ここで「ＮＯ」と判定されると、処理はステップＳＰ１０８に進み、ステータスバイト内のアドレス４３０によって自機が指定されたか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ１１６に進み、通信方向フラグ４３２“１”(Read)であるか否かが判定される。ここで「ＮＯ」（“０”：Write）と判定されると、処理はステップＳＰ１１８に進み、第１〜第３データが順次受信される。

なお、ステップＳＰ１１８の実行時間には所定の「最大時間」が設定されている。この最大時間中に第１〜第３データが全て受信されなかった場合には、その時点で「タイムアウト」としてステップＳＰ１１８の処理が中断される。次に、処理がステップＳＰ１２０に進むと、第１〜第３データの内容が正常であるか否かが判定される。なお、上記タイムアウトが発生した場合には、第１〜第３データは常に異常であると判定されることになる。ここで「ＮＯ」と判定されると、処理はステップＳＰ１２２に進み、所定のエラー処理が実行された後に本ルーチンの処理が終了する。一方、ステップＳＰ２０において「ＹＥＳ」と判定されると、本ルーチンが正常終了する。

このように、第１〜第３データに係るパケットが正常に受信された後にステータスバイト受信イベントルーチン（図１６）が終了すると、当該孫システムにおいては、図１３(b)に示すデータ受信ルーチンが引き続いて起動される。図１３(b)において処理がステップＳＰ２２に進むと、受信したパケットは共通プロトコルのパケットであるか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ２４に進み、受信した共通プロトコルのデータ部３８０に応じた処理が実行される。例えば、「Ｃ０１：Ｅバススタート」が受信されたのであれば、孫システム内部において必要な初期化処理が実行される。なお、「Ｃ０２：カテゴリＩＤ・サブアドレス・リクエスト」などについては、子システムが独自に親システムに対して応答すべきものであるから、孫システムにおいては無視される。

ところで、先に述べたステップＳＰ４（図１３(a)）においては、子システムによって受信された共通プロトコルのパケットは、その内容にかかわらず孫システムにも転送される。従って、上述したように、孫システムにとって不要なパケットも子システムから転送されることになり、受信した共通プロトコルのパケットを無視するか否かは孫システムにおいて独自に判断されることになる。これにより、親システムと孫システムとの間で送受信される共通プロトコルのパケットを新たに定めたとしても、子システムは単にこれを転送を実行すればよいため、追加された共通プロトコルに関して全く関知する必要がなくなり、設計変更等の作業を簡略化することができる。

一方、ステップＳＰ２２において「ＮＯ」と判定されると、処理はステップＳＰ２６に進む。本実施例において、かかる場合には、受信されたパケットは必ず標準プロトコルのパケットである。ステップＳＰ２６においては、受信した標準プロトコルのデータ部３８０に基づいて、これに応じた処理が実行される。例えば、受信したパケットが「Ｃ２３：ＪＯＧコントローラ」であれば、第１データ内のポート番号ｘおよび第２データ内の「種別」に対応する一のロータリーエンコーダの周辺ＬＥＤの点灯／消灯状態が、第３データによって示された操作量に対応する状態に変更される。

3．3．孫システム：データ送信要求の発生
次に、孫システムにおいて親システムに対して送信すべきデータが発生した場合は、図１４(a)に示すデータ発生イベントルーチンが起動される。孫システムが親システムに対して送信すべきデータには、標準プロトコルのパケットによって送信すべきデータと、共通プロトコルのパケットによって送信すべきデータとがある。例えば、該孫システムによって監視および制御されているスイッチ、ロータリーエンコーダ等の操作子が操作されると、その旨は標準プロトコルのパケットによって親システムに通知しなければならない。また、孫システムが当該孫システム自体の異常、または子システムの異常を検出した場合には、その旨を共通プロトコル（Ｃ０４：その他）によって親システム２２０に報告しなければならない。

そこで、該データ発生イベントルーチンにおいては、最初のステップＳＰ３０において、送信すべきデータは共通プロトコルによって送信すべきものであるか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ３２に進み、エラー内容等を報告するデータが共通プロトコル（Ｃ０４：その他）のパケットにおける第１〜第３データの形式で作成される。一方、ステップＳＰ３０において「ＮＯ」と判定されると、操作子等のイベント内容に基づいて、標準プロトコルのパケットの第１〜第３データが作成される。何れの場合も、次に処理がステップＳＰ３６に進むと、生成されたパケットを子システムに送信するために、“０”の送信要求信号ＴＸＲＥＱが出力され、本ルーチンの処理は終了する。

その後、当該送信要求信号ＴＸＲＥＱに応じて、子システムによってアービトレーションパケット４２０のステータスバイト４２１が送信される。これに対して、各孫システムにおいては、上述したステータスバイト受信イベントルーチン（図１６）が再び起動される。そして、処理がステップＳＰ１０７に進むと、ここで「ＹＥＳ」と判定され、処理はステップＳＰ１０９に進む。従って、各孫システムにおいては、自機が送信要求を行っているか否かと、自機のアドレスとに基づいてリプライバイト４２２が生成され、子システムが生成するクロック信号ＣＬＫに同期して該リプライバイト４２２の内容がＳバス上に送信される。

次に、送信要求を行った一または複数の孫システムの中から一の孫システムを指定するステータスバイト４１１を子システムが送信すると、各孫システムにおいては、該ステータスバイト受信イベントルーチン（図１６）が再び起動される。このステータスバイト４１１内のアドレス４３０によって受信先として指定された孫システムにおいては、ステップＳＰ１０４，ＳＰ１０８，ＳＰ１１６を介して処理はステップＳＰ１２４に進む。ここでは、先のデータ発生イベントルーチン（図１４(a)）によって準備された第１〜第３データが、送信用のレジスタに格納される。次に、処理がステップＳＰ１２６に進むと、子システムが発生するクロック信号ＣＬＫに同期して、これら第１〜第３データが子システムに対して順次送信される。そして、ステップＳＰ１２６においては、今回の送信によって子システムに現時点で送信すべきデータが全て送信されたのであれば、該孫システムが送信する送信要求信号ＴＸＲＥＱが“１”に設定される。一方、子システムに送信すべきデータが未だ残存している場合には、送信要求信号ＴＸＲＥＱは“０”のまま保たれる。

3．4．子システム：親システムへのデータ送信
次に、子システムにおいて親システムに対して送信すべきデータが発生した場合は、図１４(b)に示すデータ発生イベントルーチンが起動される。ここで、孫システムの場合と同様に、子システムが親システムに対して送信すべきデータには、標準プロトコルのパケットによって送信すべきデータと、共通プロトコルのパケットによって送信すべきデータとがある。例えば、該子システムによって監視および制御されている電動フェーダが操作されると、その旨は標準プロトコルのパケットによって親システムに通知しなければならない。また、子システムが配下の孫システムの異常を検出した場合、あるいは子システムが該子システム自体の異常を検出した場合には、その旨を共通プロトコル（Ｃ０４：その他）によって親システム２２０に報告しなければならない。

そこで、該データ発生イベントルーチンにおいても、最初のステップＳＰ４０において、送信すべきデータは共通プロトコルによって送信すべきものであるか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ４２に進み、エラー内容等を報告するデータが共通プロトコル（Ｃ０４：その他）のパケットにおける第１〜第３データの形式で作成される。一方、ステップＳＰ３０において「ＮＯ」と判定されると、操作子等のイベント内容に基づいて、標準プロトコルのパケットの第１〜第３データが作成される。何れの場合も、次に処理がステップＳＰ４６に進むと、生成された第１〜第３データがＥバス上のパケットに変換され親システム２２０に送信される。

3．5．子システム：孫システムからの送信要求に対する処理
次に、子システムにおいて受信している送信要求信号ＴＸＲＥＱが“０”になると、ＣＰＵ２５２に対して送信要求割込みが発生し、図１５(b)に示す送信要求割込みルーチンが起動される。図において処理がステップＳＰ７２に進むと、アービトレーションパケット４２０のステータスバイト４２１がＳバスを介して配下の孫システムに送信され、これに対して各孫システムが送信したリプライバイトのワイヤードアンド結果であるリプライバイト４２２が子システムにおいて受信される。

上述したように、このリプライバイト４２２においては複数の孫システムが“０”を返信することがあるため、次のステップＳＰ７４においては、これら送信要求を行った孫システムのうち、子システムに対してデータを送信すべき孫システムが決定される。次に、処理がステップＳＰ７６に進むと、子システム受信パケット４１０のステータスバイト４１１が生成される。このステータスバイト４１１において指定されるアドレス４３０は先にステップＳＰ７４において決定された孫システムのアドレスである。また、通信方向フラグ４３２は“１”(Read)であり、エラーチェックコード４３４は、過去に送信したエラーチェックコードを「１」だけカウントアップした値に設定される。

次に、処理がステップＳＰ７８に進むと、該ステータスバイト４１１がＳバスを介して送信される。次に、処理がステップＳＰ８０に進むと、孫システムから送信された第１〜第３データが順次受信される。なお、ステップＳＰ８０の実行時間には所定の「最大時間」が設定されている。この最大時間中に第１〜第３データが全て受信されなかった場合には、その時点で「タイムアウト」としてステップＳＰ８０の処理が中断される。次に、処理がステップＳＰ８２に進むと、第１〜第３データの内容が正常であるか否かが判定される。なお、上記タイムアウトが発生した場合には、第１〜第３データは常に異常であると判定されることになる。

ここで「ＹＥＳ」と判定されると、処理は正常終了する。一方、「ＮＯ」と判定されると、処理はステップＳＰ８４に進み、所定のエラー処理が実行された後に本ルーチンの処理は異常終了する。そして、送信要求割込みルーチン（図１５(b)）が正常終了した場合には、図１４(c)に示すデータ受信イベントルーチンが起動される。図において処理がステップＳＰ５０に進むと、先に受信した第１〜第３データがＥバス上のパケットとして親システム２２０に送信される。

3．6．孫システム：子システムおよび他の孫システムの監視
上述したように、子システムが出力するステータスバイトは、アービトレーションパケット４２０のものを除けば、特定の一の孫システムを通信相手として指定するものである。従って、通信相手として指定されなかった他の孫システムにおいては、該ステータスバイトに係るパケットを無視しても差し支えない。しかし、本実施例においては、各孫システムは自機が通信相手として指定されなかった場合には、子システムを監視することにより、装置全体としての信頼性を向上させている。ここで、再びステータスバイト受信イベントルーチン（図１６）を参照しその詳細を説明する。

まず、上述したように、ステータスバイトが受信されると、ステップＳＰ１０４においてエラーチェックコード４３４が正しいか否かがチェックされるが、かかる処理は自機が通信相手として指定されたか否かにかかわらず実行される。次に、通信相手として指定されなかった孫システムにおいては、ステップＳＰ１０８において「ＮＯ」と判定され、処理はステップＳＰ１１０に進む。ここでは、Ｓバス上に送出される第１〜第３データが順次受信される。このステップＳＰ１１０においても、上述したＳＰ１１８と同様に、最大時間中に第１〜第３データが全て受信されなかった場合には、その時点で「タイムアウト」が発生したと判断されステップＳＰ１１０の処理が中断される。そして、処理がステップＳＰ１１２に進むと、該第１〜第３データがが正常であるか否かが確認される。ここで「ＹＥＳ」と判定されると、本ルーチンの処理が正常終了する。一方、タイムアウトが発生した場合など異常である場合は「ＮＯ」と判定され、処理はステップＳＰ１１４に進み、所定のエラー処理が実行された後に処理が異常終了する。

3．7．エラー処理の詳細
ところで、対孫送信サブルーチン（図１５(a)）のステップＳＰ８４、ステータスバイト受信イベントルーチン（図１６）のステップＳＰ１０６，ＳＰ１１４，ＳＰ１２２においては所定のエラー処理が実行される旨を述べたが、ここでエラー処理とは、発生したエラーの詳細を報告するように、共通プロトコルの「Ｃ０４：その他」に属する第１〜第３データを作成し、これを親システム２２０に送信する処理である。ここで、子システムが孫システムの異常を検出した場合にその旨を親システムに報告する場合には通信経路上の障害は無いが、孫システムが子システムの異常を検出した場合には問題がある。すなわち、孫システムと親システム２２０の間には、エラーの詳細を直接的に報告する通信経路が設けられておらず、孫システムは障害を有する子システムを介して親システムにエラーの詳細を報告する共通プロトコルのパケットを送信しなければならないのである。

ここで、子システムに生じている障害の状況次第では、子システムは該パケットを仲介できない可能性もある。しかし、子システムにおいてなんらかの障害が存在したとしても、少なくとも孫システムから親システム２２０宛に送信されたパケットを仲介する機能が動作していれば、当該パケットを親システムに到達させることができる。これにより、装置に障害が発生した場合に、親システム２２０においては詳細な障害内容を迅速に把握することができる。さらに、例えば親システムがある子システムの暴走状態を把握することができた場合に、親システムが当該子システムに対してのみ「Ｃ０１：Ｅバススタート」を出力して該子システムをリセットしてもよい。これにより、子システムが再び正常に動作する可能性もある。

4．実施例の効果
以上のように、本実施例においては、以下のような効果がある。
(1)孫システムがデータ部３８０の内容を生成し子システムがヘッダ部３７０を生成したＥバス上のパケットは、子システムが全体を生成したパケットと全く同一の形式で親システム２２０に送信される。従って、親システム２２０においては、ある子システムからパケットを受信したとき、そのパケットは子システムが全体を生成したパケットであるのか、孫システムがデータ部３８０を生成し子システムが仲介したパケットであるのかを区別する必要がない。従って、本実施例によれば、親システム２２０が直接的に管理すべきＥバス上のデバイスをきわめて少なくすることが可能になる。さらに、孫システムのＣＰＵ２７２にはＩ²Ｃ機能を有しない安価なＣＰＵを使用することができるから、制御システム全体のコストダウンを図ることができる。

(2)また、本実施例において子システムと孫システムとの間でパケットの送受信が実行される場合は、必ず子システムが出力するステータスバイト４０１，４１１，４１２によってパケットが開始される。このステータスバイトによれば、これに引き続いて第１〜第３データまたはリプライバイト４２２を出力するデバイス（子システムまたは孫システム）が一意に特定される。従って、例えば複数のデバイスが同時にデータ送信を開始してＳバス上でデータが衝突するような事態が未然に防止される。換言すれば、かかるデータの衝突を考慮することなく子システムのシリアルＩ／Ｏ部２４６および孫システムのシリアルＩ／Ｏ部２６６を構成することができ、これらの要素にかかる費用については一層のコストダウンが可能である。

(3)さらに、各孫システムはその上位の子システムとのみ通信するために、孫システムが出力するデータ中に通信の相手先を特定する情報は全く不要である。さらに、Ｓバスにデータを出力する孫システムは予めステータスバイトにて指定された孫システムに限られるから、孫システムは自機のアドレスすら送信する必要がない。これにより、孫システムのシリアルＩ／Ｏ部２６６においては、データに送受信アドレスを付加するような動作は全く不要になり、シリアルＩ／Ｏ部２６６等の一層のコストダウンを実現することができる。

(4)また、本実施例においては、ステータスバイトにおいて通信相手として指定されなかった孫システムにおいても、エラーチェックコード４３４が正しいか否か判定（ＳＰ１０４〜ＳＰ１０６）されるとともに、Ｓバス上に現れた第１〜第３データが正常に出力されたか否かも判定される（ＳＰ１０８〜ＳＰ１１４）。これにより、データ通信に直接的に関与していない孫システムも「チェック装置」としての機能を発揮することができるから、孫システムが有するリソースを有効に利用してデジタルミキサ全体の信頼性を高めることができる。また、ステータスバイトにおいて自機が通信相手として指定されなかった孫システムにおいてエラーチェックコード４３４の推移が把握しておくことにより、次に自機を通信相手として指定したステータスバイトを受信したとき、その中に含まれるエラーチェックコード４３４が正当なものであるか否かを迅速かつ容易に判定することができる。

(5)さらに、本実施例においては、孫システムにおいてデータ送信の必要性が発生した場合には、パケットが送受信されるデータ線とは別ラインの信号線にて送信要求信号ＴＸＲＥＱが子システムに送信される。従って、これらパケットの通信を全く妨げることなく孫システムから子システムに対して、データ送信の必要性を通知することができる。かかる構成は、例えば子システムからポーリングされるのを待って孫システムから子システムにデータ送信の必要性を報告する構成と比較すると、操作子等のイベントが生じたときに、その内容をより迅速に親システムに報告できる点できわめて有利である。

5．変形例
本発明は上述した実施例に限定されるものではなく、例えば以下のように種々の変形が可能である。
(1)上記実施例においては、各孫システム２０１−Ｂ〜２０１−Ｄの送信要求信号ＴＸＲＥＱ１〜３は接続ライン２１１−６に供給され、これら送信要求信号ＴＸＲＥＱ１〜３のワイヤードアンド結果が送信要求信号ＴＸＲＥＱとして子システム２０１−Ａに供給された（図８(a)）。しかし、図１７に示すように、これら送信要求信号ＴＸＲＥＱ１〜３を独立した接続ライン２１１−１１〜１３によって子システム２０１−Ａに供給してもよい。かかる構成によれば、子システム２０１−Ａは、接続ライン２１１−１１〜１３のうち何れが“０”になったかに基づいて送信要求を行った孫システムを直ちに特定することができる。従って、孫システムから子システムに対してパケットを送信する場合に、アービトレーションパケットの送受信は全く不要になる。

従って、本変形例を採用する場合には、図１１に示した信号処理を省略し、図１２に示した信号処理を直ちに実行することができる。このように、子システムが各孫システムの送信要求信号ＴＸＲＥＱ１〜３をそのまま受信するか、これらのワイヤードアンド結果を受信するかは、子システムに求められる動作速度や許容できる回路規模等に応じて決定するとよい。なお、子システムが何れの方式によって送信要求信号ＴＸＲＥＱを受信する場合であっても、孫システム自体の構成は一切変更する必要がない。

(2)また、上記実施例は、ＥバスおよびＳバスシステムをデジタルミキサ内の各デバイス間の通信に用いた例を説明したが、本発明はデジタルミキサ内の通信に限られるものではなく、例えば大型の電子楽器等、複数のＣＰＵ等によって装置を制御する各種機器に適用することができる。また、上記実施例においては、ＥバスおよびＳバスを組み合わせてデジタルミキサ内の通信経路を形成したが、より小規模な装置においては、Ｓバスのみを用いて制御システムを構成してもよいことは言うまでも無い。なお、Ｓバスのみを用いた制御システムは、制御の全体を統括する「マスタデバイス（実施例における子システム）」と、マスタデバイスの管理の下、制御の一部を分担する「スレーブデバイス（同、孫システム）」との組み合わせによって構成されることになる。

(3) また、上記実施例において、エラーチェックコード４３４はステータスバイトが出力される毎に「１」づつカウントアップされたが、エラーチェックコードはこれに限定されるものではなく、ステータスバイトが出力される毎に所定の規則で変動する値であって、その規則通りにエラーチェックコードが変動したか否かを各孫システムによって検証できるものであればどのようなものでもよい。

(4)また、上記実施例においては、各システムのＣＰＵ２２８，２５２，２７２上で動作するプログラムによって各種処理を実行したが、このプログラムのみをＣＤ−ＲＯＭ、フレキシブルディスク等の記録媒体に格納して頒布し、あるいは伝送路を通じて頒布することもできる。

本発明の一実施例のデジタルミキサの操作パネル１００パネルの平面図である。操作パネル１００内のセクション１０１，１０３の平面図である。一実施例のデジタルミキサの制御システムの全体ブロック図である。子システムおよび孫システムのブロック図である。Ｅバスシステムの要部の回路図である。Ｅバスシステムのタイミングチャートである。Ｅバスシステムのパケット構成を示す図である。Ｓバスシステムの構成例を示すブロック図である。Ｓバスシステムのパケット構成を示す図である。Ｓバスシステムのタイミングチャートである。Ｓバスシステムのタイミングチャートである。Ｓバスシステムのタイミングチャートである。子システムおよび孫システムのデータ受信ルーチンのフローチャートである。子システムおよび孫システムのデータ発生イベントルーチン、データ受信イベントルーチンのフローチャートである。子システムの対孫送信サブルーチンおよび送信要求割込みルーチンのフローチャートである。孫システムのステータスバイト受信イベントルーチンのフローチャートである。Ｓバスシステムの構成例の変形例のブロック図である

符号の説明

１００：操作パネル、１０１〜１０４：セクション、１０１−Ａ〜１０１−Ｃ，１０２−Ａ〜１０２−Ｃ，１０３−Ａ〜１０３−Ｃ，１０４−Ａ〜１０４−Ｃ：サブセクション、１１２−１〜ｎ：オン／オフスイッチ、１１４−１〜ｎ：センドモードスイッチ、１１６−１〜ｎ：ロータリーエンコーダ、１１８−１〜ｎ：ＬＥＤ表示器群、１２０−１〜ｎ：セレクトスイッチ、１２２−１〜ｎ：オン／オフスイッチ、１２４−１〜ｎ：電動フェーダ、１２６−１〜ｎ：ＣＵＥスイッチ、１３０：タッチスクリーン、１３２−１〜１３２−６，１３６−１〜１３６−１４，１３８−１〜１３８−１５：スイッチ、１３４−１〜１３４−１５：ロータリーエンコーダ、２０１−Ａ〜２０４−Ａ：子システム、２０１−Ｂ，２０１−Ｃ，２０１−Ｄ，２０２−Ｂ，２０２−Ｃ，２０３−Ｂ，２０３−Ｃ，２０４−Ｂ，２０４−Ｃ：孫システム、２１１〜２１４：Ｓバス、２１１−１〜２１１−６：接続ライン、２１１−１１〜１３：接続ライン、２１６，２１７：Ｅバス、２１６ｂ：ＳＤＡライン、２１６ａ：ＳＣＬライン、２２０：親システム、２２２：ＥバスＩ／Ｏ部、２２４：ＣＰＵバス、２２６：その他Ｉ／Ｏ部、２２８：ＣＰＵ、２３０：フラッシュメモリ、２３２：ＲＡＭ、２３４：信号処理部、２３６：波形Ｉ／Ｏ部、２３８：ディスプレイ、２４２：表示器群、２４４：操作子群、２４６：シリアルＩ／Ｏ部、２４８：ＥバスＩ／Ｏ部、２５２：ＣＰＵ、２５４：フラッシュメモリ、２５６：ＲＡＭ、２６２：表示器群、２６４：操作子群、２６６：シリアルＩ／Ｏ部、２７２：ＣＰＵ、２７４：フラッシュメモリ、２７６：ＲＡＭ、３５１〜３５６：バッファ、３６１〜３６６：トランジスタ、３７０：ヘッダ部、３７１，３７２：抵抗器、３８０：データ部、４００：子システム送信パケット、４０１，４１１，４１２：ステータスバイト、４１０：子システム受信パケット、４２０：アービトレーションパケット、４２１：ステータスバイト、４２２：リプライバイト、４３０：アドレス、４３２：通信方向フラグ、４３４：エラーチェックコード。

Claims

操作パネルと、該操作パネル上に設けられた複数の制御要素とを有する制御システムであって、前記複数の制御要素は、識別情報により各々が一意に特定されるとともに、各々が該操作パネル上の複数のセクションのうち何れか一のセクションに属するものである、制御システムにおいて、
送信先アドレスを含む第１種パケットを、前記送信先アドレスに基づいて伝送するための第１種バスと、
前記第１種バスに接続され、前記第１種バスにおいて一意なアドレスが付与された親デバイスと、
前記第１種バスに接続され、それぞれ前記第１種バスにおいて一意なアドレスが付与され、前記操作パネルの前記複数のセクションのうち何れかに対応する複数の子デバイスと、
第２種パケットを伝送するための、前記複数の子デバイスにそれぞれ固有に設けられた複数の第２種バスと、
前記複数の第２種バスの何れかに接続され、前記操作パネルの前記複数のセクションのうち何れかに対応する複数の孫デバイスと、
を備え、
前記親デバイスは、
前記第１種パケットであって、前記子デバイスのうち何れか一つを指標する前記送信先アドレスと、前記操作パネルの制御要素のうち何れか一つを指標する前記識別情報と、当該制御要素のための制御データとを含み、前記識別情報にて指定された制御要素を前記制御データにて制御するための第１種パケットを生成するとともに前記第１種バスを介して伝送する親デバイス第１種送信手段と、
前記第１種パケットであって、当該親デバイスを指標する前記送信先アドレスと、前記操作パネルの制御要素のうち何れか一つを指標する前記識別情報と、当該制御要素に対するユーザ操作内容を表す制御データとを含む第１種パケットを、前記第１種バスを介して前記複数の子デバイスのうち何れかから受信する親デバイス第１種受信手段と、
を有し、
前記各子デバイスは、
当該子デバイスが対応する前記操作パネルのセクションに含まれる前記一または複数の制御要素である子デバイス制御要素と、
当該子デバイスを指標する送信先アドレス情報を含む前記第１種パケットを、前記第１種バスを介して前記親デバイスから受信する子デバイス第１種受信手段と、
前記子デバイス第１種受信手段が前記第１種パケットを受信したことに応じて、該第１種パケットの識別情報が当該子デバイス制御要素の何れかを指標していた場合に、当該子デバイス制御要素を制御する子デバイス制御手段と、
前記子デバイス第１種受信手段が受信した前記第１種パケットの識別情報が前記子デバイス制御要素の何れかを指標するものでない場合に、当該受信した第一種パケットに含まれる識別情報および制御データと同一の識別情報および制御データを含む第２種パケットを生成し、該生成した第２種パケットが当該子デバイスに係る前記孫デバイスの何れかにて受信されるように前記第２種バスに伝送する子デバイス第２種送信手段と、
前記子デバイス制御要素に対するユーザ操作を検出する子デバイス操作検出手段と、
前記第２種バスを介して当該第２種バスに接続された一または複数の前記孫デバイスから前記第２種パケットを受信する子デバイス第２種受信手段と、
前記子デバイス操作検出手段が前記ユーザ操作を検出したことに応じて、当該操作された子デバイス制御要素を指標する識別情報と、当該操作された子デバイス制御要素に対する操作内容を示す制御データと、前記親デバイスを指標する送信先アドレスとを含む前記第１種パケットを生成して、前記第１種バスを介して前記親デバイスに伝送し、また、前記子デバイス第２種受信手段が前記第２種パケットを受信したことに応じて、当該第２種パケットに含まれる識別情報および制御データと同一の識別情報および制御データと、前記親デバイスを指標する送信先アドレスとを含む前記第１種パケットを生成して、前記第１種バスを介して前記親デバイスに送信する子デバイス第１種送信手段と、
を有し、
前記各孫デバイスは、
当該孫デバイスが対応する前記操作パネルのセクションに含まれる前記一または複数の制御要素である孫デバイス制御要素と、
前記第２種バスを介して、当該第２種バスに接続されている前記子デバイスから前記第２種パケットを受信する孫デバイス第２種受信手段と、
前記孫デバイス第２種受信手段が前記第２種パケットを受信したことに応じて、該受信した第２種パケットの識別情報が前記孫デバイス制御要素を指標するものであった場合に、当該第２種パケットに含まれる制御データに基づいて当該孫デバイス制御要素を制御する孫デバイス制御手段と、
前記孫デバイス制御要素に対するユーザ操作を検出する孫デバイス操作検出手段と、
前記孫デバイス操作検出手段が前記ユーザ操作を検出したことに応じて、当該操作された孫デバイス制御要素を指標する識別情報と、当該操作された孫デバイス制御要素に対する操作内容を示す制御データとを含む前記第２種パケットを生成して、前記第２種バスを介して前記第２種バスに接続された前記子デバイスに送信する孫デバイス第２種送信手段と、
を有することを特徴とする制御システム。
複数の前記孫デバイスが前記第２種バスを介して一の前記子デバイスに接続されており、
前記子デバイス第１種受信手段は、前記第２種バスに接続された前記複数の孫デバイスのうち何れかの孫デバイスに対応する前記孫デバイス制御要素を示す識別情報を含む前記第１種パケットを受信するものであり、
前記子デバイス第２種送信手段は、前記第２種バスに接続された前記複数の孫デバイスのうち何れか一の孫デバイスを指定する宛先情報を前記第２種パケットに付与し、当該第２種パケットを前記第２種バスに送出するものであり、
前記孫デバイス第２種受信手段は、前記第２種バスに送出された前記第２種パケットのうち、当該孫デバイスを指標する前記宛先情報が付与されたものを受信すること
を特徴とする請求項１記載の制御システム。
前記第１種パケットは、前記第１種バスに接続されている前記親デバイスまたは前記複数の子デバイスのうち何れか一のデバイスを示す送信元アドレスを含むこと
を特徴とする請求項１記載の制御システム。
前記複数の制御要素には、予めそれぞれポート番号が割り当てられており、
前記第１種パケットの前記識別情報は、前記ポート番号により前記複数の制御要素のうちの一の制御要素を特定するものであり、
前記子デバイス制御手段または前記子デバイス第２種送信手段は、前記ポート番号に基づいて、前記受信した第１種パケットの識別情報が、当該子デバイスの子デバイス制御要素のうちの何れかを指標するものであるか否かを判別すること
を特徴とする請求項１記載の制御システム。
前記複数の制御要素には、予めそれぞれポート番号が割り当てられており、
前記第１種パケットの前記識別情報は、前記ポート番号により前記複数の制御要素のうちの一の制御要素を特定するものであり、
前記子デバイス第２種送信手段は、前記受信した第１種パケットの識別情報の前記ポート番号に基づき、前記宛先情報を生成すること
を特徴とする請求項２記載の制御システム。