プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

UPS(OMRON BW55T)のバッテリー交換

先日、仕事が立て込んでいたので、休みの日の昼過ぎに仕事場に行くと、ピーピー音が鳴ってます。

あれ?やばそうだな、多分この手の音はUSP関係だろうな、と思いつつ仕事部屋に入ると、案の定、UPS(OMRON BW55T)から音がしていました。

LCDインジケータを見ると、こんな感じです。

(上記はブザーを止めた後の状態です)

とりあえず、一番上のボタン(「ブザー停止 / 決定」スイッチ)をおしたら、ブザーは止まりました。嫌な感じに赤いマークがついてますね。

メインのPCは、これにつながっているのですが、電源を入れると一応問題なく動きます。なので、この状態でオムロンのページを見てみると、上記の赤いインジケータは『バッテリーの交換サイン』とのことです。

ということで、 ORMON の UPS もバッテリーを更新したのですが、こちらは初めての作業だったので一応メモっておきます。

交換用バッテリーの発注

とりあえずは交換用バッテリーを手に入れます。この機種は、購入後3年なら、無償で交換してくれるそうなので、改めて調べてみると、2019年9月に購入しています。ということは、おおよそ4年半使っている計算になりますかね?

この機種のマニュアルを見ると、室温25℃で5年が期待寿命と記載されています。この仕事部屋は、夏場は西日でめっちゃ暑くなるので、まあ妥当な寿命といったところでしょうか?

ということで、交換用バッテリー BWB55T を注文して、しばし到着をまちます。

BWB55T|製品情報|OMRON 無停電電源装置(UPS)

交換作業

交換用バッテリーが到着したら、早速作業です。

まずは、 UPS につながっているコンセントを全部抜いて、UPS を停止します。次に、 UPS 本体も AC コンセントから抜いておきます。

で、 UPS を引っ張り出してきて、カバーを開けます。カバーは工具もいらず、ずらせば簡単に外せました。

で、ラペル(写真の PULL と書いてあるシールっぽいやつ)を持って、おもむろにバッテリーを引き出します。

横からだとこんな感じ。

あとは、端子を外して、新しいものと入れ替えて再度端子を接続して、格納します。

端子のコードがそれなりに長いので、 APC ES-550M1 のバッテリー交換の時よりも簡単な印象です。

自己診断とバッテリー寿命カウンタのリセット

BWB55Tの製品ページにも書いてありますが、バッテリーの交換が終わったら、自己診断とバッテリー寿命カウンタのリセットという作業を行う必要があるそうです。

この手順によると、 AC プラグをコンセント(商用電源)から抜いた場合は自己診断を行う必要はないみたいなのですが、一応やっておきます。

UPS を元の位置に戻して、 AC プラグをコンセント(商用電源)につなぎます。すると、このタイミングから、ブザー音が鳴り始めます。「ブザー停止 / 決定」スイッチを押しても、鳴りやんでくれません。これには困りました。

仕方ないので、手順通りに作業を進めます。作業自体は手順通りに行っていけば問題なく終わったのですが、ボタン長押し、のタイミングが長すぎてもうまく反応してくれなくて、ちょっと手間取ってしまいました。

無事に、自己診断とバッテリー寿命カウンタのリセットが完了したら、 UPS 背面のコンセントに機器をつないで、最後に UPS 本体の電源スイッチを入れれば、 UPS 再開です。

後始末

さて、交換後のバッテリーは引取サービスとかあるかな?と思っていたら、バッテリー引取の用紙が入ってました。

ということで、こちらに必要事項を記入して返送しておきました。ちなみに、ネット上にも、引取についてちゃんと説明がありましたので、事前に詳細を知りたい方は下記などを参考にしてください。

リプレイスサービス|サポート/サービス|OMRON 無停電電源装置(UPS)

まとめ

バッテリー交換のサインが出ても、交換用バッテリーが来るまでは普通に使えるのはありがたいですね(もちろん、 UPS としては機能していませんが)。

たぶん、また4年後ぐらいに交換することになるんでしょうが、きっと忘れていて、またブザーが鳴ってる、とびっくりすんでしょうね。

Logicool M705 マウスの修理

こちらの記事で書いた、 Logicool M705 のマウス、使い勝手が良くて使っていたのですが、最近、ドラッグ&ドロップの途中で動きがおかしくなるなど、なんか挙動が怪しくなってきました。

ドラッグの途中で、ボタンを押しているのに、離したときのような挙動になるので、最初は電池がもうすぐなくなるのかな?と思い、電池交換とかしたのですが、治りません。

結構長く(6年強になりますね)使っていたので、そろそろ寿命かな?と思いつつ、念のため似たような現象ないかググってみると、いっぱいあります。

どうも、マウスの『チャタリング』と呼ばれる現象のようです。こんな名前がついてるのか、知らなかったー。

で、他にもいろいろと記事を見ていると、自分で修理もできるとのこと。長く使っていることもあり、失敗してもいいや、ということで、マウスの修理に挑戦しましたので、そのメモ書きです。

準備

さて、実際の作業の前に、道具を準備します。

  • 星型のドライバー(トルクスドライバー)
  • 接点復活材

後で写真載せているように M705 の場合、ネジがトルクスネジ(星型のネジ)になっていたので、近所の百円ショップでトルクスドライバーを買っておきます。あと、接点復活材は下記のものを購入しました。

で、道具が準備できたので、いよいよ分解です!

分解

分解は下記の記事などを参考に進めます。

こちらが、今回分解するマウスになります。

電池を外して内部を確認すると、ネジが一つあります。

あと、型番のシールが貼ってあり、それを見ると、 M-R0073 という番号になっていました。

下記の記事などを参考にすると、どうもこれは M705m という商品名で販売されていたものっぽいです。

logicool M705を買い替えたらモデルチェンジしていた - ドナドナされるプログラマのメモ

ネジの取り外し

上記の記事によると、電池のふたを外したところ以外にも、あと4か所隠れネジがあるようです。頑張って外します。

マウスの上側のネジ

まずは、マウスの上側のほうにある、マウスソール(というのかな?)を剥がします。が、これがなかなか剥がせない。

仕方ないので、写真のように、マイナスの精密ドライバーの小さい奴でこじって強引に剥がしました。あってんのかこれ?

左右とも剥がすとこんな感じになります。

拡大すると、

こんな感じです。

電池ケースの下

電池ケースの下にあるネジは、電池ケース底面のシールが邪魔になって確認できません。『シールをはがして外します。』という記事も見たのですが、不精なのとシールは残したいので、このあたりだろうとアテをつけて、ドライバーでつついていきます。

シールとネジの間に少し空洞があるようで、若干へこむところがあるので、思い切ってドライバーを刺してネジの頭を探すと、そのうちぴったりとはまりました。こんな調子で2本ともはずします。

外した後は、こんな感じになります。

カバーを外す

ネジが5本とも外れたら、カバーを外します。カバーは少し力を入れると簡単に外せます。

本来であれば、基盤とカバーをつないでいるコネクタを外したほうがいろいろと作業もしやすいし、断線するリスクもないんでしょうが、なんかうまく外せなかったので、強引ですがこのまま作業をすることにしました。

マウスボタンのスイッチ部分のカバーを外す

今回は、マウスの左ボタンの調子が悪いので、そのボタンの下にあるスイッチ部分のカバー(黒い箱状のもの)を外します。

で、これを外すのが一苦労です。黒いカバーの下に、2か所ほど隙間があるので、そちらにドライバを入れて外そうとしたんですが、なかなか外れません。

なんども試すうちに、前側の隙間からドライバーをスイッチの前方側に向かって入れて、力を入れたら、思いっきりカバーが飛んでいきました。

我ながら不器用にもほどがある・・・

焦りながら、あちこち探してみると、無事に一応カバーとスイッチ部分(白いパーツ)が見つかりました。

せっかくなので、カバーの写真を載せておきます。

スイッチ(白いやつ)

この白いやつがないと、マウスのボタンを押したときに反応しない(はず)なので、くれぐれも無くさないようにする必要があります。

修理

修理は簡単で、カバーが外れた後の金属部分に、接点復活スプレーを吹きかけるだけです(写真撮り忘れました)。

ノズルを使ってかけたのですが、結構広範囲に吹き付けられるようなので、作業時には周りに注意しましょう。

組み立て

あとは組み立てるだけです。組み立ては難しくはないのですが、さきほどの白いスイッチの部品をカバーにセットして、基盤にはめます。

白いスイッチの少し幅が大きくなっているほうを、黒いカバーの内側にして、白いスイッチの幅の狭いほうが、外側に出てっ来るようにします。この状態で、基盤にセットできればOKなはずです。

が、基盤を下側にしてはめようとすると、当然ながら、何も支えていない白いスイッチが落ちてきます。なので、基盤を上にして、黒いカバーを下側からはめ込んでやる必要があります。

最初の写真のように、カバーの中央付近に白いスイッチがみえていたら大丈夫っぽいです。

ここまでできたら、ネジを戻して終わりです。ちなみに電池カバーの部分は、ネジをつけるとこんな感じになりました。

動作確認

組みあがったマウスの電源を入れて、PCにつないで使ってみます。ドラッグ’&ドロップしてみると、おぉ、スムーズに動きます。

一時はどうなるかと思ったけど、無事に治ったようです。

参考

作業が終わった後でしたが、下記の記事を見ると、マウスボタンのスイッチの構造について詳しく載ってました。

datyotosanpo.blog.fc2.com

あと、上記の記事でも紹介されていますが、チャタリングを判定してくれるサイトがあるようです。これ使って試せばよかったー。

service.webgoto.net

まとめ

工程としては、そんなに難しくない印象です。

が、この作業、老眼の身には非常につらいです。次も同じことがあったとしたらどうするかな?作業用ルーペでも買わないと自分ではできなさそうな雰囲気です。

でも、下記の記事などを見ると、スイッチの部分までは分解しなくてもよかったのかもしれません。これでいけるなら、十分やる価値ありますね。

マウスのドラッグが途切れる症状、チャタリングは自分で直せる!コンタクトスプレーの使い方 | 梨々コミ

なんにしても、老眼の方はお気をつけて。

Android Studio が重い

Android Stduio でアプリの改修作業を行っていたら、ある時突然 CPU 使用率が80%~90%超で推移して、フリーズするようになってしまいました。

結論としては・・・修正したコードに無限ループが含まれていたことが原因だったようです(トホホです)。

まあ、それがわかるまでに結構時間を使ってしまったので、一応やったことメモに残しておきます。

  • OS: WIndows 11 22H2
  • Android Studio : 2021.3.1 Dolphin Patch 1

異常発生

何も意識せずに、とあるプロジェクトの修正作業を行っていたところ、急に Android Studio が重くなり、フリーズしてしまいました。当然、何の操作もできなくなりました。

仕方ないので、何が起きたんだ?と思いつつ、タスクマネージャで落としてから、もう一度立ち上げても、しばらくすると同じ現象になります。

今度は、タスクマネージャをよく見ると、 CPU 使用率が非常に高いままになって、一向に下がりません。

どうも、何かトラブったようです。

やったこと

手始めにこんなことをやりました。

  • Android Studio の再起動
  • PC の再起動

これでも改善しません。プロジェクトを壊してしまったかな?と思ったので、一度、別のプロジェクトを開いてみます。なんと、問題なく開けますね。どうも、プロジェクト依存の問題のようです。

ということで、

  • プロジェクトのバックアップコピーをとっておき、 build, .idea, .gradle あたりをディレクトリごと削除して、Android Studio でオープン

としてみました。これやったとき、一時的に治ったかに見えたのですが、結局作業を始めると同じ現象になってしまいました。

そうこうするうちに、画面上に Analyzing... とでて止まっているのに気が付いたので、それでググると、似たような現象の記事がありました。

kotlin - Android Studio stuck at "Analyzing..." - Stack Overflow

それによると、Android Studio のキャッシュを消せ、とのこと。なので、

  • C:\Users\ユーザー名\AppData\Local\Google\AndroidStudio2021.3\cache を削除

とやってみましたが、再度試してもだめ。

困ったなーと思って、上記のディレクトリを眺めていると、 log というフォルダがあります。ここを見ると、いろいろとあるんですが、 idea.log というファイルが今試している更新日時になっています。これが、 Android Studio のログファイルっぽいぞ、とおもったので、エディタで開いてみると、今回のエラーが起きてる日時について、 OutOfMemory だの Low Memory だのというメッセージがたくさん見えます。

あ、これが原因だったのね。(最終的に、これは原因ではありませんでした。あとで、間違いに気づきます。)

対応策?

原因がわかれば、対応できます。

ヒープサイズエラーが出た時の対処方法 - Android アプリ開発「MATRIX」

Android Studio のメモリ不足(ヒープサイズエラー)は昔も対応やったな、と思いつつ、改めてググってみると、上記のような記事が出てきました。

早速、いったん、 Android Studio を閉じて、テキストエディタを開き、このプロジェクトの gradle.properties ファイルを開いて、 -Xmx2048m となっているこころを -Xmx4096m にしてみます。

その後、 Android Studio を起動します。これで、解決!

とおもいきや、状況が変わりません。あれれ?とおもって、さらに調べてみると、どうもこの設定は、一度プロジェクトをリビルドしないと有効にならないとのことです。

Configure Android Studio  |  Android Developers

まじか。。。

ということで、仕方ないので、編集中のファイルを一旦、スタッシュに退避させて、リポジトリを間違いなく動いていたところまで戻して、この状態で Android Studio を立ち上げます。

で、さきほどの gradle.properties を編集後、 rebuild をかけます。問題ないですね。

ここまで出来たら、リポジトリを元に戻して、さらにスタッシュに退避させていたものを反映させます。この状態で Android Studio を操作すると、おぉ、無事に動きます。

ついでに、上記の記事を元に、 IDE のメモリの上限も増やしておきました。

これで解決、と思ったのですが、しばらくすると、やっぱりフリーズします。新たに割り当てたメモリが足りないのかな?とおもいつつ、 2G -> 4G -> 8G -> 16G -> 32G あたりまで試しましたが、やっぱり落ちます。

これは妙だな。なんか違うぞ。

Android Studio の再インストール

やる手がなくなってきたので、 Android Studio も再インストールしてみます。

2021.3.1 Dolphin Patch 1

を 2023.1.1 Patch 2

にしました。

で、結論は・・・やっぱり状況変わらずです。

原因発見!

何が原因だろうか?と思っていろいろと調べてみるけど、なかなか理由がわかりません。何かの際に、先ほどの AndroidStudio のログファイルを見直していたら、 OutOfMemory のところにスタックトレースが出ており、自分が修正したクラス名が出ているのがわかります。しかも、その後 HashMap でエラーが起きて止まってます。

ん? HashMap でエラー?なんか怪しいぞ。

と思ってコードをよく見ると、なんと、 HashMap に要素を追加する処理が無限ループになっています!

やっと見つけました。

単に処理中に無限ループがあるのではなく、運悪く既存の Layout クラスを extends して、独自のクラスを定義している時に、一部の初期化処理を static イニシャライザ( static の初期化ブロック)で行っており、その中に無限ループを入れ込んでいました。

static のため、プロジェクトを実行しなくても、このクラスを用いたレイアウトファイル(xml ファイル)を表示するだけで、初期化処理が動いて無限ループが呼ばれたようで、当然メモリが足りなくなり、落ちていたということのようです。

あー、こんなことが原因になるなんてな・・・

まとめ

結局、ヒープメモリ設定は悪くなく、上記のバグ修正後は元に戻しても快適に動いていました。思わぬところで OutOfMemory を引き起こしていましたね。こんなミスもあるよ、ということで、晒しておきます。何かの参考になれば幸いです。

にしても、最初に Android Studio のログ見たときに、もうちょっと注意していれば、解決が早かったように思えて、悔やまれます。ログの確認は大事ですね。