JP5147520B2 - 通信方法 - Google Patents

Description

本発明は、通信方法に関し、詳しくは記録媒体上に画像を形成する画像形成装置に関するものであり、特に、ハンドシェークプロトコルを有した機内通信を持つ画像形成装置に関するものである。

従来、通信のプロトコルは、受信不良を示すところのＮＡＣＫ（Ｎｅｇａｔｉｖｅ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ信号）（ネガティブアクナリッジ信号）（以下ＮＡＣＫ）を受信したら再送信手段を持つように設計されている（例えば、特許文献１参照）。

すなわち、特許文献１では、ホストから与えられた送信データをＰＩＯデータ保持部に保持する。パケット生成部は送信データをもとにこの送信データの記憶場所の情報を含む送信パケットを生成し、これを通信リンク制御部がネットワークへ送出する。このとき、送信データの記憶領域は解放しない。この送信パケットに対して送信データの記憶場所の情報を含むＮＡＣＫが受信された場合には、その記憶場所に送信データが未だ記憶されているので、これをもとに送信パケット生成して再送する。ＡＣＫ（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ信号）（アクナリッジ信号）パケット（以下ＡＣＫ）が受信された場合には、送信データの記憶領域を開放する。

このような構成とすることで、再送による信頼性のある通信を遅延時間の増加やハードウエア使用量の増加を抑制しつつ実現することを可能にしている。
特開２００４−２７４３７６号公報

しかしながら、上記従来例では、ＮＡＣＫに対し必ず再送信を実行するようになっているため、以下のような課題があった。

Ａ−ＣＰＵがＢ−ＣＰＵにＮＡＣＫを送信した場合に、通信エラーが発生すると、Ｂ−ＣＰＵからＡ−ＣＰＵにＮＡＣＫが返信され、Ａ−ＣＰＵの記憶場所に記憶されているＮＡＣＫが再送信される。Ｂ−ＣＰＵの記憶場所にもＮＡＣＫが記憶されているので、Ｂ−ＣＰＵからもＮＡＣＫが再送信される状況となっている。そして結果的には、ＮＡＣＫをお互いに送信しつづけることにより、正常に通信ができなくなってしまう（通信のハングアップとも言う）こととなる。

本発明は以上の点に着目して成されたもので、ネガティブアクナリッジ信号に対しネガティブアクナリッジ信号を再送する状況を避け、正常に通信ができなくなる状況を回避する通信方法を提供することを課題とする。

また、コマンド信号とアクナリッジ信号とステータス信号に識別コードを付加し、通信エラーの検知性能を向上させる通信方法を提供することを課題とする。

さらに、対応する動作が二重起動され、不必要な動作が引き起こされることを防止する通信方法を提供することを課題とする。

前記課題を解決するために、本発明は以下の構成を備える。

（１）第一の制御部と第二の制御部とを有し、前記第一の制御部または前記第二の制御部が、コマンド信号を発行し、前記コマンド信号に対する応答信号またはステータス信号を受信することにより、前記第一の制御部と前記第二の制御部との間で通信を行う通信装置の通信方法において、前記コマンド信号に対する、前記応答信号または前記ステータス信号が返信されるまでは新たなコマンド信号の発行を停止する工程と、前記第一の制御部または前記第二の制御部が、前記コマンド信号を発行していない状態で、前記応答信号または前記ステータス信号を受信した場合、または、通信エラーを検知した場合には、受信不良を示す信号を発行する工程と、前記第一の制御部または前記第二の制御部が、前記コマンド信号を発行してから前記応答信号または前記ステータス信号を受信するまでの間に、前記通信エラーを検知し、または、前記受信不良を示す信号を受信した場合には、前記コマンド信号を再発行する工程と、を有し、前記第一の制御部または前記第二の制御部が、前記コマンド信号を発行していない状態で、前記受信不良を示す信号を受信した場合には、前記受信不良を示す信号を無視する工程を備えることを特徴とする通信方法。

本発明によれば、ネガティブアクナリッジ信号の再送によって、正常に通信できない状況の発生が回避されるので、通信の品位が向上する。さらに、２個のＣＰＵから独立して双方向に通信が実行できる。また、通信ごとの識別コードを付加することにより通信エラーの発生をより詳しく検知することができる。さらに、通信ごとの識別コードを確認することにより、不必要な動作を誤って二重起動することがなくなるので、通信エラーを起因とするハードウエアトラブルを防止することができる。

以下本発明を実施するための最良の形態を、実施例により詳しく説明する。

本実施例の通信プロトコルは、以下の〔１〕〜〔１８〕に示す１８項目で定義されるものである。
〔１〕２個のＣＰＵを接続する通信である。
〔２〕２個のＣＰＵをＡ−ＣＰＵ（後述するＣＰＵ１１），Ｂ−ＣＰＵ（後述するＣＰＵ１６）とする。
〔３〕相手側に命令をするところのＣｏｍｍａｎｄ（以下Ｃｏｍｍａｎｄ）を受信したＡ−ＣＰＵは、そのＣｏｍｍａｎｄに対応した受信完了通知であるところのＡＣＫ（以下ＡＣＫ）または、状況を返信するところのＳｔａｔｕｓ（以下Ｓｔａｔｕｓ）を返信する。
〔４〕Ｃｏｍｍａｎｄを受信したＢ−ＣＰＵは、そのＣｏｍｍａｎｄに対応したＡＣＫまたは、Ｓｔａｔｕｓを返信する。
〔５〕Ａ−ＣＰＵからＢ−ＣＰＵに対しＣｏｍｍａｎｄを発行した場合には、Ｂ−ＣＰＵよりそのＣｏｍｍａｎｄに対応した正常なＡＣＫまたは正常なＳｔａｔｕｓが返信されるまでは、Ａ−ＣＰＵはＢ−ＣＰＵに対し新たなＣｏｍｍａｎｄは発行しない。
〔６〕Ｂ−ＣＰＵからＡ−ＣＰＵに対しＣｏｍｍａｎｄを発行した場合には、Ａ−ＣＰＵよりそのＣｏｍｍａｎｄに対応した正常なＡＣＫまたは正常なＳｔａｔｕｓが返信されるまでは、Ｂ−ＣＰＵはＡ−ＣＰＵに対し新たなＣｏｍｍａｎｄは発行しない。
〔７〕Ａ−ＣＰＵがＣｏｍｍａｎｄを発行していない状態で、通信エラーを検知したらＡ−ＣＰＵは受信不良を示すところのＮＡＣＫ（以下ＮＡＣＫ）を発行する。
〔８〕Ｂ−ＣＰＵがＣｏｍｍａｎｄを発行していない状態で、通信エラーを検知したらＢ−ＣＰＵはＮＡＣＫを発行する。
〔９〕Ａ−ＣＰＵがＣｏｍｍａｎｄを発行し、ＡＣＫまたは、Ｓｔａｔｕｓを受信するまでの間に、通信エラーを検知したら最後に発行したＣｏｍｍａｎｄを再発行する。
〔１０〕Ｂ−ＣＰＵがＣｏｍｍａｎｄを発行し、ＡＣＫまたは、Ｓｔａｔｕｓを受信するまでの間に、通信エラーを検知したら最後に発行したＣｏｍｍａｎｄを再発行する。
〔１１〕Ａ−ＣＰＵがＣｏｍｍａｎｄを発行していない状態で、ＮＡＣＫを受信したらＮＡＣＫを無視しなにもしない。
〔１２〕Ｂ−ＣＰＵがＣｏｍｍａｎｄを発行していない状態で、ＮＡＣＫを受信したらＮＡＣＫを無視しなにもしない。
〔１３〕Ａ−ＣＰＵがＣｏｍｍａｎｄを発行し、ＡＣＫまたは、Ｓｔａｔｕｓを受信するまでの間に、ＮＡＣＫを受信したら最後に発行したＣｏｍｍａｎｄを再発行する。
〔１４〕Ｂ−ＣＰＵがＣｏｍｍａｎｄを発行し、ＡＣＫまたは、Ｓｔａｔｕｓを受信するまでの間に、ＮＡＣＫを受信したら最後に発行したＣｏｍｍａｎｄを再発行する。
〔１５〕Ａ−ＣＰＵがＣｏｍｍａｎｄを発行していない状態にもかかわらずＡＣＫまたはＳｔａｔｕｓを受信した場合には、ＮＡＣＫを発行する。
〔１６〕Ｂ−ＣＰＵがＣｏｍｍａｎｄを発行していない状態にもかかわらずＡＣＫまたはＳｔａｔｕｓを受信した場合には、ＮＡＣＫを発行する。
〔１７〕Ａ−ＣＰＵがＣｏｍｍａｎｄを発行したにもかかわらず一定時間経過してもＡＣＫまたは、Ｓｔａｔｕｓが返信されなかった場合には、最後に発行したＣｏｍｍａｎｄを再発行する。
〔１８〕Ｂ−ＣＰＵがＣｏｍｍａｎｄを発行したにもかかわらず一定時間経過してもＡＣＫまたは、Ｓｔａｔｕｓが返信されなかった場合には、最後に発行したＣｏｍｍａｎｄを再発行する。

以下、図１〜図１２を用いて、本実施例を詳しく説明する。

［画像形成装置の構成］
図１は本発明の特徴を最もよく表す図面であり、同図において１は画像形成を行う画像形成装置本体である。２は画像を形成するための用紙を保持するカセットである。３は画像形成済みの用紙を排出する排紙トレイである。４は用紙を一枚ずつ取り出すため（以下ピックアップと称す）のピックアップローラである。５は画像を形成する現像転写部である。６は用紙上に転写された画像を定着させる定着器である。７は、定着済みの用紙を搬送する搬送ローラであり、８はピックアップした用紙を現像転写部へ搬送する搬送ローラである。１０は外部機器であるＰＣ（パーソナルコンピュータ）等と接続しかつ画像情報を生成するビデオコントローラ部（Ｖｉｄｅｏ−Ｃｏｎｔｒｏｌｌｅｒ部）である。１１はビデオコントローラ部１０のＣＰＵである。１２は画像情報を生成するビデオ生成部（Ｖｉｄｅｏ生成部）であり、ビデオ信号（Ｖｉｄｅｏ信号）により電子写真を用い画像を形成する。１３は外部のＰＣと接続するための通信制御部であり、例えばＰＣとＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）にて接続する場合には、１３はＵＳＢコントローラを示す。１４は画像形成装置本体内のもう一つのＣＰＵと通信で接続するための通信制御部である。

１５は画像形成装置の搬送、現像、転写、定着等の機械部分の制御を担当するエンジン基板である。１６はエンジン基板１５の制御を司るエンジンＣＰＵである。１７は、電子写真制御部、１８は定着制御部、１９は搬送制御部、２０はビデオコントローラ部１０のＣＰＵ１１と通信で接続するための通信制御部である。２１はＰＣと接続するプリンタケーブルであり、例えばＵＳＢケーブルが使用される。２２は、ＰＣ等であり、画像形成装置にプリントの命令を出す。ＰＣ２２から印字命令を受信したビデオコントローラ部１０は、エンジン基板１５に印刷命令を出す。それと同時にビデオ生成部１２にて画像情報を生成する。用紙は、カセット２からピックアップローラ４によりピックアップされ、搬送ローラ８により現像転写部５に送り込まれる。用紙上に画像が形成され、定着器６に送られる。そして定着が終了した用紙は、排紙トレイ３に排出される。

［ビデオコントローラ部１０のＣＰＵ１１とエンジン基板１５のＣＰＵ１６の接続］
図２は、エンジン基板１５のＣＰＵ１６とビデオコントローラ部１０のＣＰＵ１１の接続図である。

ビデオコントローラ部１０のＣＰＵ１１は、ＵＳＢコントローラ１３と接続され、プリンタケーブル２１を介してＰＣ２２とのＵＳＢ接続を可能とする。ビデオコントローラ部１０のＣＰＵ１１は、ビデオ生成部１２に接続され、ビデオ生成に必要な情報をビデオ生成部１２に供給する。ビデオ信号は、差動ドライバ３１により差動信号に変換され出力される。差動信号となったビデオ信号は、現像転写部５に伝えられ画像を形成する。ビデオコントローラ部１０とエンジン基板１５は、ＧＮＤを接続する。ビデオコントローラ部１０のＣＰＵ１１とエンジン基板１５のＣＰＵ１６との通信は、それぞれのＣＰＵに内蔵するシリアル通信機能を使用する。ＣＰＵ１１のシリアル通信機能の送信ポートであるところのＴＸポート（以下ＴＸポート）から通信データが送出される。そしてＣＰＵ１６のシリアル通信機能の受信ポートであるところのＲＸポート（以下ＲＸポート）より受信される。ＣＰＵ１６のシリアル通信機能のＴＸポートから通信データが送出される。そしてＣＰＵ１１のシリアル通信機能のＲＸポートより受信される。３２，３３，３４，３５は、シリアル通信用のバッファＩＣである。エンジン基板１５のＣＰＵ１６は、ビデオコントローラ部１０のＣＰＵ１１とシリアル通信バッファ３４，３５で接続されている。

エンジン基板１５のＣＰＵ１６は、電子写真制御部１７と接続され電子写真の現像転写を制御する。エンジン基板１５のＣＰＵ１６は定着制御部１８と接続され定着器６の温度を制御することにより用紙への画像の定着を制御する。エンジン基板１５のＣＰＵ１６は搬送制御部１９と接続され、ピックアップローラ４と搬送ローラ７，８を制御し、用紙の搬送を制御する。ビデオ生成部１２で生成されたビデオ信号は、電子写真制御部１７を通過し、レーザ基板３８へ伝えられる。そしてレーザ基板３８上にある差動レシーバ３６により受信され、レーザ３７を駆動する。

ピックアップローラ４、搬送ローラ７，８を駆動する搬送モータは、搬送制御部１９に接続されている。定着器６は、定着制御部１８に接続されている。現像転写部５は、電子写真制御部１７に接続されている。

［ＣＰＵ１１に適用される通信タスクについて］
次にＣＰＵ１１に適用されるＦ／Ｗ（ファームウエア）である通信タスクを説明する。

まず、状態定義とＦ／Ｗの制御ブロックであるところのタスク（以下ＴＡＳＫ）とハードウエアとのデータの受け渡しをするところのドライバ（以下ドライバ）とデータの一時記憶場所であるバッファ（以下Ｂｕｆｆｅｒ）の説明をする。

＜定義＞
同期状態と通常状態について、以下のように定義する。
同期状態：ＣＰＵ１１からステータス要求であるところのステータスリクエスト（以下
ステータスＲｅｑｕｅｓｔ）を送信し、そのステータスＲｅｑｕｓｅｔに対応
する正しいステータスをＣＰＵ１１が受信するまでの間またはＣＰＵ１１から
実動作を要求するところの実行コマンド（以下実行コマンド）を送信し、その
実行コマンドに対応する正しいステータスをＣＰＵ１１が受信するまでの間。
通常状態：ＣＰＵ１１が上記同期状態にない場合。

＜ＴＡＳＫとドライバ＞
ＴＡＳＫ２個とドライバ２個から通信ソフトが構成されている。
各々の名前を、“コマンド・ステータス制御ＴＡＳＫ”（１０１）、“第１受信ＴＡＳＫ”（１０２）、“送信ドライバ”（１０３）、“受信ドライバ”（１０４）とする。これら、１０１〜１０４の機能は以下のとおりである。

（１０１）“コマンド・ステータス制御ＴＡＳＫ”
以下にこのＴＡＳＫの機能を列挙する。
＊送信すべきステータスＲｅｑｕｅｓｔまたは実行コマンド（コマンド信号）を制御
し、なおかつ、どのコマンドを送信したかを記憶する。
＊返信されたステータスを所定のメモリに格納する。
＊再送すべきステータスＲｅｑｕｅｓｔまたは実行コマンドを制御する。
＊ＮＡＣＫ（ネガティブアクナリッジ信号）を返信する。
＊受信したＮＡＣＫを無視する。

（１０２）“第１受信ＴＡＳＫ”
以下にこのＴＡＳＫの機能を列挙する。
＊ＲｘＤａｔａ（後述）の内容がＣＰＵ１６からのステータスを表示するための
ＳＴＣｏｍｍａｎｄ（以下ＳＴＣｏｍｍａｎｄ）であると判断したらＡＣＫ（アク
ナリッジ信号）を返信する。
＊ＲｘＤａｔａ（後述）の内容がＣＰＵ１６からのＳＴＣｏｍｍａｎｄでない場合に
は、そのデータをＴｘＲｘＢｕｆｆｅｒ（後述）を通じてコマンド・ステータス制
御ＴＡＳＫ１０１にデータ内容を渡す。

（１０３）“送信ドライバ”
以下にこのＴＡＳＫの機能を列挙する。
＊コマンド・ステータス制御ＴＡＳＫ１０１から依頼のあった送信を実行する。
＊第１受信ＴＡＳＫ１０２から依頼のあったＡＣＫを送信する。

（１０４）“受信ドライバ”
以下にこのＴＡＳＫの機能を列挙する。
＊受信したデータをＲｘＤａｔａを通じて第１受信ＴＡＳＫ１０２に渡す。

＜Ｂｕｆｆｅｒ＞
各ＴＡＳＫ間での情報の受け渡しに使用するＢｕｆｆｅｒを説明する。

各々の名前を、ＲｘＤａｔａ、ＴｘＲｘＢｕｆｆｅｒ、ＴｘＱｕｅｕｅ、ＳＲ＿ＣｏｍｍａｎｄＱｕｅｕｅ、ＮｏｒｍａｌＳｔａｔｕｓ、ＳＴＣｏｍｍａｎｄＳａｖｅＡｒｅａとする。
２０１ＲｘＤａｔａ：受信ドライバ１０４が受信したデータをＲｘＤａｔａに格納し、第１受信ＴＡＳＫ１０２に受け渡すために使用するメモリ領域である。
２０２ＴｘＲｘＢｕｆｆｅｒ：第１受信ＴＡＳＫ１０２からコマンド・ステータス制御ＴＡＳＫ１０１に受信データを受け渡すために使用するメモリ領域である。
２０３ＴｘＱｕｅｕｅ：コマンド・ステータス制御ＴＡＳＫ１０１または、第１受信ＴＡＳＫ１０２から送信データを送信ドライバ１０３に通知するために使用するメモリ領域である。
２０４ＳＲ＿ＣｏｍｍａｎｄＱｕｅｕｅ：通信ＴＡＳＫ以外の部分（１５１）からのステータスＲｅｑｕｅｓｔ、実行コマンドの送信要求を格納するメモリ領域である。
２０５ＮｏｒｍａｌＳｔａｔｕｓ：通常のステータスの格納エリアである。通信ＴＡＳＫ以外の部分１５１から参照可能となっている。
２０６ＳＴＣｏｍｍａｎｄＳａｖｅＡｒｅａ：ＣＰＵ１６から到着したＳＴＣｏｍｍａｎｄを格納するメモリ領域である。通信ＴＡＳＫ以外の部分から参照可能となっている。

＜ＣＰＵ１１の通信ＴＡＳＫ構造の説明＞
図３に従って、ＣＰＵ１１の通信ＴＡＳＫ構造を説明する。

ＣＰＵ１１のＲＸポートからのデータを処理する部分が受信ドライバ１０４である。受信ドライバ１０４で受信されたデータはＲｘＤａｔａ２０１に格納される。次に、ＲｘＤａｔａ２０１のデータを解析するのが、第１受信ＴＡＳＫ１０２である。この第１受信ＴＡＳＫ１０２は、ＲｘＤａｔａ２０１に格納されたデータがＣＰＵ１６から送信されたＳＴＣｏｍｍａｎｄであるかどうかをチェックする（１１０）。ＳＴＣｏｍｍａｎｄであった場合はＳＴＣｏｍｍａｎｄＳａｖｅＡｒｅａ２０６に格納する（１０９）。通信ＴＡＳＫ以外の部分１５１がＳＴＣｏｍｍａｎｄＳａｖｅＡｒｅａ２０６の内容を参照する。そして、ＡＣＫをＣＰＵ１６に返信する。具体的には、送信バッファであるＴｘＱｕｅｕｅ２０３にＡＣＫをセットし、送信ドライバ１０３からＴｘＱｕｅｕｅ２０３に格納された送信データを送信する。

ＲｘＤａｔａ２０１がＳＴＣｏｍｍａｎｄでなかった場合には、そのデータのエラー発生状況を含めて、ＴｘＲｘＢｕｆｆｅｒ２０２に格納する。次のコマンド・ステータス制御ＴＡＳＫ１０１では、ＴｘＲｘＢｕｆｆｅｒ２０２に格納されたデータを解析する。そして、ＮＡＣＫを返信するか（１０８）、ステータスＲｅｑｕｅｓｔまたは、実行コマンドの再送信をするか（１０７）、正常であると判断し、ＮｏｒｍａｌＳｔａｔｕｓ２０５にステータスを格納するか（１０６）を選択する。また、通信ＴＡＳＫ以外の部分１５１がＮｏｒｍａｌＳｔａｔｕｓ２０５の内容を参照する。また、ＳＲ＿ＣｏｍｍａｎｄＱｕｅｕｅ２０４に通信ＴＡＳＫ以外の部分１５１から書き込まれたデータがある場合には（１０５）、送信バッファであるＴｘＱｕｅｕｅ２０３に送信データをセットする。最後に送信ドライバ１０３では、ＴｘＱｕｅｕｅ２０３に格納された送信データを順次送信する。送信ドライバ１０３は、ＣＰＵ１１のＴＸポートへのデータを処理する部分である。

〜受信ドライバ１０４〜
図４にて、受信ドライバ１０４のフローチャートを説明する。

受信ドライバ１０４では、常に、ハードウエアからの受信割り込みであるところの受信Ｉｎｔｅｒｒｕｐｔ（受信Ｉｎｔｅｒｒｕｐｔ）が発生したかどうかを監視している（ステップ３５４、以下ステップをＳとする）。 もしも受信Ｉｎｔｅｒｒｕｐｔが発生したら（Ｉｎｔｅｒｒｕｐｔ受信）、受信データをＲｘＤａｔａ２０１に格納する（Ｓ３５５）。

〜第１受信ＴＡＳＫ１０２〜
図５にて第１受信ＴＡＳＫ１０２のフローチャートを説明する。

まず、ＲｘＤａｔａ２０１にデータがあるかどうか、すなわちＲｘＤａｔａ２０１が空か否かを監視する（Ｓ３２１）。もしも、空ではない、すなわちデータが格納されたＲｘＤａｔａ２０１が到着したらデータの解析を開始する。

まず、ＲｘＤａｔａ２０１を確認し、通信エラーが発生していないかどうかを確認する（Ｓ３２２）。もしも、エラーが発生している場合には、ＴｘＲｘＢｕｆｆｅｒ２０２にＲｘＤａｔａ２０１のデータを格納する。そしてその場合には、エラーが発生している情報も含める（Ｓ３２９）。

通信エラーが発生していない場合には、ＲｘＤａｔａ２０１がＣＰＵ１６から通知されたＳＴＣｏｍｍａｎｄであるかどうかを確認する（Ｓ３２３）。もしもＳＴＣｏｍｍａｎｄであった場合には、ＳＴＣｏｍｍａｎｄＳａｖｅＡｒｅａ２０６に到着したＳＴＣｏｍｍａｎｄを格納する（Ｓ３２４）。そして、ＣＰＵ１６にＳＴＣｏｍｍａｎｄを正常に受信したことを通知するために、ＡＣＫを返信する。そのために、ＴｘＱｕｅｕｅ２０３にＡＣＫをセットする（Ｓ３２５）。

ＲｘＤａｔａ２０１がＳＴＣｏｍｍａｎｄでない場合には、ＮＡＣＫであるかどうかを確認する（Ｓ３２６）。もしもＮＡＣＫであった場合には、ＴｘＲｘＢｕｆｆｅｒ２０２にＮＡＣＫを格納し、コマンド・ステータス制御ＴＡＳＫ１０１に渡す（Ｓ３２８）。もしもＲｘＤａｔａ２０１がＮＡＣＫでない場合には、格納されたＲｘＤａｔａ２０１は、通信エラーでもＮＡＣＫでもないことが確定するので、ＴｘＲｘＢｕｆｆｅｒ２０２にエラー発生なしの情報も含めてＲｘＤａｔａ２０１の内容を格納する（Ｓ３２７）。

なお、このフローチャートの中のＳ３２３，Ｓ３２４，Ｓ３２５の処理が前述の〔３〕に該当する処理である。

〜コマンド・ステータス制御ＴＡＳＫ１０１〜
図６にてコマンド・ステータス制御ＴＡＳＫ１０１のフローチャートを説明する。

ＳＲ＿ＣｏｍｍａｎｄＱｕｅｕｅ２０４の中に、ステータスＲｅｑｕｅｓｔまたは実行コマンドの送信要求があるかどうかを確認する（Ｓ３０１）。

もしもＳＲ＿ＣｏｍｍａｎｄＱｕｅｕｅ２０４が空の場合には、ＴｘＲｘＢｕｆｆｅｒ２０２の確認を行う（Ｓ３０９）。もしもＴｘＲｘＢｕｆｆｅｒ２０２にも到着データがない場合には、ＳＲ＿ＣｏｍｍａｎｄＱｕｅｕｅ２０４の確認に戻る（Ｓ３０９）。もしも、ＴｘＲｘＢｕｆｆｅｒ２０２に受信データが格納されていた場合には、まず、通信エラーが発生していないかを確認する（Ｓ３１０）。もしも通信エラーが発生していた場合には、ＴｘＱｕｅｕｅ２０３にＮＡＣＫをセットする（Ｓ３１２）。通信エラーが発生していない場合には、ＴｘＲｘＢｕｆｆｅｒ２０２がＮＡＣＫかどうかを確認する（Ｓ３１１）。そして、データがＮＡＣＫの場合には、そのＮＡＣＫを無視し、ＳＲ＿ＣｏｍｍａｎｄＱｕｅｕｅ２０４の確認に戻る（Ｓ３１１）。

もしも、ＴｘＲｘＢｕｆｆｅｒ２０２のデータがＮＡＣＫでない場合には、ＣＰＵ１６にＮＡＣＫを返信しなければいけないので、ＴｘＱｕｅｕｅにＮＡＣＫをセットする（Ｓ３１２）。

なお、Ｓ３０９，Ｓ３１０，Ｓ３１１，Ｓ３１２の処理を実行している状態が通常状態である。

そして、Ｓ３１０，Ｓ３１２の処理が前述の〔７〕に該当する処理である。また、Ｓ３１１，Ｓ３１２の処理が前述の〔１５〕に該当する処理である。また、Ｓ３１１からＳ３０１へ戻る処理が前述の〔１１〕に該当する処理である。

次に同期状態の説明をする。

ＳＲ＿ＣｏｍｍａｎｄＱｕｅｕｅ２０４の中に、ステータスＲｅｑｕｅｓｔまたは実行コマンドの送信要求がある場合には（Ｓ３０１ Ｎｏ）、ＴｘＱｕｅｕｅ２０３にステータスＲｅｑｕｅｓｔまたは実行コマンドをセットする（Ｓ３０２）。このとき、再送信が発生した場合に備えて発行したステータスＲｅｑｕｅｓｔまたは実行コマンドを記憶する（Ｓ３０２）。

ＣＰＵ１６から返信であるＴｘＲｘＢｕｆｆｅｒ２０２の到着を確認する（Ｓ３０３）。そして、このデータの確認はタイムオーバーであるところのＴｉｍｅ−Ｏｖｅｒ（以下Ｔｉｍｅ−Ｏｖｅｒ）も同時に監視する（Ｓ３０３）。

もしも、Ｔｉｍｅ−Ｏｖｅｒが発生したら（Ｓ３０３ Ｙｅｓ，Ｓ３０４ Ｙｅｓ）、再送の準備をする。すなわち、ＴｘＱｕｅｕｅ２０３に再送データを格納できるような準備をする（Ｓ３０７）。再送は、Ｓ３０２にて記憶したデータを使用する（Ｓ３０７）。

Ｓ３０４でＴｉｍｅ−Ｏｖｅｒが発生しなかった場合には、次に通信エラーが発生しているかどうか確認する（Ｓ３０５）。

通信エラーが発生している場合には（Ｓ３０５ Ｙｅｓ）、再送の準備をする。すなわち、ＴｘＱｕｅｕｅ２０３に再送データを格納できるような準備をする（Ｓ３０７）。再送は、Ｓ３０２にて記憶したデータを使用する（Ｓ３０７）。

次に、ＴｘＲｘＢｕｆｆｅｒ２０２を確認し、ＮＡＣＫであるかどうかを確認する（Ｓ３０６）。ＮＡＣＫであった場合には、再送の準備をする。すなわち、ＴｘＱｕｅｕｅ２０３に再送データを格納できるような準備をする（Ｓ３０７）。再送は、Ｓ３０２にて記憶したデータを使用する（Ｓ３０７）。

そして、ＮＡＣＫでない場合は（Ｓ３０６ Ｎｏ）、ＴｘＲｘＢｕｆｆｅｒ２０２に通常のステータスが格納されているので、それをＮｏｒｍａｌＳｔａｔｕｓ２０５に格納する（Ｓ３０８）。

Ｓ３０８を通過しない限り、次のＳＲ＿ＣｏｍｍａｎｄＱｕｅｕｅ２０４のチェックを実施しない。すなわち、正常なＡＣＫまたはＳｔａｔｕｓが受信されない限り次の新しいステータスＲｅｑｕｅｓｔまたは実行コマンドが発行できないようになっている。すなわち、正常なＡＣＫまたは正常なＳｔａｔｕｓが返信されるまでは実行コマンドの発行を停止する。

なお、Ｓ３０８が前述の〔５〕に該当する処理である。また、Ｓ３０４，Ｓ３０７の処理が前述の〔１７〕に該当する処理である。Ｓ３０４，Ｓ３０５，Ｓ３０７の処理が前述の〔９〕に該当する処理である。Ｓ３０４，Ｓ３０５，Ｓ３０６，Ｓ３０７の処理が前述の〔１３〕に該当する処理である。Ｓ３０４，Ｓ３０５，Ｓ３０６，Ｓ３０８，Ｓ３０１の処理が前述の〔５〕に該当する処理である。

〜送信ドライバ１０３〜
図７にて送信ドライバ１０３のフローチャートを説明する。

ＴｘＱｕｅｕｅ２０３にデータが格納されているかどうか、すなわち、空か否かを確認する（Ｓ３５１）。

もしも、ＴｘＱｕｅｕｅ２０３にデータがある場合には、送信データをハードウエアに書き込み、実際の送信動作を実行する（Ｓ３５２）。

そして、送信動作が完了するのを待つ（Ｓ３５３）。送信動作が完了したらＴｘＱｕｅｕｅ２０３の確認動作に戻る（Ｓ３５３）。

［ＣＰＵ１６に適用される通信タスクについて］
次にＣＰＵ１６に適用されるＦ／Ｗである通信タスクを説明する。

まず、定義とＴＡＳＫとドライバとＢｕｆｆｅｒの説明をする。

＜定義＞
同期状態と通常状態について、以下のように定義する。
同期状態：ＣＰＵ１６からＳＴＣｏｍｍａｎｄを送信し、そのコマンドに対応する正し
いＡＣＫが返信されるまでの間。
通常状態：ＣＰＵ１６が上記同期状態にない場合。

＜ＴＡＳＫとドライバ＞
ＴＡＳＫ２個とドライバ２個から通信ソフトが構成されている。

（４０１）コマンド・ステータス制御ＴＡＳＫ
以下にこのＴＡＳＫの機能を列挙する。
＊送信すべきＳＴＣｏｍｍａｎｄを制御し、なおかつ、どのＳＴＣｏｍｍａｎｄを送
信したかを記憶する。
＊返信されたＡＣＫを確認する。
＊再送すべきＳＴＣｏｍｍａｎｄを制御する。
＊ＮＡＣＫ を返信する。
＊受信したＮＡＣＫを無視する。

（４０２）第１受信ＴＡＳＫ
以下にこのＴＡＳＫの機能を列挙する。
＊ＲｘＤａｔａの内容がＣＰＵ１６からのステータスＲｅｑｕｅｓｔであると判断し
たら対応するステータスを返信する。
＊Ｒｘｄａｔａの内容がＣＰＵ１６からの実行コマンドであると判断したら実行コマ
ンド受信情報５０５に格納し、さらに対応するステータスを返信する。
＊ＲｘＤａｔａの内容がＣＰＵ１６からのステータスＲｅｑｕｅｓｔまたは実行コマ
ンドでない場合には、そのデータをＴｘＲｘＢｕｆｆｅｒ５０２を通じてコマンド
・ステータス制御ＴＡＳＫ４０１に渡す。

（４０３）送信ドライバ
以下にこのＴＡＳＫの機能を列挙する。
＊コマンド・ステータス制御ＴＡＳＫ４０１から依頼のあった送信を実行する。
＊第１受信ＴＡＳＫ４０２から依頼のあったステータスを送信する。

（４０４）受信ドライバ
以下にこのＴＡＳＫの機能を列挙する。
＊受信したデータをＲｘＤａｔａ５０１を通じて第１受信ＴＡＳＫ４０２に渡す。

＜Ｂｕｆｆｅｒ＞
各ＴＡＳＫ間での情報の受け渡しに使用するＢｕｆｆｅｒを説明する。
ＲｘＤａｔａ５０１：受信ドライバ４０４が受信したデータをＲｘＤａｔａ５０１に格納し、第１受信ＴＡＳＫ４０２に受け渡すために使用するメモリ領域である。
ＴｘＲｘＢｕｆｆｅｒ５０２：第１受信ＴＡＳＫ４０２からコマンド・ステータス制御ＴＡＳＫ４０１に受信データを受け渡すために使用するメモリ領域である。
ＴｘＱｕｅｕｅ５０３：コマンド・ステータス制御ＴＡＳＫ４０１または、第１受信ＴＡＳＫ４０２から送信データを送信ドライバに通知するために使用するメモリ領域である。
ＳＴＣｏｍｍａｎｄＱｕｅｕｅ５０４：通信ＴＡＳＫ以外の部分４５１からのＳＴＣｏｍｍａｎｄの送信要求データを格納するために使用するメモリ領域である。
実行コマンド受信情報５０５：実行コマンドの受信データ格納エリアである。通信ＴＡＳＫ以外の部分４５１から参照可能となっている。

＜ＣＰＵ１６の通信ＴＡＳＫ構造の説明＞
図８に従って、ＣＰＵ１６の通信ＴＡＳＫ構造を説明する。

ＣＰＵ１６のＲＸポートからのデータを処理する部分が受信ドライバ４０４である。受信ドライバ４０４で受信されたデータはＲｘＤａｔａ５０１に格納される。次に、ＲｘＤａｔａ５０１のデータを解析するのが、第１受信ＴＡＳＫ４０２である。この第１受信ＴＡＳＫ４０２は、ＲｘＤａｔａ５０１に格納されたデータがＣＰＵ１１から送信された実行コマンドまたはステータスＲｅｑｕｅｓｔであるかどうかをチェックする（４１０）。実行コマンドであった場合は、実行コマンド受信情報５０５のＢｕｆｆｅｒに情報を格納する。そしてその実行コマンドに対応するステータスを返信する。ステータスＲｅｑｕｅｓｔであった場合は対応するステータスを返信する。

通信ＴＡＳＫ以外の部分４５１が実行コマンド受信情報５０５を参照する。ＲｘＤａｔａ５０１が実行コマンドまたはステータスＲｅｑｕｅｓｔでなかった場合には、そのデータのエラー発生状況を含めて、ＴｘＲｘＢｕｆｆｅｒ５０２に格納する。次のコマンド・ステータス制御ＴＡＳＫ４０１では、ＴｘＲｘＢｕｆｆｅｒ５０２に格納されたデータを解析する。そして、ＮＡＣＫを返信するか（４０８）、ＳＴＣｏｍｍａｎｄの再送信をするか（４０７）、正常にＡＣＫを受信したと判断し（４０６）、次のＳＴＣｏｍｍａｎｄの送信を許可するかを選択する。また、ＳＴＣｏｍｍａｎｄＱｕｅｕｅ５０４に通信ＴＡＳＫ以外の部分４５１から書き込まれたデータがある場合には、送信バッファであるＴｘＱｕｅｕｅ５０３に送信データをセットする。最後に送信ドライバ４０３では、ＴｘＱｕｅｕｅ５０３に格納された送信データを順次送信する。

〜受信ドライバ４０４〜
図９にて、受信ドライバ４０４のフローチャートを説明する。

受信ドライバ４０４では、常に、ハードウエアからの受信Ｉｎｔｅｒｒｕｐｔが発生したかどうかを監視している（Ｓ６５４）。

もしも受信Ｉｎｔｅｒｒｕｐｔが発生したら、受信データをＲｘＤａｔａ５０１に格納する（Ｓ６５５）。

〜第１受信ＴＡＳＫ４０２〜
図１０にて第１受信ＴＡＳＫ４０２のフローチャートを説明する。

まず、ＲｘＤａｔａ５０１にデータがあるかどうか、すなわち空か否かを監視する（Ｓ６２１）。もしも、空ではないＲｘＤａｔａ５０１が到着したらデータの解析を開始する。

まず、ＲｘＤａｔａ５０１を確認し、通信エラーが発生していないかどうかを確認する（Ｓ６２２）。もしも、エラーが発生している場合には、ＴｘＲｘＢｕｆｆｅｒ５０２にＲｘＤａｔａ５０１のデータを格納する。そしてその場合には、エラーが発生している情報も含める（Ｓ６２９）。

通信エラーが発生していない場合には、ＲｘＤａｔａ５０１がＣＰＵ１１から通知された実行コマンドまたはステータスＲｅｑｕｅｓｔであるかどうかを確認する（Ｓ６２３）。もしも実行コマンドまたはステータスＲｅｑｕｅｓｔであった場合には、さらに、実行コマンドであるかステータスＲｅｑｕｅｓｔであるかを判断する（Ｓ６８１）。実行コマンドが到着した場合には、実行コマンド受信情報５０５にデータを格納する（Ｓ６８２）。そして、その実行コマンドに対応するステータスを通信ＴＡＳＫ以外の部分４５１から取得する（Ｓ６８４）。そしてそのステータスをＴｘＱｕｅｕｅ５０３にセットする（Ｓ６８５）。

ステータスＲｅｑｕｅｓｔが到着した場合には、そのステータスＲｅｑｕｅｓｔに対応するステータスを通信ＴＡＳＫ以外の部分４５１から取得する（Ｓ６２４）。そしてそのステータスをＴｘＱｕｅｕｅ５０３にセットする（Ｓ６２５）。

ＲｘＤａｔａ５０１が実行コマンドまたはステータスＲｅｑｕｅｓｔでない場合には（Ｓ６２３ Ｎｏ）、ＮＡＣＫであるかどうかを確認する（Ｓ６２６）。もしもＮＡＣＫであった場合には、ＴｘＲｘＢｕｆｆｅｒ５０２ にＮＡＣＫを格納し、コマンド・ステータス制御ＴＡＳＫ４０１に渡す（Ｓ６２８）。もしもＲｘＤａｔａ５０１がＮＡＣＫでない場合には、格納されたＲｘＤａｔａ５０１は、通信エラーでもＮＡＣＫでもないことが確定するので、ＴｘＲｘＢｕｆｆｅｒ５０２にエラー発生なしの情報も含めてＲｘＤａｔａ５０１の内容を格納する（Ｓ６２７）。

このフローチャートの中のＳ６２３，Ｓ６８１，Ｓ６２４，Ｓ６２５の処理、およびＳ６２３，Ｓ６８１，Ｓ６８２，Ｓ６８４，Ｓ６８５の処理が前述の〔４〕に該当する処理である。

〜コマンド・ステータス制御ＴＡＳＫ４０１〜
図１１にてコマンド・ステータス制御ＴＡＳＫ４０１のフローチャートを説明する。

ＳＴＣｏｍｍａｎｄＱｕｅｕｅ５０４の中に、ＳＴＣｏｍｍａｎｄの送信要求があるかどうかを確認する（Ｓ６０１）。

もしもＳＴＣｏｍｍａｎｄＱｕｅｕｅ５０４が空の場合には、ＴｘＲｘＢｕｆｆｅｒ５０２の確認を行う（Ｓ６０９）。もしもＴｘＲｘＢｕｆｆｅｒ５０２にも到着データがない場合には、ＳＴＣｏｍｍａｎｄＱｕｅｕｅ５０４の確認に戻る（Ｓ６０９）。もしも、ＴｘＲｘＢｕｆｆｅｒ５０２に受信データが格納されていた場合には、まず、通信エラーが発生していないかを確認する（Ｓ６１０）。もしも通信エラーが発生していた場合にはＴｘＱｕｅｕｅ５０３にＮＡＣＫをセットする（Ｓ６１２）。通信エラーが発生していない場合には、ＴｘＲｘＢｕｆｆｅｒ５０２がＮＡＣＫかどうかを確認する（Ｓ６１１）。そして、データがＮＡＣＫの場合には、そのＮＡＣＫを無視し、ＳＴＣｏｍｍａｎｄＱｕｅｕｅ５０４の確認に戻る（Ｓ６１１）。

もしも、ＴｘＲｘＢｕｆｆｅｒ５０２のデータがＮＡＣＫでない場合には、ＣＰＵ１１にＮＡＣＫを返信しなければいけないので、ＴｘＱｕｅｕｅ５０３にＮＡＣＫをセットする（Ｓ６１２）。

なお、Ｓ６０９，Ｓ６１０，Ｓ６１１，Ｓ６１２の処理を実行している状態が通常状態である。

そして、Ｓ６１０，Ｓ６１２の処理が前述の〔８〕に該当する処理である。また、Ｓ６１１，Ｓ６１２の処理が前述の〔１６〕に該当する処理である。Ｓ６１１からＳ６０１へ戻る処理が前述の〔１２〕に該当する処理である。

次に同期状態の説明をする。

ＳＴＣｏｍｍａｎｄＱｕｅｕｅ５０４の中に、ＳＴＣｏｍｍａｎｄの送信要求がある場合には（Ｓ６０１ Ｎｏ）、ＴｘＱｕｅｕｅ５０３にＳＴＣｏｍｍａｎｄをセットする（Ｓ６０２）。このとき、再送信が発生した場合に備えて発行したＳＴＣｏｍｍａｎｄを記憶する（Ｓ６０２）。

ＣＰＵ１１からの返信であるＴｘＲｘＢｕｆｆｅｒ５０２を確認する（Ｓ６０３）。そして、このデータの確認はＴｉｍｅ−Ｏｖｅｒも同時に監視する（Ｓ６０３）。

もしも、Ｔｉｍｅ−Ｏｖｅｒが発生したら（Ｓ６０３ Ｙｅｓ，Ｓ６０４ Ｙｅｓ）、再送の準備をする。すなわち、ＴｘＱｕｅｕｅ５０３に再送データを格納できるような準備をする（Ｓ６０７）。再送は、Ｓ６０２にて記憶したデータを使用する（Ｓ６０７）。

Ｔｉｍｅ−Ｏｖｅｒが発生しなかった場合には（Ｓ６０４ Ｎｏ）、次に通信エラーが発生しているかどうか確認する（Ｓ６０５）。

通信エラーが発生している場合には（Ｓ６０５ Ｙｅｓ）再送の準備をする。すなわち、ＴｘＱｕｅｕｅ５０３に再送データを格納できるような準備をする（Ｓ６０７）。再送は、Ｓ６０２にて記憶したデータを使用する（Ｓ６０７）。

次に、ＴｘＲｘＢｕｆｆｅｒ５０２を確認し、ＮＡＣＫであるかどうかを確認する（Ｓ６０６）。 ＮＡＣＫであった場合には、再送の準備をする。すなわち、ＴｘＱｕｅｕｅ５０３に再送データを格納できるような準備をする（Ｓ６０７）。再送は、Ｓ６０２にて記憶したデータを使用する（Ｓ６０７）。

そして、ＮＡＣＫでない場合は（Ｓ６０６ Ｎｏ）、ＴｘＲｘＢｕｆｆｅｒ５０２に通常のステータスが格納されている（Ｓ６０６）。

Ｓ６０６を通過しない限り、次のＳＴＣｏｍｍａｎｄＱｕｅｕｅ５０４のチェックを実施しない。すなわち、正常なＡＣＫが受信されない限り次の新しいＳＴＣｏｍｍａｎｄが発行できないようになっている（Ｓ６０６）。この部分が前述の〔６〕に該当する処理である。

なお、Ｓ６０４，Ｓ６０７の処理が前述の〔１８〕に該当する処理である。また、Ｓ６０４，Ｓ６０５，Ｓ６０７の処理が前述の〔１０〕に該当する処理である。Ｓ６０４，Ｓ６０５，Ｓ６０６，Ｓ６０７の処理が前述の〔１４〕に該当する処理である。Ｓ６０４，Ｓ６０５，Ｓ６０６，Ｓ６０１の処理が前述の〔６〕に該当する処理である。

〜送信ドライバ４０３〜
図１２にて送信ドライバ４０３のフローチャートを説明する。

ＴｘＱｕｅｕｅ５０３にデータが格納されているかどうか、すなわち空か否かを確認する（Ｓ６５１）。

もしも、ＴｘＱｕｅｕｅにデータがある場合には、送信データをハードウエアに書き込み、実際の送信動作を実行する（Ｓ６５２）。

そして、送信動作が完了するのを待つ（Ｓ６５３）。送信動作が完了したら（Ｓ６５３）、ＴｘＱｕｅｕｅ５０３の確認動作に戻る（Ｓ６５３）。

このように本実施例によれば、ネガティブアクナリッジ信号（ＮＡＣＫ）に対しネガティブアクナリッジ信号（ＮＡＣＫ）を再送する状況を避け、通信のハングアップを防止することができる。また、片方からの通信によりハンドシェークを実行中にも、完全に双方向の通信を実行できる。

実施例２の構成は実施例１と同一であり、本実施例の画像形成装置の構成は図１で示される。またＣＰＵの接続も同一であり、図２で示される。

なお、本実施例の通信プロトコルは、実施例１の〔１〕〜〔１８〕の通信形態を有し、さらに、下記〔１９〕〜〔２２〕の通信プロトコルが付加されたものである。
〔１９〕Ａ−ＣＰＵがＣｏｍｍａｎｄを発行する場合には、Ｃｏｍｍａｎｄに識別コードをＡ−ＣＰＵが割り振り、Ｂ−ＣＰＵが、ＡＣＫおよびＳｔａｔｕｓを返信するときには、受信した識別コードをＡＣＫ、および、Ｓｔａｔｕｓの中にコピーして返信する。
〔２０〕Ｂ−ＣＰＵがＣｏｍｍａｎｄを発行する場合には、Ｃｏｍｍａｎｄに識別コードをＢ−ＣＰＵが割り振り、Ａ−ＣＰＵが、ＡＣＫおよびＳｔａｔｕｓを返信するときには、受信した識別コードをＡＣＫ、および、Ｓｔａｔｕｓの中にコピーして返信する。
〔２１〕Ａ−ＣＰＵが識別コードを保存した状態で、Ｃｏｍｍａｎｄを発行しその後、受信したＡＣＫ，またはＳｔａｔｕｓの中に記載された識別コードが保存してあったＣｏｍｍａｎｄ用の識別コードと異なっていた場合には、ＮＡＣＫを送信する。
〔２２〕Ｂ−ＣＰＵが識別コードを保存した状態で、Ｃｏｍｍａｎｄを発行しその後、受信したＡＣＫ，またはＳｔａｔｕｓの中に記載された識別コードが保存してあったＣｏｍｍａｎｄ用の識別コードと異なっていた場合には、ＮＡＣＫを送信する。

＜ＣＰＵ１１の通信ＴＡＳＫ構造の説明＞
図１３から図１７が実施例２におけるＣＰＵ１１のＴＡＳＫ構成およびフローチャートである。

パケット識別コード（識別コード）であるところのパケットＩＤ（以下パケットＩＤ）の付加およびパケットＩＤの不一致の発生状況確認以外の処理は実施例１と同一である。以下、実施例１と同一のものについては同一の符号を用いて説明する。

図１３で示すように、ＳＴＣｏｍｍａｎｄ、ＡＣＫ、ステータス、ステータスＲｅｑｕｅｓｔ、実行コマンド等には、すべてパケットを特定するための固有番号であるパケットＩＤが付加されている（図３と比較参照）。パケットに付加されたパケットＩＤにより通信が正常に実施されたかどうかの確認を行う。

パケットＩＤの決定は、１０５の処理の中で実施される。具体的には、パケットＩＤが１ずつ増加される。すなわちＩｎｃｒｅｍｅｎｔ（以下Ｉｎｃｒｅｍｅｎｔ）される。

〜受信ドライバ１０４〜
図１４のＳ３７５に示すように、受信はパケット単位で行われ、ＲｘＤａｔａ２０１への格納もパケット単位で行われ、以降のデータ解析もパケット単位で実施される。

〜第１受信ＴＡＳＫ１０２〜
図１５で示すように、Ｓ３８５でＡＣＫを返信する場合には、ＳＴＣｏｍｍａｎｄにて通知されたパケットＩＤをそのまま付加する。この処理が前述の〔１９〕に対応する処理である。

〜コマンド・ステータス制御ＴＡＳＫ１０１〜
図１６で示すように、Ｓ３８２で送信したパケットＩＤを記憶するとともに、次に使用するパケットＩＤがＩｎｃｒｅｍｅｎｔされたものとなるように準備する。

また、Ｓ３８８では、受信したパケットＩＤと送信したパケットＩＤの比較が実施され、より精度のよい通信エラーの検知を実施している。もしも、パケットＩＤの不一致が発生した場合には（Ｓ３８８ Ｎｏ）、ＮＡＣＫを返信するために、ＴｘＱｕｅｕｅ２３０にＮＡＣＫをセットする（Ｓ３８９）。この処理が前述の〔２１〕に対応する処理である。

〜送信ドライバ１０３〜
図１７で示すように、送信ドライバ１０３の動作は実施例１と同一である。

＜ＣＰＵ１６の通信ＴＡＳＫ構造の説明＞
図１８から図２２が実施例２におけるＣＰＵ１６のＴＡＳＫ構成およびフローチャートである。

パケットＩＤの付加およびパケットＩＤの不一致の発生状況確認以外の処理は実施例１と同一である。

図１８で示すように、ステータスＲｅｑｕｅｓｔ、実行コマンド、ステータス、ＡＣＫ、ＳＴＣｏｍｍａｎｄ等にはすべてパケットＩＤが付加されている。パケットに付加されたパケットＩＤにより通信が正常に実施されたかどうかの確認を行う。

パケットＩＤの決定は、４０５の処理の中で実施される。具体的には、パケットＩＤがＩｎｃｒｅｍｅｎｔされる。

〜受信ドライバ４０４〜
図１９のＳ６７５で示すように、受信はパケット単位で行われ、ＲｘＤａｔａ５０１への格納もパケット単位で行われ、以降のデータ解析もパケット単位で実施される。

〜第１受信ＴＡＳＫ４０２〜
図２０で示すように、Ｓ６７５、Ｓ６７６で、返信すべきステータスには、ステータスＲｅｑｕｅｓｔのパケットＩＤあるいは実行コマンドのパケットＩＤをそのまま付加する。この処理が前述の〔２０〕に対応する処理である。

〜コマンド・ステータス制御ＴＡＳＫ４０１〜
図２１で示すように、Ｓ６４２では、送信したパケットＩＤを記憶するとともに、次に使用するパケットＩＤがＩｎｃｒｅｍｅｎｔされたものとなるように準備する。

Ｓ６９７では、受信したパケットＩＤと送信したパケットＩＤの比較が実施され、より精度のよい通信エラーの検知を実施している。もしも、パケットＩＤの不一致が発生した場合には（Ｓ６９７ Ｎｏ）、ＮＡＣＫを返信するために、ＴｘＱｕｅｕｅ２３０にＮＡＣＫをセットする（Ｓ６９８）。この処理が前述の〔２２〕に対応する処理である。

〜送信ドライバ４０３〜
図２２で示すように、送信ドライバ４０３の動作は実施例１と同一である。

このように、本実施例によれば、通信エラーの発生をより詳しく検知することができる。

実施例３は実施例２と比較して、第１受信ＴＡＳＫ１０２と第１受信ＴＡＳＫ４０２のフローチャートのみが変更となっている。以下、実施例２と同じものについては同じ符号を用いて説明する。

なお、本実施例の通信プロトコルは、実施例１の〔１〕〜〔１８〕、実施例２の〔１９〕〜〔２２〕の通信形態を有し、さらに、下記〔２３〕、〔２４〕の通信プロトコルが付加されたものである。
〔２３〕Ａ−ＣＰＵがＣｏｍｍａｎｄを受信した時点で、識別コードを保存する。Ａ−ＣＰＵはＣｏｍｍａｎｄに対応した動作を起動する。Ａ−ＣＰＵはＣｏｍｍａｎｄに対応するＡＣＫまたはＳｔａｔｕｓをＢ−ＣＰＵに返信する。Ａ−ＣＰＵが次のＣｏｍｍａｎｄを受信した場合に、もしも、Ｃｏｍｍａｎｄに記載された識別コードが前回のＣｏｍｍａｎｄ受信時に保存した識別コードと一致した場合には、Ａ−ＣＰＵは、Ｃｏｍｍａｎｄに対応した動作は起動しない。そしてＣｏｍｍａｎｄに対応するＡＣＫまたはＳｔａｔｕｓを返信する。
〔２４〕Ｂ−ＣＰＵがＣｏｍｍａｎｄを受信した時点で、識別コードを保存する。Ｂ−ＣＰＵはＣｏｍｍａｎｄに対応した動作を起動する。Ｂ−ＣＰＵはＣｏｍｍａｎｄに対応するＡＣＫまたはＳｔａｔｕｓをＡ−ＣＰＵに返信する。Ｂ−ＣＰＵが次のＣｏｍｍａｎｄを受信した場合に、もしも、Ｃｏｍｍａｎｄに記載された識別コードが前回のＣｏｍｍａｎｄ受信時に保存した識別コードと一致した場合には、Ｂ−ＣＰＵは、Ｃｏｍｍａｎｄに対応した動作は起動しない。そしてＣｏｍｍａｎｄに対応するＡＣＫまたはＳｔａｔｕｓを返信する。

〜第１受信ＴＡＳＫ１０２〜
図２３のＳ３４３で示すように、到着したＳＴＣｏｍｍａｎｄのパケットＩＤが前回（直前に）受信したパケットＩＤと同一であるかどうかを確認する。もしも、パケットＩＤが前回受信したパケットＩＤと同一であれば、再送信が発生したものとして、ＳＴＣｏｍｍａｎｄＳａｖｅＡｒｅａ２０６には格納しない（Ｓ３４３ Ｙｅｓ，Ｓ３４４）。この処理が前述の〔２３〕に対応する処理である。この処理をすることにより、再送信によるステータスの破壊を防止する。

一方、Ｓ３４３で、直前に受信したパケットＩＤと今回のパケットＩＤが同一ではない場合、Ｓ３４４でＳＴＣｏｍｍａｎｄＳａｖｅＡｒｅａ２０６にＳＴＣｏｍｍａｎｄを格納し、パケットＩＤも記憶する。

〜第１受信ＴＡＳＫ４０２〜
図２４のＳ６９９で示すように、今回通知された到着した実行コマンドのパケットＩＤが記憶している前回受信した実行コマンドのパケットＩＤと同一であるかどうかを確認する。もしも、パケットＩＤが前回受信した実行コマンドのパケットＩＤと同一であれば、再送信が発生したものとして、実行コマンド受信情報５０５には書き込まない（Ｓ６９９ Ｙｅｓ）。このように、実行コマンド受信情報５０５には書き込まず、記憶した前回のステータスをＴｘＱｕｅｕｅ５０３にセットする準備をする（Ｓ７０１）。この処理が前述の〔２４〕に対応する処理である。

この処理をすることにより、再送信による不必要な動作の起動を回避できる。そして、再送信が発生したと認識した場合には、記憶してある前回のステータスを返信する。

一方、Ｓ６９９で記憶しているパケットＩＤと今回通知されたパケットＩＤが同一ではない場合は、Ｓ６３９で実行コマンド受信情報５０５に実行コマンド情報を格納し、今回通知されたパケットＩＤも記憶する。

以上説明したように、本実施例によれば、通信ごとのパケット識別コード（パケットＩＤ）を確認することにより、不必要な動作を誤って二重起動することがなくなるので、通信エラーを起因とするハードウエアトラブルを防止することができる。

本発明の画像形成装置本体を説明する図 エンジン基板１５のＣＰＵ１６とビデオコントローラ部１０のＣＰＵ１１の接続図 実施例１のＣＰＵ１１の通信ＴＡＳＫ構造図 実施例１の受信ドライバ１０４のフローチャート 実施例１の第１受信ＴＡＳＫ１０２のフローチャート 実施例１のコマンド・ステータス制御ＴＡＳＫ１０１のフローチャート 実施例１の送信ドライバ１０３のフローチャート 実施例１のＣＰＵ１６の通信ＴＡＳＫ構造図 実施例１の受信ドライバ４０４のフローチャート 実施例１の第１受信ＴＡＳＫ４０２のフローチャート 実施例１のコマンド・ステータス制御ＴＡＳＫ４０１のフローチャート 実施例１の送信ドライバ４０３のフローチャート 実施例２のＣＰＵ１１の通信ＴＡＳＫ構造図 実施例２の受信ドライバ１０４のフローチャート 実施例２の第１受信ＴＡＳＫ１０２のフローチャート 実施例２のコマンド・ステータス制御ＴＡＳＫ１０１のフローチャート 実施例２の送信ドライバ１０３のフローチャート 実施例２のＣＰＵ１６の通信ＴＡＳＫ構造図 実施例２の受信ドライバ４０４のフローチャート 実施例２の第１受信ＴＡＳＫ４０２のフローチャート 実施例２のコマンド・ステータス制御ＴＡＳＫ４０１のフローチャート 実施例２の送信ドライバ４０３のフローチャート 実施例３の第１受信ＴＡＳＫ１０２のフローチャート 実施例３の第１受信ＴＡＳＫ４０２のフローチャート

符号の説明

１ 画像形成装置本体
１０ ビデオコントローラ部
１１ ＣＰＵ
１５ エンジン基板
１６ エンジンＣＰＵ
３２，３３，３４，３５ シリアル通信用バッファＩＣ

Claims (4)

1. 第一の制御部と第二の制御部とを有し、前記第一の制御部または前記第二の制御部が、コマンド信号を発行し、前記コマンド信号に対する応答信号またはステータス信号を受信することにより、前記第一の制御部と前記第二の制御部との間で通信を行う通信装置の通信方法において、
   前記コマンド信号に対する、前記応答信号または前記ステータス信号が返信されるまでは新たなコマンド信号の発行を停止する工程と、
   前記第一の制御部または前記第二の制御部が、前記コマンド信号を発行していない状態で、前記応答信号または前記ステータス信号を受信した場合、または、通信エラーを検知した場合には、受信不良を示す信号を発行する工程と、
   前記第一の制御部または前記第二の制御部が、前記コマンド信号を発行してから前記応答信号または前記ステータス信号を受信するまでの間に、前記通信エラーを検知し、または、前記受信不良を示す信号を受信した場合には、前記コマンド信号を再発行する工程と、を有し、
   前記第一の制御部または前記第二の制御部が、前記コマンド信号を発行していない状態で、前記受信不良を示す信号を受信した場合には、前記受信不良を示す信号を無視する工程を備えることを特徴とする通信方法。
2. 前記第一の制御部または前記第二の制御部が、前記コマンド信号を発行してから一定時間経過しても前記応答信号または前記ステータス信号が返信されなかった場合には、前記コマンド信号を再発行する工程を備えることを特徴とする請求項１に記載の通信方法。
3. 前記第一の制御部または前記第二の制御部が発行する前記コマンド信号に識別コードを付加し、前記識別コードを記憶する工程と、
   前記第一の制御部または前記第二の制御部が、前記識別コードが付加された前記コマンド信号を受信した場合に、前記識別コードを前記応答信号または前記ステータス信号に付加する工程と、
   前記第一の制御部または前記第二の制御部が、前記識別コードが付加された前記応答信号または前記ステータス信号を受信した場合に、前記記憶する工程により記憶された前記識別コードと前記応答信号または前記ステータス信号に付加された前記識別コードとが異なる場合には、前記受信不良を示す信号を送信する工程と、
   を備えることを特徴とする請求項１又は２に記載の通信方法。
4. 前記第一の制御部または前記第二の制御部が、識別コードが付加されたコマンド信号を受信した場合に、前記識別コードを記憶する工程と、
   前記第一の制御部または前記第二の制御部が、識別コードが付加された次のコマンド信号を受信した場合に、前記記憶する工程により記憶された識別コードと、前記次のコマンド信号に付加された識別コードとが一致する場合には、前記次のコマンド信号に対応する動作を起動せず、前記次のコマンド信号に対する前記応答信号またはステータス信号を返信する工程と、
   を備えることを特徴とする請求項３に記載の通信方法。

Images