More from: FAX

もっと勉強してきて欲しい

現場のFAX機の入れ替え作業にメーカー(〇コー)からCEさんが来てくれた。
元のFAX機から宛先や設定を引き継いでくれることになっていたので私は現場には行かずに電話対応で済ませることにしていた。
もしなにも問題無ければ作業完了の報告を受けるだけだったんだけど、作業開始予定時刻を過ぎてすぐに電話が来てしまった。
話を聞くと宛先の一つ(データ転送先のサーバー)のログインユーザーとパスワードを知りたいとのこと。
これは元のFAX機(EL-6000)からバックアップしたデータにそのまま書かれているのでそれを見て欲しいと言ったところ、どこに書かれているのか判らないとのこと。
#電話でユーザー名やパスワードを口に出して伝えるようなことはしたくないため
念のため私の方でも同じ機種からバックアップしたファイル(”,”区切りのCSVファイル)を見ながら話をして、フィールドを教えたんだけど何故か通じない。
もしかして?と思って旧機種に関して聞いてみたら触ったことも無く操作方法を含めて全く知らないとのこと。
おいおい、入れ替え対象の機種でデータ引継ぎの必要があるんだから事前にバックアップデータの形式とかを調べてから来いよなぁ・・・
しかも元の機種のバックアップデータから新機種(FAX 5520)へ登録するためのファイルの変換は手作業でやっているという。
ここまで聞いて「馬鹿か?」と思ったよ(笑)。
専門にやっているわけでは無い私ですら以前の入れ替え時(SL3400からEL-6000)に手打ちが面倒なのでスクリプトを書いて変換したほどなんだから、毎日のように同様な作業が発生するメーカーさんが手作業でやっているなんて信じられないよ!
手作業ってことはタイプミスの可能性もあるし、そもそも作業量が多くなって効率が悪いのは火を見るより明らかだ。
エクセルとかを使えば変換用のツールを作るのはそれほど難しくは無いし、一度作っておけば次からはミスなく変換できるのにねぇ。
結局、問題の宛先は新しい機種のWEBインターフェースの使い方を教えて貰って私が新規に登録したよ。
やっぱりリ〇ーさんの機種を採用するのは今回で最後にしたほうが良さそうだな。

←クリックしてくれると嬉しいです。

10年前のFAX?

現場のFAX機がエラーを出しているというのでリモートでチェックしてみたらなんと紙詰まりorz
いや、こんなことで連絡してくるなよなぁ・・・と思いつつも現場に指示して対処して貰ったところ無事に受信できるようになった。
というか、受信はしていたんだけど、紙詰まりのためにサーバーへの送信が出来ていなかったのが順次送られるようになったというのが正しい。
送られてきたFAXの内容をサーバーにログインして見てみると、ヘッダーに印字された送信時刻がなんと2009年!
そんな前のFAXもFAX機に滞留していたのか?!と思ったが、内容を見ると日付の箇所が今日になっているので別に古い受信データでは無かった(汗)。
#そもそも2009年の時点ではこのFAX機では無かったし・・・
ヘッダー部に印字されるのは送信側のFAX機に設定されている日時なので、送信してきた相手側のFAXの時計が10年以上遅れているんだな(笑)。

←クリックしてくれると嬉しいです。

FAXが送れない?

ユーザーから「特定の相手にFAXが送れない。FAX番号を限定して受信している相手なので、FAX機の設定でどうにかならないか?」との連絡を貰った。
ちょっと待って、相手のFAXが番号を見ているということだけど、それはどのレベルでの話?ということで、回線レベルなのかFAX機レベルなのかという話をした。
その説明をしている間にユーザーが相手の番号の先頭に”186”を付けたら無事に送れたということだったので回線レベルの話だということが判明。
ということは、FAXに使っている回線(ISDN)は発信者番号通知がデフォルトで非通知になっているということ。
それなら話は簡単で、問題の相手にFAXを送る時は186を付けて送れば良いだけ。
ま、今後別の相手でも同じことが起きるかもしれないし、別に通知をしないメリットは無いので通知にするように業者に頼んで見るとのことだった。
それにしてもISDNって契約時に特に指定しないと通知の状態の筈なので、わざわざ非通知にして契約したんだな。

←クリックしてくれると嬉しいです。

またRidocでトラブル?

遠隔地の現場から受信したFAXがRidocのフォルダに入らないとの連絡が来た。
ここはつい先日もクライアントPCのRidocDeskNavigatorLt.がエラーを出して再インストールが必要になった現場。
今度はサーバー側のトラブルかと思い、リモートでサーバーに入ってチェックしてみるとサーバー自体には異常は見られない。
FAX側に表示されたというエラーコードを頼りにググってみると、出て来たのはこのブログの過去ログ(汗)。
それによるとFAX機とサーバーの間の通信に障害が発生した場合に起きる問題らしく、実際にFAX機がpingに応答しなくなっている。
なので現地に連絡してLANケーブル周りを点検してもらうことにして、こちらではpingの応答を待っていると10分ちょっとで応答が帰って来るようになった。
早速サーバーとFAX機に接続して状況を見ると、受信したFAXがサーバーに届いていて、PCでも見えるようになったとのこと。
聞くと、LANケーブルは挿してあるように見えたが、念のため弄っているとFAX機のエラーが消えたとのこと。
直ったのは良かったんだけど、LANケーブルを交換した方が良いかもぁ、、、

←クリックしてくれると嬉しいです。

苦労した・・・

遠隔地のFAX(RICOHのEL6000)がいきなりエラー表示を出してしまった。
ちょうど私がリモートで宛先設定をしていて、変更内容を保存しようと”適用”ボタンを押したら反応が無い。
おかしいと思って原因を考えていると、その現場から「FAXが変な画面を出してなにも出来なくなった」との連絡が来た。
詳しい状況を聞くと、液晶画面に起動時に表示される”Under Processing”という画面と、見たことも無いエラー画面が交互に表示されているという。
ソフト的なエラーなら電源の再投入で復帰することが多いので、先ずは電源を入れ直して貰ったが、それでも同じ画面の繰り返しだとのこと。
どうにも手に負えそうにないのでメーカーサポートに連絡して状況を説明、何度かやり取りを繰り返すと、エラー内容が実はあまり出ないものらしく、制御基板の交換が必要かも?とのこと。
とにかく実機を見ないとなんとも言えないということなので、現地の責任者と調整して貰って来て貰うことになった。
ちょうど同じ型のFAX機を別途購入したばかりなので、替わりに設置することにして最低限のネットワーク設定までして貰った。
後は私が遠隔から設定をすることになるんだけど、スキャンtoフォルダの機能を使おうとして大嵌りorz。
どう設定しようが転送先のPCのフォルダにスキャンした内容が転送されない。
故障した同型機では問題無く転送できていたのでPC側の問題とは思えなかった。
いろいろと調べる内に公式サイトに「Windows10のPCに送信できない場合があり、その場合はファームウェアの更新が必要で、保守契約の内容によっては有償になる」という記述を発見。
確かに転送先のPCのOSはWindows10なのでファーム更新が必要なのかも?その場合はお金がかかるのかぁ、、、と思い現地の責任者にその旨を知らせると、別のPCならWindows7なのでそちらに転送できないか?とのこと。
試しにそちらのPCに転送するように設定すると、嘘のように問題が解決した。
いやぁ、解決したから良いけど、今日はほぼ一日この問題にかかりっきりだったな(汗)。
ちなみに最初に故障したFAXのエラー画面はこんなの

EL6000のエラー表示

←クリックしてくれると嬉しいです。

迷惑なFAX?

通常の電話回線にしつこくFAXから着信がある。
それもしつこく何度も何度も。
放っておくとしばらくなり続けているところを見ると一定の呼び出し回数で勝手に切れることも無いようだ。
かといって受話器を取って切るとまたすぐに着信する。
その部署の人達は電話が大切な仕事の道具なので、電話回線が塞がれてしまうと業務妨害になる。
幸いにして1時間ほどでこの攻撃(?)は一応収まったが、どこの誰がこんな嫌がらせをしてくるんだろう?

←クリックしてくれると嬉しいです。

あれ?転送出来ない???

ユーザーから「FAXが受信したFAXデータがファイルサーバーに入っていない。」という連絡が来た。
使っているのはRICOHの「RIFAX EL-6000」というFAX専用機で、受信したFAXをtiff形式にしてファイルサーバーの特定ディレクトリにftpで転送するようにしてある。
この転送がどうもうまくいっていないようで、ファイルサーバーの中にはここ数日で受信しているデータが全く入っていない。
最初は転送設定が狂ってしまったかと思い見てみたが特に問題は無い。
このFAX機はスキャナとしても使えるので、スキャンデータ保存用の宛先も設定してあって、そちらにはちゃんと転送出来ているのでサーバー自体がftp接続を拒否しているわけでもない。
転送されないのはFAX受信データだけなので、試しに受信データ用の宛先にスキャンデータを転送してみたところ、下の写真のエラー(ED0601)が出てデータの送信が出来なかった。

EL-6000のエラー表示

EL-6000のエラー表示


つまり問題は受信データ用の宛先にあることが判明。
そこでサーバー内の受信データ用ディレクトリの中を見ると過去に受信して転送されたファイルが6000個余りあったので、ファイル数が多すぎて駄目なのかと思い試しに自サーバーからlocalhostにftp接続して適当なファイルを送信してみると問題無く送信された。
ということはファイル数が多すぎて駄目と言うわけでも無さそう・・・
うーん、なんだろう?としばらく悩んだ後で駄目元でディレクトリ内のファイルを整理して数を減らしてみたところあっさりと解決した。
FAX機の内部でどんな処理をしているのか判らないけど、smb転送の場合と同じくftp転送の場合もファイル数が多すぎると駄目らしい・・・
なのでユーザーには原因を説明してあまりファイルを溜めないようにお願いしておいた。

←クリックしてくれると嬉しいです。

そりゃぁ受信出来ないよ

現場から「FAXが全然来ない」という連絡が来た。
時々FAXシステムが不調になることがあるので、そのせいかと思ったがすぐに解決。
なんとFAXに接続してある電話線が抜けていたとのこと。
何故抜けていたかは不明だけど今使っているFAXは目立たないところ(完全に裏側)に電話線の挿入口があるので、なにかを引っ掛けて抜けると言うことはまず無い筈。
ということは誰かが意図的に抜いた?

←クリックしてくれると嬉しいです。

不良品じゃないの?

リコーのFAX「EL-6000」を導入した。
職場のFAXの大半を入れ替えたわけだが、評判は芳しく無い・・・と言うかはっきり言って”悪い”。
評判が悪いのはいくつか理由があるが、その中に「前の機種より送信エラーになることが多い(ような気がする)」というのがある。
聞くと導入当初からエラーが出ていたと言うことなので、先だってメーカーさんのサポートに協力して貰って原因を調査するためにエラーログの採取をするように設定して貰った。
先日もある現場からFAXを送ろうとしたがエラーになって送ることが出来ないと連絡が入ったので早速メーカーさんに連絡して対処して貰ったところ、原稿を読み取る部分に紙が詰まったのが原因だとのこと。
その時は原稿を取り除いたところ復旧したと言うことだった。
ところが今日になってメーカさんのサポート担当の方から連絡が入り、「原稿の取り除き方によってはエラーがリセットされないことがある」とのこと。
その説明をしたいので一度訪問させて貰いたいとのことだったので、後日訪問を受けることになった。
でもなぁ、これってはっきり言って機械自体の不具合なんじゃないだろうか?
今の機械はソフトウェアでいろいろと制御しているから、原因がハードにあるかソフトにあるかは私には判断できないけど、もしソフト側の対処で済むならファームウェアの更新をして貰いたいな。
他にもいろいろと改善して貰いたいところはあるけどね(汗)。

←クリックしてくれると嬉しいです。

通信時間が安定しない

FAX機の通信時間が前の機種より長くなったと言う”クレーム”が入っているので、メーカーさんにもお願いして対処方法を探している。
つい先日メーカーさんから通信モードの変更に関しての提案があったので、実験用に機材を貸し出して貰ってテストを行ってみたが、通信モードを変更してある筈の機材でも顕著な改善は見られなかった。
というか殆ど測定結果に有意な違いは見られなかった。
その旨をメーカーさんに伝えると、一緒にテストをさせて欲しいという申し出があり、折角なので一緒にテストをして貰った。
まずは通信モードの変更がちゃんと設定されているかを確認して貰ったところ指定どおりに設定されているとのこと。
そこで再度テストを行ってみたが、結果はやはり変わらず通信モードの変更がうまくいっていないとしか思えない。
ところが、その後何度か行ったテストでは、前の機種ほどでは無いが通信時間が短縮されるケースがあり期待を持たせてくれたが、その結果を出した時の設定がバラバラでどのように設定すれば改善されるかが判断出来ない。
なにせ設定を変えてテストして結果に違いが無くても、同じ条件で再度テストすると改善されたり、設定を元に戻して行っても改善されたままだったりという状態。
後半はテスト毎に通信管理レポートを出力したが、そこに表示される通信時間が実測値とかけ離れていたりしたので、レポート自体も信用できなくなってきた。
こんな調子だったので一度テストを中断してメーカーさんに結果を持ち帰って貰って再度調査をして頂くことになった。
今日になってレポートの表示におかしな点がある(同じ文書番号が連続して出現したり)ので、これは試験に用いた機材になんらかの不具合がある可能性が高いと言うことで、別の機材に変更させて欲しいとの連絡が来た。
ということは、テストは一からやり直しと言うことになるなぁ、、、
まぁ、これで改善方法が見つかれば良いんだけどね。

←クリックしてくれると嬉しいです。