JP3707036B2 - ファクシミリ装置とファクシミリの通信制御方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ファクシミリ装置とファクシミリの通信制御方法に関する。
【０００２】
【従来の技術】
ファクシミリ装置においては、１９９４年にＩＴＵ−Ｔ（International Telecommunications Union-Tele-communications Standarization Sector）Ｖ．３４が勧告された。このＩＴＵ−Ｔ勧告Ｖ．３４（以下Ｖ．３４とする）はモデムの通信方法の勧告である。この勧告Ｖ．３４では、回線の特性を測定し、これに照らし合わせて送信するためのパラメータを微妙に調整することで、28,800ｂｐｓまでのデータレートを実現するモデムの通信方法を規定する。なお、勧告Ｖ．３４の正式な題名は、「電話網もしくは１対１の２線式専用線のために使われる、データレートが28,800ｂｉｔ／ｓまでのモデムの動作」である。
【０００３】
また、この勧告Ｖ．３４を採用したファクシミリ装置は、伝送制御手順をＩＴＵ−Ｔ勧告Ｔ．３０「一般電話交換網における文書ファクシミリ伝送用手順」の「バイナリ制御手順」に従っている。この「バイナリ制御手順」は、複雑な運用手順を発呼局側と被呼局側とで相互に確認するために、データ伝送用に開発されたハイレベルデータリンク制御（ＨＤＬＣ）のフレーム構成を用いる。
【０００４】
なお、上記勧告Ｖ．３４を採用したファクシミリ装置は、ＩＴＵ−Ｔ勧告Ｖ．８（以下、Ｖ．８とする）の機能を備えている。この勧告Ｖ．８は、モデムの接続シーケンスを規定する。即ち、通信する相互のモデム同士が、どの勧告（モード）に沿った通信方法で通信するかを決める方法である。勧告Ｖ．３４の前手順として勧告Ｖ．８の方法を必ず行うので、勧告Ｖ．３４を採用するモデムでは勧告Ｖ．８の機能を有している。
【０００５】
以下に、勧告Ｖ．８及びＶ．３４（以下単にＶ．８、Ｖ．３４と表現する）の機能を備えたモデムを採用しているファクシミリ装置について説明する。
【０００６】
Ｖ．８及びＶ．３４の機能を備えたモデムを採用したファクシミリ装置においては、発呼局から被呼局に情報を送信する場合、回線接続後、ＩＴＵ−Ｔ勧告Ｔ．３０Fax Handshakingの手順を行う前に、所定のシーケンスを行う。このシーケンスでは、発呼局のモデムと被呼局のモデムとが、ＣＰＵ（中央処理装置）を介さずにモデム自身でネゴシエーション（伝送モードを決めるまでの発呼局と被呼局とのやり取り）を行う。この発呼局のモデムと被呼局のモデムとがネゴシエーションを行うシーケンスが、以下に示すＶ．３４フェーズ２である。
【０００７】
Ｖ．８及びＶ．３４の機能を備えたモデムは、Ｖ．８フェーズ１と、Ｖ．３４フェーズ２からフェーズ４までの合わせて４つのフェーズ処理を行う。この４つのフェーズの中で回線特性の補正や変調パラメータの決定が行われる。この各フェーズで行われることがＶ．３４の主な動作になる。
【０００８】
次にＶ．３４フェーズ２について説明する。Ｖ．３４フェーズ２では、ラインプロービングとモデムの持っている変調オプションを交換することで、Ｖ．３４の基本的設定を行う。まず、Ｖ．８フェーズ１で、発呼局モデムと被呼局モデムの接続が開始される。そしてその後、Ｖ．３４フェーズ２が開始される。このＶ．３４フェーズ２では、Ｖ．８によりＶ．３４で通信することが確定した後、すぐに発呼局と被呼局双方のモデムが持っている変調オプションを交換し合う。その後で原稿の送信側がラインプローブ信号を送信し、ラインプローブ信号によって測定された回線特性とＩＮＦＯデータの内容によって、シンボルレート、プリエンファシスの有無、使用可能なデータレート、キャリア周波数、各送信機の送出レベルを交換する。そして次のＶ．３４フェーズ３に移る。
【０００９】
このＶ．３４フェーズ２においては、モデム自身でネゴシエーションを行うので、ネゴシエーションが不可能であった場合には、リトレーニングをモデムが自動的に行う。回線が細く信号が通り難かったり、ノイズが発生しやすい回線であって回線状況が悪いと、モデムのネゴシエーションが不可能となる。そのような場合には、ネゴシエーションが成立するまで半永久的にモデムはリトレーニングを繰り返す。
【００１０】
ファクシミリ装置に内蔵されたＣＰＵは、モデムのネゴシエーションに介在することが不可能なため、モデムが半永久的にリトレーニングを繰り返す恐れがある。これを防止するために、Ｖ．３４フェーズ２内にタイマを使用している。そして、所定時間内にＶ．３４フェーズ２を抜けることができない場合には、ＣＰＵが回線切断処理を行い、通信エラーとするように設定されている。
【００１１】
【発明が解決しようとする課題】
上記ファクシミリ装置においては、Ｖ．３４フェーズ２において、回線状況が悪く、発呼局のモデムと被呼局のモデムとでネゴシエーションができずに通信エラーとなった場合、その後リダイヤル（再送信）で再度Ｖ．３４通信を行ったとしても、回線状況が悪いままの状態では通信エラーとなってしまう場合があった。
【００１４】
〈構成４〉
構成１または２または３に記載のファクシミリ装置において、送信すべき画像情報を予め蓄積しておく画像メモリを備え、制御手段は、通信エラーが発生したとき上記画像メモリの内容を保存し、リダイヤル処理後、新たな伝送モードが選択されて通信が開始されたとき、上記画像メモリの内容を読み出して送信することを特徴とするファクシミリ装置。
【００１５】
【課題を解決するための手段】
本発明は以上の点を解決するため次の構成を採用する。
〈構成１〉
回線と接続されて通信を行うモデムと、通信すべき画像情報を保持しておく画像メモリと、該モデムの動作と該画像情報の送受信を制御する制御手段と、通信エラーの原因を示す通信管理情報を格納する通信管理情報蓄積手段とを備え、前記制御手段は、前記通信管理情報の通信エラーに応じて再接続が可能と判断したときには、前記画像情報を保存したままとして前記通信管理情報の通信エラーに応じたリダイヤル制御を行い、新たな通信が開始されたときには、前記画像情報を読み出して送信し、リダイヤル処理を繰り返しても通信エラーが発生するときには、前記画像情報の保存を解除してリダイヤルを中止することを特徴とするファクシミリ装置。
【００２６】
【発明の実施の形態】
本発明の実施の形態について図面を参照しながら説明する。なお、具体例毎に、各図面に共通な要素には同一の符号を付す。
本実施の形態に示す発呼局側のファクシミリ装置（以下発呼局とする）及び被呼局側のファクシミリ装置（以下被呼局とする）は、Ｖ．８及びＶ．３４の機能を備えたモデムを採用している。また、伝送制御手順をＩＴＵ−Ｔ勧告Ｔ．３０「一般電話交換網における文書ファクシミリ伝送用手順」の「バイナリ制御手順」に従って行うものとする。
【００２７】
なお、モデムの通信プロトコルを定める規定には、Ｖ．３４以外にも、ＩＴＵ−Ｔ勧告Ｖ．１７、ＩＴＵ−Ｔ勧告Ｖ．２９、ＩＴＵ−Ｔ勧告Ｖ．２７ｔｅｒ（以下それぞれＶ．１７、Ｖ．２９、Ｖ．２７ｔｅｒとする）等がある。Ｖ．３４は、発呼局と被呼局とが回線接続後、ＩＴＵ−Ｔ勧告Ｔ．３０Fax Handshakingの手順を行う前に、発呼局のモデムと被呼局のモデムとが、ＣＰＵを介さずにモデム自身でネゴシエーションを行う。一方、Ｖ．１７、Ｖ．２９、Ｖ．２７ｔｅｒは、回線接続後、直ちに勧告Ｔ．３０Fax Handshakingの手順へと移り、この手順の中でＣＰＵの指示を受けて、発呼局のモデムと被呼局のモデムとがネゴシエーションを行う。
【００２８】
Ｖ．３４はモデム同士のみでネゴシエーションを行うので、データレートを他のモデムよりも高速化することができるという利点がある。一方、Ｖ．３４以外では、ＣＰＵを介してモデム同士のネゴシエーションを行い、データレートがＶ．３４よりもＶ．１７、Ｖ．２９、Ｖ．２７ｔｅｒの順序で低下するから、回線状況が悪くても通信を行うことができる利点がある。なお、Ｖ．１７、Ｖ．２９、Ｖ．２７ｔｅｒの最高データレートは、それぞれ14,400ｂｐｓ、9,600ｂｐｓ、4,800ｂｐｓとなっている。
【００２９】
〈具体例１〉
以下、ファクシミリ装置の構造について説明する。
図１は、具体例１のファクシミリ装置のブロック図である。
【００３０】
図１において、一点鎖線で示す発呼局側のファクシミリ装置１（以下発呼局とする）には、送信原稿２Ａ上の情報を読み取るスキャナ２と、被呼局から受信した情報を受信コピー３Ａ上に記録するプリンタ３と、スキャナ２で読み取った情報を処理し、画像情報としてラインメモリ４へと送信する読取り処理部５ａと、ラインメモリ４から受信した印刷すべき画像情報を処理し、プリンタ３へと送信する記録処理部５ｂとが設けられている。なお、読取り処理部５ａと記録処理部５ｂとで読取・記録処理部５が構成されている。
【００３１】
発呼局１にはまた、被呼局に送信すべき画像情報を、データ圧縮モードに応じてラインメモリ４から読み出しを行いながら画信号に圧縮すると共に、被呼局から受信し、処理された画信号を復元する画像情報圧縮・復元部６と、画像情報圧縮・復元部６で圧縮された画信号がアドレス／データバス７を介して送信され、送信バッファとなって画信号を記録する通信バッファ用ＲＡＭ（ランダムアクセスメモリ）８と、通信バッファ用ＲＡＭ８に記録された画信号をモデム・ＮＣＵ（ネットワークコントロールユニット）インタフェース９を介して送信し、該送信すべき画信号及び制御信号を変調すると共に、被呼局から画信号及び応答信号を受信すると、該画信号及び応答信号を復調するモデム１０と、ＮＣＵ１７とが設けられている。
【００３２】
なお、上記通信バッファ用ＲＡＭ８は、被呼局からの受信時には、受信バッファとなり、モデム１０で復調された画信号及び応答信号を格納する。該格納された画信号及び応答信号は、アドレス／データバス７を介して画像情報圧縮・復元部６へと送信される。また、モデム１０は、Ｖ．８及びＶ．３４の機能を備えたモデムである。
【００３３】
発呼局１には更に、発呼局１全体のシステム制御及び各信号の流れの管理、通信制御、網制御の総括コントロール等を行うＣＰＵ（制御手段）１１と、ＣＰＵ１１のプログラムデータを格納するプログラム用ＲＯＭ（リードオンリメモリ）１２と、後述する通信エラーフラグビットや、発呼する電話番号を格納する通信管理情報蓄積用ＲＡＭ１３と、インタフェース１４を介してアドレス／データバス７と接続された機構制御部１５及び操作・表示部１６が設けられている。
【００３４】
なお、機構制御部１５はドライバや媒体検知センサ等の制御をＣＰＵ１１からの指示に従って行う。また操作・表示部１６はマンマシンインタフェース機能を持ち、ファクシミリ通信に伴う主な機器の操作内容（動作指示）をＣＰＵ１１に伝え、また機器の状態表示内容をＣＰＵ１１から受信し、図示せぬパネルに表示する。
【００３５】
次に発呼局１と被呼局との送受信手順の方法について説明する。
図１に示す発呼局１から被呼局へ制御信号を送信する場合には、制御信号がＣＰＵ１１からアドレス／データバス７、モデム・ＮＣＵインタフェース９を介してモデム１０に送信される。そして、モデム１０で変調されＮＣＵ１７を介して電話回線に送り出され、被呼局へと送信される。
【００３６】
一方、被呼局から電話回線を介して制御信号を受信した場合には、制御信号は、ＮＣＵ１７を介してモデム１０に受信され、モデム１０で復調され、モデム・ＮＣＵインタフェース９及びアドレス／データバス７を介してＣＰＵ１１で受信される。
【００３７】
なお、発呼局が被呼局と回線接続された後、データを送信するためのＩＴＵ−Ｔ勧告Ｔ．３０Fax Handshakingの手順を行う前に、Ｖ．８及びＶ．３４の機能を備えたモデム１０は、Ｖ．８フェーズ１と、Ｖ．３４フェーズ２からフェーズ４までの合わせて４つのフェーズ処理を行う。この４つのフェーズの中で回路特性の補正や変調パラメータの決定が行われる。
【００３８】
以下、４つのフェーズのうち、Ｖ．８フェーズ１と従来の技術に詳説したＶ．３４フェーズ２における、被呼局と送受信動作を行うときの発呼局１の動作について図１に示す図面を参照し、図２、図３、図４に示すフローチャートに従って説明する。図２、図３、図４は実施の形態の発呼局の処理手順を示すフローチャートである。
【００３９】
まず、オペレータが被呼局の電話番号を操作・表示部１６から入力する。すると、入力された電話番号が、インタフェース１４、アドレス／データバス７を介してＣＰＵ１１に送信される。
【００４０】
ステップＳ１でＣＰＵ１１は、通信管理情報蓄積用ＲＡＭ１３内のリダイヤル電話番号格納エリアに発呼する電話番号を格納する。
【００４１】
ステップＳ２でＣＰＵ１１は発呼処理を行う。ステップＳ３でＣＰＵ１１はＣＮＧ信号（発呼トーン）を送信する。ＣＮＧ信号は電話回線を介して被呼局へ送信される。ステップＳ４でＣＰＵ１１は、被呼局からＡＮＳａｍ（Answer Tone）信号を持つ。このＡＮＳａｍを受信すると、被呼局のモデムがＶ．８通信が可能なモデムであると判断してステップＳ５に進み、「否」ならば、ステップＳ１８に進む。
【００４２】
ステップＳ５でＣＰＵ１１は、自分の持っている変調モードを知らせるＣＭ（Call Menu Signal）信号を被呼局へ送信する。すると、被呼局は共通する変調モードのみを有効にして、ＣＭ信号と同じフォーマットでＪＭ（Joint Menu Signal）信号として発呼局に返す。ステップＳ６でＣＰＵ１１はＪＭ信号を検出し、これにより有効な変調モードを確認することができる。ステップＳ７でＣＰＵ１１は、ＪＭ信号から、被呼局がＶ．３４全二重モードであるか否かを判断する。この例に示すファクシミリ装置はＶ．３４半二重モードであるので、Ｖ．３４全二重モードである場合には、ステップＳ１７に進み、回線切断処理を行い、処理を終了する。一方、「否」の場合は、ステップＳ８に進み、ＪＭ信号を受けたことを示す、すべて「０」であるシングルオクテットの信号、即ちＣＪ（Call Joint Signal）信号を被呼局に送信する。
【００４３】
以上ステップＳ３からステップＳ８までがＶ．８フェーズ１である。そして、７５ｍｓｅｃ（millisecond）の後、モデム１０はＶ．３４フェーズ２に入る。ステップＳ９で、ＣＰＵ１１はＶ．３４フェーズ２のタイマをスタートし、フェーズ２が開始される。
【００４４】
ステップＳ１０で、ＣＰＵ１１はＶ．３４フェーズ２が終了すれば、ステップＳ１１に進み、Ｖ．３４フェーズ３へと進み、Ｖ．３４通信制御をそのまま継続する。
【００４５】
Ｖ．３４フェーズ２は、ステップＳ１２でＶ．３４フェーズ２がタイムアウトとなるまで継続されるが、Ｖ．３４フェーズ２がタイムアウトとなってもまだＶ．３４フェーズ２が終了しないのならば、ステップＳ１３に進む。ステップＳ１３でＣＰＵ１１は、通信管理情報蓄積用ＲＡＭ１３内に格納されている、Ｖ．３４通信エラーフラグビットを「１」にして、再び通信管理情報蓄積用ＲＡＭ１３内に格納する。
【００４６】
なお、ステップＳ１２で、Ｖ．３４フェーズ２がタイムアウトとなっても、Ｖ．３４フェーズ２が終了とならないのは、回線状況が悪いためであると考えられる。
【００４７】
ステップＳ１４でＣＰＵ１１は回線切断処理を行い、ステップＳ１５で通信エラー処理を行う。そして、ステップＳ１６でリダイヤル送信制御を行うための準備をし、リダイヤル送信制御へと移る。
【００４８】
なお、上記ステップＳ４からステップＳ１８に進んだ場合、ステップＳ１８で、ＣＰＵ１１は被呼局からＮＳＦ（非標準機能）信号、ＣＳＩ（被呼端末識別）信号、ＤＩＳ（ディジタル識別）信号を受信したことを検出したならば、ステップＳ１９に進み、「否」ならばステップＳ２８に進む。なお、上記ＣＳＩ信号は、オプショナル信号であるので、必ずしも送信されてくるとは限らない。
【００４９】
ステップＳ１８からステップＳ２８に進むと、予め設定されたＴ１がタイムアウトとなるまで、ＣＰＵ１１は、上記ステップＳ３、ステップＳ４、ステップＳ１８、ステップＳ２８の処理を繰り返し、被呼局からの信号を待つ。
【００５０】
ステップＳ２８で、Ｔ１がタイムアウトとなっても被呼局から信号を受信しなければ、ステップＳ２９に進み、ＣＰＵ１１は回線切断処理を行い、ステップＳ１６へと進む。なお、ステップＳ２８からステップＳ２９に進むのは、被呼局が「話中」の場合である。
【００５１】
一方、ステップＳ１８で、ＣＰＵ１１が被呼局からＮＳＦ信号、ＣＳＩ信号、ＤＩＳ信号を受信したことを検出すると、ＣＰＵ１１はＮＳＦ信号、ＣＳＩ信号、ＤＩＳ信号を解析し、被呼局のモデムの能力、即ち通信能力を調べる。そして、ステップＳ１９でＶ．３４の通信能力があるモデムであった場合には、ステップＳ２０に進み、被呼局にＣＩ（Call Indicator Signal）信号を送出し、ステップＳ４に戻る。一方、ステップＳ１９で「否」の場合には、ステップＳ２１に進む。ステップＳ２１で、Ｖ．１７の通信能力があるモデムであった場合には、ステップＳ２２に進み、Ｖ．１７の送信制御へ移行する。一方、ステップＳ２１で「否」の場合には、ステップＳ２３に進む。ステップＳ２３で、Ｖ．２９の通信能力があるモデムであった場合には、ステップＳ２４に進み、Ｖ．２９の送信制御へ移行する。一方、ステップＳ２３で「否」の場合は、ステップＳ２５に進む。ステップＳ２５で、Ｖ．２７ｔｅｒの通信能力があるモデムであった場合には、ステップＳ２６に進み、Ｖ．２７ｔｅｒの送信制御へ移行する。一方、ステップＳ２５で「否」の場合は、ステップＳ２７に進み、ＣＰＵ１１は回線切断処理を行い、処理を終了とする。
【００５２】
次に、上記フローチャートにおいて、ステップＳ１６でリダイヤル送信制御へと進んだ場合の処理について、図５〜図７に示すフローチャートに従って説明する。
図５、図６、図７は、この具体例１によるのリダイヤル時の発呼局の処理手順を示すフローチャートである。
【００５３】
まず、ステップＳ４１でＣＰＵ１１は、通信管理情報蓄積用ＲＡＭ１３内のリダイヤル電話番号格納エリアから、発呼先の電話番号を読み込む。ステップＳ４２でＣＰＵ１１はリダイヤル発呼処理を行う。ステップＳ４３でＣＰＵ１１はＣＮＧ信号（発呼トーン）を送信する。ＣＮＧ信号は電話回線を介して被呼局へ送信される。
【００５４】
すると、ステップＳ４４でＣＰＵ１１は、被呼局からＡＮＳａｍ信号を待つ。このＡＮＳａｍを受信すると、被呼局がＶ．８通信が可能なモデムであるとしてステップＳ４５に進み、「否」ならば、ステップＳ６０に進む。
【００５５】
ステップＳ４５でＣＰＵ１１は、通信管理情報蓄積用ＲＡＭ１３からＶ．３４通信エラーフラグビットを読み込む。ステップＳ４６でＣＰＵ１１は、Ｖ．３４通信エラーフラグビットが「１」であるか否か判断し、「１」であればステップＳ６０に進み、「否」ならばステップＳ４７に進む。
【００５６】
ステップＳ４７からステップＳ５９までは、図２に示すフローチャートのステップＳ５からステップＳ１７までの処理と同様であるので、重複する説明は省略する。
【００５７】
なお、ステップＳ４６からステップＳ４７に進む場合は、被呼局へＶ．８，Ｖ．３４通信が可能である。このケースは、第１回目に発呼処理したときに被呼局が「話中」であり、リダイヤル発呼処理になって、「話中」が解除された場合である。
【００５８】
一方、ステップＳ４４からステップＳ６０に進んだ場合、ステップＳ６０で、ＣＰＵ１１は被呼局からＮＳＦ信号、ＣＳＩ信号、ＤＩＳ信号を受信したならば、ステップＳ６１に進み、「否」ならばステップＳ７３に進む。また、ステップＳ４６で、Ｖ．３４通信エラーフラグビットが「１」であり、ステップＳ６０に進んだ場合には、被呼局から自動的にＮＳＦ信号、ＣＳＩ信号、ＤＩＳ信号が送信されてくるように予め設定されている。
【００５９】
ステップＳ６０で、ＣＰＵ１１は被呼局からＮＳＦ信号、ＣＳＩ信号、ＤＩＳ信号を受信したことを検出すると、ステップＳ６１に進む。
【００６０】
一方、上記ステップＳ６０からステップＳ７３に進むと、予め設定されたＴ１がタイムアウトとなるまで、ＣＰＵ１１は、上記ステップＳ４３、ステップＳ４４、ステップＳ６０、ステップＳ７３を繰り返し、被呼局からの信号を待つ。
【００６１】
ステップＳ７３で、Ｔ１がタイムアウトとなっても、被呼局から信号を受信しなければ、ステップＳ７４に進み、回線切断処理を行い、そして、ステップＳ５８に進み、リダイヤル送信制御を行うための準備をし、ステップＳ４１に戻る。なお、ステップＳ７３からステップＳ７４に進むのは、被呼局が「話中」の場合等である。
【００６２】
ステップＳ６０で、ＣＰＵ１１がＮＳＦ信号、ＣＳＩ信号、ＤＩＳ信号を受信したことを検出すると、各信号を解析し、被呼局のモデムの能力、即ち通信能力を調べる。そして、ステップＳ６１で、被呼局にＶ．３４の通信能力があり、且つＶ．３４通信エラーフラグビットが「０」である場合には、ステップＳ６２に進み、被呼局にＣＩ信号を送出し、ステップＳ４４に戻る。一方、ステップＳ６１で「否」の場合にはステップＳ６３に進む。ステップＳ６３で、被呼局にＶ．１７の通信能力がある場合には、ステップＳ６４に進み、Ｖ．３４通信エラーフラグビットを「０」にクリアし、通信管理情報蓄積用ＲＡＭ１３に格納する。そして、ステップＳ６５に進み、Ｖ．１７の送信制御へ移行する。（モデム１０の伝送モードをＶ．１７の送信制御用に変更し通信を行う。）
【００６３】
一方、ステップＳ６３で「否」の場合は、ステップＳ６６に進む。ステップＳ６６で、被呼局にＶ．２９の通信能力がある場合には、ステップＳ６７に進み、Ｖ．３４通信エラーフラグビットを「０」にクリアし、通信管理情報蓄積用ＲＡＭ１３に格納する。そして、ステップＳ６８に進み、Ｖ．２９の送信制御へ移行する。
【００６４】
一方、ステップＳ６６で「否」の場合は、ステップＳ６９に進む。ステップＳ６９で、被呼局にＶ．２７ｔｅｒの通信能力がある場合には、ステップＳ７０に進み、Ｖ．３４通信エラーフラグビットを「０」にクリアし、通信管理情報蓄積用ＲＡＭ１３に格納する。そして、ステップＳ７１に進み、Ｖ．２７ｔｅｒの送信制御へ移行する。
【００６５】
一方、ステップＳ６９で「否」の場合は、ステップＳ７２に進み、Ｖ．３４通信エラーフラグビットを「０」にクリアし、通信管理情報蓄積用ＲＡＭ１３に格納する。そして、ステップＳ５９に進み、ＣＰＵ１１は回線切断処理を行い、処理を終了する。
【００６６】
なお、図４に示すステップＳ２１、ステップＳ２３、ステップＳ２５、図６に示すステップＳ６３、ステップＳ６６、ステップＳ６９に示す順序で、被呼局のモデムの通信能力が順に低下していく。それ故、可能な限り高速に送信することができるように、処理の順序を決めている。
また、図３のステップＳ１６でリダイヤル送信制御となった場合、自動的に図５に示すフローチャートの処理が開始され、リダイヤル発呼処理が始まる。
【００６７】
このときの送信方法は、フィーダー送信の場合であってもメモリ送信の場合であっても変わらない。即ち、フィーダー送信の場合であっても、まだ原稿を読み込む前であればリダイヤルを実行し、自動的に装置にセットされた原稿を読み込み、１ページ目の送信から処理を開始することができる。また、メモリ送信であれば問題なくリダイヤル処理後に全ての原稿の送信を自動的に開始できる。
【００６８】
〈具体例１の効果〉
ＩＴＵ−Ｔ勧告Ｖ．３４で規定された機能によれば、発呼局のモデムと被呼局のモデムとの間で制御手段の制御無しにトレーニングを行って、データレート決定のための独自のネゴシエーションを実行する。そのネゴシエーションが成立しないで通信エラーによる回線切断処理が行われたとき、通信管理情報蓄積手段がその通信管理情報を格納して保存する。通信エラーの原因を明らかにして、リダイヤル処理後の制御方法を決定するためである。このような場合に、その後リダイヤル処理を実行するとき、制御手段は、ＩＴＵ−Ｔ勧告Ｖ．３４によるモデム独自のネゴシエーションを排除する。そして、制御手段がモデムを制御するネゴシエーションを実行し、制御手段の判断によって、ＩＴＵ−Ｔ勧告Ｖ．１７、Ｖ．２９、Ｖ．２７ｔｅｒといった通信能力による伝送モードを選択する。
【００６９】
以上の構成によれば、リダイヤル処理後再度モデム独自のネゴシエーションを行って通信エラーを繰り返すといった動作を未然に防止できる。
また、リダイヤル後、Ｖ．３４通信が不可能な回線状況であっても、他の伝送モードを用いて確実に通信を行うことが可能になる。
【００７０】
以上のようにして、被呼局がＶ．３４通信を行うことが可能なモデムを備えている場合に、回線状況が悪くて通信エラーになると、自動的にリダイヤル発呼処理を行い、Ｖ．３４で失敗したという履歴表示（フラグ）を残しておく。リダイヤル時には被呼局のモデムの能力に合わせて、Ｖ．３４以外のモデムの伝送モードで送信制御を行うことにしたので、Ｖ．３４通信が不可能な回線状況であっても、確実に発呼局と被呼局との通信を行うことが可能となる。
【００７１】
また、モデムの能力の変更は回線状況に合わせて選択可能となっている、即ち可能な限り高速で送信できるようにモデムの伝送モードが選択されるので、そのときの回線状況で最高の伝送モードでの通信が可能となる。
【００７２】
〈具体例２〉
具体例１では、モデムが主としてラインプロービングを行って通信エラーを生じた場合について、そのリダイヤル時の動作モードの最適化を図るようにした。しかしながら、実際に正常に通信が開始された後も、同様の問題が生じ得る。即ち、モデムが、独自のネゴシエーションを行ってそのネゴシエーションが成立し、通信が開始された後、通信エラーで回線切断処理が行われることがある。
このような場合も、ネゴシエーションが成立しなかった場合に準じて、具体例１と同様の制御を行えば、通信エラーを繰り返すのを防止できる。
【００７３】
図８に、ファクシミリ装置の通信シーケンスチャートを示す。
ファクシミリ装置は、この図の左上から右下に向かって一定の通信手順を実行し、原稿のイメージを送信する。この手順については、既に従来技術の部分で詳細に説明をしたので、ここでは簡単に触れ、具体例２の要点を説明する。
【００７４】
まず、発呼処理を行うと、フェーズ１のネットワーク（回線）への接続が行われる。そして、フェーズ２で、既に説明したラインプロービングが行われ、フェーズ３では、プライマリチャネルでのトレーニングが行われる。そして、フェーズ４では、変調パラメータの交換が行われる。次に、Ｔ．３０のファックスハンドシェーキング（Fax Handshaking）が行われる。ここで手順信号データの交換が終わると、１ページ分のデータ送信に移る。
【００７５】
第１ページのデータ送信は、プライマリチャネルにおいて行われる。また、ファクシミリ送信の場合、１ページ分のデータ送信が終わると、再びＴ．３０Fax Handshakingが行われる。この部分をコントロールチャネルと呼ぶ。このコントロールチャネルは、複数枚の送信を行うときは、１ページ送信毎に設けられる。
【００７６】
コントロールチャネルにおけるＴ．３０Fax Handshakingは、2,400ｂｐｓあるいは1,200ｂｐｓの通信速度で行われる。従って、手順信号データの交換を３００ｂｐｓで行う他の伝送モード、例えばＶ．１７，Ｖ．２９等に較べて信頼性が低い。また、このコントロールチャネルでもモデム自身がＣＰＵ１１の制御によらず独自のネゴシエーションを行う。そして、ネゴシエーションができない場合には、リトレーニングを行うが、これが成立しないと通信エラーとなる。従って、具体例１の場合と同様の問題が生じる。
【００７７】
なお、通信開始後にリダイヤルを行う場合には、自動的に全ての送信原稿のイメージを再送することが必要になる。従って、予め全ての原稿の画像情報を画像メモリに予め蓄積しておくいわゆるメモリ送信を行うことが好ましい。この画像情報は、図１に示した通信バッファ用ＲＡＭ８に格納される。即ち、図１に示したスキャナ２で読み取られた画像情報は、読取り処理部５ａを経て、一旦ラインメモリ４に記憶される。
【００７８】
その後、画像情報圧縮・復元部６のデータ圧縮モードに応じて、ラインメモリ４から画像情報が読み出され、圧縮処理される。このデータは、アドレス／データバス７を通じて通信バッファ用ＲＡＭ８に蓄積される。こうして、全ての送信原稿について、画像情報を通信バッファ用ＲＡＭ８に蓄積した後、その画像情報を順次読み出して送信する。その他の部分についての装置構成は具体例１と変わるところはなく、重複する説明を省略する。
【００７９】
次に、具体例２についての動作を説明する。
図９と図１０には、具体例２の発呼局の処理手順を示すフローチャート（その１）、（その２）を示す。
なお、具体例２は、その処理が新たにステップＳ１より開始しており、これらのステップ表示は具体例１のフローチャートとは対応していない。即ち、具体例２独自のステップを示している。
【００８０】
まず初めに、オペレータが電話番号を操作・表示部１６に入力すると、ＣＰＵ１１はその情報をインタフェース１４を経て認識する。続いて、ステップＳ１で、ＣＰＵ１１は、通信管理情報蓄積用ＲＡＭ１３のリダイヤル電話番号格納エリアにリダイヤルの際発呼する電話番号を格納する。その後、ステップＳ２で、ＣＰＵ１１は、送信原稿２Ａをスキャナ２を用いて読み取る。読み取られた画像情報は、読取り処理部５ａ、ラインメモリ４、画像情報圧縮・復元部６を経て、通信バッファ用ＲＡＭ８に格納される。
【００８１】
次に、ステップＳ３で、ＣＰＵ１１は、発呼処理を行う。更に、ＣＰＵ１１は、ステップＳ４で、ＣＮＧ信号を送出し、ステップＳ５で、ＡＮＳａｍ信号を待つ。このＡＮＳａｍ信号を受信すると、被呼局のモデムがＶ．８通信の可能なモデムであると判断する。この場合には、ステップＳ６に進む。一方、被呼局のモデムがＶ．８通信の不可能なモデムと判断すると、ステップＳ１１に進む。
【００８２】
ステップＳ６で、ＣＰＵ１１は、自分の持っている変調モードを知らせるＣＭ信号を被呼局へ送信する。被呼局は、発呼局の変調モードに対してどれが有効かを提示するＪＭ信号を発呼局に送出する。ステップＳ７で、ＣＰＵ１１は、このＪＭ信号を検出する。その後、ステップＳ８で、ＣＪ信号を送出する。更に、ステップＳ９に進み、モデム１０は、Ｖ．３４フェーズ２の処理に進む。
【００８３】
Ｖ．３４フェーズ２の処理では、発呼側と着呼側のモデムが変調オプションを交換し合い、ラインプロービング信号により回線特性を測定し、シンボルレート、プリエンファシスの有無、使用可能なデータレート、キャリア周波数、各送信機の送出レベルに関する情報を交換する。その後、次のステップＳ１０に移る。
【００８４】
ステップＳ１０では、モデム１０が、Ｖ．３４フェーズ３を実行する。Ｖ．３４フェーズ３では、シンボルレートとキャリア周波数から、イコライザとエコーキャンセラのトレーニングを行う。こうして、図１０に示すステップＳ１４に進む。
【００８５】
このステップＳ１４で、モデム１０は、コントロールチャネルの動作に移る。コントロールチャネルの先頭部分では、実質的に通信に使用される変調パラメータを交換し、トレーニングを行う。これによって、通信できるデータレートを決定する。ステップＳ１４で、ＣＰＵ１１は、コントロールチャネル用タイマをスタートさせる。そして、ステップＳ１５で、ＣＰＵ１１は、モデム１０が変調パラメータの交換とトレーニングを終了してデータモードに進んだかどうかをチェックする。データモードに進むと、次はステップＳ１６を実行する。
【００８６】
ステップＳ１６で、ＣＰＵ１１は、ＩＴＵ−ＴのＴ．３０に従って手順信号を被呼局との間で送受信する。そして、その手続が完了すると、ステップＳ１７に進む。ここで、未送信の画像情報が１ページ以上メモリ内に存在するかどうかを判断する。メモリに送信用画像データが蓄積されていればステップＳ１８に進む。そして、ステップＳ１８では、この画像情報をプライマリチャネルデータとして、１ページ分被呼局に送信する。
【００８７】
送信が終了すると、ステップＳ１４に戻り、ステップＳ１４〜ステップＳ１８までの処理を繰り返し、全てのページについての送信を実行する。全てのページの送信が終了すると、ステップＳ１７からステップＳ１９に進み、回線の切断処理を行ってファクシミリ送信を終了する。
【００８８】
各ページが送信される度に、コントロールチャネルが実行されるが、コントロールチャネルが開始される度にコントロールチャネル用タイマがスタートする（ステップＳ１４）。そして、コントロールチャネル用タイマがタイムアウトになっても、ステップＳ１５において、コントロールチャネルのデータモードに移行しない場合やステップＳ１６において、コントロールチャネルのデータ送受信が完了しないような場合には、何らかの障害が発生したものとしてステップＳ２１に進む。
【００８９】
そして、ステップＳ２１において、通信管理情報蓄積用ＲＡＭ１３内のＶ．３４通信エラーフラグビットを“１”にして格納する。このエラーフラグビットは、モデムがコントロールチャネルにおいて、独自のネゴシエーションを行い、通信エラーが生じたことを表すフラグである。このような通信エラーが生じるのは、例えば通信開始後、回線状況が悪化した場合が考えられる。ステップＳ２２では、回線切断処理が行われ、ステップＳ２３で、通信エラー処理を行い、更にステップＳ２４のリダイヤル送信制御へ進む。
【００９０】
なお、図９のステップＳ５において、ＡＮＳａｍ信号を受信しない場合には、ステップＳ１１に進む。これ以降の処理は、既に図２を用いて説明したものと同様である。図９のステップＳ１１は、図２のステップＳ１８に対応し、図９のステップＳ１２は、図２のステップＳ２８に対応する。また、図９のステップＳ１３は、図２のステップＳ２９に対応する。更に、ステップＳ１１でイエスと判断された場合には、図４に示した処理が実行される。そして、図４のステップＳ２０の処理を終了すると、図９のステップＳ５に戻る。その他の処理は、図４で示した通りとなる。
【００９１】
一方、リダイヤル送信制御が実行される場合は、実質的に具体例１で説明した図５〜図７までの処理と同一となる。即ち、図１に示した通信管理情報蓄積用ＲＡＭ１３のリダイヤル電話番号格納エリアから発呼元の電話番号を読み込んでリダイヤル処理が実行される。そして、通信エラーフラグビットを読み込む。これが“１”の場合には、図６に示したステップＳ６３以降の処理によってモデム独自のネゴシエーションを排除し、ＣＰＵ１１が介在するネゴシエーションが実行される。
【００９２】
こうして、伝送モードが決定されると、図１に示した通信バッファ用ＲＡＭ８に格納した送信原稿についての画像情報を読み出し、全ての画像情報の送信を実行する。この送信手順等は、Ｖ．１７、Ｖ．２９、Ｖ．２７ｔｅｒに規定された通りの手順で実行される。
【００９３】
〈具体例２の効果〉
上記のように通信が開始された後、コントロールチャネルにおいて、モデムが独自のネゴシエーションを行って通信エラーが生じたとき、具体例１と同様の制御を行えば、回線状況が悪化しているとしても、通信エラーを繰り返すのを防止できる。
なお、通信が開始された後に通信エラーが生じて、自動的にリダイヤル処理を実行する場合には、送信原稿の画像情報が既にメモリに格納されていることが好ましい。これで、通信再開後もオペレータの介在無しに必要な全ての通信を自動継続できるという効果がある。
【００９４】
〈具体例３〉
通信エラーの発生原因によっては、リダイヤル処理をしても再接続が不可能な場合がある。その場合には、リダイヤル処理を止めたり、画像メモリの内容を保存しないでおけば、無駄なリダイヤル処理を防止して、画像メモリを有効に利用できる。
被呼局の機能上通信ができないきは、再接続できないからこれに該当する。
繰り返し通信エラーが発生するときも同様である。
オペレータによる強制的な回線切断は、再接続できない特別の理由によることが多い。
【００９５】
更に、通信エラーの原因に応じて、すぐにリダイヤル処理を実行すれば再接続可能な場合と、しばらく待機してからリダイヤル処理を実行したほうがよい場合がある。これを判断して待機時間を設定すれば、無駄なリダイヤル処理と通信エラーの繰り返しを防止できる。
【００９６】
通信エラーの原因によっては、リダイヤル処理を繰り返せば再接続可能な場合と、リダイヤル処理を繰り返しても再接続が不可能な場合とがある。これを判断して、リダイヤル処理を繰り返す制限回数を設定すれば、無駄なリダイヤル処理と通信エラーの繰り返しを防止できる。
【００９７】
こうした通信エラーに基づくリダイヤル制御を完了するまでは、通信エラーの原因を表示する情報を通信管理情報蓄積手段に保持しておき、これをいつでもＣＰＵ１１が参照できるようにしておくことが好ましい。通信エラーに基づくリダイヤル制御を完了するのは、リダイヤル処理により再接続されてその通信が完了するか、リダイヤル処理が中止されたときである。
【００９８】
以上のような観点にもとづいてなされた具体例３の発明の説明をする。
図１１は、具体例３のパラメータ説明図である。
具体例３を実施するにあたっては、図１に示した通信管理情報蓄積用ＲＡＭ１３に、この図に示すような各種のパラメータを記憶する。この図に示すように、通信管理情報蓄積用ＲＡＭ１３には、エラーコード記憶部２１、リダイヤル回数格納部２２、リダイヤル間隔格納部２３、リダイヤル有無表示部２４及び通信結果格納部２５が設けられる。
【００９９】
エラーコード記憶部２１には、後で説明するような内容のエラーコードが記憶される。エラーの種類を表示するためである。リダイヤル回数格納部２２には、通信エラーが生じた後、何回リダイヤルをするかという回数が格納される。ここには、製品出荷時に適当なデフォルト値が記憶される。また、オペレータによって入力された任意の数値が記憶される。この具体例では、通信結果の如何によって自動的にＣＰＵ１１がこの回数を決定する。
【０１００】
リダイヤル間隔格納部２３には、「話中」等によってリダイヤルを失敗した場合に、何分おきにリダイヤルを実行するかといった指示を格納する。これもＣＰＵ１１によって通信結果に応じて設定される。リダイヤル有無表示部２４は、リダイヤルをすべきかどうか、例えばリダイヤルをしても無駄な場合にはリダイヤルをしないといった表示データを格納する部分である。
【０１０１】
通信結果格納部２５には、正常終了の場合には正常終了、通信エラーの場合にはどういった原因でエラーが生じたかといった情報が格納される。この情報には、さらに、例えば相手方ファックス番号、送信の線密度、圧縮方式、誤り訂正機能の有無、伝送時のデータレート、その他各種の情報が付加される。これらの情報によって、通信エラーがどういった原因で発生し、その通信エラーが発生した場合には、リダイヤル回数を何回にし、リダイヤル間隔を何分にすればよいかといった判断を行うことが可能になる。
【０１０２】
図１１中の破線に示した矢印は、通信管理情報蓄積用ＲＡＭ１３に記憶された各種のパラメータを利用して、ＣＰＵ１１が所定の処理を行う際の手順を示す。即ち、Ｘは、通信結果格納部２５に格納された内容に基づいてエラーコードを生成する処理である。その生成した結果得られたエラーコードがエラーコード記憶部２１に記憶される。
【０１０３】
また、Ｙは、エラーコード記憶部２１に記憶されたエラーコードに基づいてＣＰＵ１１がリダイヤル回数、リダイヤル間隔、リダイヤルの有無等を決定し、これらをリダイヤル回数格納部２２、リダイヤル間隔格納部２３及びリダイヤル有無表示部２４に格納するためのリダイヤル判定処理を示している。
【０１０４】
図１２には、エラーコード生成処理とリダイヤル判定処理の説明図を示す。
この図の最も左の欄には、通信が成立しない状態の種類を示す。また、その右側の欄には、判断要素を示す。そして、その更に右側には、エラーコードの例を示す。ＣＰＵ１１は、判断要素に従って、図の左側に示すような状態であることを認識し、その右側に示すようなエラーコードを生成する。そして、そのエラーコードに基づいて、リダイヤルの有無やリダイヤル間隔、リダイヤル回数等が決定される。
【０１０５】
例えば、受信側が通話中でビジートーンが検出された場合には、エラーコードを“１１１１”とする。この場合、リダイヤル有りとする情報をリダイヤル有無表示部２４に格納すると共に、リダイヤル間隔やリダイヤル回数を、例えばオペレータの設定したままあるいはデフォルトの状態にしておく。次に、エラーが頻発して通信が切断された場合を考える。これは、例えば回線不良が原因と考えればよい。このときには、ＣＰＵ１１がエラー原因を調べるポストコマンドを発するとＲＴＮが受信される。このような場合には、エラーコードを“３２１０”とする。この場合、リダイヤルを行うとするものの、回線不良が回復する時間を考慮すると、リダイヤルの間隔をあまり短くするのは好ましくない。
【０１０６】
そこで、例えばリダイヤル間隔を５分とする。更に、数回リダイヤルを行っても状況が変わらない場合には、回線が直ちに復旧する見込みがないと判断してよい。そこで、リダイヤル回数は３回程度に設定する。
【０１０７】
次に、トレーニング中のエラーによって、2,400ｂｐｓといった最低の通信速度でも通信エラーになった場合を考える。この場合には、これ以上ＦＴＴフォールバックができない。回線状態が悪くなければ、そのまますぐに再接続が可能とも予想できる。このときは、エラーコードを、例えば“２３４５”とする。そして、必要最小限の時間だけ間隔を空けてリダイヤルを実行する。従って、リダイヤル間隔を３分とする。また、この場合には、通信が成立するまでリダイヤルを繰り返せばよいから、例えばリダイヤル回数を５回に設定する。
【０１０８】
今度は、例えば受信側が、受信中に紙詰まりや紙無しで受信続行不能になった場合を考える。あるいは受信側が受信中に停電によってパワーオフになった場合を考える。これは、ポストコマンドに対して３回とも無応答であるといった状態で判断できる。このときは、エラーコードを“３１１１”とする。こうした場合、受信側で受信用紙をセットする時間やあるいは停電が回復するまでの時間を考慮すると、短時間でリダイヤルをしても無駄となる。そこで、リダイヤルの間隔を１５分というように長い時間に設定する。
【０１０９】
また、それだけ間隔を空けてリダイヤルを行っても、更に接続が不可能な場合には、他の原因により容易に回復できないことも考えられる。そこで、無駄なリダイヤルを防止するために、リダイヤル回数を２回と限定する。
【０１１０】
次に、送信中に送信側が停電した場合を考える。この場合は、エラーコードを“３５００”にする。リダイヤルは停電が回復すればすぐに実行すればよい。リダイヤル回数は自由に設定すればよい。
【０１１１】
次に、受信機がパワーオフのため呼び出しに応じない、あるいは受信側が電話機のため音声が返ってきたというような場合、呼接続待ちタイムアウトという状況でこの状態が判断できる。このときは、エラーコードを“１２ＡＡ”とし、リダイヤルをしないと決定する。即ち、リダイヤルをしても必ずしも受信側で正しい応答が行われないと判断されるからである。
【０１１２】
また、発呼中に発呼側のオペレータが停止スイッチを押し下げて送信をキャンセルした場合、あるいは送信中に送信を停止するスイッチを押し下げて通信が中断されたりキャンセルされたりした場合を考える。これらは、ストップキーを押し下げたことを検出することにより判断できる。このとき、エラーコードは“１００１”あるいは“３Ａ００”とする。こうした場合、オペレータの側に特別の事情があると考えられるから、自動的にリダイヤル処理をするのは不適切である。従って、リダイヤルをしないという設定を行う。
【０１１３】
また、親展送信を行った場合に、受信側にその機能がないことがある。相手方に親展受信機能がないかどうかは、ＮＳＦ信号等の検出ビットを利用して判断することができる。また、中継依頼送信等を要求した場合、受信側にその機能がないことがある。これも同様の方法で検出が可能である。こうした場合、エラーコードを“５６７８”あるいは“５６７９”と設定する。これもリダイヤルをする意味がないからリダイヤルをしないと設定する。
【０１１４】
以上のようなエラーコードの形式は、番号や記号等を組み合わせた任意の形態でよい。送信側や受信側から見たときに、それぞれ数多くのエラー形態があるため、分類可能な判別しやすい桁数で表現するとよい。例えば、図の例のように３〜４桁程度の１６進数の英数字を用いると表現がしやすい。更に、先頭の数字が、例えば“１”で始まれば受信側につながる前のエラーであるとか、“２”で始まれば手順上のフェーズＢでのエラーであるといった分類をしておくと判断がしやすくなる。なお、リダイヤルの間隔や回数等については、エラーコードを見て、オペレータが手動で設定するようにしても構わない。
【０１１５】
図１３には、具体例３の動作フローチャートを示す。
この図により、上記のような具体例３のファクシミリ装置の動作を説明する。なお、このフローチャートに示す動作に移行する前に、ファクシミリ装置は既に、発呼、ネゴシエーション等を経て、原稿の一部を送信し始めている。
【０１１６】
まず、ステップＳ１で、通信エラーが発生すると、ステップＳ２で、送信原稿の画像情報を保存したままにする。即ち、図１に示した通信バッファ用ＲＡＭ８に対し、メモリ送信用として予め読み込んだ全ての原稿の画像情報を、消去させないように保存しておく。通常は、回線を切断すると自動的にメモリ中の画像情報が消去されてしまうからである。次のステップＳ３において、通信エラーが発生したそのときの状態を通信結果格納部２５（図１１）に記憶する。そして、ＣＰＵ１１は、この通信結果に基づいて、既に説明した要領でエラーコードを生成して、図１１に示したエラーコード記憶部２１に記憶する。
【０１１７】
更に、ＣＰＵ１１は、そのエラーコードに基づき、図１１に示すリダイヤル有無表示部２４にリダイヤルの有無、即ちリダイヤルをすべきかどうかの情報を記憶する（ステップＳ５）。次のステップＳ６では、この情報を参照してリダイヤルが必要かどうかを判断する。リダイヤルが必要であればステップＳ７に進み、リダイヤル回数とリダイヤル間隔とを決定し、図１１に示すリダイヤル回数格納部２２とリダイヤル間隔格納部２３に記憶する。
【０１１８】
次のステップＳ８で、リダイヤルのためのタイマをセットする。そして、ステップＳ９で、時間待ちを行う。タイムアップした場合には、ステップＳ１０に進み、リダイヤルを実行する。その後通信が正常に終了するかどうかを監視する。なお、このとき、既に具体例１や具体例２を用いて説明した要領で、ＣＰＵ１１の制御によるネゴシエーションが実行され、所定のデータレートでの通信が実行される。
【０１１９】
ここで、通信が正常終了すれば処理を終わる。また、通信エラーが生じた場合には、ステップＳ１１からステップＳ１２に進み、その通信のエラーコードを生成する。次にステップＳ１３で、記憶されている前回のエラーコードと今回のエラーコードとを比較する。前回のエラーコードと今回のエラーコードとが等しい場合には、ステップＳ１４で、リダイヤル回数のデクリメントを行って、その結果をリダイヤル回数格納部２２に格納する。ステップＳ１５でこのリダイヤル回数がゼロより大きいか判断する。リダイヤル回数がゼロより大きければステップＳ８にもどり、再び、リダイヤルを繰り返す。リダイヤル回数がゼロならば、これ以上のリダイヤルをしないで、ステップＳ１６へ進み、通信エラー表示処理を行う。
【０１２０】
ステップＳ１６において、画像情報の保存を解除するのは、メモリ送信用に保存していた画像情報を開放し、他の通信に利用できるようにするためである。リダイヤルをしないと判断された場合には、それ以上画像情報を保存しておくと、他の処理の効率を低下させ、メモリ資源が無駄になるからである。
ステップＳ１７において、通信エラー表示を行うのは、これ以上リダイヤルをしない旨をオペレータに通知して、通信エラーに対する後処理をオペレータに要求するためである。この通信エラー表示は、ファクシミリ装置の操作・表示部１６（図１）に表示する。
【０１２１】
一方、ステップＳ１３で前回のエラーコードと今回のエラーコードとが異なると判断されたときは、ステップＳ２に戻って、新たな通信エラーが発生した場合の処理を実行する。
なお、通信エラーが多発する回線では、上記ステップＳ１３で、前回のエラーコードと今回のエラーコードとが異なると判断されたときに、ステップＳ２に戻って、リダイヤル回数やリダイヤル間隔を新たに設定するようにした場合、いつまでもリダイヤルが終了しないことが考えられる。
【０１２２】
そこで、前回のエラーコードと今回のエラーコードとが異なると判断されたとき、そのままステップＳ１６に進んで、通信エラー表示処理を行うようにしてもよい。また、エラーコードの内容にかかわりなく、リダイヤル回数に上限を設けて、合計リダイヤル回数が上限をこえた場合には、無条件にステップＳ１６に進んで、通信エラー表示処理を行うようにしてもよい。
【０１２３】
〈具体例３の効果〉
以上説明したように、通信エラーが発生したとき、その通信エラーの原因を示す通信管理情報を収集して、リダイヤル処理により再接続が可能と判断した場合には画像メモリの内容を保存し、リダイヤル処理の後、新たな伝送モードが選択されて通信が再開されたとき、その画像メモリの内容を読み出して送信するようにすれば、自動的なリダイヤル処理が可能になる。また、再接続が不能な場合にリダイヤル処理を繰り返すという無駄も防止できる。
【０１２４】
また、通信エラーの原因に応じてリダイヤル処理を実行するまでの待機時間やリダイヤル処理を繰り返す制限回数を設定することによって、無駄なリダイヤルを数多く繰り返す無駄を防止することができる。こうして、リダイヤル制御を完了するまで、通信エラーの原因を表示する情報を通信管理情報蓄積手段に保持しておき、これを制御手段が参照することによって、常に最適なリダイヤル制御が可能となる。
【図面の簡単な説明】
【図１】具体例１のファクシミリ装置のブロック図である。
【図２】具体例１の発呼局の処理手順を示すフローチャート（その１）である。
【図３】具体例１の発呼局の処理手順を示すフローチャート（その２）である。
【図４】具体例１の発呼局の処理手順を示すフローチャート（その３）である。
【図５】具体例１のリダイヤル時の処理手順を示すフローチャート（その１）である。
【図６】具体例１のリダイヤル時の処理手順を示すフローチャート（その２）である。
【図７】具体例１のリダイヤル時の処理手順を示すフローチャート（その３）である。
【図８】ファクシミリ装置の通信シーケンスチャートである。
【図９】具体例２の発呼局の処理手順を示すフローチャート（その１）である。
【図１０】具体例２の発呼局の処理手順を示すフローチャート（その２）である。
【図１１】具体例３のパラメータ説明図である。
【図１２】エラーコード生成処理とリダイヤル判定処理の説明図である。
【図１３】具体例３の動作フローチャートである。
【符号の説明】
１ ファクシミリ装置
１０ モデム
１１ ＣＰＵ（制御手段）

Claims (1)

1. 回線と接続されて通信を行うモデムと、通信すべき画像情報を保持しておく画像メモリと、該モデムの動作と該画像情報の送受信を制御する制御手段と、通信エラーの原因を示す通信管理情報を格納する通信管理情報蓄積手段とを備え、
   前記制御手段は、前記通信管理情報の通信エラーに応じて再接続が可能と判断したときには、前記画像情報を保存したままとして前記通信管理情報の通信エラーに応じたリダイヤル制御を行い、
   新たな通信が開始されたときには、前記画像情報を読み出して送信し、
   リダイヤル処理を繰り返しても通信エラーが発生するときには、前記画像情報の保存を解除してリダイヤルを中止することを特徴とするファクシミリ装置。

Images