JPH09277671A

JPH09277671A - プリント制御方法及びプリンタ装置

Info

Publication number: JPH09277671A
Application number: JP8095615A
Authority: JP
Inventors: Takuyuki Matsuo; 卓幸松尾
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1996-04-17
Filing date: 1996-04-17
Publication date: 1997-10-28

Abstract

(57)【要約】【課題】例外事象の発生に従って常に統一的な記録制
御を行なうことができるプリント制御方法及びプリンタ
装置を提供する。【解決手段】プリンタエンジンにおける画像形成動作
の種々の例外事象の発生を監視し、その監視結果に従っ
て、例外パケットを例外事象の発生順に例外キューにキ
ューイングし、発生した例外事象の内容と、他の例外事
象との相互関係とに従って、その例外パケットのコント
ローラへの通知を所定時間待ち合わせ、その後、例外キ
ューに新たにキューイングされた例外パケットがあるか
どうかを調べ、さらにその新たにキューイングされた例
外パケットと待ち合わされている例外パケットとの相互
関係を解析し、その解析結果に従って、待ち合わされて
いる例外パケットを削除したり、或は、これをコントロ
ーラへの通知する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はプリント制御方法及
びプリンタ装置に関し、特に、プリンタコントローラ部
とプリンタエンジン部とから構成されるプリンタ装置及
びその装置で用いられるプリント制御方法に関する。

【０００２】

【従来の技術】従来より、ページプリンタ、ディジタル
複写機、ファクシミリ等のデータをプリントする機能を
備えたプリンタ装置（部）は、プリント機構を制御する
部分（以下、プリンタエンジンという）と、プリンタデ
ータの管理・処理とプリンタエンジンの制御を担当する
部分（以下、コントローラという）を夫々、クライアン
ト、サーバとして構成し、分散処理するようになってい
る。即ち、コントローラをクライアント、プリンタエン
ジンをサーバとし、両者間でコマンドとそのコマンドに
対する応答（リプライ）を交換することにより記録動作
を行わせている。

【０００３】通常のクライアント／サーバシステムで
は、クライアントからのコマンドに対してサーバが正常
にその処理を実行したか、或は、処理を異常終了したか
の結果をリプライとしてクライアントに返送することに
よって、互いの状況を把握している。

【０００４】さて、サーバ側に何らかの異常や通常の動
作状況では予期できない事象が発生することがある。以
後、これらの事象を総括的に「例外事象」と呼ぶ。上述
のプリンタ装置（部）では、例えば、ページプリンタの
プリンタエンジンでの紙詰まり、記録剤（トナー、イン
ク、インクリボン等）の不足、ハードウェアの故障など
の事象はクライアントからのコマンドとは無関係に発生
する。サーバにこのような例外事象が発生した場合に
は、もはやクライアントからのコマンドを実行できない
場合が多く、クライアントに対しては例外事象の発生を
通知して何らかの対応をユーザに要求しなければならな
い場合が多い。前述の例では、紙詰まりが生じたらユー
ザに詰まった紙を除去してもらい、その後記録動作を再
開するようコントローラに指示を行うことが望まれる。

【０００５】このことを例を挙げて説明する。

【０００６】例えば、ページプリンタでは、プリンタエ
ンジンのカバーが記録動作中に何等かの理由によって開
いた場合には、危険防止のためプリンタエンジンの機構
部に供給している電源が停止する構造になっている。即
ち、いくつかのアクチュエータであるモータが緊急停止
し、更に記録剤の温度制御のためのヒータへの電源供給
も停止するのである。サーバ側（プリンタエンジン）
は、これらモータの制御やヒータの温度制御は各々独立
したプロセスで行っており、各プロセスは制御対象の動
作異常を検出するよう構成されているため、各プロセス
はそれぞれモータ、ヒータの異常を検出する。つまり、
本当にモータやヒータが故障して異常を示したわけでは
なく、カバーがオープンしたという「例外事象」の発生
がもとになって副次的な例外事象を発生させてしまった
わけである。このような副次的例外事象は、カバーがオ
ープンしたという「例外事象」の発生が原因となって発
生したのもであるから、クライアント（コントローラ）
には報告すべき性質のものではない。

【０００７】従って、従来のページプリンタでは、副次
的例外事象をクライアントに通知しないように制御して
いた。つまり、元の原因となった「カバーオーブン」と
いう例外事象がすでに発生していたか否かを各プロセス
側でチェックし、もし、その例外事象が発生していたと
判断されたならば、検出したハードウェアの異常（モー
タやヒータの異常）は通知しないようにし、その例外事
象が発生してはいないと判断された場合には、ハードウ
ェア異常が発生したとみなして、そのハードウェア異常
を例外事象の発生の通知として、クライアントであるコ
ントローラに送るようにしていた。

【０００８】図１１はカバーオープンという例外事象の
発生後、副次的例外事象が発生するタイミングを示す図
である。

【０００９】図１１（ａ）に示す例では、ｔ＝ｔ0でカ
バーが実際に開いた後、ｔ＝ｔ1でカバーオープンの例
外事象が検出され、その後、副次的例外事象であるモー
タ異常がｔ＝ｔ2で検出され、さらにｔ＝ｔ3では別の副
次的例外事象としてヒータの温度異常を検出している。
このような順で例外事象の検出が行われると、モータ異
常を例外事象として検出するモジュールは、モータ動作
の突然の停止を検出してコントローラに報告する前に、
カバーオープンという例外事象が発生しているかどうか
を検査する。これは、具体的にはモジュールが実行され
るメモリの作業領域の内、他のモジュールと共有して利
用可能な所定領域に設定されたカバー状態を示すフラグ
を参照することで行われる。そして、その検査結果に従
って、モータ異常を例外事象として通知するかどうかを
決定する。この例では、モータ異常を例外事象として検
出する前に、既にカバーオープンの発生を例外事象とし
て検出しているので、モータ異常は例外事象としては通
知されない。同様に、ヒータの温度異常を例外事象とし
て検出したモジュールも、カバーオープンの例外事象が
発生していることを判別して、ヒータの温度異常を例外
事象としては通知しない。

【００１０】従って、コントローラはカバーオープンと
いう例外事象の通知しか受信しないので、ユーザに対し
てカバーを閉じるようにメッセージを送るよう制御する
だけで、そのカバーが閉じられるのを待つ。

【００１１】

【発明が解決しようとする課題】このように、副次的例
外事象の検出が、その元になる例外事象の検出がなされ
た後になされる場合には、副次的例外事象はコントロー
ラには通知されずに済む。しかしながら上記従来例で
は、カバーオーブンという例外事象を検出するモジュー
ルと、モータ異常という例外事象を検出するモジュール
とは、通常異なり、これらのモジュールは互いに独立に
動作しているので、これらのモジュールの処理状況やシ
ステム全体の記録制御の実行によって必ずしも、各モジ
ュールが例外事象を検出する順が実際の事象の発生順と
一致している訳ではない。

【００１２】例えば、図１１（ｂ）に示すように、ｔ＝
ｔ0でカバーが実際に開いたにも係わらず、モータ異常
の検出（ｔ＝ｔ2'）がカバーオープンの検出（ｔ＝ｔ
1'）よりも先になされてしまう可能性がある。このよう
な場合、モータ異常という例外事象を検出したモジュー
ルは、既にカバーオープンという例外事象が発生してい
るかどうかを検査しても、まだカバーオープンは検出さ
れていないと認識する。すると、実際にはモータが故障
していないにも係わらず、コントローラに（最終的には
ユーザ）モータ異常という例外異常が発生したことが通
知されてしまう。

【００１３】このような通知を受けたコントローラは、
更なる故障を防ぐために実行していたプリント動作を停
止するよう制御することになる。

【００１４】このように、カバーが開いているという同
じ事象でも、その検出タイミングが異なると、コントロ
ーラに通知される例外事象が異なり、さらに、コントロ
ーラが異なる制御を行なってしまうという問題がある。
こうしたことはユーザの装置操作という観点からも望ま
しくないのは明らかである。

【００１５】本発明は上記従来例に鑑みてなされたもの
で、例外事象の発生に従って常に統一的な記録制御を行
なうことができるプリント制御方法及びプリンタ装置を
提供することを目的としている。

【００１６】

【課題を解決するための手段】上記目的を達成するため
に本発明のプリント制御方法は、以下のような工程から
なる。

【００１７】即ち、記録媒体に画像を形成する画像形成
部と外部装置からの画像データの受信や画像形成動作の
制御を行う制御部とを有するプリンタ装置に用いられる
プリント制御方法であって、前記画像形成部における画
像形成動作の種々の例外事象の発生を監視する監視工程
と、前記監視工程における監視結果に従って、例外事象
の発生を示す情報を該例外事象の発生順にキューイング
するキューイング工程と、前記発生した例外事象の内容
と、他の例外事象との相互関係とに従って、前記例外事
象の発生を示す情報の前記制御部への通知を所定時間待
ち合わせる待ち合わせ工程と、前記所定時間の後、前記
キューイング工程におけるキューに新たにキューイング
された例外事象の発生を示す情報があるかどうかを調
べ、さらに前記新たにキューイングされた例外事象の発
生を示す情報と前記待ち合わせ工程において待ち合わさ
れている前記例外事象の発生を示す情報との相互関係を
解析する解析工程と、前記解析工程による解析結果に従
って、前記待ち合わせ工程において待ち合わされている
前記例外事象の発生を示す情報の前記制御部への通知を
制御する通知制御工程とを有することを特徴とするプリ
ント制御方法を備える。

【００１８】また他の発明によれば、記録媒体に画像を
形成する画像形成手段と外部装置からの画像データの受
信や画像形成動作の制御を行う制御手段を有するプリン
タ装置であって、前記画像形成手段における画像形成動
作の種々の例外事象の発生を監視する監視手段と、前記
監視手段による監視結果に従って、前記例外事象の発生
を示す情報を該例外事象の発生順にキューイングするキ
ューイング手段と、前記発生した例外事象の内容と、他
の例外事象との相互関係とに従って、前記例外事象の発
生を示す情報の前記制御手段への通知を所定時間待ち合
わせる待ち合わせ手段と、前記所定時間の後、前記キュ
ーイング手段に新たにキューイングされた例外事象の発
生を示す情報があるかどうかを調べ、さらに前記新たに
キューイングされた例外事象の発生を示す情報と前記待
ち合わせ手段によって待ち合わされている前記例外事象
の発生を示す情報との相互関係を解析する解析手段と、
前記解析手段による解析結果に従って、前記待ち合わせ
手段によって待ち合わされている前記例外事象の発生を
示す情報の前記制御手段への通知を制御する通知制御手
段とを有することを特徴とするプリンタ装置を備える。

【００１９】

【発明の実施の形態】以上の構成により本発明は、画像
形成部における画像形成動作の種々の例外事象の発生を
監視し、その監視結果に従って、例外事象の発生を示す
情報を該例外事象の発生順にキューイングし、発生した
例外事象の内容と、他の例外事象との相互関係とに従っ
て、その例外事象の発生を示す情報の制御部への通知を
所定時間待ち合わせ、所定時間の後、キューに新たにキ
ューイングされた例外事象の発生を示す情報があるかど
うかを調べ、さらにその新たにキューイングされた例外
事象の発生を示す情報と待ち合わされている例外事象の
発生を示す情報との相互関係を解析し、その解析結果に
従って、待ち合わされている例外事象の発生を示す情報
の制御部への通知を制御するよう動作する。

【００２０】さらに、以上の動作には、複数の例外事象
と、複数の例外事象各々の事象を引き起こす元となる他
の例外事象との関係と、複数の例外事象各々に関し待ち
合わせる時間とを登録する管理テーブルを用いる。そし
て、その待ち合わせにおいて管理テーブルを参照して他
の例外事象との相互関係を調べる。

【００２１】また、キューイングにおいて、既に他の例
外事象の発生を示す情報がキューイングされているかど
うかを調べ、他の例外事象の発生を示す情報がキューイ
ングされている場合には、管理テーブルを参照して、例
外事象の発生を示す情報のキューイングを行なわないよ
うに制御しても良い。

【００２２】さらにまた、上記の解析において、所定時
間の間に新たにキューイングされた例外事象の発生を示
す情報と待ち合わされている例外事象の発生を示す情報
との相互関係を、管理テーブルを参照して調べても良
い。

【００２３】さらにまた、待ち合わされている例外事象
の発生を示す情報を、制御部へ通知せず削除するか、或
は、制御部へ通知するかを決定するようにしても良い。

【００２４】さて、制御部と画像形成部との関係は、ク
ライアントとサーバとの関係にあり、制御部は画像形成
部にコマンドを出力して画像形成指示を行い、画像形成
部はそのコマンドに応答してステータスをその制御部に
返送するようにできる。そして、その画像形成部は、電
子写真方式に従って記録媒体上に画像形成を行うプリン
タエンジンでも良いし、或は、インクジェット方式に従
って記録媒体上に画像形成を行うプリンタエンジンでも
良い。

【００２５】また、種々の例外事象として、記録媒体の
ジャム、電源供給の停止、温度異常、装置カバーの開
放、画像形成部に設けられたモータの異常などが監視さ
れる。

【００２６】なお、制御部は、通知される例外事象の発
生を示す情報に従って画像形成動作を制御する。

【００２７】以下添付図面を参照して本発明の好適な実
施の形態について、詳細に説明する。

【００２８】＜装置構成の説明（図１〜図３）＞図１は
本発明の代表的な実施形態であるコントローラとプリン
タエンジンとから構成されるプリンタ装置の構成概略を
示すブロック図である。このコントローラとプリンタエ
ンジンとは、クライアント／サーバの概念を導入したシ
ステムとなっており、コントローラがクライアント、プ
リンタエンジンがサーバとして位置付けられている。

【００２９】図１において、１００はコントローラ、１
０７はプリンタエンジン、２００は形成されるプリント
結果、３００はプリントデータを出力するホストコンピ
ュータ（以下、ホストという）である。コントローラ１
００には、プリンタ装置全体を制御するＣＰＵ１０１を
はじめ、以下に示す構成を備えている。

【００３０】１０２はＣＰＵ１０１が実行する制御プロ
グラムを格納するＲＯＭ、１０３は制御プログラムを実
行するための作業領域として用いられるＲＡＭ、１０４
は受信データを格納するページバツフア、１０５は１ペ
ージ分のイメージデータを展開するビツトマツプメモ
リ、１０６はアウトラインフオントデータを記憶してい
るフオントメモリ、１０７はビツトマツプメモリ１０５
に展開されたイメージデータに基づいて実際に印刷処理
を行うプリンタエンジン、１０８はホスト３００から送
られてくるデータを一旦格納する受信バツフアである。

【００３１】図２は電子写真方式を採用して記録を行な
うプリンタエンジン１０７を含んだプリンタ装置の内部
構造を示す側断面図である。

【００３２】図２において、７４０はレーザビームプリ
ンタ（ＬＢＰ）であり、供給される文字パターン等を基
に、記録媒体である記録紙上に像を形成する。７００は
操作のためのスイツチ及びＬＥＤ表示器などが配されて
いる操作パネル、７０１はＬＢＰ７４０全体の制御及び
文字パターン情報等を解析するプリンタ制御ユニツトで
ある。図１のブロック図では、エンジン部１０７を除い
たコントローラ１００は、プリンタ制御ユニット７０１
に含まれている。

【００３３】レーザドライバ７０２は半導体レーザ７０
３を駆動するための回路であり、入力されたビデオ信号
に応じて半導体レーザ７０３から発射されるレーザ光７
０４をオン・オフ切替えする。レーザ光７０４は回転多
面鏡７０５で左右方向に振られて静電ドラム７０６上を
走査する。これにより、静電ドラム７０６上には文字パ
ターンの静電潜像が形成される。この潜像は静電ドラム
７０６周囲の現像ユニツト７０７により現像された後、
記録紙に転写される。この記録紙にはカツトシートを用
い、カツトシート記録紙はＬＢＰ７４０に装着した用紙
カセツト７０８に収納され、給紙ローラ７０９及び搬送
ローラ７１０と７１１とにより装置内に取込まれて、静
電ドラム７０６に供給される。

【００３４】このようにして、与えられた印刷データは
用紙上に記録出力される。

【００３５】なお、プリンタエンジン１０７は、図２に
示したような電子写真方式に従うレーザビームプリンタ
でなくとも良い。例えば、図３に示すようなインクジェ
ット方式に従って記録を行うプリンタでも良い。

【００３６】図３は、インクジェットプリンタ１０７の
構成の概要を示す外観斜視図である。図３において、駆
動モータ５０１３の正逆回転に連動して駆動力伝達ギア
５００９〜５０１１を介して回転するリードスクリュー
５００５の螺旋溝５００４に対して係合するキャリッジ
ＨＣはピン（不図示）を有し、ガイドレール５００３に
支持されて矢印ａ，ｂ方向を往復移動する。キャリッジ
ＨＣには、記録ヘッドＩＪＨとインクタンクＩＴとを内
蔵した一体型インクジェットカートリッジＩＪＣが搭載
されている。５００２は紙押え板であり、キャリッジＨ
Ｃの移動方向に亙って記録用紙Ｐをプラテン５０００に
対して押圧する。５００７，５００８はフォトカプラ
で、キャリッジのレバー５００６のこの域での存在を確
認して、モータ５０１３の回転方向切り換え等を行うた
めのホームポジション検知器である。５０１６は記録ヘ
ッドＩＪＨの前面をキャップするキャップ部材５０２２
を支持する部材で、５０１５はこのキャップ内を吸引す
る吸引器で、キャップ内開口５０２３を介して記録ヘッ
ドの吸引回復を行う。５０１７はクリーニングブレード
で、５０１９はこのブレードを前後方向に移動可能にす
る部材であり、本体支持板５０１８にこれらが支持され
ている。ブレードは、この形態でなく周知のクリーニン
グブレードが本例に適用できることは言うまでもない。
又、５０２１は、吸引回復の吸引を開始するためのレバ
ーで、キャリッジと係合するカム５０２０の移動に伴っ
て移動し、駆動モータからの駆動力がクラッチ切り換え
等の公知の伝達機構で移動制御される。

【００３７】これらのキャッピング、クリーニング、吸
引回復は、キャリッジがホームポジション側の領域に来
た時にリードスクリュー５００５の作用によってそれら
の対応位置で所望の処理が行えるように構成されている
が、周知のタイミングで所望の動作を行うようにすれ
ば、本例にはいずれも適用できる。

【００３８】なお、以下の説明は、図２に示すような構
成をした電子写真方式に従って記録を行うページプリン
タを例とする。

【００３９】図１に示すプリンタ装置のうち、サーバと
なるプリンタエンジン１０７には、機能的に、様々な例
外事象を検出するための各プログラムモジュール、検出
された例外事象の通知をキューイングするための例外キ
ュー、計時機能、計時機能から指定した時刻に呼び出さ
れるアラームハンドラプログラムが備えられている。プ
ログラムモジュールとしては、装置のカバーオープンを
例外事象として検出するカバーマネージャー、モータ異
常を例外事象として検出するモータマネージャー、ヒー
タの温度異常を例外事象として検出するヒータマネージ
ャー等がある。一方、クライアントであるコントローラ
１００は、機能的に、ホスト３００と通信するモジュー
ル、プリンタエンジン１０７とコマンド、ステータス、
例外事象等をやり取りするインタフェースモジュールが
備えられている。

【００４０】これらのプログラムモジュールは、ＣＰＵ
１０１で実行されるので、この実施形態ではコントロー
ラ１００とプリンタエンジン１０７とはソフトウェア的
に分離しているだけであるが、プリンタエンジン１０７
に専用のプロセッサを実装し、物理的に別々のの回路上
で夫々に属するプログラムモジュールを実行させ、互い
をシリアル通信などでコミュニケーションするように構
成しても良い。この実施形態では、コントローラ１００
とプリンタエンジン１０７はＣＰＵ１０１で実行される
オペレーティングシステム（ＯＳ）に備えられたメッセ
ージ交換機能を用いて互いのメッセージをやり取りする
ようになっている。

【００４１】＜メッセージ交換の説明（図４〜図６）＞
図４はコントローラ１００とプリンタエンジン１０７と
の間のメッセージ交換を示す図である。図４（ａ）に示
すように、クライアントであるコントローラ１００から
サーバであるプリンタエンジン１０７に対してはコマン
ドが発行され、プリンタエンジン１０７からコントロー
ラ１００にはステータスが返される。

【００４２】そして、図４（ｂ）に示すようにコントロ
ーラ１００からプリンタエンジン１０７に渡されるメッ
セージデータ構造を「コマンドパケット」と呼び、図４
（ｃ）に示すようにプリンタエンジン１０７からコント
ローラ１００に渡されるメッセージデータ構造を「ステ
ータスパケット」と呼ぶ。

【００４３】図５は、メモリ上におけるコマンドパケッ
トとステータスパケットの詳細なメッセージデータ構造
を示す図である。

【００４４】図５（ａ）に示すように、コマンドパケッ
トは、２バイトのコード化されたコマンドと８バイトの
パラメータから構成されるが、実際には、ＯＳのメッセ
ージ交換機能を用いるためにメッセージリンクエリアと
して別に４バイトの領域が必要となる。パラメータは各
コマンドに応じてその内容と大きさが異なるがパケット
の大きさはコマンドコードに依らず定型サイズ（１４バ
イト）である。コマンドパケットを受け取ったプリンタ
エンジン１０７はコマンドコードとパラメータによって
指定された動作を行う。その後、その動作の終了時にコ
ントローラ１０７に対してステータスパケットを返す。

【００４５】図５（ｂ）に示すように、ステータスパケ
ットは、コマンドパケットと同様に、４バイトのメッセ
ージリンクエリアが含まれ、２バイトのステータスと８
バイトのデータ領域とで構成され、１４バイトの定型サ
イズとなっている。

【００４６】ステータスパケットは、例外事象の通知パ
ケットを兼ねており、両者の区別はステータスコードが
１０００ｈ以上である場合、そのパケットはコントロー
ラ１００によって例外事象の通知パケットとみなされ
る。また、ステータスコードが００００ｈと０００１ｈ
である場合、それぞれを正常終了ステータスのステータ
スパケット、異常終了のステータスパケットとみなす。

【００４７】コマンドパケットをサーバ（プリンタエン
ジン）に対して送信すると、サーバは、通常、正常終了
或は異常終了を示すコードをステータスにセットして、
ステータスパケットをクライアント（コントローラ）に
返すことになっている。異常終了の場合には、プリンタ
エンジン１０７に何らかの「例外事象」が発生している
ので、図５（ｂ）に示すような何らかの例外コードが記
された例外事象の通知パケットがさらにコントローラ１
００に返される。ステータスパケットや例外事象の通知
パケット中に定義される８バイトのデータ領域にはコマ
ンドパケットのパラメータと同様にコマンドに対応して
プリンタエンジン１０７からコントローラ１００に対し
て返すべきデータがある場合にのみセットされることに
なっている。

【００４８】さて、コントローラ１００からプリンタエ
ンジン１０７へ発行されたコマンドパケットに同期し
て、プリンタエンジン１０７ではこれを処理して、その
結果をステータスパケットとしてコントローラ１００に
返送することなっているが、例外事象の通知パケットは
コマンドの発行とは非同期にプリンタエンジン１０７で
その事象が検出される度に生成されてコントローラ１０
０に送られる。この実施形態では、プリンタエンジン１
０７の制御のために機能する各プログラムモジュールに
よって検出された例外事象は、すぐにコントローラ１０
０に例外事象の通知パケットを作成して送らずに、一
旦、図６に示すような例外事象の通知パケットのキュー
（これを例外キューという）にリンクし、その後、真に
通知すべき例外事象だけを選択して通知するように制御
される。

【００４９】即ち、各モジュールで検出された例外事象
は、例外事象の通知パケットとして例外キューに登録さ
れる。その後、コントローラ１００に本当に通知が必要
な例外事象の通知パケットだけがキューからはずされて
コントローラ１００に送られる。プリンタエンジン１０
７に関係した制御プログラムを実行するＲＡＭ１０３の
作業領域に設けられた例外キューのヘッダ（例外キュー
ヘッダ）には、例外事象を検出した各モジュールからの
例外事象の通知パケットが登録ルーチンを用いてリスト
構造にリンクされている。そして、最後（時間的に最
新）に登録された例外事象の通知パケットのリンクエリ
アにはＮＵＬＬ（０）がセットされて、キューの最後尾
であることが判別できるようになっている。

【００５０】＜選択的な例外事象発生の通知（図７〜図
１０）＞この実施形態では、従来例で指摘された例外事
象の検出タイミングが実際の事象の発生順序と必ずしも
一致しないという問題点を解決するために、例外事象の
発生の通知を遅延させるとともに、例外事象間の依存関
係を分析し、例外キューに登録してある例外事象の通知
パケットから副次的に発生した例外事象についてのパケ
ットを取り除くことにより、副次的に発生する例外事象
の通知をコントローラ１００へ行わないようにしてい
る。

【００５１】このために、この実施形態では、例外情報
テーブルという管理テーブルを用いて、例外事象の通知
パケットにセットされる例外事象を示すステータスコー
ド（例外コード）を一括して管理する。

【００５２】図７は例外情報テーブルの構造を示す図で
ある。

【００５３】図７に示すように、このテーブルには各例
外コードに対応して、例外事象の発生の通知をどのくら
い遅延させるかを定めるディレイ時間（ＤＬＹ）と
「親」と呼ばれるいくつかの例外コード（親例外コー
ド）を設定する。ここで、「親」とはある例外事象の発
生の直接の原因となる例外事象のことである。例えば、
「プリンタ装置のカバーが開いていた（カバーオープ
ン）」という例外事象は、モータ異常という例外事象の
「親」の例外事象である。また、「電源異常」という例
外事象はヒータの温度異常という例外事象の「親」の例
外事象である。ある例外事象は複数の「親」の例外事象
を持つこともあるし、ある例外事象は複数の例外事象の
「親」の例外事象となっていることもある。このような
例外事象間の依存関係が各例外コードに対応して、
「親」例外事象の個数とともに例外情報テーブルに登録
されている。

【００５４】一方、ディレイ時間（ＤＬＹ）とは、ある
例外事象の通知パケットが例外キューに登録されて後、
通知されずにキューにリンクされたままにすべき最小期
間のことである。ディレイ時間の値は、各例外事象によ
って異なるが、具体的にはある例外の登録から引き続き
登録されるであろう副次的例外事象を待つ時間として決
定される。例えば、カバーオープンという例外事象が登
録されてから約２００（ｍｓ）でモータ異常の例外事象
やヒータの温度異常の例外事象が検出されることが予め
わかっているのであれば、２００ｍｓをカバーオープン
の例外事象のディレイ時間として定めることになる。

【００５５】上述のように、この実施形態では、ディレ
イ時間（ＤＬＹ）の導入によって検出が前後するいくつ
かの例外事象の通知パケットを例外キュー上で待ち合わ
せ、副次的に発生した例外事象の通知パケットを除去す
る。

【００５６】ここでは、図８に示すようなタイミングで
例外事象の発生と検出がなされた例を取り上げて、例外
事象の検出の通知順序と実際の事象の発生順序とを必ず
一致させ、副次的な例外事象発生の通知を抑止する制御
について、図９〜図１０に示すフローチャートを参照し
て説明する。

【００５７】なお、図８に示す例は、図１１（ｂ）に示
した例と同じである。そして、この例ではモータ異常と
いう例外事象に対応したディレイ時間（ＤＬＹ）は、図
７に示す例外情報テーブルに設定されているように、遅
れて報告される可能性のある親例外であるカバーオープ
ンという例外事象の検出を待ち合わせるために設けてあ
る。また、この例ではモータ異常とヒータの温度異常の
例外事象はカバーオープンという例外事象の副次的例外
事象となっている。さらに、この実施形態では、ＣＰＵ
１０１で実行されるＯＳに現時点から指定された時間の
経過後に指定したソフトウェアルーチンを呼び出す機能
（アラーム機能）を備えていることを前提にしている。

【００５８】まず、例外事象を検出したモジュールは前
述した例外事象の通知パケットを生成し、例外キューに
登録するための専用ルーチンである「例外登録ルーチ
ン」を呼び出して実行する。以下、図９を参照して例外
登録ルーチンの処理について説明する。

【００５９】まず、ステップＳ１では、例外キューが空
かであるかどうかを調べる。ここで、そのキューが空で
あった場合、処理はステップＳ２に進み、空でなかった
場合（すでに例外キューに例外事象の通知パケットがリ
ンクされていた場合）には処理はステップＳ５に進む。

【００６０】ステップＳ２では、登録しようとしている
例外事象の通知パケットの例外コードに基づいて、図７
に示した例外情報テーブルから、その例外コードに対応
するディレイ時間（ＤＬＹ）を得、続くステップＳ３で
は、アラーム機能にそのディレイ時間を設定する。さら
に、ステップＳ４では例外事象の通知パケットを例外キ
ューにリンクして処理を終了する。この後、設定された
ディレイ時間（ＤＬＹ）の経過後に後述するアラームハ
ンドラルーチンが呼び出される。つまり設定したディレ
イ時間の間は登録された例外事象の通知パケットはコン
トローラ１００に送信されずにキューにリンクされたま
ま、「親」の例外事象、或は、副次的例外事象の登録を
待ち合わせることになる。

【００６１】一方、処理はステップＳ５において、図７
に示した例外情報テーブルから親例外コードを得る。次
に、ステップＳ６では、例外キュー内の全例外コードの
中に例外情報テーブルから得た親例外コードに一致する
ものがあるかどうかを調べる。ここで、一致するものが
あれば登録しようとしていた例外事象は副次的例外事象
と判定されるので、処理はステップＳ７に進み、その例
外事象の通知パケットは例外キューに登録することなく
破棄し、処理を終了する。これに対して、一致するもの
が無ければ、処理はステップＳ４に進み、例外キューの
最後尾にそのパケットをリンクし、その後処理を終了す
る。

【００６２】以上のような処理によって、「親」の例外
事象が検出された後に検出された副次的例外事象を除去
することができる。

【００６３】次に、ステップＳ３において設定されたデ
ィレイ時間（ＤＬＹ）の経過後に実行されるアラームハ
ンドラルーチンの処理について、図１０を参照して説明
する。アラームハンドラルーチンは例外設定ルーチンで
設定したアラーム機能を用いて呼び出され実行されるル
ーチンであり、このルーチンが呼ばれたことは必ず例外
キューに例外事象の通知パケットが存在することを意味
する。

【００６４】その処理は、まず、ステップＳ８では、デ
ィレイ時間が終了したパケットの例外コードに対応する
親例外コードを例外情報テーブルから得る。続いて、ス
テップＳ９にて例外キューにその「親」の例外事象の通
知パケットが登録されているかどうかを調べる。もし、
それが登録されていれば処理はステップＳ１０に進み、
未登録であれば処理はステップＳ１４に進む。

【００６５】さて、ステップＳ１０では、例外キューに
ディレイ時間が終了したパケットの「親」の例外事象が
存在したことが判別され、そのパケットはコントローラ
１００に通知すべき例外事象ではないとみなされ例外キ
ューから取り除かれ破棄される。このことを、図８で示
した例で説明する。

【００６６】即ち、例外キューの先頭にはモータ異常の
例外事象を通知するパケットが登録され、続いてカバー
オープンの例外事象を通知するパケットがリンクしてい
た訳であるが、モータ異常の例外事象の通知パケットの
ディレイ時間（ＤＬＹ）が経過して、アラームハンドラ
ルーチンが呼ばれた時点では、ステップＳ８〜Ｓ９の処
理によって、モータ異常の例外事象の「親」の例外事象
が、図７に示す例外情報テーブルからカバーオープンの
例外事象と電源異常の例外事象であることがわかる。一
方、例外キューにはまさにカバーオープンの例外事象の
通知パケットがリンクされているので、ステップＳ１０
の処理によって、モータ異常の例外事象の通知パケット
は破棄されることになるのである。なお、図８に示す例
では、ヒータの温度異常という例外事象も検出されてい
るが、この時点ではすでにカバーオープンの例外事象の
通知パケットが例外キューに登録されているので、例外
登録ルーチンの実行によって例外キューにはリンクされ
ずに破棄される。

【００６７】一方、ステップＳ１４では、例外キューか
らディレイ時間が終了したパケットを取り出して、その
パケットをクライアント（コントローラ１００）に送信
する。その後、処理はステップＳ１１に進む。

【００６８】ステップＳ１１では、例外キューが空にな
ったかどうかを調べる。ここで、空になったと判定され
れば処理は終了するが、まだ例外キューは空ではない
（図８の例で言えば、カバーオープンの例外事象の通知
パケットがリンクされている）と判定されれば、処理は
ステップＳ１２に進み、ステップＳ１０の処理の結果、
例外キューで先頭となったパケット（図８の例で言え
ば、カバーオープンの例外事象の通知パケット）のディ
レイ時間が例外情報テーブルから得、さらにステップＳ
１３ではその取り出した値を取出されてアラーム機能に
セットして処理を終了する。

【００６９】従って以上説明した実施形態に従えば、例
外情報テーブルに設定されたディレイ時間（ＤＬＹ）を
用い、検出が前後するいくつかの例外事象の通知パケッ
トを例外キュー上で待ち合わせ、さらに、それら例外事
象間の依存関係を調べ、副次的に発生した例外事象の通
知パケットを除去することができる。これによって、ク
ライアントであるコントローラには元の原因となる例外
事象が通知されるので、副次的に発生する例外事象に惑
わされることなく、より適切なプリント制御を行うこと
ができる。

【００７０】また、本発明の目的は、前述した実施形態
の機能を実現するソフトウェアのプログラムコードを記
録した記憶媒体を、システムあるいは装置に供給し、そ
のシステムあるいは装置のコンピュータ（またはＣＰＵ
やＭＰＵ）が記憶媒体に格納されたプログラムコードを
読出し実行することによっても、達成されることは言う
までもない。

【００７１】この場合、記憶媒体から読出されたプログ
ラムコード自体が前述した実施形態の機能を実現するこ
とになり、そのプログラムコードを記憶した記憶媒体は
本発明を構成することになる。

【００７２】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピディスク，ハードディス
ク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ
−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭな
どを用いることができる。

【００７３】また、コンピュータが読出したプログラム
コードを実行することにより、前述した実施形態の機能
が実現されるだけでなく、そのプログラムコードの指示
に基づき、コンピュータ上で稼働しているＯＳ（オペレ
ーティングシステム）などが実際の処理の一部または全
部を行い、その処理によって前述した実施形態の機能が
実現される場合も含まれることは言うまでもない。

【００７４】さらに、記憶媒体から読出されたプログラ
ムコードが、コンピュータに挿入された機能拡張ボード
やコンピュータに接続された機能拡張ユニットに備わる
メモリに書込まれた後、そのプログラムコードの指示に
基づき、その機能拡張ボードや機能拡張ユニットに備わ
るＣＰＵなどが実際の処理の一部または全部を行い、そ
の処理によって前述した実施形態の機能が実現される場
合も含まれることは言うまでもない。

【００７５】本発明を上記記憶媒体に適用する場合、そ
の記憶媒体には、先に説明したフローチャートに対応す
るプログラムコードを格納することになるが、簡単に説
明すると、図１２のメモリマップ例に示す各モジュール
を記憶媒体に格納することになる。すなわち、少なくと
も「監視モジュール」、「キューイングモジュール」、
「待ち合わせモジュール」、「解析モジュール」、「通
知モジュール」の各モジュールのプログラムコードを記
憶媒体に格納すればよい。

【００７６】

【発明の効果】以上説明したように本発明によれば、画
像形成部における画像形成動作の種々の例外事象の発生
を監視し、その監視結果に従って、例外事象の発生を示
す情報を該例外事象の発生順にキューイングし、発生し
た例外事象の内容と、他の例外事象との相互関係とに従
って、その例外事象の発生を示す情報の制御部への通知
を所定時間待ち合わせ、所定時間の後、キューに新たに
キューイングされた例外事象の発生を示す情報があるか
どうかを調べ、さらにその新たにキューイングされた例
外事象の発生を示す情報と待ち合わされている例外事象
の発生を示す情報との相互関係を解析し、その解析結果
に従って、待ち合わされている例外事象の発生を示す情
報の制御部への通知を制御するので、例えば、副次的に
発生した例外事象は通知されず、真に必要な例外事象だ
けが制御部に通知されることになり、制御部はより適切
なプリント制御を行うことができるという効果がある。

【００７７】

【図面の簡単な説明】

【図１】本発明の代表的な実施形態であるコントローラ
とプリンタエンジンとから構成されるプリンタ装置の構
成概略を示すブロック図である。

【図２】電子写真方式を採用して記録を行なうプリンタ
エンジン１０７を含んだプリンタ装置の内部構造を示す
側断面図である。

【図３】インクジェットプリンタ１０７の構成の概要を
示す外観斜視図である。

【図４】コントローラ１００とプリンタエンジン１０７
との間のメッセージ交換を示す図である。

【図５】メモリ上におけるコマンドパケットとステータ
スパケットの詳細なメッセージデータ構造を示す図であ
る。

【図６】例外事象の通知パケットのキューを示す図であ
る。

【図７】例外情報テーブルの構造を示す図である。

【図８】例外事象の発生と検出がなされたタイミングの
一例を示す図である。

【図９】例外登録ルーチンの処理を示すフローチャート
である。

【図１０】アラームハンドラルーチンの処理を示すフロ
ーチャートである。

【図１１】カバーオープンという例外事象の発生後、副
次的例外事象が発生するタイミングを示す図である。

【図１２】メモリマップを示す図である。

【符号の説明】

１００コントローラ１０１ＣＰＵ１０２ＲＯＭ１０３ＲＡＭ１０７プリンタエンジン

Claims

【特許請求の範囲】

【請求項１】記録媒体に画像を形成する画像形成手段
と外部装置からの画像データの受信や画像形成動作の制
御を行う制御手段を有するプリンタ装置であって、前記画像形成手段における画像形成動作の種々の例外事
象の発生を監視する監視手段と、前記監視手段による監視結果に従って、前記例外事象の
発生を示す情報を該例外事象の発生順にキューイングす
るキューイング手段と、前記発生した例外事象の内容と、他の例外事象との相互
関係とに従って、前記例外事象の発生を示す情報の前記
制御手段への通知を所定時間待ち合わせる待ち合わせ手
段と、前記所定時間の後、前記キューイング手段に新たにキュ
ーイングされた例外事象の発生を示す情報があるかどう
かを調べ、さらに前記新たにキューイングされた例外事
象の発生を示す情報と前記待ち合わせ手段によって待ち
合わされている前記例外事象の発生を示す情報との相互
関係を解析する解析手段と、前記解析手段による解析結果に従って、前記待ち合わせ
手段によって待ち合わされている前記例外事象の発生を
示す情報の前記制御手段への通知を制御する通知制御手
段とを有することを特徴とするプリンタ装置。
【請求項２】複数の例外事象と、前記複数の例外事象
各々の事象を引き起こす元となる他の例外事象との関係
と、前記複数の例外事象各々に関し前記待ち合わせ手段
によって待ち合わせる時間とを登録する管理テーブルを
さらに有することを特徴とする請求項１に記載のプリン
タ装置。
【請求項３】前記待ち合わせ手段は、前記管理テーブ
ルを参照して他の例外事象との相互関係を調べることを
特徴とする請求項２に記載のプリンタ装置。
【請求項４】前記キューイング手段は、既に他の例外事象の発生を示す情報がキューイングされ
ているかどうかを調べる検査手段と、前記他の例外事象の発生を示す情報がキューイングされ
ている場合には、前記管理テーブルを参照して、前記例
外事象の発生を示す情報のキューイングを行なわないよ
うに制御するキューイング制御手段とを有することを特
徴とする請求項２に記載のプリンタ装置。
【請求項５】前記解析手段は、前記所定時間の間に新
たにキューイングされた例外事象の発生を示す情報と前
記待ち合わせ手段によって待ち合わされている前記例外
事象の発生を示す情報との相互関係を、前記管理テーブ
ルを参照して調べることを特徴とする請求項２に記載の
プリンタ装置。
【請求項６】前記通知制御手段は、前記待ち合わせ手
段によって待ち合わされている前記例外事象の発生を示
す情報を、前記制御手段へ通知せず削除するか、或は、
前記制御手段へ通知するかを決定することを特徴とする
請求項１に記載のプリンタ装置。
【請求項７】前記制御手段と前記画像形成手段との関
係は、クライアントとサーバとの関係のあることを特徴
とする請求項１に記載のプリンタ装置。
【請求項８】前記制御手段は前記画像形成手段にコマ
ンドを出力して画像形成指示を行い、前記画像形成手段
は前記コマンドに応答してステータスを前記制御手段に
返送することを特徴とする請求項７に記載のプリンタ装
置。
【請求項９】前記画像形成手段は、電子写真方式に従
って前記記録媒体上に画像形成を行うプリンタエンジン
であることを特徴とする請求項１に記載のプリンタ装
置。
【請求項１０】前記画像形成手段は、インクジェット
方式に従って前記記録媒体上に画像形成を行うプリンタ
エンジンであることを特徴とする請求項１に記載のプリ
ンタ装置。
【請求項１１】前記監視手段は、前記種々の例外事象
として、前記記録媒体のジャム、電源供給の停止、温度
異常、装置カバーの開放、前記画像形成手段に設けられ
たモータの異常などを監視することを特徴とする請求項
１に記載のプリンタ装置。
【請求項１２】前記制御手段は、通知される前記例外
事象の発生を示す情報に従って画像形成動作を制御する
ことを特徴とする請求項１に記載のプリンタ装置。
【請求項１３】記録媒体に画像を形成する画像形成部
と外部装置からの画像データの受信や画像形成動作の制
御を行う制御部とを有するプリンタ装置に用いられるプ
リント制御方法であって、前記画像形成部における画像形成動作の種々の例外事象
の発生を監視する監視工程と、前記監視工程における監視結果に従って、例外事象の発
生を示す情報を該例外事象の発生順にキューイングする
キューイング工程と、前記発生した例外事象の内容と、他の例外事象との相互
関係とに従って、前記例外事象の発生を示す情報の前記
制御部への通知を所定時間待ち合わせる待ち合わせ工程
と、前記所定時間の後、前記キューイング工程におけるキュ
ーに新たにキューイングされた例外事象の発生を示す情
報があるかどうかを調べ、さらに前記新たにキューイン
グされた例外事象の発生を示す情報と前記待ち合わせ工
程において待ち合わされている前記例外事象の発生を示
す情報との相互関係を解析する解析工程と、前記解析工程による解析結果に従って、前記待ち合わせ
工程において待ち合わされている前記例外事象の発生を
示す情報の前記制御部への通知を制御する通知制御工程
とを有することを特徴とするプリント制御方法。
【請求項１４】記録媒体に画像を形成する画像形成部
と外部装置からの画像データの受信や画像形成動作の制
御を行う制御部とを有するプリンタ装置に適用されるプ
リント制御を実行するプログラムコードが格納されたコ
ンピュータ可読メモリであって、前記画像形成部における画像形成動作の種々の例外事象
の発生を監視する監視工程を実行するコードと、前記監視工程における監視結果に従って、例外事象の発
生を示す情報を該例外事象の発生順にキューイングする
キューイング工程を実行するコードと、前記発生した例外事象の内容と、他の例外事象との相互
関係とに従って、前記例外事象の発生を示す情報の前記
制御部への通知を所定時間待ち合わせる待ち合わせ工程
を実行するコードと、前記所定時間の後、前記キューイング工程におけるキュ
ーに新たにキューイングされた例外事象の発生を示す情
報があるかどうかを調べ、さらに前記新たにキューイン
グされた例外事象の発生を示す情報と前記待ち合わせ工
程において待ち合わされている前記例外事象の発生を示
す情報との相互関係を解析する解析工程を実行するコー
ドと、前記解析工程による解析結果に従って、前記待ち合わせ
工程において待ち合わされている前記例外事象の発生を
示す情報の前記制御部への通知を制御する通知制御工程
を実行するコードとを有することを特徴とするコンピュ
ータ可読メモリ。