(57)【要約】【課題】搬送エラーの発生状況に応じて適切な報知を行うための技術を提供する。【解決手段】エラー回数に応じて搬送機能の正常化に必要なメンテナンスの程度を判定し（ｓ２１０，ｓ２２０）、その程度に応じて、ユーザへのメッセージ通知またはサービスセンタへのメッセージ送信により報知を行う。ここで、メッセージをユーザに通知する場合（ｓ２３０）、このメッセージで示される内容のメンテナンスで搬送機能を正常化させるべき旨をユーザに把握させることができるため、ユーザによる適切な処置を経て搬送機能を正常化させることができる。また、メッセージをサービスセンタ側へ送信する場合（ｓ２５０）、このメッセージで示される内容に応じてサービスセンタ側でメンテナンスレベルを把握することができるため、サービスマンが複合機１の設置場所へ出向いて修理することにより搬送機能を正常化させることができる。【選択図】図５
2005328374.tif 000002
【特許請求の範囲】
【請求項１】
被記録媒体を搬送する搬送手段と、
該搬送手段による被記録媒体の搬送状況を監視する状況監視手段と、
該状況監視手段により監視されている搬送状況に応じて、前記搬送手段が被記録媒体を搬送する搬送機能の正常化に必要なメンテナンスの程度を示すメンテナンスレベルを判定するレベル判定手段と、
該レベル判定手段により判定されたメンテナンスレベルに応じた態様によって、該メンテナンスレベルのメンテナンスにて前記搬送機能を正常化すべき旨を報知する報知手段と、を備えている
ことを特徴とする搬送装置。
【請求項２】
前記搬送手段による被記録媒体の搬送が正常に行われたか否かを判定するエラー判定手段を備え、
前記状況監視手段は、前記エラー判定手段により搬送が正常に行われなかったと判定されたエラー回数をカウントしており、
前記レベル判定手段は、前記状態監視手段により監視されているエラー回数に応じて異なるメンテナンスレベルであると判定する
ことを特徴とする請求項１に記載の搬送装置。
【請求項３】
前記状況監視手段は、現在までに前記エラー判定手段により搬送が正常に行われなかったと判定された累積エラー回数をカウントしており、
前記レベル判定手段は、前記状態監視手段により監視されている累積エラー回数が所定の累積しきい値より小さければ、メンテナンスレベルが第１エラーレベルであると判定する一方、前記累積エラー回数が前記累積しきい値以上であれば、メンテナンスレベルが第１エラーレベルより重度のメンテナンスが必要な第２エラーレベルであると判定する
ことを特徴とする請求項２に記載の搬送装置。
【請求項４】
前記状況監視手段は、前記累積エラー回数、および、前記エラー判定手段により搬送が正常に行われなかったと連続して判定された連続エラー回数をカウントしており、
前記レベル判定手段は、前記状態監視手段により監視されている搬送状況に基づいて、前記累積エラー回数が前記累積しきい値より小さい状態で前記連続エラー回数が所定の連続しきい値以上となった場合に、前記メンテナンスレベルが前記第１エラーレベルであると判定する
ことを特徴とする請求項３に記載の搬送装置。
【請求項５】
前記状況監視手段により監視されている連続エラー回数が前記連続しきい値に到達するまでの間、前記エラー判定手段により搬送が正常に行われなかったと判定される毎に、前記搬送手段による搬送を繰り返し再試行させる再試行手段を備えている
ことを特徴とする請求項４に記載の搬送装置。
【請求項６】
前記報知手段は、前記レベル判定手段により判定されたメンテナンスレベルが、第１エラーレベルであると判定された場合、ユーザに第１エラーレベルのメンテナンスにて搬送機能を正常化すべき旨のメッセージを通知して、
前記状況監視手段は、前記報知手段によりメッセージが通知された以降、ユーザによりメンテナンスが終了した旨の操作を受けた際に、前記連続エラー回数のカウント値をリセットする
ことを特徴とする請求項４または請求項５に記載の搬送装置。
【請求項７】
前記報知手段は、前記レベル判定手段により判定されたメンテナンスレベルが、第２エラーレベルであると判定された場合、当該搬送装置とデータ通信可能なホストコンピュータに対し、当該搬送装置が第２エラーレベルのメンテナンスにて搬送機能を正常化する必要がある旨のメッセージを送信して、
前記状況監視手段は、前記報知手段によりメッセージが送信された際、前記累積エラー回数のカウント値をリセットする
ことを特徴とする請求項３から６のいずれかに記載の搬送装置。
【請求項８】
前記レベル判定手段によりメンテナンスレベルが第２エラーレベルであると判定された際、当該搬送装置の動作を停止させる動作停止手段を備えている
ことを特徴とする請求項３から７のいずれかに記載の搬送装置。
【請求項９】
前記状況監視手段は、前記エラー判定手段により搬送が正常に行われなかったと判定された場合に、前記累積エラー回数に所定の第１の値を加算する一方、前記エラー判定手段により搬送が正常に行われたと判定された場合に、前記累積エラー回数から第１の値より小さい第２の値を減算することにより、前記累積エラー回数のカウントを行う
ことを特徴とする請求項３から８のいずれかに記載の搬送装置。
【請求項１０】
前記状況監視手段は、前記エラー判定手段により搬送が正常に行われなかったと判定された場合に、前記累積エラー回数に所定の第３の値を加算する一方、前記エラー判定手段により搬送が正常に行われたと判定された場合に、前記累積エラー回数から第３の値より大きい第４の値を減算することにより、前記累積エラー回数のカウントを行う
ことを特徴とする請求項３から８のいずれかに記載の搬送装置。
【請求項１１】
前記状況監視手段は、前記搬送手段により被記録媒体を搬送した総搬送回数をカウントしており、
前記レベル判定手段は、前記状態監視手段により監視されている前記総搬送回数が所定の搬送しきい値以上であれば、前記メンテナンスレベルが、当該搬送装置の使用状態に起因するメンテナンスが必要である消耗レベルであると判定する
ことを特徴とする請求項１から１０のいずれかに記載の搬送装置。
【請求項１２】
前記報知手段は、前記レベル判定手段により判定されたメンテナンスレベルが前記消耗レベルであると判定された場合、データ通信可能なホストコンピュータに対し、当該搬送装置が前記消耗レベルのメンテナンスにて前記搬送機能を正常化する必要がある旨のメッセージを送信して、
前記状況監視手段は、前記報知手段によりメッセージが送信された際、前記総搬送回数のカウント値をリセットする
ことを特徴とする請求項１１に記載の搬送装置。
【請求項１３】
前記レベル判定手段によりメンテナンスレベルが前記消耗レベルであると判定された場合、前記搬送機能を維持する
ことを特徴とする請求項１１または請求項１２に記載の搬送装置。
【請求項１４】
当該搬送装置外部からの指令を受けて、前記しきい値として設定される値を任意に変更可能な設定変更手段を備えている
ことを特徴とする請求項３から１３のいずれかに記載の搬送装置。
【請求項１５】
前記報知手段がホストコンピュータに対して送信するメッセージには、当該搬送装置に関する情報が含まれている
ことを特徴とする請求項６，請求項７および請求項１２のいずれかに記載の搬送装置。
【請求項１６】
前記報知手段がホストコンピュータに対して送信するメッセージには、前記状況監視手段による監視状況を示す情報が含まれている
ことを特徴とする請求項１５に記載の搬送装置。
【請求項１７】
シート状の被記録媒体を搬送する搬送手段による搬送状況を監視して、
該監視している搬送状況に応じて、前記搬送手段が被記録媒体を搬送する搬送機能の正常化に必要なメンテナンスの程度を示すメンテナンスレベルを判定して、
該判定したメンテナンスレベルに応じた態様によって、該メンテナンスレベルのメンテナンスにて前記搬送機能を正常化すべき旨を報知する
ことを特徴とする報知方法。
【請求項１８】
請求項１から１６のいずれかに記載の状況監視手段，レベル判定手段および報知手段としてコンピュータシステムを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記録用紙を搬送する搬送装置に関する。
【背景技術】
【０００２】
従来、記録用紙を搬送する搬送装置を内蔵するプリンタなどにおいては、例えば、搬送エラーなどに起因して搬送機能を正常化させるためのメンテナンスが必要になった際に、このようなトラブルの発生をユーザに通知することによって、ユーザ自身が搬送機能を正常化するためのメンテナンスを行う、サービスマンにメンテナンスを依頼する、といった処置をとることが一般的である。
【０００３】
このように、トラブルの発生をユーザに通知するための技術としては、例えば、エラー（給紙ミス）と判断される一連の動作が所定回数以上繰り返されても給紙が正常に行われない場合を搬送エラー（給紙エラー）の発生と判断し、エラーメッセージを表示するように構成されたものが提案されている（特許文献１参照）。
【０００４】
この技術であれば、ユーザは、搬送エラーが発生したことをエラーメッセージで確認できるが、この構成では、単に搬送エラーの発生を報知することしかできないため、ユーザに対し、どのような処置を経て搬送装置による搬送機能を正常化すべきか、といったことまで充分に把握させることができるとはいえない。そして、どのような処置をとるべきかを充分に把握できなかったユーザが適切な処置をとることができなければ、搬送機能を正常化させることができない。
【０００５】
そこで、適切な処置を経て搬送機能を正常化させることができるようにするために、例えば、搬送エラーの発生（給紙ローラオンから給紙センサオンまでの時間が所定時間以上となった）時に、通信回線（電話回線）を介して接続されたサービスセンタ側のホスト（パソコン３６）への通知を行う（特許文献２参照）、といった技術を利用することが考えられる。
【０００６】
このような技術を利用すれば、搬送エラーが発生したことを、搬送装置に熟知したサービスセンタのサービスマンが確認することになるため、このサービスマンが搬送装置の設置場所まで出向いて適切なメンテナンスを行うことにより、搬送装置の搬送機能を間違いなく正常化させることができる。
【特許文献１】特開２００３−０６３６７０号公報（例えば、段落［００４３］など）
【特許文献２】特開平０６−０８０２７７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、上述したように、サービスセンタ側のホストに対して通知を行う構成では、搬送機能を正常化させるのに必要なメンテナンスの程度に拘わらず、サービスセンタへの通知が行われてしまうため、サービスマンが搬送装置の設置場所へ出向く機会が不必要に多くなってしまう虞がある。
【０００８】
例えば、搬送装置は、多くの機械要素から構成されているため、周辺環境の変化や僅かなゴミの混入などによって偶発的に搬送エラーが惹き起こされる可能性があるが、この場合の搬送エラーは、例えば、給紙ローラの交換等の本質的なメンテナンスが必要ないものや、内部の清掃など容易なメンテナンスにより充分に搬送機能の正常化が可能なものであるため、サービスセンタ側への通知を行うまでもないといえる。
【０００９】
このように、従来の技術では、搬送エラーの発生状況に拘わらず画一的な報知を行うことしかできないために、例え、サービスマンの来訪が不要な場合でも結果としてサービスマンの来訪を招来することとなり、適切な報知を行うことができているとはいえなかった。
【００１０】
本発明は、この課題に対してなされたものであり、その目的は、搬送エラーの発生状況に応じて適切な報知を行うための技術を提供することである。
【課題を解決するための手段】
【００１１】
上記課題を解決するため請求項１に記載の搬送装置は、被記録媒体を搬送する搬送手段と、該搬送手段による被記録媒体の搬送状況を監視する状況監視手段と、該状況監視手段により監視されている搬送状況に応じて、前記搬送手段が被記録媒体を搬送する搬送機能の正常化に必要なメンテナンスの程度を示すメンテナンスレベルを判定するレベル判定手段と、該レベル判定手段により判定されたメンテナンスレベルに応じた態様によって、該メンテナンスレベルのメンテナンスにて前記搬送機能を正常化すべき旨を報知する報知手段と、を備えている。
【００１２】
このように構成された搬送装置によれば、被記録媒体の搬送状況に応じて搬送機能の正常化に必要なメンテナンスレベルを判定し、このメンテナンスレベルのメンテナンスにより搬送機能を正常化すべき旨を報知することができる。これにより、被記録媒体の搬送状況に応じた態様により適切な報知を行うことができる。
【００１３】
そのため、例えば、搬送状況に応じたエラーメッセージの表示により報知を行う場合であれば、エラーメッセージの内容で示されるメンテナンスレベルのメンテナンスで搬送機能を正常化（または回復）させるべき旨をユーザに把握させることができ、ユーザによる適切な処置を経て搬送機能を正常化させることができる。また、搬送状況に応じたエラーメッセージのサービスセンタ側への通知により報知を行う場合であれば、エラーメッセージの内容に応じて、サービスセンタ側でメンテナンスレベルを把握することができるため、本質的なメンテナンスが必要であると把握される場合にのみ、サービスマンが出向いて修理するようにすれば、搬送装置の設置場所へ出向く機会が不必要に多くなってしまうこともない。
【００１４】
また、この構成において、上述した状況監視手段は、例えば、搬送手段による被記録媒体の搬送が正常に行われなかったエラー回数を搬送状況として監視するように構成することが考えられる。このためには、請求項２に記載のように、前記搬送手段による被記録媒体の搬送が正常に行われたか否かを判定するエラー判定手段を備え、前記状況監視手段は、前記エラー判定手段により搬送が正常に行われなかったと判定されたエラー回数をカウントしており、前記レベル判定手段は、前記状態監視手段により監視されているエラー回数に応じて異なるメンテナンスレベルであると判定する、ように構成するとよい。
【００１５】
このように構成すれば、搬送手段により被記録媒体の搬送が正常に行われなかったエラー回数に応じてメンテナンスレベルを判定し、このレベルのメンテナンスにより搬送機能を正常化すべき旨を報知することができる。
【００１６】
なお、上述した状況監視手段により監視する具体的なエラー回数としては、例えば、エラー判定手段により搬送が正常に行われなかったと連続した判定された連続エラー回数を採用することが考えられる。また、現在までにエラー判定手段により搬送が正常に行われなかったと判定された累積エラー回数を採用することも考えられる。この累積エラー回数を監視するための構成としては、例えば、請求項３に記載のように、前記状況監視手段は、現在までに前記エラー判定手段により搬送が正常に行われなかったと判定された累積エラー回数をカウントして、前記レベル判定手段は、前記状態監視手段により監視されている累積エラー回数が所定の累積しきい値より小さければ、メンテナンスレベルが第１エラーレベルであると判定する一方、前記累積エラー回数が前記累積しきい値以上であれば、メンテナンスレベルが第１エラーレベルより重度のメンテナンスが必要な第２エラーレベルであると判定する、といった構成が考えられる。
【００１７】
このように構成すれば、累積エラー回数に応じてメンテナンスレベルを判定し、そのメンテナンスレベルのメンテナンスにより搬送機能を正常化すべき旨を報知することができる。
【００１８】
また、累積エラー回数は、現在までにエラー判定手段により搬送が正常に行われなかったと判定された回数であり、この回数が多くなるほど、搬送装置が劣化していることを示しているといえるため、搬送装置が劣化しているか否かを状況監視手段により長期的に監視することができる。
【００１９】
また、この構成においては、レベル判定手段により第１エラーレベルと判定するにあたり、エラー判定手段により搬送が正常に行われなかったと連続した判定された連続エラー回数を併せて用いるように構成してもよい。
【００２０】
このためには、例えば、請求項４に記載のように、前記状況監視手段は、前記累積エラー回数、および、前記エラー判定手段により搬送が正常に行われなかったと連続して判定された連続エラー回数をカウントしており、前記レベル判定手段は、前記状態監視手段により監視されている搬送状況に基づいて、前記累積エラー回数が前記累積しきい値より小さい状態で前記連続エラー回数が所定の連続しきい値以上となった場合に、前記メンテナンスレベルが前記第１エラーレベルであると判定する、ように構成すればよい。
【００２１】
このように構成すれば、累積エラー回数および連続エラー回数に応じてメンテナンスレベルが第１エラーレベルであると判定し、このレベルのメンテナンスにより搬送機能を正常化すべき旨を報知することができる。
【００２２】
また、連続エラー回数のみが多くなった状況は、搬送装置の劣化以外の要因、例えば、搬送装置周辺の環境変化や内部へのゴミの混入などにより、短期間の間に搬送が連続して正常に行われなかった状況と推測できる。そのため、状況監視手段で連続エラー回数を監視することによって、搬送装置の劣化以外の要因でメンテナンスが必要な状況になったか否かを短期的に監視することができる。
【００２３】
また、上述したように、連続エラー回数を監視する構成においては、請求項５に記載のように、前記状況監視手段により監視されている連続エラー回数が前記連続しきい値に到達するまでの間、前記エラー判定手段により搬送が正常に行われなかったと判定される毎に、前記搬送手段による搬送を繰り返し再試行させる再試行手段を備える、とよい。
【００２４】
このように構成すれば、連続エラー回数が連続しきい値に到達するまでの間であれば、搬送が正常に行われなかったと判定される毎に搬送手段による搬送を繰り返し再試行させることができる。
【００２５】
また、上述したように、第１エラーレベルは、第２エラーレベルよりも軽度なメンテナンスにより搬送機能を正常化させることができるメンテナンスレベルであるため、この第１エラーレベルがユーザによるメンテナンスにて搬送機能を正常化可能なメンテナンスレベルである場合には、第１エラーレベルのメンテナンスによりメンテナンスすべき旨をユーザに報知するように構成することが望ましい。
【００２６】
このためには、例えば、請求項６に記載のように、前記報知手段は、前記レベル判定手段により判定されたメンテナンスレベルが、第１エラーレベルであると判定された場合、ユーザに第１エラーレベルのメンテナンスにて搬送機能を正常化すべき旨のメッセージを通知して、前記状況監視手段は、前記報知手段によりメッセージが通知された以降、ユーザによりメンテナンスが終了した旨の操作を受けた際に、前記連続エラー回数のカウント値をリセットする、ように構成すればよい。
【００２７】
このように構成すれば、レベル判定手段により第１エラーレベルであると判定された場合に、このレベルのメンテナンスでメンテナンスすべき旨をユーザに通知することができ、ユーザによるメンテナンスを経て搬送機能を正常化することができる。
【００２８】
また、第２エラーレベルは、第１エラーレベルよりも重度なメンテナンスでなければ、搬送機能を正常化させることができないメンテナンスレベルであるため、この第２エラーレベルが重度，つまり搬送機能を正常化することが容易でないメンテナンスレベルである場合には、第２エラーレベルのメンテナンスによりメンテナンスすべき旨をサービスセンタ側に報知するように構成することが望ましい。
【００２９】
このためには、例えば、請求項７に記載のように、前記報知手段は、前記レベル判定手段により判定されたメンテナンスレベルが、第２エラーレベルであると判定された場合、当該搬送装置とデータ通信可能なホストコンピュータに対し、当該搬送装置が第２エラーレベルのメンテナンスにて搬送機能を正常化する必要がある旨のメッセージを送信して、前記状況監視手段は、前記報知手段によりメッセージが送信された際、前記第２エラー回数のカウント値をリセットする、ように構成すればよい。
【００３０】
このように構成すれば、レベル判定手段により第２エラーレベルであると判定された場合に、このレベルのメンテナンスでメンテナンスすべき旨をサービスセンタ側に通知することができ、このサービスセンタ側のサービスマンによるメンテナンスを経て搬送機能を正常化することができる。
【００３１】
また、搬送装置が、上述のように第１エラーレベルである場合にユーザへの通知を行う構成であれば、第２エラーレベルの場合にのみサービスセンタ側への報知を行うことができる。そのため、重度のメンテナンスが必要である場合にのみ、サービスマンが出向いて修理するようにすることができ、結果、搬送装置の設置場所へ出向く機会が不必要に多くなってしまうこともない。
【００３２】
また、上述したレベル判定手段によりメンテナンスレベルが第２エラーレベルであると判定された場合には、搬送装置の動作を停止させるように構成することが望ましい。第２エラーレベルは、搬送装置の劣化により発生するものであると考えられるため、搬送装置の動作を継続させてしまうと、この劣化の影響で搬送装置が異常な動作をしてしまう危険があるからである。
【００３３】
このように動作を停止させるためには、例えば、請求項８に記載のように、前記レベル判定手段によりメンテナンスレベルが第２エラーレベルであると判定された際、当該搬送装置の動作を停止させる動作停止手段を備えるとよい。
【００３４】
このように構成すれば、メンテナンスレベルが第２エラーレベルである場合、動作停止手段により搬送装置の動作を停止させることができるため、搬送装置が異常な動作をしてしまうことを防止できる。
【００３５】
また、上述した状況監視手段がエラー回数を監視するための構成については、特に限定されないが、例えば、エラー判定手段により搬送が正常に行われなかったと判定される毎に、エラー回数を加算（積算）していくように構成すればよい。
【００３６】
また、単にエラー回数を加算するだけでなく、搬送が正常に行われた際にエラー回数を減算するように構成してもよい。この場合、例えば、請求項９に記載のように、前記状況監視手段は、前記エラー判定手段により搬送が正常に行われなかったと判定された場合に、前記累積エラー回数に所定の第１の値を加算する一方、前記エラー判定手段により搬送が正常に行われたと判定された場合に、前記累積エラー回数から第１の値より小さい第２の値を減算することにより、前記累積エラー回数のカウントを行う、といった構成が考えられる。
【００３７】
このように構成すれば、搬送が正常に行われなければエラー回数が積算されていくが、搬送が正常に行われる毎にエラー回数が少しずつ減算されていくため、偶発的に発生した搬送エラーによりエラー回数が加算されたとしても、以後の搬送が数回正常に行われることで、偶発的な搬送エラーによるエラー回数の加算分，つまり偶発的な搬送エラーの影響を相殺することができる。
【００３８】
また、搬送が正常に行われた際にエラー回数を減算するように構成する場合には、請求項１０に記載のように、前記状況監視手段は、前記エラー判定手段により搬送が正常に行われなかったと判定された場合に、前記累積エラー回数に所定の第３の値を加算する一方、前記エラー判定手段により搬送が正常に行われたと判定された場合に、前記累積エラー回数から第３の値より大きい第４の値を減算することにより、前記累積エラー回数のカウントを行う、といった構成を考えることもできる。
【００３９】
このように構成すれば、搬送が正常に行われなければエラー回数が積算されていくが、搬送が正常に行われると、搬送が正常に行われなかったときの加算値よりも大きな値がエラー回数から減算されるため、搬送が正常に行われない状況が連続して発生しない限り、エラー回数が大きな値になることはない。つまり、搬送が正常に行われない状況が連続して発生し、搬送手段による搬送が正常に行えなくなったときにのみ、エラー回数が大きな値となり、これにより、レベル判定手段が第２エラーレベルであると判定することになる。よって、上述のように大きな値をエラー回数から減算するように構成することは、搬送手段による搬送が正常に行えなくなった場合のように、重度のメンテナンスが必要になったことを検出するために適しているといえる。
【００４０】
また、請求項１１に記載の搬送装置は、前記状況監視手段は、前記搬送手段により被記録媒体を搬送した総搬送回数をカウントしており、前記レベル判定手段は、前記状態監視手段により監視されている前記総搬送回数が所定の搬送しきい値以上であれば、前記メンテナンスレベルが、当該搬送装置の使用状態に起因するメンテナンスが必要である消耗レベルであると判定する、ように構成されている。
【００４１】
このように構成すれば、搬送手段による搬送が行われた回数が搬送しきい値以上になった際に、メンテナンスレベルが消耗レベルであると判定し、その旨を報知することができる。そのため、「搬送しきい値」を、例えば、搬送手段による被記録媒体の搬送が正常に行える枚数に設定しておくことにより、使用状態によって消耗した構成要素，例えば、給紙ローラ等の部品や搬送用のモータ等を交換する等のメンテナンスが必要である旨を報知することができる。
【００４２】
また、このような消耗レベルは、ユーザによるメンテナンスでは搬送機能を正常化させることは困難であると考えられるため、請求項１２に記載のように、前記報知手段は、前記レベル判定手段により判定されたメンテナンスレベルが前記消耗レベルであると判定された場合、データ通信可能なホストコンピュータに対し、当該搬送装置が前記消耗レベルのメンテナンスにて前記搬送機能を正常化する必要がある旨のメッセージを送信して、前記状況監視手段は、前記報知手段によりメッセージが送信された際、前記総搬送回数のカウント値をリセットする、ように構成するとよい。
【００４３】
このように構成すれば、レベル判定手段により消耗レベルであると判定された場合に、このレベルのメンテナンスでメンテナンスすべき旨をサービスセンタ側に通知することができ、このサービスセンタ側のサービスマンによるメンテナンスを経て搬送機能を正常化することができる。
【００４４】
なお、上述したレベル判定手段によりメンテナンスレベルが消耗レベルであると判定された場合は、搬送が行われた回数が多くなっただけで、搬送手段による搬送が直ちに行えなくなる訳ではない。そのため、請求項１３に記載のように、前記レベル判定手段によりメンテナンスレベルが前記消耗レベルであると判定された場合、前記搬送機能を維持する、ように構成すればよい。
【００４５】
このように構成すれば、メンテナンスレベルが消耗レベルである場合であっても、搬送装置の動作は停止することはないため、搬送手段による搬送を継続的に行うことができ、ユーザまたはサービスマンによる任意のタイミングでメンテナンスを行えるようにすることができる。
【００４６】
また、上述した累積しきい値，連続しきい値，搬送しきい値については、あらかじめ定められた値としておけばよいが、任意の値に変更できるように構成してもよい。この後者の場合には、請求項１４に記載のように、当該搬送装置外部からの指令を受けて、前記しきい値として設定される値を任意に変更可能な設定変更手段を備えるとよい。
【００４７】
このように構成すれば、各しきい値を外部からの指令により任意の値に変更することができる。
また、上述したように、ホストコンピュータにメッセージを送信することにより報知を行う構成において、このメッセージについては、レベル判定手段により判定されたメンテナンスレベルのメンテナンスにて搬送機能を正常化すべき旨が示されていればよいが、その他の情報が含まれていてもよい。
【００４８】
例えば、請求項１５に記載のように、前記報知手段がホストコンピュータに対して送信するメッセージには、当該搬送装置に関する情報が含まれている、とよい。この場合、サービスセンタ側では、メンテナンスにより搬送機能を正常化すべき旨の他、メッセージに含まれる情報により搬送装置がどのようなものであるかについても把握することができ、より適切なメンテナンスに役立てることができる。
【００４９】
より具体的な情報の内容としては、請求項１６に記載のように、前記状況監視手段による監視状況を示す情報が含まれている、とよい。この場合、サービスセンタ側では、メンテナンスにより搬送機能を正常化すべき旨の他、メッセージに含まれる情報により搬送装置の搬送状況についても把握することができる。
【００５０】
また、請求項１７に記載の報知方法は、シート状の被記録媒体を搬送する搬送手段による搬送状況を監視して、該監視している搬送状況に応じて、前記搬送手段が被記録媒体を搬送する搬送機能の正常化に必要なメンテナンスの程度を示すメンテナンスレベルを判定して、該判定したメンテナンスレベルに応じた態様によって、該メンテナンスレベルのメンテナンスにて前記搬送機能を正常化すべき旨を報知する、ことを特徴とする。
【００５１】
このような方法により報知を行う場合、請求項１から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
また、この報知方法においては、搬送手段による被記録媒体の搬送が正常に行われたか否かを判定すると共に、この判定により搬送が正常に行われなかったと判定されたエラー回数をカウントしておき、このエラー回数に応じて異なるメンテナンスレベルであると判定する、ようにすればよい。この場合、請求項２から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００５２】
また、この報知方法においては、現在までに搬送が正常に行われなかったと判定された累積エラー回数をカウントしておき、この累積エラー回数が所定の累積しきい値より小さければ、メンテナンスレベルが第１エラーレベルであると判定する一方、累積エラー回数が前記累積しきい値以上であれば、メンテナンスレベルが第１エラーレベルより重度のメンテナンスが必要な第２エラーレベルであると判定する、ようにするとよい。この場合、請求項３から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００５３】
また、この報知方法においては、累積エラー回数、および、搬送が正常に行われなかったと連続して判定された連続エラー回数をカウントしておき、累積エラー回数が累積しきい値より小さい状態で連続エラー回数が所定の連続しきい値以上となった場合に、メンテナンスレベルが第１エラーレベルであると判定する、ようにしてもよい。この場合、請求項４から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００５４】
また、この報知方法においては、連続エラー回数が連続しきい値に到達するまでの間、搬送が正常に行われなかったと判定される毎に、搬送手段による搬送を繰り返し再試行させるようにするとよい。この場合、請求項５から請求項１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００５５】
また、連続エラー回数を監視する場合には、メンテナンスレベルが第１エラーレベルであると判定された場合、ユーザに連続エラーレベルのメンテナンスにて搬送機能を正常化すべき旨のメッセージを通知して、このメッセージを通知した以降、ユーザによりメンテナンスが終了した際に、連続エラー回数のカウント値をリセットする、ようにするとよい。この場合、請求項６から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００５６】
また、第１，第２エラーレベルであると判定する場合には、メンテナンスレベルが第２エラーレベルであると判定された場合、ホストコンピュータに対し、第２エラーレベルのメンテナンスにて搬送機能を正常化する必要がある旨のメッセージを送信して、このメッセージを送信した際、累積エラー回数のカウント値をリセットする、ようにするとよい。この場合、請求項７から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００５７】
また、メンテナンスレベルが前記第２エラーレベルであると判定された際には、搬送手段による搬送に係る動作を停止させるようにするとよい。この場合、請求項８から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００５８】
また、累積エラー回数のカウントを行う場合には、搬送が正常に行われなかったと判定された場合に、累積エラー回数に所定の第１の値を加算する一方、搬送が正常に行われたと判定された場合に、累積エラー回数から第１の値より小さい第２の値を減算することにより、累積エラー回数のカウントを行う、ようにするとよい。この場合、請求項９，１１から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００５９】
同様に、累積エラー回数のカウントを行う場合には、搬送が正常に行われなかったと判定された場合に、累積エラー回数に所定の第３の値を加算する一方、搬送が正常に行われたと判定された場合に、累積エラー回数から第３の値より大きい第４の値を減算することにより、累積エラー回数のカウントを行う、ようにしてもよい。この場合、請求項１０から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００６０】
また、上述の各報知方法においては、搬送手段により被記録媒体を搬送した総搬送回数をカウントしておき、この総搬送回数が所定の搬送しきい値以上であれば、メンテナンスレベルが、搬送手段の使用状態に起因するメンテナンスが必要である消耗レベルであると判定する、ようにするとよい。この場合、請求項１１から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００６１】
また、この報知方法においては、メンテナンスレベルが消耗レベルであると判定された場合、ホストコンピュータに対し、消耗レベルのメンテナンスにて搬送機能を正常化する必要がある旨のメッセージを送信して、このメッセージを送信した際、総搬送回数のカウント値をリセットする、ようにしてもよい。この場合、請求項１２から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００６２】
また、この報知方法では、メンテナンスレベルが前記消耗レベルであると判定された場合、搬送機能による搬送が実現可能な状態を維持する、こととするとよい。この場合、請求項１３から１６のいずれかに記載の搬送装置と同様の作用，効果を得ることができる。
【００６３】
また、請求項１８に記載のプログラムは、請求項１から１６のいずれかに記載の状況監視手段，レベル判定手段および報知手段としてコンピュータシステムを機能させるためのプログラムである。このようなプログラムにより制御されるコンピュータシステムは、請求項１から１６のいずれかに記載の搬送装置の一部を構成することができる。
【００６４】
また、このプログラムにおいては、さらに、請求項２から１６のいずれかに記載のエラー判定手段としてコンピュータシステムを機能させるためのプログラムとしてもよい。この場合、コンピュータシステムを、請求項２から１６のいずれかに記載の搬送装置の一部を構成することができる。
【００６５】
また、これらプログラムにおいては、さらに、請求項５から１６のいずれかに記載の再試行手段としてコンピュータシステムを機能させるためのプログラムとしてもよい。この場合、コンピュータシステムは、請求項５から１６のいずれかに記載の搬送装置の一部を構成することができる。
【００６６】
また、これらプログラムにおいては、さらに、請求項８から１６のいずれかに記載の動作停止手段としてコンピュータシステムを機能させるためのプログラムとしてもよい。この場合、コンピュータシステムは、請求項８から１６のいずれかに記載の搬送装置の一部を構成することができる。
【００６７】
また、これらプログラムにおいては、請求項１４から１６のいずれかに記載の設定変更手段としてコンピュータシステムを機能させるためのプログラムとしてもよい。この場合、コンピュータシステムは、請求項１４から１６のいずれかに記載の搬送装置の一部を構成することができる。
【００６８】
なお、これらのプログラムは、コンピュータによる処理に適した命令の順番付けられた列からなるものであって、例えば、ＦＤ，ＣＤ−ＲＯＭ，メモリーカードなどの記録媒体、インターネットなどの通信回線網を介して、コンピュータシステム，または，コンピュータシステムを利用するユーザに提供されるものである。なお、このプログラムをユーザに提供する場合には、コンピュータシステムのハードディスクやメモリにプレインストールされた状態で提供する形態であってもよい。また、このプログラムを実行するコンピュータシステムとしては、例えば、搬送装置に搭載されたコンピュータシステム，搬送装置とデータ通信可能な他のコンピュータなどが利用できる。
【発明を実施するための最良の形態】
【００６９】
以下に本発明の実施形態を図面と共に説明する。
複合機１は、ファクシミリ機能，プリンタ機能，複写機能，スキャナ機能などを有する装置であって、図１に示すように、筐体２の上面に配置された各種キーからなる操作パネル３，操作パネル３の後側に配置された液晶ディスプレイからなる表示部４，表示部４の後側に配置された原稿セット部５，筐体２の前側に配置されている記録排紙トレイ６，記録排紙トレイ６の上部に配置されている読取排紙トレイ７，原稿セット部５の後側に配置された給紙装置１０などを備えている。
【００７０】
給紙装置１０は、図２に示すように、シート状の記録用紙を収納する収納部１２，収納部１２に収納される記録用紙の下端部側に位置する媒体保持部１４，収納部１２に収納された記録用紙を給紙方向（図２における矢印Ａの方向）へ搬送する給紙ローラユニット１６などからなり、収納部１２に収納された記録用紙の下端部と媒体保持部１４との摩擦によって、収納部１２から記録用紙を１枚ずつ抽出して給紙を行う装置である。
【００７１】
この給紙装置１０では、図３に示すように、給紙ローラユニット１６における給紙ローラ１６ａを回転させることによって、収納部１２にセットされた記録用紙のうち、最上部の記録用紙Ｐを、媒体保持部１４に押しつける方向へ搬送する。これにより、この記録用紙Ｐは、その曲がりやすさに応じて突出部材２０の突出部２２を下端部で押し下げながら、突出部２２に沿って搬送方向へ徐々に変位していく。そして、この記録用紙Ｐは、その下端部が媒体保持部１４の上面１４ａに接触するまで突出部２２に沿って変位した後、この上面１４ａに沿った方向，つまり給紙方向へ搬送されていくことになる。
【００７２】
また、複合機１は、図４に示すように、複合機１全体の動作を制御するＣＰＵ１１２，ＣＰＵ１１２による処理手順などを記憶するＲＯＭ１１４，ＣＰＵ１１２による処理結果などを記憶するＲＡＭ１１６，各種機能における設定内容などを記憶するＥＥＰＲＯＭ（Electrically Erasable Programmable Read-only Memory ）１１８，給紙装置１０の動作を制御する給紙制御回路１２０，記録用紙からの画像の読み取りを行うスキャナ部１２２，記録用紙への画像の形成を行うプリンタ部１２４，複合機１を通信回線網Ｎへ接続する通信制御部１２６などをバス１２８にて接続することにより制御系統を構成している。
【００７３】
このように構成された複合機１について、それぞれ処理内容の異なる複数の実施形態を順に説明する。なお、本発明は、以下に示す実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態をとり得ることはいうまでもない。
［第１実施形態］
以下に、ＣＰＵ１１２が給紙装置１０に給紙を行わせる動作，即ち画像形成処理の処理手順を図５に基づいて説明する。
【００７４】
まず、変数「Retry 」がリセット（Retry ←０）される（ｓ１１０）。この変数「Retry 」は、給紙装置１０に連続して給紙エラーが発生した回数（連続エラー回数）を積算する変数としてＲＡＭ１１６内の所定の記憶領域に記憶されるものである。
【００７５】
次に、給紙装置１０に記録用紙がセットされているか否かがチェックされる（ｓ１２０）。ここでは、給紙装置１０に設けられた用紙検出センサ（不図示）からの検出結果によって、給紙装置１０に記録用紙がセットされているか否かが判定される。なお、この用紙検出センサにより記録用紙の有無を判定するための構成については、周知であるため詳細な説明は省略する。
【００７６】
このｓ１２０の処理で、記録用紙がセットされていないと判定されれば（ｓ１２０：ＮＯ）、給紙装置１０へ記録用紙をセットすべき旨が報知された後（ｓ１３０）、記録用紙のセットを終了した旨の操作が操作パネル３により行われるまでｓ１３０の処理が繰り返し実行される（ｓ１４０：ＮＯ）。このｓ１３０の処理では、記録用紙の補給が必要である旨のメッセージ「用紙をセットして下さい」を、表示部４に表示させることにより報知が行われる。
【００７７】
この後、記録用紙のセットが終了した旨の操作が行われた場合（ｓ１４０：ＹＥＳ）、または、上述したｓ１２０の処理で記録用紙がセットされていた場合（ｓ１２０：ＹＥＳ）、給紙制御回路１２０を介して給紙装置１０の給紙動作が実行される（ｓ１５０）。ここでは、給紙装置１０の給紙ローラユニット１６によって、収納部１２にセットされた最上部の記録用紙を給紙方向へ搬送する（図３参照）。
【００７８】
次に、給紙エラーが発生しているか否かがチェックされる（ｓ１６０）。ここでは、ｓ１５０の処理で給紙装置１０に給紙動作を開始させてから所定時間以内に、プリンタ部１２４に設けられた給紙検出センサ（不図示）により記録用紙の搬送が検出されなければ、プリンタ部１２４まで記録用紙が正常に搬送されてきていないこととなるため、給紙エラーが発生していると判定する。なお、この給紙検出センサにより判定するための構成については、周知であるため詳細な説明は省略する。
【００７９】
このｓ１６０の処理で、給紙エラーが発生していないと判定された場合（ｓ１６０：ＮＯ）、プリンタ部１２４まで搬送されてきた記録用紙に対する画像の形成をプリンタ部１２４に実行させる（ｓ１７０）。ここでは、プリンタ部１２４によって、搬送されてきた記録用紙への画像の形成が行われ、更に記録用紙は記録排紙トレイ６まで搬送される。
【００８０】
この後、次のページとして形成すべき画像が存在すれば（ｓ１８０：ＹＥＳ）、ｓ１１０の処理へ戻って次のページに対する本画像形成処理を実行する一方、次のページとして形成すべき画像が存在しなければ（ｓ１８０：ＮＯ）、本画像形成処理を終了する。
【００８１】
また、上述したｓ１６０の処理で、給紙エラーが発生したと判定された場合（ｓ１６０：ＹＥＳ）、変数「Retry 」が１だけインクリメント（Retry ←Retry ＋１）され（ｓ１９０）、変数「Count 」も１だけインクリメント（Count ←Count ＋１）される（ｓ２００）。この変数「Count 」は、給紙装置１０に給紙エラーが発生した回数（累積エラー回数）を積算する変数としてＥＥＲＯＭ１１８内の所定の記憶領域に記憶された変数であって、初期設定（工場出荷時）において「０」がセットされている。
【００８２】
次に、変数「Count 」が所定のしきい値（本実施形態においては３０回）Ｋに到達している（Count ＝Ｋ）か否かがチェックされる（ｓ２１０）。
このｓ２１０の処理で、変数「Count 」が所定のしきい値Ｋに到達していないと判定されれば（ｓ２１０：ＮＯ）、変数「Retry 」が「最大リトライ回数Ｌ（本実施形態においては、３回）」に到達している（Retry ＝Ｌ）か否かがチェックされる（ｓ２２０）。
【００８３】
このｓ２２０の処理で、最大リトライ回数Ｌに到達していないと判定されれば（ｓ２２０：ＮＯ）、ｓ１５０の処理へ戻って給紙動作が繰り返される。一方、最大リトライ回数Ｌに到達したと判定されれば（ｓ２２０：ＹＥＳ）、給紙装置１０の給紙ローラユニット１６（給紙ローラ１６ａ）を清掃すべき旨が報知される（ｓ２３０）。このｓ２３０の処理では、給紙ローラユニット１６の清掃が必要である旨のメッセージ「給紙ローラを清掃して下さい」を、表示部４に表示させることにより報知が行われる。このように、本実施形態においては、給紙エラーの発生した累積回数（変数「Count 」）が少ない（しきい値Ｋに到達していない）ときに、連続して給紙エラーの発生した回数（変数「Retry 」）が最大リトライ回数Ｌに到達した状況を、給紙ローラユニット１６を清掃する程度（メンテナンスレベル）のメンテナンスで記録用紙を搬送する搬送機能を正常化（または回復）させることができる状態であると判定し、給紙ローラユニット１６を清掃すべき旨が報知される。
【００８４】
この報知が行われた後、給紙ローラユニット１６の清掃を終了した旨の操作が操作パネル３により行われるまでｓ２３０の処理が繰り返し実行され（ｓ２４０：ＮＯ）、この操作が行われたら（ｓ２４０：ＹＥＳ）、ｓ１１０の処理へ戻って、本画像形成処理が最初から繰り返される。
【００８５】
また、上述したｓ２１０の処理で、変数「Count 」が所定のしきい値Ｋに到達したと判定されれば（ｓ２１０：ＹＥＳ）、給紙装置１０のメンテナンスが必要である旨が報知される（ｓ２５０）。ここでは、給紙装置１０のメンテナンスが必要である旨のメッセージを、サービスセンタ側のホストコンピュータに自動的に送信することにより報知が行われる。なお、このメッセージには、本複合機１および給紙装置１０の製造番号（またはロット番号），変数「Count 」の値，変数「Retry 」の値なども含まれており、サービスセンタ側では、これら情報に基づいて複合機１において搬送機能を正常化するのに必要なメンテナンスの程度（メンテナンスレベル）を特定することができる。また、本複合機１および給紙装置１０の製造番号（またはロット番号）がメッセージに含まれているので、給紙エラーの発生する頻度の高い製造番号（またはロット番号）を統計的に認識することができ、サービスセンタ側は今後の対策に生かすことができる。
【００８６】
そして、変数「Count 」がリセット（Count←０）され（ｓ２６０）、給紙装置１０の動作が停止された後（ｓ２７０）、本画像形成処理は終了される。このように、本実施形態においては、給紙エラーの発生した累積回数（変数「Count 」）が多くなった（しきい値Ｋに到達していない）状況を、給紙ローラユニット１６の交換等といった重度のメンテナンスでなければ搬送機能を正常化させることができない状況であると判定し、給紙装置１０のメンテナンスが必要である旨のメッセージをサービスセンタ側のホストコンピュータに送信している。
［第１実施形態の効果］
このように構成された複合機１の給紙装置１０によれば、図５におけるｓ２１０，ｓ２２０の処理により搬送機能の正常化に必要なメンテナンスの程度（メンテナンスレベル）を判定し、このメンテナンスレベルに応じて、ユーザへのメッセージの通知，または，サービスセンタ側へのメッセージの送信により報知を行うことができる。これにより、ｓ２１０，ｓ２２０の処理で判定される記録用紙の搬送状況に応じた態様により適切な報知を行うことができる。
【００８７】
ここで、例えば、同図ｓ２３０の処理でメッセージをユーザに通知する場合であれば、このメッセージで示される内容のメンテナンスで搬送機能を正常化させるべき旨をユーザに把握させることができるため、ユーザによる適切な処置を経て搬送機能を正常化させることができる。また、同図ｓ２５０の処理でメッセージのサービスセンタ側へ送信する場合であれば、このメッセージで示される内容に応じてサービスセンタ側でメンテナンスレベルを把握することができるため、サービスマンが複合機１の設置場所へ出向いて修理することにより搬送機能を正常化させることができる。
【００８８】
また、図５の画像形成処理においては、ｓ２１０，ｓ２２０の処理で給紙エラー（累積エラー回数および連続エラー回数）の発生回数に応じてメンテナンスレベルを判定し、そのメンテナンスレベルのメンテナンスにより搬送機能を正常化すべき旨を同図ｓ２３０，ｓ２５０の処理で報知することができる。
【００８９】
また、図５における画像形成処理においては、ｓ２１０の処理で累積エラー回数に応じてメンテナンスレベルを判定している。この累積エラー回数は、現在までに給紙エラーが発生した累積回数であり、この回数が多くなるほど、給紙装置１０が劣化していることを示しているといえるため、給紙装置１０が劣化しているか否かを累積エラー回数に基づいて長期的に監視することができる。
【００９０】
また、図５における画像形成処理においては、ｓ２２０の処理で連続エラー回数に応じてメンテナンスレベルを判定している。この連続エラー回数のみが多くなった状況は、給紙装置１０の劣化以外の要因、例えば、複合機１周辺の環境変化や内部へのゴミの混入などにより、短期間の間に搬送が連続して正常に行われなかった状況であると推測できる。そのため、ｓ２２０の処理で連続エラー回数をチェックすることによって、給紙装置１０の劣化以外の要因でメンテナンスが必要な状況になったか否かを短期的に監視することができる。
【００９１】
また、図５におけるｓ２２０の処理で変数Retryがしきい値Ｌに到達していない場合には、同図ｓ１５０の処理へ戻って給紙動作をやり直すように構成されているため、変数Retryがしきい値Ｌに到達するまでの間であれば、給紙エラーが発生する毎に給紙動作を繰り返し再試行させることができる。
【００９２】
また、図５における画像形成処理においては、累積エラー回数が多くなった場合，つまり本質的なメンテナンスでなければ搬送機能を正常化させることができない状況のときにのみ、ｓ２５０の処理で給紙装置１０のメンテナンスが必要である旨のメッセージをサービスセンタ側へ送信している。そのため、重度のメンテナンスが必要である場合にのみ、サービスマンが出向いて修理するようにすることができ、結果、サービスマンが複合機１の設置場所へ出向く機会が不必要に多くなってしまうことがない。
【００９３】
また、図５における画像形成処理においては、累積エラー回数が多くなった場合には、同図ｓ２７０の処理で給紙装置１０の動作を停止させている。累積エラー回数が多くなった状況は、重度のメンテナンスでなければ搬送機能を正常化させることができない状況であるため、給紙装置１０の動作を継続させてしまうことにより、給紙装置１０が異常な動作をしてしまう危険がある。よって、本実施形態のように、給紙装置１０の動作を停止させることは、給紙装置１０が異常な動作をしてしまうことを防止するために好適である。
【００９４】
また、図５におけるｓ２５０の処理で送信されるメッセージには、本複合機１および給紙装置１０の製造番号，変数「Count 」の値，変数「Retry 」の値などが含まれている。そのため、サービスセンタ側では、メンテナンスにより搬送機能を正常化すべき旨の他、メッセージに含まれる情報により複合機１または給紙装置１０がどのようなものであるか，どのような使用状況であるのかについても把握することができ、より適切なメンテナンスに役立てることができる。また、本複合機１および給紙装置１０の製造番号（またはロット番号）がメッセージに含まれているので、給紙エラーの発生する頻度の高い製造番号（またはロット番号）を統計的に認識することができ、サービスセンタ側は今後の対策に生かすことができる。
［第２実施形態］
本実施形態における複合機１は、画像形成処理の一部が第１実施形態と異なっているだけであるため、その相違点についてのみ説明する。
【００９５】
本実施形態における画像形成処理では、図６に示すように、まず、ｓ２００の処理で変数「Count 」に所定の加算値αが加算（Count ←Count ＋α）される（ｓ２００）。この加算値αは、本実施形態においては「２」であり、「１」よりも大きな値が望ましい。
【００９６】
また、ｓ１７０の処理で画像の形成がプリンタ部１２４により実行された後、変数「Retry 」が「０」であるか否かがチェックされる（ｓ１７１）。
このｓ１７１の処理で、変数「Retry 」が「０」でなければ（ｓ１７１：ＮＯ）、変数「Count 」が後述する減算値β（本実施形態においては「１」）以上であるか否かがチェックされ（ｓ１７２）、変数「Count 」が減算値β以上であれば（ｓ１７２：ＹＥＳ）、変数「Count 」から所定の減算値βが減算（Count ←Count −β）された後で（ｓ１７４）、ｓ１８０の処理が実行される。一方、ｓ１７２の処理で、変数「Count 」が減算値β以上でなければ（ｓ１７２：ＮＯ）、変数「Count 」に「０」がセット（Count ←０）された後で（ｓ１７３）、ｓ１８０の処理が実行される。この減算値βは、本実施形態においては「１」であるが、上述の加算値αよりも小さな値であれば、「１」以外の値でもよい。
【００９７】
一方、ｓ１７１の処理で変数「Retry 」が「０」であれば（ｓ１７１：ＹＥＳ）、変数「Count 」からの減算が行われることなくｓ１８０の処理が実行される。
このように、本実施形態においては、ｓ１７１の処理で変数「Retry 」が「０」でない場合，つまり本画像形成処理の実行中に給紙エラーが発生していた場合にのみ、変数「Count 」から減算値βが減算される。
［第２実施形態の効果］
このように構成された複合機１の給紙装置１０においては、第１実施形態と同様の構成から得られる作用，効果の他に、以下に示すような作用，効果を得ることができる。
【００９８】
この給紙装置１０では、給紙エラーが発生すれば図５におけるｓ２００の処理で累積エラー回数（変数「Count 」の値）が積算されていくが、給紙が正常に行われる毎に、同図ｓ１７４の処理で累積エラー回数が少しずつ減算されていく。そのため、偶発的に発生した給紙エラーにより累積エラー回数が加算されていたとしても、以後の給紙が数回正常に行われることで、偶発的な給紙エラーによる累積エラー回数の加算分，つまり偶発的な搬送エラーの影響を相殺することができる。
【００９９】
また、図６におけるｓ２００の処理で変数「Count 」に加算される加算値αは、第１実施形態での加算値「１」よりも大きな値（α＝２）であるため、同じように給紙エラーが発生する状況であれば、第１実施形態の構成と比べて変数「Count 」の値がしきい値Ｋに到達するタイミングが早くなる。そのため、本実施形態の構成であれば、給紙装置１０に実質的な不具合が生じたことに起因して累積エラーが多発するようになった場合には、第１実施形態の構成よりも早期に、ｓ２５０の処理によるサービスセンタ側への報知を行うことができる。この効果は、加算値αの値が大きいほど顕著である。
［第３実施形態］
本実施形態における複合機１は、画像形成処理の一部が第１実施形態と異なっているだけであるため、その相違点についてのみ説明する。
【０１００】
本実施形態における画像形成処理では、図７に示すように、まず、ｓ１５０の処理の後、変数「Total 」が１だけインクリメントされ（ｓ１５２）、ｓ１６０の処理が実行される。この変数「Total 」は、給紙装置１０により給紙を行った総給紙回数を積算する変数としてＥＥＲＯＭ１１８内の所定の記憶領域に記憶された変数であって、初期設定（工場出荷時）において「０」がセットされている。
【０１０１】
また、ｓ２１０の処理で「ＮＯ」と判定された際、変数「Total 」が所定のしきい値Ｊ（本実施形態においては、１００，０００）以上（Total≧Ｊ）の値になっているか否かをチェックする（ｓ２１２）。
【０１０２】
このｓ２１２の処理で、変数「Total 」がしきい値Ｊ以上の値になっていないと判定されれば（ｓ２１２：ＮＯ）、ｓ２２０の処理へ移行する一方、変数「Total 」がしきい値Ｊ以上の値になっていると判定されれば（ｓ２１２：ＹＥＳ）、給紙装置１０のメンテナンスが必要である旨が報知される（ｓ１８４）。その後、変数「Total 」がリセット（Total ←０）され（ｓ１８６）、本画像形成処理が終了する。ここでは、図５におけるｓ２５０の処理と同様に、サービスセンタ側のホストコンピュータにメッセージを送信することにより報知が行われる。また、変数「Total 」がしきい値Ｊ以上の値になっている場合には、給紙の行われた回数が多くなっただけで、給紙装置１０による給紙が直ちに行えなくなる訳ではないため、ｓ２１２の処理で変数「Total 」がしきい値Ｊ以上の値になっていると判定されたときには、給紙装置１０の動作は停止されることなく本画像形成処理が終了される。
【０１０３】
また、ｓ１８０の処理で「ＮＯ」と判定された場合、ｓ２１２の処理と同様、変数「Total 」がしきい値Ｊ以上の値になっているか否かがチェックされ（ｓ１８２）、変数「Total 」がしきい値Ｊ以上の値になっていないと判定されれば（ｓ１８２：ＮＯ）、本画像形成処理は終了されるが、変数「Total 」がしきい値Ｊ以上の値になっていると判定されれば（ｓ１８２：ＹＥＳ）、ｓ１８４の処理が実行される。
【０１０４】
このように、本実施形態においては、総給紙回数（変数「Total 」）が多くなった（しきい値Ｊに到達した）状況が、消耗した給紙ローラユニット１６の部品を交換するなどといった程度（メンテナンスレベル）のメンテナンスで記録用紙を搬送する搬送機能を正常化（または回復）させる必要がある状況として判定され、給紙装置１０のメンテナンスが必要である旨のメッセージが送信される。
【０１０５】
また、ｓ２６０の処理では、変数「Count 」だけでなく、変数「Total」についてもリセット（Total ←０）がされる。
［第３実施形態の効果］
このように構成された複合機１の給紙装置１０によれば、第１実施形態と同様の構成により得られる作用，効果の他、以下に示すような作用，効果を得ることができる。
【０１０６】
この給紙装置１０では、変数「Total 」がしきい値Ｊ以上の値になった場合には、図７におけるｓ１８４の処理で、給紙の行われた回数が多くなったことによるメンテナンス（例えば、消耗した部品を交換する等）が必要である旨を報知することができる。
【０１０７】
また、この報知は、サービスセンタ側のホストコンピュータに対してメッセージとして送信されるため、このサービスセンタ側のサービスマンによるメンテナンスを経て給紙装置１０の搬送機能を正常化することができる。
【０１０８】
また、図７におけるｓ２１２の処理で変数「Total 」がしきい値Ｊ以上の値になっていると判定されたときには、給紙装置１０の動作を停止させることなく画像形成処理を終了するように構成されている。このように、変数「Total 」がしきい値Ｊ以上の値になっている状態は、単に給紙の行われた回数が多くなっただけで、給紙装置１０による給紙が直ちに行えなくなる訳ではない。そのため、このようなときに給紙装置１０の動作を停止させずに搬送機能を維持することによって、給紙装置１０による給紙を継続的に行うことができるようにし、ユーザまたはサービスマンによる任意のタイミングでメンテナンスを行えるようにすることができる。
［変形例］
以上、本発明の実施の形態について説明したが、本発明は、上記実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態をとり得ることはいうまでもない。
【０１０９】
例えば、上記実施形態においては、本発明の搬送装置を給紙装置に適用した構成を例示したが、本発明の搬送装置は、記録用紙を搬送するための装置であれば、給紙装置以外の装置に適用することもできる。
【０１１０】
また、上記実施形態においては、累積エラー回数（変数「Count 」）および連続エラー回数（変数「Total 」）によりメンテナンスレベルを判定するように構成されたものを例示したが、累積エラー回数および連続エラー回数のいずれか一方、または、給紙装置１０の搬送状況を示す他のパラメータに基づいて、メンテナンスレベルを判定するように構成してもよい。
【０１１１】
また、第２実施形態においては、図６におけるｓ２００の処理で変数「Count 」に加算する加算値αを、同図ｓ１７４の処理で変数「Count 」から減算される減算値βよりも大きな値とした構成を例示した。しかし、この加算値α，減算値βについては、加算値αを減算値βより小さな値としてもよい。この場合、例えば、加算値αを「１」とし、減算値βを「２」とすればよい。
【０１１２】
このように構成した場合、給紙エラーが発生する毎に図５におけるｓ２００の処理で累積エラー回数が積算されていくが、給紙が正常に行われると、同図ｓ１７４の処理で給紙が正常に行われなかったときよりも大きな減算値βが累積エラー回数から減算される。そのため、給紙が正常に行われない状況が連続して発生しない限り、累積エラー回数が大きな値になることはない。つまり、給紙が正常に行われない状況が連続して発生し、給紙装置１０（給紙ローラユニット１６）による給紙が正常に行えなくなったときにのみ、累積エラー回数が大きな値となり、これにより、ｓ２５０の処理へ移行することになる。よって、上述のように大きな減算値βを累積エラー回数から減算するように構成することは、給紙装置１０による搬送が正常に行えなくなった場合のように、本質的なメンテナンスが必要になったことを検出するために適しているといえる。
【０１１３】
また、上記実施形態において、画像形成処理で使用されるしきい値（Ｌ，Ｋ，Ｊ）については、ＥＥＰＲＯＭ１１８に記憶されるものとし、操作パネル３により所定の手順に従った操作が行われた際に任意の値に変更されるように構成してもよい。また、通信回線網Ｎ側（例えば、サービスセンタ）からの指令に基づいて、任意の値に変更されるように構成してもよい。このように構成すれば、ユーザまたはサービスセンタ側が、変更報知処理で使用される「しきい値」を任意に変更することができる。
【０１１４】
また、上記実施形態における画像形成処理には、図８に示すように、第２実施形態における変数「Count 」に加算値α，減算値βを加減算する構成と、第３実施形態における総給紙回数をチェックする構成とを両方備えることもできる。
［本発明との対応関係］
上記説明した実施形態において、給紙装置１０および給紙装置１０の制御に関する構成が本発明における搬送装置であり、記録用紙が本発明における被記録媒体であり、給紙ローラユニット１６が本発明における搬送手段である。
【０１１５】
また、図５〜図８におけるｓ１１０，ｓ１５２，ｓ１７４，ｓ１８６，ｓ１９０，ｓ２１０，ｓ２６０の処理は本発明における状況監視手段であり、ｓ１８２，ｓ２１０，ｓ２１２，ｓ２２０の処理は本発明におけるレベル判定手段であり、ｓ１８４，ｓ２３０，ｓ２５０の処理は本発明における報知手段であり、ｓ１６０の処理は本発明におけるエラー判定手段であり、ｓ２２０の処理は本発明における再試行手段であり、ｓ２７０の処理は本発明における動作停止手段である。
【０１１６】
また、図５〜図８におけるｓ２２０の処理で「ＹＥＳ」と判定された場合のメンテナンスレベルが本発明における第１エラーレベルであり、ｓ２１０の処理で「ＹＥＳ」と判定された場合のメンテナンスレベルが本発明における第２エラーレベルであり、ｓ２１２，ｓ１８２の処理で「ＹＥＳ」と判定された場合のメンテナンスレベルが本発明における消耗レベルである。
【０１１７】
また、図６，図８におけるｓ２００の処理で変数「Count 」に加算される加算値αは本発明における第１の値であり、ｓ１７４の処理で変数「Count 」から減算される減算値βは本発明における第２の値である。
【０１１８】
また、加算値αを減算値βより小さな値とした場合における加算値αは本発明における第３の値であり、減算値βは本発明における第４の値である。
また、画像形成処理で使用されるしきい値を任意に変更可能とした場合において、操作パネル３の操作を受けてしきい値を変更，または，通信回線網Ｎ側からの指令に基づいてしきい値を変更する処理を行うＣＰＵ１１２は、本発明における設定変更手段である。
【図面の簡単な説明】
【０１１９】
【図１】複合機を示す斜視図
【図２】給紙装置を示す斜視図
【図３】給紙装置により給紙が行われる様子を示す図
【図４】複合機の制御系統を示すブロック図
【図５】第１実施形態における画像形成処理の手順を示すフローチャート
【図６】第２実施形態における画像形成処理の手順を示すフローチャート
【図７】第３実施形態における画像形成処理の手順を示すフローチャート
【図８】別の実施形態における画像形成処理の手順を示すフローチャート
【符号の説明】
【０１２０】
１…複合機、２…筐体、３…操作パネル、４…表示部、５…原稿セット部、６…記録排紙トレイ、７…読取排紙トレイ、１０…給紙装置、１２…収納部、１４…媒体保持部、１６…給紙ローラユニット、１６ａ…給紙ローラ、２０…突出部材、２２…突出部、１１２…ＣＰＵ、１１４…ＲＯＭ、１１６…ＲＡＭ、１１８…ＥＥＰＲＯＭ、１２０…給紙制御回路、１２２…スキャナ部、１２４…プリンタ部、１２６…通信制御部、１２８…バス。
【図１】
2005328374.tif 000003
【図２】
2005328374.tif 000004
【図３】
2005328374.tif 000005
【図４】
2005328374.tif 000006
【図５】
2005328374.tif 000007
【図６】
2005328374.tif 000008
【図７】
2005328374.tif 000009
【図８】
2005328374.tif 000010