1/32 オーナーズクラブシリーズ ’57 ダイハツ ミゼット(前期型)
2012/5/9 水曜日 – 20:14:57汚れた感じのプラモデルはあまり作ったことがないので、練習に作ってみた。
やっぱ、難しくて駄作となってしまったけど、せっかくなんで、HPにアップしとこっと。
詳細は「ダイハツ ミゼット」のページで。
サイドスタンド
2012/4/22 日曜日 – 9:55:51バイクをちょこっと押すと倒れそうになるW400。
バイクがまっすぐ立った状態でなく、ちょっとでも傾いているとサイドスタンドが出しにくい。
つまり、サイドスタンドが長すぎるんじゃないのか？
先日整備したときに、錆が回ったのか動きが鈍くなっていたのでこの際短いのに交換したいなぁと思ってどうなっているのか見てみた。
錆が出ていた・・
まぁ、それは仕方が無いにしても、サイドスタンドを取り付けているネジ。マフラーの内側に隠れている。
薄いメガネレンチで回すことはできそうだが、ネジは外せそうもない。
と、いうことはサイドスタンドは外せない。
W400のサイドスタンドを外すときはマフラーも外さないといけないということ。
まぁ、サイドスタンドししかないバイクは解体する順序としてはいろんなパーツを外したあとの一番最後にスタンドを外すようになるんだからこれでいいのだろうけど。
マフラーまで外してスタンドを交換するのはめんどうなのでパス。
グリスも塗ることが出来ないので潤滑スプレーで動きやすくしておいた。
駐輪中に倒れにくくするには、
・ハンドルを右にいっぱいきって止める
・ハンドルをグッとひっぱってフロントフォークを一回伸ばした状態にする
ということをちゃんとやるしかないようで。
カスタム検索
Nゲージコントローラ用の指示板
2012/4/16 月曜日 – 12:36:09ノッチ指示板に続いて、主幹制御器の上部にある各種の指示板をモデラで加工。
詳細は、「Nゲージ電機用コントローラ (その4) 主幹制御器-3 (その他の指示板)」に。
つづいては、主幹制御器の本体部分かなぁ。
カスタム検索
W400車検
2012/4/10 火曜日 – 18:42:07W400、早くも3度目の車検。
昨年は自粛ムード+曲がったハンドルの影響でほとんど乗っていない状態。
なもんで、月に1～2回はバッテリーの充電を欠かさずやっておいたのでバッテリーはOK。
曲がったハンドルやブレーキレバー、ブレーキフルードも交換し、ちょこっと整備はしたのでノープロブレム。
検査場の予約はこれまでの電話からwebに変わっていた。
いつものようにヘッドライトの調整ができる程度の工具を背負って出発。
書類を記入して、いざ検査ラインに。
今日は2輪が結構混んでいた。
灯火類、排ガスの検査のあとラインに入る。
前輪のブレーキ検査のあと、ちょっと前進してローラに後輪を乗せる。
W400のスピード検出は後輪なので、ここでスピードメータとブレーキの検査。
が・・スピードメーターが回らない。
そういえば、検査機器の音も静か。
後輪の下のローラーを見ると回っていない。
あら！？検査機器のフットスイッチを踏みなおしてもローラーが回らない。
「機器をリセットしますから、1回ラインから出てください」ということで一回りして再度並びなおす。4台待ち・・・
再びラインに入って検査を開始。
ヘッドライトも含めて全てOK。
並び直したおかげで、所要時間は45分。結構かかったほうだが、まぁ、ヘッドライトで1回落ちたと思えばこんな時間かも。
いつもなら、車検場を出る前に記念撮影をするのだが、今日はデジカメを忘れた・・
健忘症か、痴ほうの始まりか。
最近もの忘れが・・恐ろしい・・
費用
| OCR用紙代 | ￥20 | ||||||
| 検査登録印紙代 | ￥400 | ||||||
| 審査証紙代 | ￥1,300 | ||||||
| 重量税 | ￥4,400 | ||||||
| 自賠責 | ￥14,110 | 前回は￥13,400だった | |||||
| 整備 | ざっと￥？ |
|
|||||
| 合計 | ￥20,230 |
所有権は息子に移り？整備の仕事だけが私の仕事となったようなこのバイク。
久しぶりに乗ったが、渋滞のなかを乗るのはXJRやカタナに比べてやっぱ楽。
XJRに乗るのが疲れるようになったら息子から戻してもらおうか・・
さらに歳をとった時用に残してあるGT125も整備することも考えなくちゃ。
カスタム検索
W400 ブレーキフルード交換
2012/4/9 月曜日 – 8:31:27まもなく車検ということで、いろいろと整備。
ひとまず、ブレーキフルードを交換。
XJR1300は、フロント、リア、クラッチの3箇所のフルードを交換しなくちゃならないが、W400はフロントブレーキのみなので、楽といえば、楽。
フルードを追い出しているときに空気を吸い込まないようにワンウェイバルブが必要になるが、我が家ではこれがないため、助手を一人手配。
今回は息子。
ブリーダプラグにメガネレンチをかませておき、排出用のチューブを取り付け、その先はペットボトルへ。
..今回、チューブを固定するクリップが見当たらなかったのでひとまず省略。
フルードが飛び散ると塗装を傷めるのでリザーバタンクの回りをボロ布で保護。
念のためタンク周辺も。
いつものように小型の油さしをスポイド代わりにして古いフルードを吸い取る。
ゴミも溜まっていなかったので中の拭き掃除は省略するため、ブレーキパイプへの穴に空気が入り込まない程度にちょこっと残しておく。
で、新しいフルードを注ぎ足す。
助手にブレーキレバーを握らせた状態で、ブリーダプラグを少しだけ緩め、さらにブレーキをゆっくり握っていくとブリーダプラグから古いブレーキフルードがでてくる。
ブレーキがハンドルバーに着く直前にブリーダプラグを締める。
・・プリーダプラグを締める前にブレーキレバーを離すと空気を吸い込んでエア抜きが必要になります。
・・プリーダプラグを緩めすぎるとプリーダプラグの根元からブレーキフルードが漏れます。
あとは、リザーバタンクが空にならないように注意しながら、ブリーダプラグから出てくるフルードが綺麗になるまで数回～十数回この作業を繰り返す。
で、だ。
ブリーダプラグに取り付けたチューブを締めるクリップが今回は見つからなかったし、まだまだ寒かったことからチューブも硬かったという不幸が重なった。
ポロッとチューブが外れ、チューブ内のフルードがブレーキキャリパーにダラダラと流れ出てしまった(T_T)
これじゃぁ、チューブなしで作業したって同じジャン。まぁ、タンクの塗装じゃないからまぁ、いいか！？
こうなったときは・・大量の水で洗い流す。
そのあとでパーツクリーナでも洗い流しておいた。
・・これで大丈夫じゃない？
・・・ダメならあきらめるしかないし。
ということで、忙しかったのでその後の作業状態を写真に撮る余裕なし。
カスタム検索
データベースが壊れた・・・
2012/3/31 土曜日 – 9:42:02以前このホームページは自宅サーバで運用していたが、今は某社のレンタルサーバでwordpressやらpukiwikiを使って運用している。
記事を投稿しようとしたところ、wordpressのカテゴリ一覧にカテゴリが表示されていない。
(レコードの件数は表示されているが、データが表示されていない。)
おや、と思ってホームページを覗いたら一見ちゃんと表示されているような、いないような。
・・カテゴリが表示されていない。
記事単体へのリンクがあるところをクリックするとちゃんとデータは表示されるが、カテゴリへのリンクを埋め込んでいるところをクリックするとエラーになる。
どうやら、DBが壊れたみたい。
管理ツールのphpMyAdminで調べていくと、
・テーブルのデータは表示できる
・テーブルの構造を表示しようとすると「#126 – Incorrect key file for table ‘/home/tmp/*******’; try to repair it 」というエラーメッセージがでる
・テーブルによっては「#1030 – Got error 28 from storage engine」というエラーがでる
wordpressの管理画面では、全ての投稿のカテゴリが未分類になっていた。
wordpressの場合、termsというテーブルにカテゴリ名の情報を持っているが、このテーブルのデータは残っているようだった。
また、postsのテーブルもちゃんとカテゴリIDは埋まっているようだった。
phpMyAdminで、テーブルのチェック(CHECK TABLE `xxxx`)と修復(REPAIR TABLE `xxxx`)を試すが、SQLはOKを戻すが 「Incorrect key file for table 」等のエラーは消えずwordpressでもカテゴリは見えない。
・・CHECK TABLEは、DBがMyISAM、InnoDB共に使用できるSQL文ですが、REPAIR TABLE は、DBがMyISAMのときだけのようです。念のため。
google先生に聞くと、「Got error 28」等は/home/tmp等の領域不足ででるようなこともあるそうな。
ただ、レンタルコースのお安いコースでは権限が無く見ることができない。
ちょっと時間がたったバックアップしかもっていないので、全てバックアップできるか不安だったが、あわよくばという気持ちでバックアップをとってサポートに電話で相談してみた。
案の定、「ハード的に問題は無いので、DBの内容についてはお客様の自己責任で」という回答。
そうですか。
一応、「telnetで操作できる範囲なら何やってもいいんですか?」と聞いてみたら「ちがう部署が回答するのでメールで問い合わせて」とのこと。
ウ～ム、普通メールのやりとりでらちがあかないから電話するんじゃ・・と思いつつメールに向かう。
で、本日。
まだサポートから回答はないので、ひとまず対処方法を考えてみる。
■DBを作り直したら、本当に動くのか?
試しに新しいテーブルを作成してみたが、テーブルは作成されるものの、「Incorrect key file for table 」のエラーメッセージもおまけについてくる始末。
これじゃぁ、DBの作り直しだけじゃ対応できない。
まぁ、ここらがレンタルサーバのお安いコースの限界と悟る。
商用サイトを運用するなら、もうちょっとサポートの厚いコースか権限のあるvirtualサーバなどのコースが必要ということですかねぇ。
じゃぁ、このサイトは閉鎖か?
というものねぇ。
で、ふと気が付いた。
このレンタルサーバのコースは昔1つのDBだけした使えなかったが、その後複数のDBが作成できるように変更になっている。しかも、その際の移行の流れだと思うが、DBサーバが2つに分かれたようだ。
このホームページは古いDBサーバにデータをおいているので、新しいDBサーバにDBを作ることにしてみた。
DBを作成して、古いDBからエキスポートしたテーブル類を新しいDBにインポート。
DBの接続設定を変更して完了。
ちゃんと、カテゴリも表示されるようになった。データは破損していなかったようだ。
?? そこまでして修復するようなホームページかって ??
まぁ、趣味ですから・・
■教訓
・DBと設定ファイル類のバックアップはこまめにとりましょう。
・商用などの止めては困るサイトはちょっとコストがかかってもサポートの厚いコースにしましょう。
・お安いコースでいくなら、2つのコースを契約して、1日分のデータ消失はあきらめるとして日々相手側にバックアップをとって障害に備えるのも手か?
って、ところでしょうか。
結局、Mysqlのエラーの原因は未だ不明。
■本来なら
・MySQLが使用するテンポラリ領域の空きの有無の確認
・MySQLの再起動
等を行って原因調査や確認ってところでしょうが、手が出せないレンタルサーバではここまで。
