(57)【要約】【課題】エラー発生時のダウンタイム、サービスコール数、ユーザーの手間を低減しつつ、リブート後にリブート前の処理をスムーズに再開する。【解決手段】ＣＰＵ１２もしくはＤＭＡＣ１１ｂは処理対象データーをＲＡＭ１３に記憶させる際にＲＡＭ１３に記憶された処理対象データーのスタートアドレスとサイズ情報を領域レジスタ１１ｃに記憶させ、所定条件により自動リブートを行う際に、ＣＰＵ１２は上記スタートアドレスとサイズ情報に基づきＲＡＭ１３の処理対象データーを記憶された領域についてＲＡＭテストを行わずにリブートし、ＣＰＵ１２はリブート完了後に上記スタートアドレスとサイズ情報に基づき処理対象データーを特定して該処理対象データーの処理を行う。【選択図】図６
2010182001.tif 000002
【特許請求の範囲】
【請求項１】
記憶部に記憶された処理対象データーのスタートアドレスとサイズ情報を所定の記憶領域に記憶させる記憶手段と、
所定条件により自動リブートを行う際に、上記スタートアドレスとサイズ情報に基づき上記記憶部中の処理対象データーを特定して該処理対象データーを変更しないようにリブートする自動リブート手段と、
上記自動リブート手段がリブートした後で上記スタートアドレスとサイズ情報に基づき処理対象データーを特定して該処理対象データーの処理を行う処理手段とを備える画像形成装置。
【請求項２】
上記自動リブート手段は、上記サイズ情報が０でない場合には上記処理対象データーの記憶された領域を除外して上記記憶部の読み書きテストを実行し、上記サイズ情報が０の場合には上記記憶部の全領域に読み書きテストを実行する請求項１記載の画像形成装置。
【請求項３】
上記自動リブート手段は、上記サイズ情報が０でない場合には上記処理対象データーの記憶された領域を除外して上記記憶部の読み書きテストを実行し、読み書きテストの完了した領域に上記処理対象データーを移動させ、移動させた上記処理対象データーが記憶された領域について上記読み書きテストを実行する請求項１又は請求項２に記載の画像形成装置。
【請求項４】
上記記憶手段は、上記処理対象データーのページ全体について処理が完了した後で、該当するページの処理対象データーを上記記憶部から削除する請求項１〜請求項３の何れか一項に記載の画像形成装置。
【請求項５】
上記処理対象データーを上記記憶部に記憶する際に、上記処理対象データーのチェックサムを生成して上記記憶部に記憶するチェックサム生成手段を備え、
上記処理手段は、処理を行うにあたり上記チェックサムを利用して上記処理対象データーの信頼性を検証する請求項１〜請求項４の何れか一項に記載の画像形成装置。
【請求項６】
上記自動リブート手段は、発生したエラーがサービスコールを必要とし且つエラーログに記憶されていることを上記所定条件として上記自動リブートを行う請求項１〜請求項５の何れか一項に記載の画像形成装置。
【請求項７】
ＤＭＡ（Direct Memory Access）コントローラーが上記処理対象データーを上記記憶部に記憶させると共に、該ＤＭＡコントローラーが上記記憶手段と上記チェックサム生成手段を構成する請求項１〜請求項６の何れか一項に記載の画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置に関する。
【背景技術】
【０００２】
従来、印刷装置の多くの機種では、サービスコールを要するエラー発生時に、エラー内容やエラー種類を特定可能なエラー番号およびサービスセンターへの問合せを促すメッセージをパネルに表示している。また、最近の機種では、エラー発生時に電源をいったん切ってから起動し直すこと（以下、電源オフ／オンと記載する。）をパネル表示で指示することもある。これはサービスセンターへの問合せを減らして、サービスコストを削減するためである。いずれの場合でも、ユーザーはプリンターのそばに行き、パネルに表示されたエラーメッセージを確認して状況を把握し、対応を選択しなければならない。無論、ネットワークを通じてエラー内容を確認したりエラー内容が通知されたりすることもあるが、やはりユーザーは状況を把握して対応を選択しなければならないし、電源オフ／オンを指示されている場合はプリンター傍まで行って操作する必要があるのは同じである。
【０００３】
さらに、近年、ＬＡＮ（Local Area Network）やインターネット等のネットワーク上に配置可能なプリンターが増加し、ネットワーク経由でプリンターを使用することが一般的になってきている。ネットワークに接続されたプリンターは、必然的にユーザー数が多い。サービスコールを要するエラー発生からエラーが解消するまでは、プリンターの処理は行われない。すなわち、ダウンタイムの影響を受けるユーザー範囲も広くなる。
【０００４】
その一方で、サービスセンターにおいても人件費の増大に伴ってサービスセンターの維持にかかる費用は増大している。問合せには簡単な質問もあれば専門的な高度な知識を必要とするものもあるので、サービスセンターの人員は専門知識を備えていることが望ましいが、専門知識を有する人員の人件費は高く、人件費はさらに増大する。すなわち、サービスコール１本当りのコストが増大している。
【０００５】
このような実状に対応すべくなされた技術として特許文献１には、リブート対象となる故障が発生すると仕掛かり中の処理を区切りがよくリブートが安全に行える状態で停止し、各モジュールの動作抑制、動作中の処理の後始末とインターフェースの抑制を実行する画像形成装置について開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−２１９２４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記特許文献１の技術では、装置内部の状態は正常に復帰する可能性は高いが、処理途中でリブートするのでそれまでに外部デバイス等から受信したデーターはＲＡＭから消去されてしまったりＲＡＭからデーターを消去しなくともないがそのデーターを容易に再利用できなくなったりする。データーを消去する理由は、サービスコールエラーが発生した場合にはエラーが再発しないように原因を調べたり不具合を解決するためにＲＡＭをテストしたりクリアしたりするからである。外部から受信したデーター（例えばスキャンデーター等）は、装置内部のデーターからは再構築出来ないのでリブート後に外部デバイスに対してデーターの送信を要求するしかないが、外部デバイスはデーターを保持していない可能性もある。
【０００８】
本発明は、上記課題に鑑みてなされたもので、エラー発生時のダウンタイム、サービスコール数、ユーザーの手間を低減しつつ、リブート後にリブート前の処理をスムーズに再開することが可能な画像形成装置の提供を目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明の請求項１にかかる画像形成装置では、記憶手段と自動リブート手段と処理手段とを備える構成としてある。
該構成において、上記記憶手段は、記憶部に処理対象データーが記憶される状況を把握しており、記憶部に処理対象データーが記憶されるとその記憶された領域に関する情報として、スタートアドレスとサイズ情報を所定の記憶領域に記憶させる。このようにして所定の記憶領域のスタートアドレスとサイズ情報は、処理対象データーが更新されたときに更新されるし、該当する処理対象データーが画像形成装置で処理完了すると消去されたりサイズ情報を０に更新されたりする。
上記自動リブート手段は、所定条件により自動リブートを行う際に、上記所定の記憶領域から上記スタートアドレスとサイズ情報を取得して上記記憶部中の処理対象データーを特定して該処理対象データーを変更しないようにリブートし、リブートにおいて処理対象データーが失われないようにする。従って、処理手段は、上記自動リブート手段がリブートした後で上記スタートアドレスとサイズ情報に基づき処理対象データーを特定して該処理対象データーの処理を行うことが可能になる。すなわち、処理手段は、リブート後にリブート前の処理をスムーズに再開可能となる。
【００１０】
本発明の選択的な一側面として、上記自動リブート手段は、上記サイズ情報が０でない場合には上記処理対象データーの記憶された領域を除外して上記記憶部の読み書きテストを実行し、上記サイズ情報が０の場合には上記記憶部の全領域に読み書きテストを実行するようにしてもよい。すなわち、上記記憶部に処理対象データーが記憶されていないのであれば、通常通りに上記記憶部の全領域を順にテストすればよい。
【００１１】
本発明の選択的な一側面として、上記自動リブート手段は、上記サイズ情報が０でない場合には上記処理対象データーの記憶された領域を除外して上記記憶部の読み書きテストを実行し、読み書きテストの完了した領域に上記処理対象データーを移動させ、移動させた上記処理対象データーが記憶された領域について上記読み書きテストを実行するようにしてもよい。上記処理対象データーが記憶された領域に対して上記読み書きテストを実行すると上記処理対象データーが失われてしまうので、まずは、上記処理対象データーが記憶されていない領域について上記読み書きテストを実行する。次に、上記読み書きテストが完了した領域に上記処理対象データーをコピーし、コピー前に上記処理対象データーが記憶されていた領域に対して上記読み書きテストを実行する。このようにして上記記憶部の全域に対して上記読み書きテストを実行すると、リブート後のスムーズな処理再開と、画像形成装置における動作の信頼性の確保とを両立することができる。
【００１２】
本発明の選択的な一側面として、上記記憶手段は、上記処理対象データーのページ全体について処理が完了した後で、該当するページの処理対象データーを上記記憶部から削除するようにしてもよい。
例えば、レーザープリンター等のページプリンターにおいては、１ページ分の印刷データーは連続して出力しないと正常な印刷が出来ない。このような場合に、画像データー等の処理対象データーを印刷データーに変換して出力しながら出力した処理対象データーを上記記憶部から消去してしまうと、ページ半ばまで処理した時に上記所定条件となって自動リブートした場合にページ半ばまで失われたデーターだけが記憶部に残ることになる。ページプリンターは、１ページの部分的なデーターではそのページの印刷ができないので正常な印刷結果を得られない。そこで、各ページの区切りまで処理を完了するまでそのページを保持し、１ページ分の処理が完了してから該当するページの処理対象データーを上記記憶部から消去する構成にすることにより、ページ単位で画像処理を行う画像形成装置においてもスムーズに処理を再開できるようになる。
【００１３】
本発明の選択的な一側面として、上記処理対象データーを上記記憶部に記憶する際に、上記処理対象データーのチェックサムを生成して上記記憶部に記憶するチェックサム生成手段を備え、上記処理手段は、処理を行うにあたり上記チェックサムを利用して上記処理対象データーの信頼性を検証するようにしてもよい。
例えば、上記処理手段は、信頼性を検証するために、特定した上記処理対象データーのチェックサムを生成し、生成したチェックサムが上記記憶部に記憶されたチェックサムと一致する処理対象データーについて処理を行う。このようにすると、上記処理手段は、自動リブートによって処理対象データーが破損していた場合に破損したデーターで処理を再開せずに済む。無論、チェックサムの代わりに処理対象データーのＥＣＣ（Error Correcting Code）等を用いてデーターの破損を検出してもよいが、チェックサムの方がより少ない処理量とデーター量でデーターの信頼性を検証可能である。
【００１４】
本発明の選択的な一側面として、上記自動リブート手段は、発生したエラーがサービスコールを必要とし且つエラーログに記憶されていることを上記所定条件として上記自動リブートを行うようにしてもよい。
サービスコールを要するエラーとは、用紙切れやプリンターカバーのオープン等のようにユーザーの操作手順のミスによって発生したエラーを除いた全てのエラーを含んでも構わない。エラーログには発生したエラーのうちエラーが解消したものについて判別可能な記録が残るようになっている。従って、エラーログにおいてエラー解消したとの記録があるものは、リブートによってエラーが解消する可能性が極めて高いと言える。すなわち、サービスコールを要するエラーであって、エラーログに記録されたエラーが発生したときに自動リブートを行うことにより、エラー発生時のダウンタイム、サービスコール数、ユーザーの手間をより確実に低減することができる。
【００１５】
本発明の選択的な一側面として、ＤＭＡ（Direct Memory Access）コントローラーが上記処理対象データーを上記記憶部に記憶させると共に、該ＤＭＡコントローラーが上記記憶手段と上記チェックサム生成手段を構成するようにしてもよい。ＣＰＵ等の演算処理系で実行されるソフトウェア処理でデーターを記憶させる場合と比べて、ＤＭＡコントローラーのハードウェア処理で処理対象データーを上記記憶部に記憶させる方が、処理速度が速くなるし、その間はＣＰＵは他の演算処理を実行できる。また、処理対象データーを記憶部に記憶させる処理をＤＭＡコントローラーで実行するのであれば、同時にその記憶される領域情報やチェックサムも作成すると処理が高速化する。
【００１６】
なお、上述した画像形成装置は、他の機器に組み込まれた状態で実施されたり他の方法とともに実施されたりする等の各種の態様を含む。また、本発明は上記画像形成装置を備える画像形成システム、上述した装置の構成に対応した工程を有する制御方法、上述した装置の構成に対応した機能をコンピュータに実現させるプログラム、該プログラムを記録したコンピュータ読み取り可能な記録媒体、等としても実現可能である。これら画像形成システム、画像形成方法、画像形成プログラム、該プログラムを記録した媒体、の発明も、上述した作用、効果を奏する。むろん、請求項２〜７に記載した構成も、前記システムや前記方法や前記プログラムや前記記録媒体に適用可能である。
【図面の簡単な説明】
【００１７】
【図１】プリンターのハードウェア構成を示すブロック図である。
【図２】エラー監視処理のフローチャートである。
【図３】ＥＤＢの一例を示す表である。
【図４】エラーログの一例を示した表である。
【図５】起動時のエラー監視処理のフローチャートである。
【図６】ＲＡＭテスト処理のフローチャートである。
【図７】本変形例にかかるＲＡＭテスト処理のフローチャートである。
【図８】処理対象データーがＲＡＭの空き領域よりも大きい場合のＲＡＭテストを説明する図である。
【発明を実施するための形態】
【００１８】
以下、下記の順序に従って本発明の実施形態を説明する。
（１）画像形成装置の構成：
（２）エラー監視処理：
（３）起動時のエラー監視処理：
（４）ＲＡＭテスト処理：
（５）ＲＡＭテスト処理の変形例：
（６）まとめ：
【００１９】
（１）画像形成装置の構成： 
図１は、本発明の実施形態にかかる画像形成装置としてのプリンター１００のハードウェア構成を示すブロック図である。同図において、プリンター１００は、制御部（プリンターコントローラー）１０と印刷部２０とスキャナ部３０を備えている。制御部１０は、外部デバイスとしてのホストＰＣ（Personal Computer）２００と接続されており、ホストＰＣから送信された画像データーに基づきページ毎に印刷データーを生成する。また、制御部１０は、スキャナ部３０において原稿や写真等をスキャンして取得したスキャンデーターを入力され、このスキャンデーターに基づきページ毎に印刷データーを生成する。制御部１０は、生成した印刷データーを１ページ単位で印刷部２０の印刷エンジン２１に送信する。すると印刷エンジン２１は、印刷データーに従ってトナーカートリッジ、感光体ドラム、レーザ光照射機構、紙送り機構、給排紙機構等を制御して、レーザ方式の印字処理を行う。
【００２０】
制御部１０は、ＡＳＩＣ（Application Specific Integrated Circuit）１１、演算処理部としてのＣＰＵ１２、揮発性メモリーとしてのＲＡＭ１３、書き換え可能な不揮発性メモリーとしてのＲＯＭ１４、ホストインターフェース（Ｉ／Ｆ）１５、パルス幅変調回路（ＰＷＭ回路）１６、ディスプレイ１７、操作パネル１８を備えている。これら各部１１〜１８は、ＡＳＩＣ１１を介して相互通信可能に接続されている。また、スキャナ部３０もＡＳＩＣ１１に接続されており、ＡＳＩＣ１１にスキャンデーターを送信する。
【００２１】
ホストＰＣ２００から送られてきた画像データーはホストＩ／Ｆ１５に入力される。ホストＩ／Ｆ１５は、ＡＳＩＣ１１とホストＰＣ２００の間で所定のプロトコルに従ってデーター変換を行うインターフェースであり、例えばシリアル方式やパラレル方式のインターフェースである。ホストＩ／Ｆ１５は、画像データーを変換してＡＳＩＣ１１に入力する。
【００２２】
ＡＳＩＣ１１は、印刷対象の画像データーに対する画像処理や、ＡＳＩＣ１１に接続された各回路間のデーターの仲介を行うための集積回路である。ＡＳＩＣ１１は、各回路（ＣＰＵ１２、ＲＡＭ１３、ＲＯＭ１４、ホストＩ／Ｆ１５等）を制御するための回路や、画像処理回路１１ａ、ＤＭＡコントローラー（ＤＭＡＣ）１１ｂ、ＲＡＭ１３の領域レジスタ１１ｃを備える。ＡＳＩＣ１１内部の各回路は内部バスにより相互通信可能に接続されている。本実施形態においては、ＲＡＭ１３が記憶部を構成し、領域レジスタ１１ｃが所定の記憶領域を構成する。
【００２３】
ＡＳＩＣ１１に入力された画像データーやスキャンデーターはいったんＤＭＡＣ１１ｂに入力されてからＲＡＭ１３に記録される。このとき、ＣＰＵ１２は、ＤＭＡＣ１１ｂを制御することによりＣＰＵ１２を経由せずにＤＭＡＣ１１ｂから直接ＲＡＭ１３へ画像データーを転送する方式（ＤＭＡ（Direct Memory Access）方式）と、ＤＭＡＣ１１ｂから一旦画像データーを受信してからＲＡＭ１３に記録する方式と、を選択可能である。これら方式は、例えば所定のＵＩにてユーザーが操作入力を行うことにより適宜選択可能である。
【００２４】
ＤＭＡ方式の場合は、ＣＰＵ１２は、ホストＰＣ２００内部にある転送元データーのアドレスや転送先であるＲＡＭ１３のアドレス等をＤＭＡＣ１１ｂに指示し、ＤＭＡＣ１１ｂにＡＳＩＣ１１の内部バス管理の主導権を渡す。すると、ＤＭＡＣ１１ｂが、ＣＰＵ１２に代わってＡＳＩＣの内部バスに転送元アドレスと転送先アドレスを指定してホストＰＣ２００の転送データーを内部バスに開放し、メモリーに対して書き込み信号を与えることで、バス上のデーターをＲＡＭ１３の所定のアドレスに書き込む。一方、ＣＰＵ１２が主体となって画像データーをＲＡＭ１３に記録する場合は、画像データーを一旦ＣＰＵ１２のレジスタに取り込みレジスタからＲＡＭ１３に転送する。
【００２５】
ＤＭＡ方式の場合は、ＤＭＡＣ１１ｂがＲＡＭ１３に書き込んだ画像データーのスタートアドレスとサイズ情報を領域レジスタ１１ｃに記録する。一方、ＣＰＵ１２が主体となって画像データーをＲＡＭ１３に記録する場合は、ＣＰＵ１２がＲＡＭ１３に書き込んだ画像データーのスタートアドレスとサイズ情報を領域レジスタ１１ｃに記録する。無論、ＤＭＡ方式の場合にもＣＰＵ１２がＤＭＡＣ１１ｂからスタートアドレスとサイズ情報を取得して領域レジスタ１１ｃに記録してもよい。本実施形態においては、ＤＭＡＣ１１ｂもしくはＣＰＵ１２が記憶手段を構成する。
【００２６】
画像処理回路１１ａは、印刷エンジン２１が印刷可能な印刷データーを生成する。画像処理回路１１ａは、例えば、ホストＰＣ２００が生成した画像データーから印刷データーを生成し、生成した印刷データーを８ビット単位でパラレルにＰＷＭ回路１６に送信する。
ＰＷＭ回路１６は印刷エンジン２１に接続されている。ＰＷＭ回路１６は、ＡＳＩＣ１１から送信された印刷データーをＰＷＭデーターに変換して印刷エンジン２１に出力する。例えば、ＰＷＭ回路１６は、８ビットのパラレルデータ（印刷データ）が入力されるとこのデーターを１ビットのシリアルデータに変換し、順次、印刷エンジン２１に出力する。
【００２７】
画像処理回路において１ページ分の印刷データーが作成されてＰＷＭ回路１６に出力する処理が完了すると、ＣＰＵ１２は、出力処理が完了した画像データーをＲＡＭ１３から削除するとともに処理された画像データーを除いたスタートアドレスとサイズ情報で領域レジスタ１１ｃを更新する。
【００２８】
ＣＰＵ１２は、上述したデーター転送制御や領域レジスタ１１ｃの制御のみならず、ＲＯＭ１４に圧縮されて格納されている各種プログラムをＡＳＩＣ１１を介して適宜ＲＡＭ１３に展開しつつ実行することにより、制御部１０全体の制御を行う。
例えばＲＯＭ１４には、画像処理回路１１ａやＰＷＭ回路１６を制御して印刷エンジン２１に印刷を実行させるための印刷データーを生成する印刷制御プログラムＰ１、制御部１０で実行される各種プログラムにおいて発生するエラーを監視する監視プログラムＰ２、制御部１０において起動時のセルフテスト（いわゆるＰＯＳＴ（Power On Self Test）処理）を実行するためのＰＯＳＴ処理プログラムＰ３、等が予め格納されている。
【００２９】
本実施形態においては、印刷制御プログラムＰ１を実行するＣＰＵ１２が処理手段を構成し、監視プログラムＰ２とＰＯＳＴ処理プログラムＰ３を実行するＣＰＵ１２が自動リブート手段を構成する。以下、監視プログラムＰ２によりＣＰＵ１２が実行するエラー監視処理、ＰＯＳＴ処理プログラムＰ３によりＣＰＵ１２が実行するＲＡＭテスト処理について説明していく。
【００３０】
（２）エラー監視処理： 
図２はエラー監視処理のフローチャートである。エラー監視処理は、印刷装置が起動している間は常に実行されている。
【００３１】
ステップＳ１００（以下、「ステップ」の記載を省略する。）において、ＣＰＵ１２は、エラーが発生しているか否か検出する。制御部１０において実行される各プログラムは、エラー発生状況（制御・通信対象、制御内容、制御対象からの応答状況、等）に応じてエラーコードを出力する。そこで、ＣＰＵ１２は各制御プログラムの出力を監視し、エラーコードを検出した場合にはこのエラーコードを取得してＳ１０５に進む。一方、ＣＰＵ１２はエラーコードを検出しない場合にはＳ１００の処理を繰り返す。なお、本実施形態におけるエラーコードは、エラーを特定するための情報に相当する。
【００３２】
Ｓ１０５において、ＣＰＵ１２は、エラーコードとエラーデーターベース（以下、ＥＤＢと記載する。）に基づいてエラーがサービスコール（以下、ＳＣと記載する。）を必要とするか否かを判断する。ＣＰＵ１２は、エラーがＳＣを必要とする場合にはＳ１１０に進み、エラーがＳＣを必要としない場合はＳ１２５に進む。
【００３３】
図３はＲＯＭ１４に予め格納されているＥＤＢの一例を示す表である。ＥＤＢにおいては、エラーコードとエラーの概要とエラーメッセージとの対応関係が規定されている。エラーコードは、エラーの種類や内容毎に割り振られるユニークな識別コードである。エラーの概要は、エラーの内容を端的に説明したものであり、例えば、ホストＩ／Ｆ１５について実行したループバックテストにおいて応答が無いというエラーであれば、「外部機器との通信テストでエラーを検出しました。」等である。エラーメッセージは、エラーを解消するための手順を指示するメッセージであり、例えば、「電源をオフ／オンしてください。それでもエラーが解消しない場合は、サービスコールにご連絡下さい。」等のように、具体的な復旧手順が記録されている。
【００３４】
例えば、ホストＩ／Ｆ１５との通信テスト中に応答が無くてタイムアウトしてしまった場合には、制御プログラムが所定のエラーコード（例えば「0210」等）を出力する。するとＣＰＵ１２はこのエラーコード「0210」を取得するので、ＥＤＢを参照することによりエラーコード「0210」に対応するパネルメッセージ「電源をオフ／オンしてください。それでもエラーが表示される場合は、サービスコールにご連絡下さい。」を取得できる。このときＣＰＵ１２は、パネルメッセージ内にＳＣを示唆する内容（例えば「サービスコール」という文字列）を検出できるので、ＳＣが必要なエラーであると判断できる。
【００３５】
すなわち、サービスコールを要するエラーには、機械やデバイスの故障が原因で修理しない限り復帰しないもの、電源を入れなおしたりリブートをかけたりすることで動作可能になるもの、がある。後者の原因は、例えば、一時的なノイズ、特定のタイミングが重なったことによるデバイスの不具合、等である。ただし両者の区分けは確実なものではなく、実際にリブートしてみないと解消するか否かは判断しにくい。本実施形態においては、後者のエラーを確実に自動的に解消することによりダウンタイムの減少、ユーザーの手間の低減、等を実現する一方、前者のエラーについてはなるべくリブートの対象に入れないようにする。
【００３６】
一方、給紙トレイに用紙が入っている状態で給紙トレイに給紙を指示したにもかかわらず用紙が送られてこない場合には、制御プログラムが所定のエラーコード（例えば「8101」等）を出力する。するとＣＰＵ１２はこのエラーコード「8101」を取得するので、ＥＤＢを参照することによりエラーコード「8101」に対応するパネルメッセージ「紙詰まりの可能性があります。詰まった用紙を取除いてください。」を取得できる。このときＣＰＵ１２は、パネルメッセージ内にＳＣを示唆する内容（例えば「サービスコール」という文字列）が無いので、ＳＣが不要なエラーであると判断できる。
【００３７】
すなわち、サービスコールを要しないエラーには、エラーになる前のアラート、ユーザーの操作手順誤りを通知するエラー（紙サイズ、紙の向き、扉が開いている、対応していない機能の実施を指示した、等）等と言える。このようなエラーについては、ユーザーが実際に作業をしないと解消しないので、従来どおり通知する。
【００３８】
無論、エラーメッセージの内容からサービスコールの要否を判断するのではなく、ＥＤＢに予めサービスコールを必要とするか否かを示すフラグを付けておいて、ＣＰＵ１２は、このフラグの有無を判断することによりＳＣの要否を判断しても構わない。
【００３９】
さらに、ＣＰＵ１２は、サービスコールを必要とするか否かのみならず、リブートで復帰可能であるか否かも判断してもよい。例えば、ＣＰＵ１２は、エラーメッセージにおいてリブートを指示する特定する文字列の有無（例えば、「オフ／オン」等）を判断し、エラーがＳＣを必要とし且つエラーメッセージにおいてリブートを指示している場合にはＳ１１０に進み、それ以外の場合はＳ１２５に進んでもよい。無論、リブートで復帰できる可能性のあるエラー種類を予めプログラム中やＲＯＭ１４に登録しておき、該当するエラーコードが発生したか否かを判断するなどの手法も採用できる。
【００４０】
リブートで復帰する可能性のあるエラー種類としては、例えば、ホストＩ／Ｆ１５がホストＰＣ２００と通信する際に発生するネットワークエラー、ＲＯＭ１４に記録されたデーターのチェックサムエラー、ＲＡＭ１３に記録されたデーターのチェックサムエラー、外部機器との間の通信状況を確認するために実行するループバックテストにおいて応答が無い場合のループバックエラー、ＣＰＵ１２における例外処理(例えば、ＴＬＢ（Translation Lookaside Buffer）ミスによるページフォールトが発生したときの例外処理等）等である。
【００４１】
Ｓ１１０において、ＣＰＵ１２は、Ｓ１００で発生したエラーが過去に発生していて、リブートによって解消したことのあるエラーであるか否かを判断する。より具体的には、ＣＰＵ１２は、エラーコードがすでにエラーログに記録されていてエラー解消フラグが付されているか否かを判断する。ＣＰＵ１２は、エラーコードがすでにエラーログに記録されていてエラー解消フラグが付されている場合にはＳ１１５に進み、Ｓ１００で検出したエラーコードについてエラーログに記録してＳ１２０に進む。一方、ＣＰＵ１２は、エラーコードが未だエラーログに記録されていなかったり、エラーログに記録されているもののエラー解消フラグが付されていなかったりする場合にはＳ１４０に進んでＳ１００で検出したエラーコードについてエラーログに記録し、Ｓ１４５に進む。
【００４２】
図４はエラーログの一例を示した表である。同図において、エラーログは、エラー発生番号、パネルメッセージ、エラーコード、ページ数、エラー発生日時、エラー解除日時、エラー解消フラグ、で構成されている。エラー発生番号は、エラーの発生した順に自動的に割り振られる管理番号である。パネルメッセージは、上述したようにエラー発生時にディスプレイ１７に表示する文字列であり、エラーの概要やエラー発生時にユーザーが取るべき対応を指示するものである。ページ数は、エラー発生時に印刷していた印刷ジョブのページ数である。エラー発生日時は、エラーが発生した年月日と時分が記録される。エラー解除日時は、発生したエラーが解除された年月日と時分が記録される。エラーが解除された日時とはエラー状態が終了した日時である。エラー解消フラグは、発生したエラーをリブートによって解消したか否かを示すフラグである。すなわち、ＣＰＵ１２は、Ｓ１００で取得したエラーコードをエラーログから検索することによりＳ１００で発生したエラーが過去に発生しているか否かを判断できるし、エラー解消フラグを参照することによりＳ１００で発生したエラーをリブートで解消できるか否かを判断できる。
【００４３】
Ｓ１２０において、ＣＰＵ１２は、ＡＳＩＣ１１の所定のレジスタに自動リブートを行う旨の情報と、自動リブートにより中断される処理に関する情報を記録してからエラー監視処理を終了し、プリンター１００のリブートを行う。
【００４４】
Ｓ１２５において、ＣＰＵ１２は、Ｓ１００で検出したエラーコードについてエラーログに記録してＳ１３０に進む。
Ｓ１３０において、ＣＰＵ１２は、ＥＤＢを参照してエラーコードに対応するエラーメッセージをディスプレイ１７に表示してＳ１３５に進む。
Ｓ１３５において、ＣＰＵ１２は、エラーが解消したか否かを判断する。ＣＰＵ１２は、エラーが解消された場合はＳ１００に戻り、エラーが解消されていない場合はＳ１３０からの処理を繰り返す。例えば上述した紙詰まりエラーの場合であれば、給紙機構のいずれかのカバーが開閉されたことを検出すると、給紙機構に給紙動作を指示し、用紙が正常に送られたことを検出できればエラーが解消したと判断できる。
【００４５】
Ｓ１４５において、ＣＰＵ１２は、リブートするか否かを判断する。ＣＰＵ１２は、リブートする場合にはＳ１２０に進み、リブートしない場合にはＳ１５０に進む。ＣＰＵ１２は、エラー関する情報をディスプレイ１７に表示するとともにリブートするか否かの操作入力が行われたか否かを判断する。例えば、ＣＰＵ１２は、エラーコードに対応するエラーの概要をディスプレイ１７に表示するとともに、現在のエラーがリブートによって解消する可能性あることを示唆するメッセージを表示し、リブートするか否かをユーザーに選択させる。ユーザーは、操作パネル１８を操作してリブートするか否かを選択するので、ＣＰＵ１２は、操作パネル１８における操作入力に基づいてリブートの要否を判断できる。
【００４６】
Ｓ１５０において、ＣＰＵ１２は、Ｓ１３０と同様にＥＤＢを参照してエラーコードに対応するエラーメッセージをディスプレイ１７に表示してＳ１５５に進む。
Ｓ１５５において、ＣＰＵ１２は、Ｓ１３５と同様にエラーが解消したか否かを判断する。ＣＰＵ１２は、エラーが解消された場合はＳ１００に戻り、エラーが解消されていない場合はＳ１５０からの処理を繰り返す。
【００４７】
（３）起動時のエラー監視処理： 
図５は起動時のエラー監視処理のフローチャートである。
ステップＳ２００において、ＣＰＵ１２は、ＰＯＳＴ（Power On Self Test）処理を実行する。ＰＯＳＴ処理は、接続デバイスのチェックや初期化を行うプログラムであり、ＡＳＩＣ１１内の所定のレジスタを初期化したり、ＲＡＭ１３のメモリテスト（ＲＡＭテスト）を実行したり、ホストＩ／Ｆ１５に接続されているホストＰＣ２００やＡＳＩＣ１１に接続されているデバイスや内部バスに接続されたデバイスに関する情報（通信における遅延時間等）を取得したりする。
【００４８】
ステップＳ２０５において、ＣＰＵ１２は、ＰＯＳＴ処理の途中でエラーが発生したか否かを判断する。ＣＰＵ１２は、エラーを検出するとＳ２１０に進んでＳ２０５で検出したエラーコードについてエラーログに記録してＳ２１５に進む。一方、ＣＰＵ１２は、エラーを検出しない場合は直近のエラーログのエラー解消フラグにリブートによってエラーを解消した旨を示すフラグを付し、エラー監視処理のＳ１００に進む。よって、リブートによってエラーが解消された場合は、ユーザーはエラーが発生したことを意識する必要が無いし、ダウンタイムが最短時間でエラーが解消することになる。また、リブートを行う前に初めて発生したエラーであっても次に同じエラーが発生した時にはエラー解消フラグを参照することにより自動的にリブートするので、ユーザーはリブートの可否を選択する必要がなくなる。
【００４９】
Ｓ２１５において、ＣＰＵ１２は、現在の起動がＣＰＵ１２によって実行されたリブート処理（自動リブート処理）で実行されたものであるか否かを判断する。ＣＰＵ１２は、Ｓ１２０のリブートを行う際に所定のレジスタに自動リブートを実行する旨の情報を記録しているので、このレジスタを参照することにより自動リブート処理であるか否かを判断できる。ＣＰＵ１２は、自動リブートである場合はＳ２２０に進み、自動リブートで無い場合はエラー監視処理のＳ１００に進む。
【００５０】
Ｓ２２０において、ＣＰＵ１２は、自動リブートの前後で同じエラーが発生しているか否かを判断する。例えば、ＣＰＵ１２は、ＥＤＢを参照して直近の２つのエラーログが同一のエラーコードであるか否かを判断することにより、自動リブートの前後で同じエラーが発生しているか否かを判断することができる。エラー判断部は、自動リブートの前後で同じエラーが発生している場合はＳ２２５に進み、自動リブートの前後で同じエラーが発生していない場合は、自動リブートの直前に記録されたエラーログのエラー解消フラグにリブートによってエラーを解消した旨を示すフラグを付し、エラー監視処理のＳ１１０に進む。すなわち、自動リブート前に発生したエラーが既に解消して他のエラーが発生している場合には、前記エラー監視処理において自動リブートが必要であるか否かを判断することになる。よって、異なるエラーでリブートを失敗した場合においても、誤ったエラーメッセージをユーザーに提供したり、ユーザーに手間をかけさせたりすることがない。
【００５１】
Ｓ２２５において、ＣＰＵ１２は、自動リブートの原因となったエラーコードに対応するエラーメッセージをディスプレイ１７に表示してＳ２３０に進む。
Ｓ２３０において、ＣＰＵ１２は、エラーが解消したか否かを判断する。ＣＰＵ１２は、エラーが解消された場合は上述のエラー監視処理を開始し、エラーが解消されていない場合はＳ２１５からの処理を繰り返す。このとき表示されるメッセージに電源のオフ／オンを指示する部分は表示されず、エラーの内容とサービスコールに連絡するようにユーザーに指示するメッセージが表示される。なお、この時点で既にリブートによるエラーを解消出来ないことが判明しているので、ユーザーは自ら電源スイッチを操作する必要が無い。また、自動リブートが行われた場合には、ユーザーはＳ２３０において初めてエラーメッセージを見ることになる。
【００５２】
（４）ＲＡＭテスト処理： 
図６は、ＰＯＳＴ処理の一環として実行されるＲＡＭテスト処理のフローチャートである。ＲＡＭテスト処理とは、ＲＡＭ１３にデーターをライトした後そのデーターをリードしてライトデータとリードデータの一致／不一致を検出する処理である。本実施形態のＲＡＭテスト処理においては、ＰＯＳＴ処理が自動リブートによって実行されたか否かを判断し、自動リブートによってＰＯＳＴ処理が実行されている場合にはＲＡＭテスト処理の対象から処理対象データーの記憶された記憶領域を除外する。よって自動リブートによって処理対象データーが消滅するのを回避され、自動リブート前に実行されていた処理を自動リブートが完了した後に容易に再開できるようになる。以下、図６を参照しつつ、本実施形態におけるＲＡＭテスト処理の流れを説明する。
【００５３】
Ｓ４００において、ＣＰＵ１２は、現在実行されているＰＯＳＴ処理が自動リブート後のＰＯＳＴ処理であるか否かを判断する。すなわちＣＰＵ１２は、ＡＳＩＣ１１の所定のレジスタを参照して、所定のレジスタに自動リブートを行う旨の情報が記録されているか否かを判断する。ＣＰＵ１２は、自動リブートを行う旨の情報が記録されている場合にはステップＳ４０５に進み、該情報が記録されていない場合にはステップＳ４２０に進む。
【００５４】
Ｓ４２０に進むとＣＰＵ１２は、ＲＡＭの全領域に対してＲＡＭテストを実行してＲＡＭテスト処理を終了する。すなわち、手動リブート時や通常の電源投入時に実行されるＰＯＳＴ処理においては、ＲＡＭ１３の全域を対象にした通常のＲＡＭテストが実行される。なお、手動リブートとはユーザーが電源オフ／オンを行って実行するリブートである。
【００５５】
Ｓ４０５において、ＣＰＵ１２は、領域レジスタ１１ｃからスタートアドレスとサイズ情報を取得する。
Ｓ４１０において、ＣＰＵ１２は、ＲＡＭ１３に処理対象データーが記録されているか否かを判断する。すなわち、ＣＰＵ１２は領域レジスタ１１ｃから取得したサイズ情報が０であるか否かを判断する。自動リブートが発生したタイミング次第では、例えばＲＡＭ１３に転送された画像データーを全て処理し終わっていれば処理対象データーが記録されていないので、このような場合にＲＡＭ１３の一部を除外してＲＡＭテストを行う必要は無いからである。ＣＰＵ１２は、サイズ情報が０の場合にはステップＳ４２０に進み、サイズ情報が０でない場合にはステップＳ４１５に進む。
【００５６】
Ｓ４１５において、ＣＰＵ１２は、領域レジスタ１１ｃから取得したスタートアドレスとサイズ情報とに基づいて処理対象データーが記録されたＲＡＭ領域を決定し、この領域を除く領域に対してＲＡＭテストを実行する。よって、処理対象データーはＲＡＭテストによって消失せず、その後の処理において利用可能となる。Ｓ４１５が終了すると、ＣＰＵ１２は、自動リブートにより中断される処理に関する情報を参照して、自動リブート前に実行していた処理（例えば印刷処理等）を再開する。このとき、処理対象データーが自動リブート前と同じアドレスに変更されずに残っているので、ホストＰＣ２００やスキャナ部３０に画像データーやスキャンデーターの再送を要求したりすることなく処理をスムーズに再開できる。
【００５７】
（５）ＲＡＭテスト処理の変形例： 
以上説明した実施形態のＲＡＭテスト処理においては、自動リブート時のＲＡＭテストの対象から領域レジスタ１１ｃに記載された領域を除外しているが、機器の安定動作を確保する観点からは、この除外した領域についてもＲＡＭテストを行った方が好ましい。そこで、本変形例においては領域レジスタ１１ｃに記載された領域を除外してＲＡＭテストを実行した後で、処理対象データーをＲＡＭテストにて正常動作が確認された領域にコピーして処理対象データーが記録されていた領域についてもＲＡＭテストを実行する。
【００５８】
図７は、本変形例にかかるＲＡＭテスト処理のフローチャートである。同図において、Ｓ５００〜Ｓ５１０、Ｓ５２０の処理は、Ｓ４００〜Ｓ４１０，Ｓ４２０の処理と同様であるので説明を省略する。
Ｓ５１５において、ＣＰＵ１２は、領域レジスタ１１ｃから取得したスタートアドレスとサイズ情報とに基づいて処理対象データーが記録されたＲＡＭの領域を決定し、この領域を除く領域に対してＲＡＭテストを実行する。ＣＰＵ１２は、Ｓ５１５が終了するとＳ５２５に進む。
【００５９】
Ｓ５２５において、ＣＰＵ１２は、Ｓ５１５にてＲＡＭテストを完了した領域に処理対象データーを移動させ、処理対象データーが記録されていた領域にＲＡＭテストを実行する。なお、Ｓ５１５にてＲＡＭテストが完了した領域よりもＲＡＭ１３に記録されていた処理対象データーの方が大きい場合は、図８に示すような方法でＲＡＭテストを実行するとよい。
【００６０】
図８は、処理対象データーがＲＡＭの空き領域よりも大きい場合のＲＡＭテストを説明する図である。同図に示すように、［処理対象データーのサイズ］＞［ＲＡＭの空き領域］の場合には、まず、Ｓ５１５においてＲＡＭテストが完了した領域に記録可能なサイズの処理対象データーを部分的にコピーする。そして、コピー済みの処理対象データーが記録されている領域に対してＲＡＭテストを行う。この手順を順次繰り返すことにより、ＲＡＭ１３全体に対してＲＡＭテストを完了することができる。
【００６１】
Ｓ５３０において、ＣＰＵ１２は、Ｓ５２５が実行される前の位置に処理対象データーを順次書き戻す処理を行う。よって、ＲＡＭテストをＲＡＭ１３の全領域に対して行うとともに処理対象データーを変更せず、さらにＰＯＳＴ処理の後で再開される処理において処理対象データーの正しいアドレスを参照することができる。無論、処理対象データーを元の位置に書き戻す代わりに、領域レジスタ１１ｃの情報を、Ｓ５２５において移動した後の処理対象データーの領域に対応したスタートアドレスとサイズ情報とで更新しても構わない。
【００６２】
（６）まとめ： 
以上説明したように、本実施形態にかかるプリンター１００によれば、ＣＰＵ１２もしくはＤＭＡＣ１１ｂは処理対象データーをＲＡＭ１３に記憶させる際にＲＡＭ１３に記憶された処理対象データーのスタートアドレスとサイズ情報を領域レジスタ１１ｃに記憶させ、所定条件により自動リブートを行う際に、ＣＰＵ１２は上記スタートアドレスとサイズ情報に基づきＲＡＭ１３の処理対象データーを記憶された領域についてＲＡＭテストを行わずにリブートし、ＣＰＵ１２はリブート完了後に上記スタートアドレスとサイズ情報に基づき処理対象データーを特定して該処理対象データーの処理を行う。よって、自動リブートによって処理対象データーが失われずに済み、自動リブート前にＲＡＭ１３に記憶された処理対象データーに対する処理を、自動リブート後にスムーズに実行することができる。
【００６３】
なお、上記実施形態や変形例においては、以下のような変形も可能である。
ホストＰＣ２００とＡＳＩＣ１１とを接続するホストＩ／Ｆ１５は、シリアル方式のＩ／Ｆでなくパラレル方式のＩ／Ｆとすることによりリブート後の処理再開が容易になる。シリアル方式のＩ／Ｆは、プリンター１００側でデーター転送処理が停止してもホストＰＣ２００の側で把握出来ないので途中からデーター転送を再開できないが、パラレル方式のＩ／Ｆは、ホストＰＣ２００からプリンター１００へデーター転送中にプリンター１００が自動リブート処理を開始してデーター転送が停止した場合にはビジー状態になり、その後データー受信を継続することができるからである。
【００６４】
ＤＭＡＣ１１ｂやＣＰＵ１２は、画像データーやスキャンデーターをＲＡＭ１３に記録する際にチェックサムを生成し、記録する画像データーやスキャンデーターに関連付けてＲＡＭ１３に記録してもよい。この場合、画像データーやスキャンデーターのチェックサムを生成してＲＡＭ１３に記録するＤＭＡＣ１１ｂやＣＰＵ１２が、チェックサム生成手段を構成する。チェックサムを記録しておくと、上述したＲＡＭテストが終了して自動リブート前の処理を再開する際にＣＰＵ１２は、ＲＡＭ１３に残っている処理対象データーからチェックサムを生成し、ＲＡＭ１３に記録されているチェックサムと比較することによりＲＡＭテスト後にＲＡＭ１３に残っている処理対象データーの信頼性を確認できる。チェックサム生成は処理の負担が少ないので、短時間で作成できる。無論、チェックサムに限らずＥＣＣ等を用いてもよく、データーの誤りを検出できるものであれば様々なものが採用可能である。
【００６５】
なお、本発明は上述した実施形態や変形例に限られず、上述した実施形態および変形例の中で開示した各構成を相互に置換したり組み合わせを変更したりした構成、公知技術並びに上述した実施形態および変形例の中で開示した各構成を相互に置換したり組み合わせを変更したりした構成、等も含まれる。
【符号の説明】
【００６６】
１０…制御部、１１…ＡＳＩＣ、１１ａ…画像処理回路、１１ｂ…ＤＭＡＣ、１１ｃ…領域レジスタ、１２…ＣＰＵ、１３…ＲＡＭ、１４…ＲＯＭ、１５…ホストＩ／Ｆ、１６…ＰＷＭ回路、１７…ディスプレイ、１８…操作パネル、２０…印刷部、２１…印刷エンジン、３０…スキャナ部、１００…プリンター、２００…ホストＰＣ、Ｐ１…印刷制御プログラム、Ｐ２…監視プログラム、Ｐ３…ＰＯＳＴ処理プログラム
【図１】
2010182001.tif 000003
【図２】
2010182001.tif 000004
【図３】
2010182001.tif 000005
【図４】
2010182001.tif 000006
【図５】
2010182001.tif 000007
【図６】
2010182001.tif 000008
【図７】
2010182001.tif 000009
【図８】
2010182001.tif 000010