図面 (/)

技術 通信方法及び画像形成装置

出願人 キヤノン株式会社
発明者 中村彰浩
出願日 2008年4月24日 (12年0ヶ月経過) 出願番号 2008-114059
公開日 2009年11月12日 (10年5ヶ月経過) 公開番号 2009-267705
状態 特許登録済
技術分野 電子写真における制御・保安 電子写真における制御・管理・保安 ファクシミリ一般
主要キーワード 二重起動 受信ドライバ ステータスリクエスト パケット識別コード 状態定義 IOデータ 送信ドライバ 差動レシーバ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2009年11月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

ACK再送を避け、正常に通信ができなくなる状況を回避し、通信エラー検知性能を向上させ、通信エラー発生時のコマンド再発行による動作の二重起動を防止する。

解決手段

CPU11がコマンドを発行していない状態で(S301Yes)、ACKやStatusを受信し(S311No)、または通信エラーを検知した場合には(S310Yes)NACKを発行し(S312)、NACKを受信した場合には(S311Yes)NACKを無視し(〔11〕)、CPU11がコマンドを発行してから(S301No)ACKやStatusを受信するまでの間に、通信エラーを検知し(S305Yes)またはNACKを受信した場合には(S306Yes)、コマンド信号を再発行し(S307)、コマンドを発行してから一定時間経過してもACKやStatusが返信されなかった場合には(S304Yes)コマンドを再発行する(S307)。

概要

背景

従来、通信プロトコルは、受信不良を示すところのNACK(Negative ACKnowledgement信号)(ネガティブアクリッジ信号)(以下NACK)を受信したら再送信手段を持つように設計されている(例えば、特許文献1参照)。

すなわち、特許文献1では、ホストから与えられた送信データをPIOデータ保持部に保持する。パケット生成部は送信データをもとにこの送信データの記憶場所の情報を含む送信パケットを生成し、これを通信リンク制御部がネットワーク送出する。このとき、送信データの記憶領域は解放しない。この送信パケットに対して送信データの記憶場所の情報を含むNACKが受信された場合には、その記憶場所に送信データが未だ記憶されているので、これをもとに送信パケット生成して再送する。ACK(ACKnowledgement信号)(アクナリッジ信号)パケット(以下ACK)が受信された場合には、送信データの記憶領域を開放する。

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

概要

NACKの再送を避け、正常に通信ができなくなる状況を回避し、通信エラー検知性能を向上させ、通信エラー発生時のコマンド再発行による動作の二重起動を防止する。CPU11がコマンドを発行していない状態で(S301Yes)、ACKやStatusを受信し(S311No)、または通信エラーを検知した場合には(S310Yes)NACKを発行し(S312)、NACKを受信した場合には(S311Yes)NACKを無視し(〔11〕)、CPU11がコマンドを発行してから(S301No)ACKやStatusを受信するまでの間に、通信エラーを検知し(S305Yes)またはNACKを受信した場合には(S306Yes)、コマンド信号を再発行し(S307)、コマンドを発行してから一定時間経過してもACKやStatusが返信されなかった場合には(S304Yes)コマンドを再発行する(S307)。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

第一のCPUと第二のCPUとを有し、前記第一のCPUまたは前記第二のCPUがコマンド信号発行し、前記コマンド信号に対するアクリッジ信号またはステータス信号を受信することにより、前記第一のCPUと前記第二のCPUとの間の通信を可能とし、コマンド信号に対し正常なアクナリッジ信号または正常なステータス信号が返信されるまでは新たなコマンド信号の発行を停止する通信装置通信方法であって、前記第一のCPUまたは前記第二のCPUがコマンド信号を発行していない状態で、アクナリッジ信号またはステータス信号を受信し、または、通信エラーを検知した場合には、ネガティブアクナリッジ信号を発行する工程と、前記第一のCPUまたは前記第二のCPUがコマンド信号を発行していない状態で、ネガティブアクナリッジ信号を受信した場合には、前記ネガティブアクナリッジ信号を無視する工程と、前記第一のCPUまたは前記第二のCPUがコマンド信号を発行してからアクナリッジ信号またはステータス信号を受信するまでの間に、通信エラーを検知し、または、ネガティブアクナリッジ信号を受信した場合には、前記コマンド信号を再発行する工程と、前記第一のCPUまたは前記第二のCPUがコマンド信号を発行してから一定時間経過してもアクナリッジ信号またはステータス信号が返信されなかった場合には、前記コマンド信号を再発行する工程と、を備えることを特徴とする通信方法。

請求項2

請求項1に記載の通信方法において、前記第一のCPUまたは前記第二のCPUが発行するコマンド信号に識別コードを付加し、前記識別コードを記憶する工程と、前記第一のCPUまたは前記第二のCPUが、識別コードが付加されたコマンド信号を受信した場合に、前記識別コードをアクナリッジ信号またはステータス信号に付加する工程と、前記第一のCPUまたは前記第二のCPUが、識別コードが付加されたアクナリッジ信号またはステータス信号を受信した場合に、前記記憶する工程により記憶された識別コードと前記アクナリッジ信号または前記ステータス信号に付加された識別コードとが異なる場合には、ネガティブアクナリッジ信号を送信する工程と、を備えることを特徴とする通信方法。

請求項3

請求項2に記載の通信方法において、前記第一のCPUまたは前記第二のCPUが、識別コードが付加されたコマンド信号を受信した場合に、前記識別コードを記憶する工程と、前記第一のCPUまたは前記第二のCPUが、識別コードが付加された次のコマンド信号を受信した場合に、前記記憶する工程により記憶された識別コードと、前記次のコマンド信号に付加された識別コードとが一致する場合には、前記次のコマンド信号に対応する動作を起動せず、前記次のコマンド信号に対するアクナリッジ信号またはステータス信号を返信する工程と、を備えることを特徴とする通信方法。

請求項4

請求項1乃至3のいずれかに記載の通信方法を用いた画像形成装置であって、前記第一のCPUを有し、画像情報を生成するビデオコントローラ部と、前記第二のCPUを有し、画像形成の動作を制御するエンジン基板と、を備えることを特徴とする画像形成装置。

技術分野

0001

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

背景技術

0002

従来、通信のプロトコルは、受信不良を示すところのNACK(Negative ACKnowledgement信号)(ネガティブアクリッジ信号)(以下NACK)を受信したら再送信手段を持つように設計されている(例えば、特許文献1参照)。

0003

すなわち、特許文献1では、ホストから与えられた送信データをPIOデータ保持部に保持する。パケット生成部は送信データをもとにこの送信データの記憶場所の情報を含む送信パケットを生成し、これを通信リンク制御部がネットワーク送出する。このとき、送信データの記憶領域は解放しない。この送信パケットに対して送信データの記憶場所の情報を含むNACKが受信された場合には、その記憶場所に送信データが未だ記憶されているので、これをもとに送信パケット生成して再送する。ACK(ACKnowledgement信号)(アクナリッジ信号)パケット(以下ACK)が受信された場合には、送信データの記憶領域を開放する。

0004

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

発明が解決しようとする課題

0005

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

0006

A−CPU(第一のCPU)がB−CPU(第二のCPU)にNACKを送信した場合に、通信エラーが発生すると、B−CPUからA−CPUにNACKが返信され、A−CPUの記憶場所に記憶されているNACKが再送信される。B−CPUの記憶場所にもNACKが記憶されているので、B−CPUからもNACKが再送信される状況となっている。そして結果的には、NACKをお互いに送信しつづけることにより、正常に通信ができなくなってしまう(通信のハングアップとも言う)こととなる。

0007

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

0008

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

0009

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

課題を解決するための手段

0010

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

0011

(1)第一のCPUと第二のCPUとを有し、前記第一のCPUまたは前記第二のCPUがコマンド信号を発行し、前記コマンド信号に対するアクナリッジ信号またはステータス信号を受信することにより、前記第一のCPUと前記第二のCPUとの間の通信を可能とし、コマンド信号に対し正常なアクナリッジ信号または正常なステータス信号が返信されるまでは新たなコマンド信号の発行を停止する通信装置の通信方法であって、前記第一のCPUまたは前記第二のCPUがコマンド信号を発行していない状態で、アクナリッジ信号またはステータス信号を受信し、または、通信エラーを検知した場合には、ネガティブアクナリッジ信号を発行する工程と、前記第一のCPUまたは前記第二のCPUがコマンド信号を発行していない状態で、ネガティブアクナリッジ信号を受信した場合には、前記ネガティブアクナリッジ信号を無視する工程と、前記第一のCPUまたは前記第二のCPUがコマンド信号を発行してからアクナリッジ信号またはステータス信号を受信するまでの間に、通信エラーを検知し、または、ネガティブアクナリッジ信号を受信した場合には、前記コマンド信号を再発行する工程と、前記第一のCPUまたは前記第二のCPUがコマンド信号を発行してから一定時間経過してもアクナリッジ信号またはステータス信号が返信されなかった場合には、前記コマンド信号を再発行する工程とを備えることを特徴とする通信方法。

0012

(2)前記(1)に記載の通信方法を用いた画像形成装置であって、前記第一のCPUを有し、画像情報を生成するコントローラ部と、前記第二のCPUを有し、画像形成の動作を制御するエンジン基板とを備えることを特徴とする画像形成装置。

発明の効果

0013

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

発明を実施するための最良の形態

0014

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

0015

本実施例の通信プロトコルは、以下の〔1〕〜〔18〕に示す18項目で定義されるものである。
〔1〕2個のCPUを接続する通信である。
〔2〕2個のCPUをA−CPU(後述するCPU11),B−CPU(後述するCPU16)とする。
〔3〕相手側に命令をするところのCommand(以下Command)を受信したA−CPUは、そのCommandに対応した受信完了通知であるところのACK(以下ACK)または、状況を返信するところのStatus(以下Status)を返信する。
〔4〕Commandを受信したB−CPUは、そのCommandに対応したACKまたは、Statusを返信する。
〔5〕A−CPUからB−CPUに対しCommandを発行した場合には、B−CPUよりそのCommandに対応した正常なACKまたは正常なStatusが返信されるまでは、A−CPUはB−CPUに対し新たなCommandは発行しない。
〔6〕B−CPUからA−CPUに対しCommandを発行した場合には、A−CPUよりそのCommandに対応した正常なACKまたは正常なStatusが返信されるまでは、B−CPUはA−CPUに対し新たなCommandは発行しない。
〔7〕A−CPUがCommandを発行していない状態で、通信エラーを検知したらA−CPUは受信不良を示すところのNACK(以下NACK)を発行する。
〔8〕B−CPUがCommandを発行していない状態で、通信エラーを検知したらB−CPUはNACKを発行する。
〔9〕A−CPUがCommandを発行し、ACKまたは、Statusを受信するまでの間に、通信エラーを検知したら最後に発行したCommandを再発行する。
〔10〕B−CPUがCommandを発行し、ACKまたは、Statusを受信するまでの間に、通信エラーを検知したら最後に発行したCommandを再発行する。
〔11〕A−CPUがCommandを発行していない状態で、NACKを受信したらNACKを無視しなにもしない。
〔12〕B−CPUがCommandを発行していない状態で、NACKを受信したらNACKを無視しなにもしない。
〔13〕A−CPUがCommandを発行し、ACKまたは、Statusを受信するまでの間に、NACKを受信したら最後に発行したCommandを再発行する。
〔14〕B−CPUがCommandを発行し、ACKまたは、Statusを受信するまでの間に、NACKを受信したら最後に発行したCommandを再発行する。
〔15〕A−CPUがCommandを発行していない状態にもかかわらずACKまたはStatusを受信した場合には、NACKを発行する。
〔16〕B−CPUがCommandを発行していない状態にもかかわらずACKまたはStatusを受信した場合には、NACKを発行する。
〔17〕A−CPUがCommandを発行したにもかかわらず一定時間経過してもACKまたは、Statusが返信されなかった場合には、最後に発行したCommandを再発行する。
〔18〕B−CPUがCommandを発行したにもかかわらず一定時間経過してもACKまたは、Statusが返信されなかった場合には、最後に発行したCommandを再発行する。

0016

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

0017

[画像形成装置の構成]
図1は本発明の特徴を最もよく表す図面であり、同図において1は画像形成を行う画像形成装置本体である。2は画像を形成するための用紙を保持するカセットである。3は画像形成済みの用紙を排出する排紙トレイである。4は用紙を一枚ずつ取り出すため(以下ピックアップと称す)するためのピックアップローラである。5は画像を形成する現像転写部である。6は用紙上に転写された画像を定着させる定着器である。7は、定着済みの用紙を搬送する搬送ローラであり、8はピックアップした用紙を現像転写部へ搬送する搬送ローラである。10は外部機器であるPC(パーソナルコンピュータ)等と接続しかつ画像情報を生成するビデオコントローラ部(Video−Controller部)である。11はビデオコントローラ部10のCPU(第一のCPU)である。12は画像情報を生成するビデオ生成部(Video生成部)であり、ビデオ信号Video信号)により電子写真を用い画像を形成する。13は外部のPCと接続するための通信制御部であり、例えばPCとUSB(Universal Serial Bus)にて接続する場合には、13はUSBコントローラを示す。14は画像形成装置本体内のもう一つのCPUと通信で接続するための通信制御部である。

0018

15は画像形成装置の搬送、現像、転写、定着等の機械部分の制御を担当するエンジン基板である。16はエンジン基板15の制御を司るエンジンCPU(第二のCPU)である。17は、電子写真制御部、18は定着制御部、19は搬送制御部、20はビデオコントローラ部10のCPU11と通信で接続するための通信制御部である。21はPCと接続するプリンタケーブルであり、例えばUSBケーブルが使用される。22は、PC等であり、画像形成装置にプリントの命令を出す。PC22から印字命令を受信したビデオコントローラ部10は、エンジン基板15に印刷命令を出す。それと同時にビデオ生成部12にて画像情報を生成する。用紙は、カセット2からピックアップローラ4によりピックアップされ、搬送ローラ8により現像転写部5に送り込まれる。用紙上に画像が形成され、定着器6に送られる。そして定着が終了した用紙は、排紙トレイ3に排出される。

0019

[ビデオコントローラ部10のCPU11とエンジン基板15のCPU16の接続]
図2は、エンジン基板15のCPU16とビデオコントローラ部10のCPU11の接続図である。

0020

ビデオコントローラ部10のCPU11は、USBコントローラ13と接続され、プリンタケーブル21を介してPC22とのUSB接続を可能とする。ビデオコントローラ部10のCPU11は、ビデオ生成部12に接続され、ビデオ生成に必要な情報をビデオ生成部12に供給する。ビデオ信号は、差動ドライバ31により差動信号に変換され出力される。差動信号となったビデオ信号は、現像転写部5に伝えられ画像を形成する。ビデオコントローラ部10とエンジン基板15は、GNDを接続する。ビデオコントローラ部10のCPU11とエンジン基板15のCPU16との通信は、それぞれのCPUに内蔵するシリアル通信機能を使用する。CPU11のシリアル通信機能の送信ポートであるところのTXポート(以下TXポート)から通信データが送出される。そしてCPU16のシリアル通信機能の受信ポートであるところのRXポート(以下RXポート)より受信される。CPU16のシリアル通信機能のTXポートから通信データが送出される。そしてCPU11のシリアル通信機能のRXポートより受信される。32,33,34,35は、シリアル通信用のバッファICである。エンジン基板15のCPU16は、ビデオコントローラ部10のCPU11とシリアル通信バッファ34,35で接続されている。

0021

エンジン基板15のCPU16は、電子写真制御部17と接続され電子写真の現像転写を制御する。エンジン基板15のCPU16は定着制御部18と接続され定着器6の温度を制御することにより用紙への画像の定着を制御する。エンジン基板15のCPU16は搬送制御部19と接続され、ピックアップローラ4と搬送ローラ7,8を制御し、用紙の搬送を制御する。ビデオ生成部12で生成されたビデオ信号は、電子写真制御部17を通過し、レーザ基板38へ伝えられる。そしてレーザ基板38上にある差動レシーバ36により受信され、レーザ37を駆動する。

0022

ピックアップローラ4、搬送ローラ7,8を駆動する搬送モータは、搬送制御部19に接続されている。定着器6は、定着制御部18に接続されている。現像転写部5は、電子写真制御部17に接続されている。

0023

[CPU11に適用される通信タスクについて]
次にCPU11に適用されるF/W(ファームウエア)である通信タスクを説明する。

0024

まず、状態定義とF/Wの制御ブロックであるところのタスク(以下TASK)とハードウエアとのデータの受け渡しをするところのドライバ(以下ドライバ)とデータの一時記憶場所であるバッファ(以下Buffer)の説明をする。

0025

<定義>
同期状態通常状態について、以下のように定義する。
同期状態:CPU11からステータス要求であるところのステータスリクエスト(以下
ステータスRequest)を送信し、そのステータスRequsetに対応
する正しいステータスをCPU11が受信するまでの間またはCPU11から
実動作を要求するところの実行コマンド(以下実行コマンド)を送信し、その
実行コマンドに対応する正しいステータスをCPU11が受信するまでの間。
通常状態:CPU11が上記同期状態にない場合。

0026

<TASKとドライバ>
TASK2個とドライバ2個から通信ソフトが構成されている。
各々の名前を、“コマンド・ステータス制御TASK”(101)、“第1受信TASK”(102)、“送信ドライバ”(103)、“受信ドライバ”(104)とする。これら、101〜104の機能は以下のとおりである。

0027

(101)“コマンド・ステータス制御TASK”
以下にこのTASKの機能を列挙する。
*送信すべきステータスRequestまたは実行コマンド(コマンド信号)を制御
し、なおかつ、どのコマンドを送信したかを記憶する。
*返信されたステータスを所定のメモリに格納する。
*再送すべきステータスRequestまたは実行コマンドを制御する。
*NACK(ネガティブアクナリッジ信号)を返信する。
*受信したNACKを無視する。

0028

(102)“第1受信TASK”
以下にこのTASKの機能を列挙する。
*RxData(後述)の内容がCPU16からのステータスを表示するための
STCommand(以下STCommand)であると判断したらACK(アク
ナリッジ信号)を返信する。
*RxData(後述)の内容がCPU16からのSTCommandでない場合に
は、そのデータをTxRxBuffer(後述)を通じてコマンド・ステータス制
御TASK101にデータ内容を渡す。

0029

(103)“送信ドライバ”
以下にこのTASKの機能を列挙する。
*コマンド・ステータス制御TASK101から依頼のあった送信を実行する。
*第1受信TASK102から依頼のあったACKを送信する。

0030

(104)“受信ドライバ”
以下にこのTASKの機能を列挙する。
*受信したデータをRxDataを通じて第1受信TASK102に渡す。

0031

<Buffer>
各TASK間での情報の受け渡しに使用するBufferを説明する。

0032

各々の名前を、RxData、TxRxBuffer、TxQueue、SR_CommandQueue、NormalStatus、STCommandSaveAreaとする。
201RxData:受信ドライバ104が受信したデータをRxDataに格納し、第1受信TASK102に受け渡すために使用するメモリ領域である。
202TxRxBuffer:第1受信TASK102からコマンド・ステータス制御TASK101に受信データを受け渡すために使用するメモリ領域である。
203TxQueue:コマンド・ステータス制御TASK101または、第1受信TASK102から送信データを送信ドライバ103に通知するために使用するメモリ領域である。
204SR_CommandQueue:通信TASK以外の部分(151)からのステータスRequest、実行コマンドの送信要求を格納するメモリ領域である。
205NormalStatus:通常のステータスの格納エリアである。通信TASK以外の部分151から参照可能となっている。
206STCommandSaveArea:CPU16から到着したSTCommandを格納するメモリ領域である。通信TASK以外の部分から参照可能となっている。

0033

<CPU11の通信TASK構造の説明>
図3に従って、CPU11の通信TASK構造を説明する。

0034

CPU11のRXポートからのデータを処理する部分が受信ドライバ104である。受信ドライバ104で受信されたデータはRxData201に格納される。次に、RxData201のデータを解析するのが、第1受信TASK102である。この第1受信TASK102は、RxData201に格納されたデータがCPU16から送信されたSTCommandであるかどうかをチェックする(110)。STCommandであった場合はSTCommandSaveArea206に格納する(109)。通信TASK以外の部分151がSTCommandSaveArea206の内容を参照する。そして、ACKをCPU16に返信する。具体的には、送信バッファであるTxQueue203にACKをセットし、送信ドライバ103からTxQueue203に格納された送信データを送信する。

0035

RxData201がSTCommandでなかった場合には、そのデータのエラー発生状況を含めて、TxRxBuffer202に格納する。次のコマンド・ステータス制御TASK101では、TxRxBuffer202に格納されたデータを解析する。そして、NACKを返信するか(108)、ステータスRequestまたは、実行コマンドの再送信をするか(107)、正常であると判断し、NormalStatus205にステータスを格納するか(106)を選択する。また、通信TASK以外の部分151がNormalStatus205の内容を参照する。また、SR_CommandQueue204に通信TASK以外の部分151から書き込まれたデータがある場合には(105)、送信バッファであるTxQueue203に送信データをセットする。最後に送信ドライバ103では、TxQueue203に格納された送信データを順次送信する。送信ドライバ103は、CPU11のTXポートへのデータを処理する部分である。

0036

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

0037

受信ドライバ104では、常に、ハードウエアからの受信割り込みであるところの受信Interrupt(受信Interrupt)が発生したかどうかを監視している(ステップ354、以下ステップをSとする)。 もしも受信Interruptが発生したら(Interrupt受信)、受信データをRxData201に格納する(S355)。

0038

〜第1受信TASK102〜
図5にて第1受信TASK102のフローチャートを説明する。

0039

まず、RxData201にデータがあるかどうか、すなわちRxData201が空か否かを監視する(S321)。もしも、空ではない、すなわちデータが格納されたRxData201が到着したらデータの解析を開始する。

0040

まず、RxData201を確認し、通信エラーが発生していないかどうかを確認する(S322)。もしも、エラーが発生している場合には、TxRxBuffer202にRxData201のデータを格納する。そしてその場合には、エラーが発生している情報も含める(S329)。

0041

通信エラーが発生していない場合には、RxData201がCPU16から通知されたSTCommandであるかどうかを確認する(S323)。もしもSTCommandであった場合には、STCommandSaveArea206に到着したSTCommandを格納する(S324)。そして、CPU16にSTCommandを正常に受信したことを通知するために、ACKを返信する。そのために、TxQueue203にACKをセットする(S325)。

0042

RxData201がSTCommandでない場合には、NACKであるかどうかを確認する(S326)。もしもNACKであった場合には、TxRxBuffer202にNACKを格納し、コマンド・ステータス制御TASK101に渡すS(328)。もしもRxData201がNACKでない場合には、格納されたRxData201は、通信エラーでもNACKでもないことが確定するので、TxRxBuffer202にエラー発生なしの情報も含めてRxData201の内容を格納する(S327)。

0043

なお、このフローチャートの中のS323,S324,S325の処理が前述の〔3〕に該当する処理である。

0044

〜コマンド・ステータス制御TASK101〜
図6にてコマンド・ステータス制御TASK101のフローチャートを説明する。

0045

SR_CommandQueue204の中に、ステータスRequestまたは実行コマンドの送信要求があるかどうかを確認する(S301)。

0046

もしもSR_CommandQueue204が空の場合には、TxRxBuffer202の確認を行う(S309)。もしもTxRxBuffer202にも到着データがない場合には、SR_CommandQueue204の確認に戻る(S309)。もしも、TxRxBuffer202に受信データが格納されていた場合には、まず、通信エラーが発生していないかを確認する(S310)。もしも通信エラーが発生していた場合には、TxQueue203にNACKをセットする(S312)。通信エラーが発生していない場合には、TxRxBuffer202がNACKかどうかを確認する(S311)。そして、データがNACKの場合には、そのNACKを無視し、SR_CommandQueue204の確認に戻る(S311)。

0047

もしも、TxRxBuffer202のデータがNACKでない場合には、CPU16にNACKを返信しなければいけないので、TxQueueにNACKをセットする(S312)。

0048

なお、S309,S310,S311,S312の処理を実行している状態が通常状態である。

0049

そして、S310,S312の処理が前述の〔7〕に該当する処理である。また、S311,S312の処理が前述の〔15〕に該当する処理である。また、S311からS301へ戻る処理が前述の〔11〕に該当する処理である。

0050

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

0051

SR_CommandQueue204の中に、ステータスRequestまたは実行コマンドの送信要求がある場合には(S301 No)、TxQueue203にステータスRequestまたは実行コマンドをセットする(S302)。このとき、再送信が発生した場合に備えて発行したステータスRequestまたは実行コマンドを記憶する(S302)。

0052

CPU16から返信であるTxRxBuffer202の到着を確認する(S303)。そして、このデータの確認はタイムオーバーであるところのTime−Over(以下Time−Over)も同時に監視する(S303)。

0053

もしも、Time−Overが発生したら(S303 Yes,S304 Yes)、再送の準備をする。すなわち、TxQueue203に再送データを格納できるような準備をする(S307)。再送は、S302にて記憶したデータを使用する(S307)。

0054

S304でTime−Overが発生しなかった場合には、次に通信エラーが発生しているかどうか確認する(S305)。

0055

通信エラーが発生している場合には(S305 Yes)、再送の準備をする。すなわち、TxQueue203に再送データを格納できるような準備をする(S307)。再送は、S302にて記憶したデータを使用する(S307)。

0056

次に、TxRxBuffer202を確認し、NACKであるかどうかを確認する(S306)。NACKであった場合には、再送の準備をする。すなわち、TxQueue203に再送データを格納できるような準備をする(S307)。再送は、S302にて記憶したデータを使用する(S307)。

0057

そして、NACKでない場合は(S306 No)、TxRxBuffer202に通常のステータスが格納されているので、それをNormalStatus205に格納する(S308)。

0058

S308を通過しない限り、次のSR_CommandQueue204のチェックを実施しない。すなわち、正常なACKまたはStatusが受信されない限り次の新しいステータスRequestまたは実行コマンドが発行できないようになっている。すなわち、正常なACKまたは正常なStatusが返信されるまでは実行コマンドの発行を停止する。

0059

なお、S308が前述の〔5〕に該当する処理である。また、S304,S307の処理が前述の〔17〕に該当する処理である。S304,S305,S307の処理が前述の〔9〕に該当する処理である。S304,S305,S306,S307の処理が前述の〔13〕に該当する処理である。S304,S305,S306,S308,S301の処理が前述の〔5〕に該当する処理である。

0060

〜送信ドライバ103〜
図7にて送信ドライバ103のフローチャートを説明する。

0061

TxQueue203にデータが格納されているかどうか、すなわち、空か否かを確認する(S351)。

0062

もしも、TxQueue203にデータがある場合には、送信データをハードウエアに書き込み、実際の送信動作を実行する(S352)。

0063

そして、送信動作が完了するのを待つ(S353)。送信動作が完了したらTxQueue203の確認動作に戻る(S353)。

0064

[CPU16に適用される通信タスクについて]
次にCPU16に適用されるF/Wである通信タスクを説明する。

0065

まず、定義とTASKとドライバとBufferの説明をする。

0066

<定義>
同期状態と通常状態について、以下のように定義する。
同期状態:CPU16からSTCommandを送信し、そのコマンドに対応する正し
いACKが返信されるまでの間。
通常状態:CPU16が上記同期状態にない場合。

0067

<TASKとドライバ>
TASK2個とドライバ2個から通信ソフトが構成されている。

0068

(401)コマンド・ステータス制御TASK
以下にこのTASKの機能を列挙する。
*送信すべきSTCommandを制御し、なおかつ、どのSTCommandを送
信したかを記憶する。
*返信されたACKを確認する。
*再送すべきSTCommandを制御する。
*NACK を返信する。
*受信したNACKを無視する。

0069

(402)第1受信TASK
以下にこのTASKの機能を列挙する。
*RxDataの内容がCPU16からのステータスRequestであると判断し
たら対応するステータスを返信する。
*Rxdataの内容がCPU16からの実行コマンドであると判断したら実行コマ
ンド受信情報505に格納し、さらに対応するステータスを返信する。
*RxDataの内容がCPU16からのステータスRequestまたは実行コマ
ンドでない場合には、そのデータをTxRxBuffer502を通じてコマンド
・ステータス制御TASK401に渡す。

0070

(403)送信ドライバ
以下にこのTASKの機能を列挙する。
*コマンド・ステータス制御TASK401から依頼のあった送信を実行する。
*第1受信TASK402から依頼のあったステータスを送信する。

0071

(404)受信ドライバ
以下にこのTASKの機能を列挙する。
*受信したデータをRxData501を通じて第1受信TASK402に渡す。

0072

<Buffer>
各TASK間での情報の受け渡しに使用するBufferを説明する。
RxData501:受信ドライバ404が受信したデータをRxData501に格納し、第1受信TASK402に受け渡すために使用するメモリ領域である。
TxRxBuffer502:第1受信TASK402からコマンド・ステータス制御TASK401に受信データを受け渡すために使用するメモリ領域である。
TxQueue503:コマンド・ステータス制御TASK401または、第1受信TASK402から送信データを送信ドライバに通知するために使用するメモリ領域である。
STCommandQueue504:通信TASK以外の部分451からのSTCommandの送信要求データを格納するために使用するメモリ領域である。
実行コマンド受信情報505:実行コマンドの受信データ格納エリアである。通信TASK以外の部分451から参照可能となっている。

0073

<CPU16の通信TASK構造の説明>
図8に従って、CPU16の通信TASK構造を説明する。

0074

CPU16のRXポートからのデータを処理する部分が受信ドライバ404である。受信ドライバ404で受信されたデータはRxData501に格納される。次に、RxData501のデータを解析するのが、第1受信TASK402である。この第1受信TASK402は、RxData501に格納されたデータがCPU11から送信された実行コマンドまたはステータスRequestであるかどうかをチェックする(410)。実行コマンドであった場合は、実行コマンド受信情報505のBufferに情報を格納する。そしてその実行コマンドに対応するステータスを返信する。ステータスRequestであった場合は対応するステータスを返信する。

0075

通信TASK以外の部分451が実行コマンド受信情報505を参照する。RxData501が実行コマンドまたはステータスRequestでなかった場合には、そのデータのエラー発生状況を含めて、TxRxBuffer502に格納する。次のコマンド・ステータス制御TASK401では、TxRxBuffer502に格納されたデータを解析する。そして、NACKを返信するか(408)、STCommandの再送信をするか(407)、正常にACKを受信したと判断し(406)、次のSTCommandの送信を許可するかを選択する。また、STCommandQueue504に通信TASK以外の部分451から書き込まれたデータがある場合には、送信バッファであるTxQueue503に送信データをセットする。最後に送信ドライバ403では、TxQueue503に格納された送信データを順次送信する。

0076

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

0077

受信ドライバ404では、常に、ハードウエアからの受信Interruptが発生したかどうかを監視している(S654)。

0078

もしも受信Interruptが発生したら、受信データをRxData501に格納する(S655)。

0079

〜第1受信TASK402〜
図10にて第1受信TASK402のフローチャートを説明する。

0080

まず、RxData501にデータがあるかどうか、すなわち空か否かを監視する(S621)。もしも、空ではないRxData501が到着したらデータの解析を開始する。

0081

まず、RxData501を確認し、通信エラーが発生していないかどうかを確認する(S622)。もしも、エラーが発生している場合には、TxRxBuffer502にRxData501のデータを格納する。そしてその場合には、エラーが発生している情報も含める(S629)。

0082

通信エラーが発生していない場合には、RxData501がCPU11から通知された実行コマンドまたはステータスRequestであるかどうかを確認する(S623)。もしも実行コマンドまたはステータスRequestであった場合には、さらに、実行コマンドであるかステータスRequestであるかを判断する(S681)。実行コマンドが到着した場合には、実行コマンド受信情報505にデータを格納する(S682)。そして、その実行コマンドに対応するステータスを通信TASK以外の部分451から取得する(S684)。そしてそのステータスをTxQueue503にセットする(S685)。

0083

ステータスRequestが到着した場合には、そのステータスRequestに対応するステータスを通信TASK以外の部分451から取得する(S624)。そしてそのステータスをTxQueue503にセットする(S625)。

0084

RxData501が実行コマンドまたはステータスRequestでない場合には(S623 No)、NACKであるかどうかを確認する(S626)。もしもNACKであった場合には、TxRxBuffer502 にNACKを格納し、コマンド・ステータス制御TASK401に渡す(S628)。もしもRxData501がNACKでない場合には、格納されたRxData501は、通信エラーでもNACKでもないことが確定するので、TxRxBuffer502にエラー発生なしの情報も含めてRxData501の内容を格納する(S627)。

0085

このフローチャートの中のS623,S681,S624,S625の処理、およびS623,S681,S682,S684,S685の処理が前述の〔4〕に該当する処理である。

0086

〜コマンド・ステータス制御TASK401〜
図11にてコマンド・ステータス制御TASK401のフローチャートを説明する。

0087

STCommandQueue504の中に、STCommandの送信要求があるかどうかを確認する(S601)。

0088

もしもSTCommandQueue504が空の場合には、TxRxBuffer502の確認を行う(S609)。もしもTxRxBuffer502にも到着データがない場合には、STCommandQueue504の確認に戻る(S609)。もしも、TxRxBuffer502に受信データが格納されていた場合には、まず、通信エラーが発生していないかを確認する(S610)。もしも通信エラーが発生していた場合にはTxQueue503にNACKをセットする(S612)。通信エラーが発生していない場合には、TxRxBuffer502がNACKかどうかを確認する(S611)。そして、データがNACKの場合には、そのNACKを無視し、STCommandQueue504の確認に戻る(S611)。

0089

もしも、TxRxBuffer502のデータがNACKでない場合には、CPU11にNACKを返信しなければいけないので、TxQueue503にNACKをセットする(S612)。

0090

なお、S609,S610,S611,S612の処理を実行している状態が通常状態である。

0091

そして、S610,S612の処理が前述の〔8〕に該当する処理である。また、S611,S612の処理が前述の〔16〕に該当する処理である。S611からS601へ戻る処理が前述の〔12〕に該当する処理である。

0092

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

0093

STCommandQueue504の中に、STCommandの送信要求がある場合には(S601 No)、TxQueue503にSTCommandをセットする(S602)。このとき、再送信が発生した場合に備えて発行したSTCommandを記憶する(S602)。

0094

CPU11からの返信であるTxRxBuffer502を確認する(S603)。そして、このデータの確認はTime−Overも同時に監視する(S603)。

0095

もしも、Time−Overが発生したら(S603 Yes,S604 Yes)、再送の準備をする。すなわち、TxQueue503に再送データを格納できるような準備をする(S607)。再送は、S602にて記憶したデータを使用する(S607)。

0096

Time−Overが発生しなかった場合には(S604 No)、次に通信エラーが発生しているかどうか確認する(S605)。

0097

通信エラーが発生している場合には(S605 Yes)再送の準備をする。すなわち、TxQueue503に再送データを格納できるような準備をする(S607)。再送は、S602にて記憶したデータを使用する(S607)。

0098

次に、TxRxBuffer502を確認し、NACKであるかどうかを確認する(S606)。 NACKであった場合には、再送の準備をする。すなわち、TxQueue503に再送データを格納できるような準備をする(S607)。再送は、S602にて記憶したデータを使用する(S607)。

0099

そして、NACKでない場合は(S606 No)、TxRxBuffer502に通常のステータスが格納されている(S606)。

0100

S606を通過しない限り、次のSTCommandQueue504のチェックを実施しない。すなわち、正常なACKが受信されない限り次の新しいSTCommandが発行できないようになっている(S606)。この部分が前述の〔6〕に該当する処理である。

0101

なお、S604,S607の処理が前述の〔18〕に該当する処理である。また、S604,S605,S607の処理が前述の〔10〕に該当する処理である。S604,S605,S606,S607の処理が前述の〔14〕に該当する処理である。S604,S605,S606,S601の処理が前述の〔6〕に該当する処理である。

0102

〜送信ドライバ403〜
図12にて送信ドライバ403のフローチャートを説明する。

0103

TxQueue503にデータが格納されているかどうか、すなわち空か否かを確認する(S651)。

0104

もしも、TxQueueにデータがある場合には、送信データをハードウエアに書き込み、実際の送信動作を実行する(S652)。

0105

そして、送信動作が完了するのを待つ(S653)。送信動作が完了したら(S653)、TxQueue503の確認動作に戻る(S653)。

0106

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

0107

実施例2の構成は実施例1と同一であり、本実施例の画像形成装置の構成は図1で示される。またCPUの接続も同一であり、図2で示される。

0108

なお、本実施例の通信プロトコルは、実施例1の〔1〕〜〔18〕の通信形態を有し、さらに、下記〔19〕〜〔22〕の通信プロトコルが付加されたものである。
〔19〕A−CPUがCommandを発行する場合には、Commandに識別コードをA−CPUが割り振り、B−CPUが、ACKおよびStatusを返信するときには、受信した識別コードをACK、および、Statusの中にコピーして返信する。
〔20〕B−CPUがCommandを発行する場合には、Commandに識別コードをB−CPUが割り振り、A−CPUが、ACKおよびStatusを返信するときには、受信した識別コードをACK、および、Statusの中にコピーして返信する。
〔21〕A−CPUが識別コードを保存した状態で、Commandを発行しその後、受信したACK,またはStatusの中に記載された識別コードが保存してあったCommand用の識別コードと異なっていた場合には、NACKを送信する。
〔22〕B−CPUが識別コードを保存した状態で、Commandを発行しその後、受信したACK,またはStatusの中に記載された識別コードが保存してあったCommand用の識別コードと異なっていた場合には、NACKを送信する。

0109

<CPU11の通信TASK構造の説明>
図13から図17が実施例2におけるCPU11のTASK構成およびフローチャートである。

0110

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

0111

図13で示すように、STCommand、ACK、ステータス、ステータスRequest、実行コマンド等には、すべてパケットを特定するための固有番号であるパケットIDが付加されている(図3比較参照)。パケットに付加されたパケットIDにより通信が正常に実施されたかどうかの確認を行う。

0112

パケットIDの決定は、105の処理の中で実施される。具体的には、パケットIDが1ずつ増加される。すなわちIncrement(以下Increment)される。

0113

〜受信ドライバ104〜
図14のS375に示すように、受信はパケット単位で行われ、RxData201への格納もパケット単位で行われ、以降のデータ解析もパケット単位で実施される。

0114

〜第1受信TASK102〜
図15で示すように、S385でACKを返信する場合には、STCommandにて通知されたパケットIDをそのまま付加する。この処理が前述の〔19〕に対応する処理である。

0115

〜コマンド・ステータス制御TASK101〜
図16で示すように、S382で送信したパケットIDを記憶するとともに、次に使用するパケットIDがIncrementされたものとなるように準備する。

0116

また、S388では、受信したパケットIDと送信したパケットIDの比較が実施され、より精度のよい通信エラーの検知を実施している。もしも、パケットIDの不一致が発生した場合には(S388 No)、NACKを返信するために、TxQueue230にNACKをセットする(S389)。この処理が前述の〔21〕に対応する処理である。

0117

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

0118

<CPU16の通信TASK構造の説明>
図18から図22が実施例2におけるCPU16のTASK構成およびフローチャートである。

0119

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

0120

図18で示すように、ステータスRequest、実行コマンド、ステータス、ACK、STCommand等にはすべてパケットIDが付加されている。パケットに付加されたパケットIDにより通信が正常に実施されたかどうかの確認を行う。

0121

パケットIDの決定は、405の処理の中で実施される。具体的には、パケットIDがIncrementされる。

0122

〜受信ドライバ404〜
図19のS675で示すように、受信はパケット単位で行われ、RxData501への格納もパケット単位で行われ、以降のデータ解析もパケット単位で実施される。

0123

〜第1受信TASK402〜
図20で示すように、S675、S676で、返信すべきステータスには、ステータスRequestのパケットIDあるいは実行コマンドのパケットIDをそのまま付加する。この処理が前述の〔20〕に対応する処理である。

0124

〜コマンド・ステータス制御TASK401〜
図21で示すように、S642では、送信したパケットIDを記憶するとともに、次に使用するパケットIDがIncrementされたものとなるように準備する。

0125

S697では、受信したパケットIDと送信したパケットIDの比較が実施され、より精度のよい通信エラーの検知を実施している。もしも、パケットIDの不一致が発生した場合には(S697 No)、NACKを返信するために、TxQueue230にNACKをセットする(S698)。この処理が前述の〔22〕に対応する処理である。

0126

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

0127

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

0128

実施例3は実施例2と比較して、第1受信TASK102と第1受信TASK402のフローチャートのみが変更となっている。以下、実施例2と同じものについては同じ符号を用いて説明する。

0129

なお、本実施例の通信プロトコルは、実施例1の〔1〕〜〔18〕、実施例2の〔19〕〜〔22〕の通信形態を有し、さらに、下記〔23〕、〔24〕の通信プロトコルが付加されたものである。
〔23〕A−CPUがCommandを受信した時点で、識別コードを保存する。A−CPUはCommandに対応した動作を起動する。A−CPUはCommandに対応するACKまたはStatusをB−CPUに返信する。A−CPUが次のCommandを受信した場合に、もしも、Commandに記載された識別コードが前回のCommand受信時に保存した識別コードと一致した場合には、A−CPUは、Commandに対応した動作は起動しない。そしてCommandに対応するACKまたはStatusを返信する。
〔24〕B−CPUがCommandを受信した時点で、識別コードを保存する。B−CPUはCommandに対応した動作を起動する。B−CPUはCommandに対応するACKまたはStatusをA−CPUに返信する。B−CPUが次のCommandを受信した場合に、もしも、Commandに記載された識別コードが前回のCommand受信時に保存した識別コードと一致した場合には、B−CPUは、Commandに対応した動作は起動しない。そしてCommandに対応するACKまたはStatusを返信する。

0130

〜第1受信TASK102〜
図23のS343で示すように、到着したSTCommandのパケットIDが前回(直前に)受信したパケットIDと同一であるかどうかを確認する。もしも、パケットIDが前回受信したパケットIDと同一であれば、再送信が発生したものとして、STCommandSaveArea206には格納しない(S343 Yes,S344)。この処理が前述の〔23〕に対応する処理である。この処理をすることにより、再送信によるステータスの破壊を防止する。

0131

一方、S343で、直前に受信したパケットIDと今回のパケットIDが同一ではない場合、S344でSTCommandSaveArea206にSTCommandを格納し、パケットIDも記憶する。

0132

〜第1受信TASK402〜
図24のS699で示すように、今回通知された到着した実行コマンドのパケットIDが記憶している前回受信した実行コマンドのパケットIDと同一であるかどうかを確認する。もしも、パケットIDが前回受信した実行コマンドのパケットIDと同一であれば、再送信が発生したものとして、実行コマンド受信情報505には書き込まない(S699 Yes)。このように、実行コマンド受信情報505には書き込まず、記憶した前回のステータスをTxQueue503にセットする準備をする(S701)。この処理が前述の〔24〕に対応する処理である。

0133

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

0134

一方、S699で記憶しているパケットIDと今回通知されたパケットIDが同一ではない場合は、S639で実行コマンド受信情報505に実行コマンド情報を格納し、今回通知されたパケットIDも記憶する。

0135

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

図面の簡単な説明

0136

本発明の画像形成装置本体を説明する図
エンジン基板15のCPU16とビデオコントローラ部10のCPU11の接続図
実施例1のCPU11の通信TASK構造図
実施例1の受信ドライバ104のフローチャート
実施例1の第1受信TASK102のフローチャート
実施例1のコマンド・ステータス制御TASK101のフローチャート
実施例1の送信ドライバ103のフローチャート
実施例1のCPU16の通信TASK構造図
実施例1の受信ドライバ404のフローチャート
実施例1の第1受信TASK402のフローチャート
実施例1のコマンド・ステータス制御TASK401のフローチャート
実施例1の送信ドライバ403のフローチャート
実施例2のCPU11の通信TASK構造図
実施例2の受信ドライバ104のフローチャート
実施例2の第1受信TASK102のフローチャート
実施例2のコマンド・ステータス制御TASK101のフローチャート
実施例2の送信ドライバ103のフローチャート
実施例2のCPU16の通信TASK構造図
実施例2の受信ドライバ404のフローチャート
実施例2の第1受信TASK402のフローチャート
実施例2のコマンド・ステータス制御TASK401のフローチャート
実施例2の送信ドライバ403のフローチャート
実施例3の第1受信TASK102のフローチャート
実施例3の第1受信TASK402のフローチャート

符号の説明

0137

1画像形成装置本体
10ビデオコントローラ部
11 CPU(第一のCPU)
15エンジン基板
16エンジンCPU(第二のCPU)
32,33,34,35シリアル通信用バッファIC

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • コニカミノルタ株式会社の「 画像形成装置およびその制御方法」が 公開されました。( 2020/02/13)

    【課題】印刷中断後に印刷を再開するまでの時間を短縮する技術を提供する。【解決手段】画像形成装置が実行する処理は、制御装置が駆動ローラーの回転を制御するステップ(S1315)と、給紙情報が取得されていな... 詳細

  • キヤノン株式会社の「 画像形成装置」が 公開されました。( 2020/02/13)

    【課題】コストアップを抑えるために画素数をカウントする各領域の幅に制約がある場合でも、帯電ローラの清掃動作によってスループットが低下することを抑えること。【解決手段】画素数カウント部450は、画像形成... 詳細

  • キヤノン株式会社の「 画像形成装置」が 公開されました。( 2020/02/13)

    【課題】消費電力が低減された状態から定着手段に電力が供給されない状態へ復帰して結露判定のための環境を検出する。【解決手段】画像形成装置1は、画像形成装置を第一の状態、第二の状態および第三の状態に切り替... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ