2017年05月12日

カラビナ破壊2選、拡張アンカー落下試験

知的好奇心を満たすためだけに落下試験をしてみました。
120cmのスリングに、25kgの重りをつけて落下係数1で落とすというもの。
気づいたことを羅列していきます

はじめ重りを引き上げるのに、カラビナで折り返していたがめちゃくちゃ重かった。プーリーにしたらなんと軽いことか。プーリーはCTのロールンロックです。

DSC_0296

4回目の落下のときにカラビナ破断しました。
ゲートに傷が見受けられないため、ウィップラッシュでゲートが開いたのと、ゲートの根元に乗ったのが同時に起きたのではないかなと思われます。
シャックルがあったのもハンガーの位置を悪くした要因だと思われます。
DSC_0290


スパインのカーブが伸びてました。

安全環は締めたつもりでしたがいろいろやってる中で締め忘れたのだろうと思います。この写真では、締まっている状態ですが、開いていたとしか思えないです。
またはこのカラビナは安全環を深くしめなくてはならないカラビナで閉めが浅かったのかもしれません。
あとからビデオで確認しましたが、荷重がかかると、4重に折り返したスリングが岩に押し付けられ、それに90度の角度になるようにカラビナが縦になり垂直に岩に押し付けられてました。また、ゲート側が岩に当たっているようにも見えました。...


DSC_0311

DSC_0312

ケミカルアンカーは何の変化もありませんでした。
施工ミスで穴が浅くアゴが浮いていたのですが、落下の衝撃でまがってアゴが岩についた状態になりました。
DSC_0304




DSC_0319









raccho999 at 01:20|PermalinkComments(0)TrackBack(0)

2017年02月05日

西伊豆、静浦山地、鷲頭山、亀の甲岩、クレヨンウォールの駐車スペースとアプローチについて

伊豆、静浦山地、鷲頭山、亀の甲岩、クレヨンウォールへ行くときの駐車スペースとアプローチについて記載しておきます。

駐車スペースは、御前帰の登山口にある駐車スペースを使われると良いかと思います。
登山口まで歩いて10分程度です。
クレヨン亀の甲駐車場


















大井公民館の裏が登山口になります。
クレヨンウォール入り口までが5分程度。左に折れて3分程度あるくと一番奥にクレヨンウォール。
登山口から亀の甲岩の登山道のケルンまでは10分程度、そこから斜面を直登して10分ほどで亀の甲岩です。

raccho999 at 21:59|PermalinkComments(0)TrackBack(0) クライミング 

2016年10月12日

クライミング用リングボルトの撤去の仕方

リングボルトのリボルトの時に必要なボルト撤去の方法を共有します。

  • 準備するもの
  1. ハンマードリル
  2. 5mmのコンクリート用ビット
  3. 重めのハンマー
  4. 120cmスリングとカラビナ

  • 手順
  1. リングボルトのくさびは、リングの穴の向きとは90度回転して刺さっているので、リングボルトの拡張部分が広がる方向は、通常がリングが上下に可動するという一般的な設置の場合は水平方向に広がっている。
    その為、リングボルトの片側に、細めのドリル(私は5mmを使用)で幾つか穴をあけ、拡張部分の圧をぬいてやるようにする
  2. 少し開けてはハンマーで軽く叩く。ボルトがグラグラしてきたら、リングにカラビナをかけ、それにスリングをかけ、反対側をハンマーに結び、ハンマーの重みを利用して抜く方向にハンマーを振ってやる。それでもボルトが抜けないようであればもう少し穴を広げるか、深くしてやる。
  3. ボルトが抜けた後にはクサビが残るので、クサビが取れるようになるまでドリルで穴を広げてクサビを撤去する。少し穴を追加するだけでいいはず。
hdr_00010_0




































撤去後
リングボルトをぬいた後は、表面近くの穴が広がっており金属系アンカーでは首の部分の支えがなくせん断方向への荷重に対して弱くなるので、ケミカルアンカーを使用してプロテクションを設置するようにする。

注:
RCCボルトも同様に可能と思うが、クサビの向きがわからない、深さが21mmあるため、それらを考慮して穴を開けること。8mmのビットで上側に穿孔することにより、確実に撤去でき、最低限の強度低下に抑えることができるだろう(未経験なのでまだ憶測)。

raccho999 at 23:17|PermalinkComments(0)TrackBack(0) クライミング 

2016年08月23日

CentOSでのRedmine認証Subversion (以下SVN)で大量のCommit、Update、Checkout等々をするときにエラーになる時の対処方法。おまけに1.6から1.9へのざっくりとしたアップデートについての説明。

色々悩んだけど、最終的に解決法はシンプルだったのでシェアします。

現象はタイトルの通り。クライアントはWindowsなのでTortoiseSVN最新版を使っています。

SVN 1.6+認証はRedmin.pm+MySQLを使ってRedmineユーザー認証で運用してました。
開発者から「Commit、Update、Checkout等々をするときにエラーになる。再度実行すればいいんだけど、面倒だ。SVNのバージョンが古いのが原因ではないか。上げたら治るんじゃないか」とのリクエスト。

確かに今時分で1.6は古いので、1.9系にあげようということに。
一応svnadminでdumpを取って、yum で1.6をremove後に1.9をinstall。
設定ファイルが/etc/httpd/conf.d/subversion.rpm***というようなファイルにリネームされてるので、それをsubversion.confに戻しておく。
また、mod_dav_svnがアンインストールされたので再インストール。
アップデート後、Update、CheckoutはできるがCommitが失敗するようになった。

以下の設定をsubversion.confに追加で解決。プロトコルがいまいちのようである。
SVNAdvertiseV2Protocol Off
ちなみに、Apacheのmod_dav_svnに対する設定なので、httpd.confに書いてもOk。

結果、Commitはできるようになったが、大量のファイル操作でエラーになるという現象はあい変わらず発生。
これから紆余曲折があり、以下の設定を色々試しましたがどれも根本解決にはつながらず。詳細は省略。
SVNInMemoryCacheSize
SVNCacheFullTexts
SVNCacheTextDeltas
SVNAllowBulkUpdates
RedmineCacheCredsMax

Internal Error 500とかConnectionエラーとかFileNotFoundとかが色々出たり、クライアントログ、Apacheのログ、SVNサーバ、SVNクライアントのログなどの出力先も様々なものがあり色々騙されました。

最終的に、Redmine.pmとMySQLの間のTCP接続でTIME_OUT状態の接続が増えすぎるからということが、error_logに載っていた
Can't connect to MySQL server on '127.0.0.1' (99)
でググったことから判明。下記ページに載っていました。
http://stackoverflow.com/questions/24884438/2003-cant-connect-to-mysql-server-on-127-0-0-13306-99-cannot-assign-reques

ここによると、MySQLに接続するときの接続文字列に含まれるMrSQLサーバーのホストアドレスがIPアドレスになっていると、コネクション要求に対して毎回ポートを開けてコネクションをはるため、コネクションを閉じてもTCP状態がTIME_OUTからCLOSEになるまでの60秒間ポートが使われっぱなしになる。
そのため数万のクライアントポートが使用中になることがあるらしい。
うちではSVNクライアントがリポジトリを操作するときの認証を、MySQLに保存されているRedmineユーザー情報を使用しているため、Redmine.pmからmySQLへの接続でこの問題がおきていた。
UNIX domain socketを使いなさいってことだったので、アドレスを127.0.0.1からlocalhostに変更すると開きっぱなしの接続はなくなりました。これでようやくRedmine.pmとMySQLの間の問題は解決。
なお、ポートの状態を見るには、netstatを使用してください。

それでもTIME_OUT状態のポートが数十個あるので、なにかと思ったらApacheに対しての接続が開いている。SVNクライアントはKeepAliveは使っていないのかなぁとぐぐってみると、なんとRedhat系のApacheの設定はデフォルトでKeepAliveがOffになってるとの情報をGet。
まさかと思って確認するとCentOsもRedhatからの派生ディストリなのでビンゴ。
早速Onにすると劇的にTIME_OUTが減って今は数個になりました。

で、大分安定して意味不明はエラーは解決しましたが、まだ413 'Request Entity Too Large' なんていうエラーが起きるとの報告がきたので、
LimitXMLRequestBody 52428800
をhttpd.confに追加してあげたところようやくエラーが起きなくなりました。

なお、ポートのTIME_OUTの解決に
/etc/sysctl.conf
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 10
の設定を変更しようというページも多々ありましたが、採用はしませんでした。
今後のスケールアップに伴いSVNのチューニングパラメーターと同時に検討していきたいと思います。

raccho999 at 10:36|PermalinkComments(0)TrackBack(0) コンピューター関連 

2016年07月28日

2液性エポキシ接着剤の混合比率に寄る硬度

通常エポキシって硬化剤を少な目にすると硬くなるってネットでは書かれてるんだけど、コニシのボンドのクイックメンダー30は、硬化剤が少ないとペタペタする。
混合はヘラを使ってしっかりやってるつもり。
2:3、3:2はやり過ぎかもしれないけどネットの情報と間逆なので不思議です。
ちなみに、主剤:硬化剤が
2:3=一番硬い
2:2=硬い
3:2=ペタペタする
うーん。教えてくれないかもしれないけどベンダーに聞いてみるかな。
 

追記:
コニシのWebサイトから上記質問をさせていただいた所、折り返し電話をいただきました。
クイックメンダー等に使われているポリチオールが硬化剤のエポキシ接着剤は、硬化剤が
多いほうが硬度が上がる傾向にあるらしいです。
詳しい理由は不明だとおっしゃっていました。
DSC_0752






























raccho999 at 23:05|PermalinkComments(0)TrackBack(0)