ETCマイレージ。

ふと気になったのでメモ。けっこう高速自動車道の料金も変わってきているようなので。

ソースは平成28年4月1日から、首都圏の高速道路料金が変わりました。

まず首都圏の高速道路料金から。平成28年（2016年）4月1日から首都圏の高速道路料金の計算方法が変わる（他の路線と同様になる）こと、ただし当面は緩和策として旧料金を上限とすること、ETC2.0搭載の場合には料金割引を導入することがアナウンスされています。

たとえば中央自動車道の均一区間（起点の高井戸ICから八王子ICまで）では、

• 都心発着の場合: 旧料金が620円 → ETCはそのまま620円、ETC以外は980円
• 都心通過の場合: 旧料金が620円 → ETCおよびETC以外ともに980円

となっています。ここでいう都心は首都高速と外環道のことです。また通過とは、中央道（均一区間）から首都高速を経由して東北道など別の路線に入ることを言います。

で、よくつかう国立府中から首都高9号木場出入り口では、

• ETCなし: 2280円（980+1300）
• ETCあり: 1440円（620+820）
• ETC深夜割引: 1250円（430+820）

となります。中央道区間は17km、首都高区間は20.6kmになります。


また平日朝夕割引と休日割引は首都圏近郊なので対象外です。


ETCマイレージ、首都高速はマイレージサービスをやっていません。が、NEXCO中日本はけっこうポイント付与率が高いようですね。支払い金額の10%のポイントが付与されます。
ポイントの還元は1000、3000、5000ポイントが溜まったら交換可能で、1000ポイントだと500円分、3000ポイントだと2500円分、5000ポイントだと5000円分になります。
1000ポイントは還元率が低いので、3000ポイント以上で交換するのがいいですね。

PythonでのWikiエンジン。

ドキュメント（に限らず、メモでもなんでも）を、のちのち検索性よく管理して、内容を簡単にアップデートできる、追記もできる、段落とか構造的なテキストにまとめておける、という点で、現状一番よさげなのはWikipediaがいちばん有名だけれどWikiWiki Webでしょう。

日本ではかなり昔からPukiWikiが有名ですが、自分はTWikiではじめました。もうほんとにごく初期の頃ですね。TWikiのAnnounceメーリングリストを購読し始めたのが2005年5月です。動かしたプラットフォームはNetBSD+Apacheで、WikiWiki記法に慣れるために英文のページをどんどん日本語に訳していたのを思い出します。

実はNeovimでPythonコードの品質やエラーを指摘してくれるALE (Asynchronous Lint Engine)というのがあって、そのドキュメントは英語で書かれているので、README.MDをダウンロードして自分用に翻訳しながら設定を詰めていこうかな、と思ったときに、そういえばこういうのってWiki使えば楽だよなぁ、と思いだしたのでした。

Wikiと呼ばれているシステムは、もともとがWikiWiki Webというアイデアから出ていて、ラクダ記法の単語（CamelCase）をキーワードとして認識し、そこにリンクを繋げられる（新しいページを作れる）というところから始まっています。さらに段落や箇条書き、引用、表の作成などのWikiWiki記法、索引、強力な検索機能などなど、ストレスなく記述していくための工夫が随所にあるのがWikiWikiの特徴です。

そうして書き溜めたTWikiのページがまだ手元にアーカイブとして残してあってかなりのページ数になっていますが、いまさらTWikiでもあるまい（PerlからPythonに切り替えたい）ということもあり、PythonベースのWikiエンジンはどうなってるんだろうと気になったのがこの記事のきっかけ。

同様に、いまさらPython2kではあるまいということもあり、Python3kで動くWikiWikiエンジンをまとめてみます。自分用のメモなので、自分の使い方を主軸にしているので過不足あるかと思いますが……。

DjangoベースのWikiアプリケーションでPython3k対応しているのは3つ。

• django-wiki
  最新版stableは2018年10月25日の0.4.2。ライセンスはGPLv3。バグ対応などのコミットは行われている模様。
• Waliki
  最新版は2017年3月26日の0.8.1。ステータスはβ。BSDライセンス。2018年5月2日にDjango2.0への対応が行われているが、それ以外は止まっている模様。
• django-wakawaka
  最新版stableは2016年11月26日リリース。githubをみても、以降のアップデートは行っていない模様。MITライセンス。

その他に、PythonWikiEnginesのページにまとめたものがあります。

• ZWiki
  ZopeベースのWikiWikiエンジン。過去にabuse被害がひどくて開発は止まっている？
• MoinMoin
  どうやら現在一番開発が活発そう。最新版は2018年9月8日の1.9.10ですが、githubでは2.0+の開発が進んでいるようです。

ちなみにWikiMatrixというサイトで多くのWikiWiki Webの比較を行っているので、ここも参考に。

ここにはWikiエンジン選択のウィザードがあって、まずウィザードで絞ってからいろいろな機能を比較できるというメリットがあります。
これによると、自分の用途にあいそうなのはやっぱりMoinMoinかな。

エクスプローラ上でPythonスクリプトにドラッグ&ドロップする。

Windows上では、たとえばテキストファイルをPythonスクリプトに食わせて処理させたい場合、テキストファイルをドラッグ&ドロップ（以下DnD）しようとしてもスクリプトがハイライトされず、DnDを受け付けません。

検索してみると、ベクターでDrop on Scriptというものがあるようですが、これはWindows2000までで、インストールしようとするとWindows 10は拒否してきます。32bitアプリだからというわけではないでしょうから、署名なのかマニフェストなのかそこらへんでしょうか。

どうやら一般的にはDnDを受け付けるバッチファイルを作成し、バッチファイルから引数をPythonスクリプトに渡す、ということがされているようです。

ですがそれだけのためにバッチファイルを書きたくないし、ファイルが増えるのもゴメンです。できればショートカット1つで済ませたい。

参考までにバッチファイルでやるときは、%* を使います。これですべての引数をPythonの sys.argv に渡せます。ファイル名はフルパス名で与えられるので、必要に応じて os.path などを使って加工します。


が、次のような使い方をする場合には面倒です。

data--+--1
      +--2
      +--3
      +--4

のようなディレクトリ構造を考えます。

1から4のディレクトリにはそれぞれ処理したいファイルが格納されています。すべてのディレクトリで同じように処理したい場合には、glob を使ってディレクトリとファイル名を展開すればいいですが、たとえば1と2だけ処理したい場合にはその手は使えません。

さらに1のディレクトリの中で複数ファイルがあって、その中のひとつだけを処理したい場合にはDnDでPythonスクリプトに食わせたいという場合があります。
そうすると、それぞれのディレクトリにスクリプト（とバッチファイル）をコピーして、処理したいファイルをDnDすればいいということになりますが、ここでスクリプトを変更したいという要求が出ます。すると、コピーしたすべてのスクリプトを忘れずに変更しないといけませんが、変更し忘れることもありえます。

そのため、以下のようなディレクトリ構造にします。

data--+--1
      +--2
      +--3
      +--4
      +--script

そしてスクリプトをscriptディレクトリに置いて、1から4にはスクリプトへのショートカットを作成します。そしてショートカットのプロパティの作業ディレクトリは "." にしておきます。すると、scriptにあるファイルを変更すれば済むかたちになります。
DnDで引数を渡したい場合には、バッチファイルを作成してスクリプトを呼び出す形にします。

バッチファイルの記述を以下のようにします。

script/DnD.bat:

@echo off
python ..\script\process.py %*

相対パスで呼び出しているのは、他のディレクトリでもちゃんとPythonスクリプトを参照するためです。こうすることで、このバッチファイルのショートカットのみを1から4の各ディレクトリにコピーしてやればいいことになります。
ただし、これがさらに改装が増えたりした場合には絶対パスに変えたほうがいいでしょう。

別の方法として、pyinstallerを使ってEXEファイルにしてしまうという方法があります。EXEファイルはDnDを受け付けますし、そのショートカットも同様ですので、これでも期待した動作ができるでしょう。pyinstallerに "--onefile" オプションを付けて実行すると、必要なモジュールまで含めて1つのEXEファイルを生成してくれます。

難点としては、Pythonスクリプトを変更するたびにpyinstallerでEXEファイルを作り直す必要があること、生成したEXEファイルが大きいこと、pyinstallerが作成する dist ディレクトリからscriptディレクトリにコピーしないといけないこと、などがあります。

やっぱりバッチファイルのショートカットが一番ラクですかね。

neovim-pythonからpynvimへ。

どうやら何日か前にNeovimでのPythonモジュールの呼び出しが若干変わったようで、Python-neovimを pip -U したあとで ":checkhealth" したらエラーが出るようになりました。

検索してみると :checkhealth failed after upgrade module neovim to 0.3.1 (on python 3.7.1) #366 というのがあって、python-neovimがpynvimに変わったよ、でもpython-neovimがインストールされてるとエラーになるよ（意訳）、とありました。どうも pip install -U neovim するとneovimを削除しきらずにpynvimをインストールして、なにやらコンフリクトっぽい状況になるようです。

解決方法は簡単で、いったんpython-neovimとpynvimを削除してからpynvimをインストールし直す、だそうです。
うちもそれで直りました。ちなみにneovimバージョンはnightlyの0.3.2-913でPythonは3.7です。

カバンの補修。

使っていれば擦れてくるカバンのカド。コロンブスのアドカラーで補修しました。

以前は小皿を使ってやったんですが、、今回やっとジョイフル２の画材コーナーでパレットを見つけて買ってきました。パレットだけってなかなか売ってないんですよね。絵の具セットならあるんですが、別に絵の具が欲しいわけじゃないので探してたんです。

さて早速開始です。これは愛用している青木鞄のラガードNevadaのミニダレスバッグです。電車の座席に座ったときに、膝の上においても横にはみ出さないサイズ。書類は折らないと入らないですが。
こうしてみると結構擦れてますね。

コロンブスのアドカラーと買ってきたパレット。パッケージに入ってるのはアドベースで、キズ補修用です。今回使用するのはコイチャ、クロ、アカかな。

よく見ると芯材が見えてきています。これはやばい。600番のペーパーでちょっと荒らしてみたあとですが、これは難しい。でもそのままやっちゃいます。

調色。モリモリにならないように水で適当にのばして、しっかりと混ぜていきます。

ささっと塗り塗り。いい感じに塗れてる気もするし、ちょっと濃いかなという気もしますが。

別のところも擦れを見つけたので、ペーパーをかけてから塗り塗り。

こんなもんでしょうか。触ってみるとやっぱり革の部分との肌触りの違いがあるんですが。しっとり柔らかい革に対して、ゴワッとしたビニールっぽい感じ。でもまあここは触る場所じゃないのでいいでしょう。

ついでにウォーキングというかキャンプモカのつま先の上部分が擦れていたのでこれも補修。

またちょっと色を整えて、今度は黒多め。

乾くとこんな感じ。ブラシをかけるともうちょっと馴染む感じになるけど、これはもうわかりませんね。

UV硬化型レジン。

通常は2液混合型が多い工作用レジン（樹脂）ですが、1液タイプだとUV硬化型と熱硬化型があるようです。

そのなかでもUV硬化型はアクセサリなどを作る人たちに向けたお手軽な製品が出ています。たぶん有名なところではパジコの太陽の雫と星の雫だと思うので、ちょっと比較してみました。どちらもハードタイプを比較してみます。

項目	太陽の雫	星の雫
容量	25g	25g
成分	アクリル系紫外線硬化樹脂	アクリル系光硬化樹脂
推奨ライト	UVライト(365nm?)	UV-LEDライト(405nm) UVライト(365nm)
硬化時間
UV-LEDライト	??分	30～90秒
UVライト	2～10分	2～4分
太陽光	10分～1時間	30秒～10分
価格(税別)	1,200円	1,500円

並べて比べてみると、星の雫のほうが硬化時間が短くてその分高いように見えます。また通常の蛍光灯でも若干の硬化反応があるようなので、蛍光灯照明のもとで作業するなら太陽の雫のほうがよいのかもしれません。
それと、屋外に出したり長時間露光させるときにホコリなどが入り込まないようにUV-LEDスマートライトミニなどを用意するのもいいですね。値段お手頃な感じですし。

ということで早速ヨドバシ・ドット・コムで購入してみました。
購入したのは「太陽の雫ハードタイプ 25g」とUV-LEDスマートライトミニです。ちょっと都合上写真は載せられないですが。

太陽の雫はアクリル系なので、サラサラではなくドロッとした感じです。が、パテのように盛ることはできず、粘性の液体っぽい表面張力があります。

一方、UV-LEDスマートライトミニですが、こちらはごく普通のUSBアダプタで点灯可能です。コネクタはマイクロBですが、最近のスマホなどはたいていUSB充電なので共通で使えると思います。

さて、たらした液体の上にUV-LEDを角度を調整してかぶせ、ボタン長押し（120秒）して点灯を確認してから紫外線が目に入らないようにダンボール箱を逆さにしてかぶせます。

2分後にはUV-LEDは勝手に消えているので、しばらく放置してから恐る恐る触ってみると、ちゃんと硬化していました。が、ちょっと弾力のある感じ。なので追加で2分照射しました。しっかりと硬化して、艶のある透明の感じに仕上がりました。何回かやってみましたが、2分を1回だとまだちょっと柔らかいので、2分を2回やるのがよさそうです。

もしかしたら、アクリル製品の小キズやガラス面などのちょっとした欠けなども、ヘラなどで塗布して硬化させれば結構いい感じに仕上がるかもしれません。

Google Homeで家電制御…。

家電関係のショーやフェアではスマートホームというかIoT絡みでのホームオートメーションというか、音声でライトが点いたりテレビのチャンネル変えたりなんていうのをやっているけど、誰かに何かをさせるには、そのための通信を行ってコマンドや応答のやり取りが必要になります。

そのためには有線無線関係なく、それぞれの機器が通信を行うための待機電力が増える、という問題もありますがそれは置いといて。

じゃあ家電とコントローラはどんなプロトコルとどんな手段で通信しているのだろうと、ふと思ったのであります。

ZigBee、BLE（旧Wibree）、DigiMesh、Z-Waveなどなど、低消費電力の無線規格はありますが、ソフトウェア面にはあまり注目していませんでした。

OSI参照モデル的には、Threadはトランスポート層とネットワーク層を担当し、物理層とデータリンク層は802.15.4を利用するようです。もともと802.15.4はIPv6とよく似た形でパケットの形式を定義していて、SourceやDestinationアドレスもIPv6に近い形式（6LowPAN）で指定するようになっています。そのため、LANとの親和性も高く、TCP/IPネットワークとのゲートウェイもかなりシンプルになるはずです。

Thread上でのデバイス開発は、Developing IoT Devices with Threadにありますが、それをオープンソースとして実装したOpenThreadというのがあるようです。
これをデバイス上で動かすことができれば、あとは802.15.4無線モジュールを持ってきて組み合わせてやればよい、ということでしょう。
もちろん電波で通信する関係上、セキュリティは重要になってきますので、その部分もしっかり見ないとですね。

ちなみに上記4つの無線規格のうち、BLEを除くと他の3つは802.15.4規格の上に構築されていたと思います。また、Digi Internationalが802.15.4のモジュールを国内の認証を取得して販売しています。その他にもロームなどが出しているようです。

ただ、802.15.4も電波を飛ばす部分がそれなりに電流を食いますし、受信に限っても送信ほどではないですが食いますので、メッシュネットワーク的には時刻同期を組み合わせた間欠通信かつ輻輳制御ということになるんでしょうか。

実際にはアプリ開発者はそこまではやらずに足回りは通信デバイスメーカに任せるんでしょうけど。

ということで、実際の家電への実装はOpenThreadを見ればそれなりに分かるということですね。

ちょっと眺めてみると、まず説明のところで、OpenThreadはNestが開発したものをBSDライセンスに準じた形のBSD 3-Clause "New" or "Revised" Licenseで公開している、とのこと。その目的は、多くの開発者が使えるようにすることで様々な製品の開発を加速することにあるようです。

また、

a Thread Certified Component, implementing all features defined in the Thread 1.1.1 specification, including all Thread networking layers (IPv6, 6LoWPAN, IEEE 802.15.4 with MAC security, Mesh Link Establishment, Mesh Routing) and device roles, as well as Border Router support.

だそうで、このOpenThreadは上記で通信デバイスメーカに任せるのではと書いた部分も含んでいるようです。

そういえばふと気になったので調べてみたら、かつてEM250というZigBee用のSoCを開発した米国Ember Corp.は、2012年にSilicon Laboratories, Inc.に吸収されたんですね。

余談ですが、いやらしいことに802.15.4は2.4GHzの電波を使用していて、それが無線LANの周波数とかぶっているので、無線LANの電波がバリバリ飛ぶ（たとえばYouTubeで動画を見ているとか）と電波出力の弱い802.15.4は通信障害を起こしやすくなります。また当然電子レンジにも影響を受けます。そのため、海外では700/800/900MHz帯の802.15.4モジュールもあるようです。日本では900MHzに近い帯域として950MHzを使えないかということも検討されていたようですが、現状ではまだ認可されていないかな、と思ったら920MHz帯で規格化されているようですね。

xplorer2 4.1。

Windowsを使うときには必ず使っているファイラですが、うちはデュアルペインのxplorer²を使っています。基本的にはファイラとしてしか使ってないので、あまり大したことも言えないのですが……。

そのxplorer²が9月16日に4.1.0.0をリリースし、4.0系で実装されたマクロ機能が使いやすくなったようです。

すごいらしいんだけど全然使ってないから、誰かまとめてくれないかしら。

TMPGEnc MPEG Smart Rendererのショートカットキー。

マウスで動かすよりも素早くできるので、まとめておきます。

項目	操作	ショートカットキー
移動系	次のフレーム	→
	前のフレーム	←
	次のIフレーム	Shift + →
	前のIフレーム	Shift + ←
	次のキーフレーム	Ctrl + →
	前のキーフレーム	Ctrl + ←
	次のシーン	↓
	前のシーン	↑
	開始フレームにジャンプ
	終了フレームにジャンプ
	先頭にジャンプ	Home
	末尾にジャンプ	End
	指定した時刻フレームにジャンプ	Ctrl + J
マーク系	CM候補検出	Ctrl + D
	範囲はじめ	[
	範囲おわり	]
	キーフレーム追加/削除	Ins
	クリップ分割点の指定/解除	Shift + Ins
編集系	指定範囲の削除	Del
	指定範囲以外の削除	Shift + Del
	現在位置から範囲末尾まで削除	Ctrl + [
	範囲先頭から現在位置まで削除	Ctrl + ]
	編集終了	Shift + Enter
	一つ前の操作を戻す	Ctrl + Z
	編集内容の破棄	Esc

不明なものもありますがほぼこれで網羅できているので、作業がはかどります。
とくにCMの頭出し位置などでは、Iフレーム移動で大まかに移動してから↑または↓でシーンチェンジまで移動できるので、ものすごくはかどります。マウスホイール動作も不要です。

実はテンキーに割り付けられないのかなとか考えていましたが、やりたいことはほぼ実現できているので問題ないですね。

MP4ファイルにあとからチャプターを打つ。

チャプターが打てるようになったので、もしやと思って試してみました。

まず、チャプター位置を記録したkeyframeファイル、もしくはchapter.txtファイルが必要です。
ここではtest.mp4、test.m2ts、test.keyframeを想定します。

1. TMPGEnc MPEG Smart Rendererを使っている場合、m2tsファイルが残っていればそれを読み込み、カット編集画面でCTRL+Sでkeyframeファイルを保存します。
2. 保存したkeyframeファイルをchapter.txt形式に変換します。
3. L-Smashのremuxer.exeを用意します。
   remuxer -i test.mp4 --chapter test.chapter.txt -o output.mp4
   とすれば、チャプターを打って結果を output.mp4 に保存してくれます。

ということで、これをバッチファイルにしてしまえば楽ですね。こんな感じです。

@echo off

if x%1==x goto :ERR

set MP4=%*
set BASE=%~n1

echo %MP4%
echo %BASE%".chapter.txt"

C:\Apps\aviutl\exe_files\remuxer_r1474.exe -i %MP4% --chapter "%BASE%.chapter.txt" -o temptemp.mp4
move temptemp.mp4 %MP4%
:END

このバッチファイルにMP4ファイルを食わせれば、うまいことやってくれます。

が・・・。

【悲報】VLC MediaPlayerでChrome Castに飛ばしたら、レグザのリモコンのチャプターボタンでは移動できませんでした…。

keyframe形式をaviutlで扱えるように変換する。

ビデオファイルの編集にはTMPGEnc MPEG Smart Renderer 5を使っていますが、これの出力するkeyframe形式は同じPEGASYSのTMPGEnc Video Mastering Worksなどでしか使えません。
aviutl（正確にはx264guiExプラグインなどから呼び出される muxer.exe / remuxer.exe）で扱うには、別の形式に変換する必要があります。

ということで、いつもどおりPythonでお助けスクリプトです。あらかじめ dateutil モジュールをインストールしておく必要があります。

#!python3
# -*- coding: utf-8 -*-
# vim:fenc=utf-8 ff=unix ft=python ts=4 sw=4 sts=4 si et fdm fdl=99:
# vim:cinw=if,elif,else,for,while,try,except,finally,def,class:
#
# makechap.py:
# カレントディレクトリからすべての.keyframeファイルを検索し
# 順次aviutl（muxer.exe, remuxer.exe）が取り込める形式の
# チャプターマークに変換する
#
# TMPGEnc MPEG Smart Rendereの.keyframe 出力形式
# [chap1]
# [chap2]
# ただし[chapx]はフレーム番号
# muxer / remuxer のチャプター形式
# CHAPTER01=00:03:00.000
# CHAPTER01NAME=タイトル1
# CHAPTER02=00:06:30.000
# 0CHAPTER02NAME=タイトル2

import sys
from glob import glob
from os.path import join, splitext
from os import close
from dateutil.relativedelta import *

# import pdb; pdb.set_trace()

if sys.version_info[0] != 3:
    print('This script requires Python 3')
    exit()

path = '.'
debug = 0
files = []
i = 0

files = glob(join(path, '*.keyframe'))
if debug:
    print('files:', files)

for kffile in files:
    f = open(kffile, 'r')
    outfile = open(splitext(kffile)[0]+'.chapter.txt', 'w')
    frames = f.readlines()
    base = splitext(kffile)[0]
    for frame in frames:
        i = i + 1
        rd = relativedelta(seconds=round(int(frame)*0.0333667))
        time = "{0.hours:02}:{0.minutes:02}:{0.seconds:02}.000".format(rd)
        if debug:
            print(f'CHAPTER{i:02}={time}')
            print(f'CHAPTER{i:02}NAME={i:02}\n')
        outfile.write(f'CHAPTER{i:02}={time}\n')
        outfile.write(f'CHAPTER{i:02}NAME={i:02}\n')
    i = 0
    f.close()
    outfile.close()

こうして作ったchapter.txtをチャプターとしてMP4ファイルに埋め込むには、x264guiExなどの設定パネルでチャプターを設定しておけばやってくれます。

FreeCADとクォータニオン。

FreeCADのViewではAxonometric（不等角投影）、Front/Rear、Top/Bottom、Right/Leftの7種類が標準で用意されていますが、それ以外の角度から見た図を用意したいという場合、けっこう困ります。

マウスでグリグリ動かしてうまいこといい感じの角度に持っていければいいんですが、なかなかこれが難しい。

となると、オブジェクトのPlacementプロパティのAxisとAngleを使って…という手もありますが、これもまた思うようにいきません。

ではFreeCADのPythonコンソールからやってみたらどうだろうと思ったのがこの記事の趣旨です。

Viewをツールバーのボタンアイコンやメニューから変更すると、Pythonコンソールにそのときに発行されたコマンドが出力されます。つまりこれは、FreeCADが内部でPythonを使ってモデルオブジェクトをいじっているということなんですが、たとえばTopボタンを押すと、

>>> Gui.activeDocument().activeView().viewTop()

というコマンドが発行されています。

また、たとえば先程のPlacementプロパティをいじると、それに対応した関数が呼ばれているのがわかります。

そんなことをしながらソースとドキュメントとコンソールをいじっていて、やっと見つけました。

まず、

Gui.ActiveDocument.ActiveView.setViewDirection([tuple])

です。これは視点方向を指定するコマンドになりますが、[tuple]のところにタプル形式で (X,Y,Z) を指定します。これがどうやら単位ベクトルになるようではあるんですが、今ひとつ挙動が思うようになりません。
ちなみに当然のように getViewDirection() もありますので、現在のViewの方向を知ることはできます。

この関数やviewTop()などをソースで追いかけていくと、Gui.ActiveDocument.ActiveView.getCameraOrientation() / setCameraOrientation() にたどり着きました。

このsetCameraOrientation()は、引数としてsbRotationオブジェクトを指定するようですが、ソースでは4つのパラメータを指定していました。それがおそらく SbRotation::SbRotation(const float q[4])だと思いますが、qが4つ。これがクォータニオンです。回転する3Dモデルを使うときには必ず出てくるもので、Direct3Dなんかをいじるときには避けては通れないものです。

それはともかく、Axo、Front/Rear、Top/Bottom、Right/LeftのそれぞれでgetCameraOrientation()のパラメータを確認した上で、マウスでできるだけ自分が参照したい角度に近づけて、再度パラメータを確認してみました。

自分が欲しかったのは、Axoと同じX-Yで、それを斜め上からではなくて真横から投影したものです。
それがちょっと傾いていたので、確認したパラメータをちょっといじって (0.65, 0.28, 0.28, 0.65)としてやったら、ちょうどよさそうな角度になりました。

本質的ではありませんが、実践的にはこういう方法もありかと思います。

Cygwin64 互換性のないランタイム。

KiCADのライブラリのうち、3Dモデルが1GBを超えていたので中身を見てみたら*.stepファイルが巨大だということがわかりました。

なので一括削除しようとして

find -name *.step | xargs rm

しようとしたら、エラーだよ、ランタイムの互換性がないんじゃないの、と言われました。

思い当たるのは、Git for WindowsとCygwin64をインストールしていて、パスはGfWのほうが先に参照されるようになっていること。なので、Cygwin64のfindからGfWのrmを呼び出そうとしてコケていたようです。

ご存知の通り、CygwinはWindowsのドライブを /cygdrive/c/ のような形で仮想的にマウントして扱います。一方、MSYS2（GfW含む）は /c/ という形で参照します。これまでは後者のほうが都合がよいのでGitはGfWを使用し、その他の場合にはCygwin64を使っていたのですが、上記のエラーが出てきたのでGfWはやめることにしました。

ちなみにマウントポイントの指定ですが、Cygwin64の場合には、c:\Cygwin64\etc\fstabを編集することで変更することができます。
うちの環境では

none /mnt cygdrive binary,posix=0,user 0 0
c:/cygwin64/bin /usr/bin ntfs binary,auto 0 0
c:/cygwin64/lib /usr/lib ntfs binary,auto 0 0

として、cygdriveを/mntに変更しています。

PEGASYSのVMW7でQSVの設定。

PEGASYSのTMPGEnc Video Mastering Works 7の試用版を使ってみているのですが、CPUがHaswell Refreshのi7 4790KなのでIntel Media SDKのハードウェアエンコーダを使うことができます。実はメインPCはGeForce 1060を搭載しているのでNVEnvも使用できるのですが、画質的にはまだちょっとな部分があるので、QSVを使ってみます。

実写系の素材では高精細を求めなければエンコード速度も早くて使いやすいですし、チャプターを打つのも素材の編集時に出力するようにしておけばカンタンです。ちなみに素材の編集はTMPGEnc MPEG Smart Renderer 5を使っています。こちらはちゃんと製品版。

さて設定ですが、駄文置場さんのKabeLake時代のQSVエンコード画質について考えるを参考に、概ね以下のような感じにしています。

映像エンコーダ Intel Media SDK Hardware
レート調整モード VBR(固定品質) VBV無し
パフォーマンス 標準
品質 50
音声 320

映像品質の50ですが、上記のページでは

51-(品質値x0.5)

とのことなので、50だとcrf=26相当になります。
音声については元のソースがAAC 250kbps程度のレートですが、余裕を持ってこのレートにしています。

映像品質ではLA-ICQが最も画質的によいというのはいろいろな評価で言われていますが、実写ソースだとcrf=26あたりでは「非常に細かいディテールは潰れるが気にならない程度」というレベルです。実際には、遠景のビルの窓の描写がのっぺりするとかそんな感じですが、メインの被写体が破綻してなければいいか、という場合にはこの程度です。

その他によく使いそうな指標としては、56でcrf=23相当、62でcrf=20相当となります。

Windows10でMIDIファイルを使う。

だいぶ昔にYAMAHAのMIDI音源MU-100とかMU-80とかVL-70mとかを購入しているんですが、手持ちのMIDIインタフェースがISAバスなので現在のPCには使えず、眠ったままになっています。

ちょっと商品の動画にBGMをつけたくて、パブリックドメインになった曲を楽譜入力してMIDIで演奏させればいいかなと思ったのでメモ。

まず楽譜入力ですが、評判とか使いやすさとかわかりませんがMuseScoreというソフトをダウンロードして使ってみました。しっかり使い込める知識も技量もないですがDTM素人が楽譜入力できるという点ではいいのかな、と。

楽譜に音符を置くと音が出てきます。MIDIで再生しているようで、入力した譜面をそのまま演奏できるようです。ある程度の音源も持っているようで、ピアノ、フルート、ベースなどもあります。パート譜に分解することもできるようです。

このソフトを使って、3つのジムノペディ（エリック・サティ作曲）を入力してみました。デフォルトで割り当てられている楽器はピアノです。

楽譜の入力が終了すれば、演奏ボタンをクリックして演奏できます。

MuseScoreは標準でGM音源をサウンドフォントの形で持っていて、これを使って演奏します。MuseScoreのサウンドフォントの説明によれば、

MuseScore 2.2 は General MIDI (GM) のサウンドフォント MuseScore_General.sf3 が搭載されており128種類を超える楽器とドラムセットが含まれています。

とのことです。現在のバージョン 2.3.2も2.2に準じているようです。

サウンドフォントはもともと、E-mu Systemsによって開発されたものをCreative TechnologyのSound BlasterシリーズでMIDI音源を搭載するために使用され、それが他のサウンドカードやソフトウェアでも使えるようになってきたものです。現在はPCのマザーボードには音声codecも搭載されているのでエンスー用途くらいでしか見ることがなくなりましたが、かつてはSound Blaster 16やSound Blaster Live!、またMonster Soundなどというサウンドカードがいくつもありました。
かつてはサウンドフォントをいくつかまとめたサウンドバンクという形式のファイルを、サウンドカードにダウンロードして使用したものでした。

それはともかく、MuseScoreではサウンドフォントが使えるということで、デフォルトの音源が気に入らなければ自分の好きなフォントを持ってきて使えるということです。
MuseScoreではSynthesizerの設定でサウンドフォントを追加・選択できるようになっています。

実はここではすでにサウンドフォントを追加しています。

サウンドフォントはフリーで提供されているものがネット上にいくつもありますが、CoolSoftのVirtualMIDISynthのページの下の方に簡単にまとめられています。

サウンドフォントはsfArkというアーカイバによって圧縮されて配布されているので、利用するにはsfArkをインストールすることが必要です。上記はダイレクトリンクですが、インストールする場合には必ずウイルス対策ソフトなどでスキャンしてください。

VirtualMIDISynthのページには作者のリコメンドのあるFluidR3_GMや巨大な（1.57GB！）CrisisGeneralMidi 3.01などのリンクが有り、さらにSoundFont聞き比べコーナーという素晴らしいページへのリンクもあります。

ここからダウンロードしたサウンドフォントをsfArkで展開し、%USERPROFILE%\MuseScore2\サウンドフォントというディレクトリに放り込みます。すると先程のSynthesizerのダイアログで追加できるようになります。

こうして作曲した譜面ですが、それを録音しないと動画と合成することができません。さて録音はどうしよう、Windows 10はサウンドレコーダーなくなってるし、と思ったら…。

MuseScoreではなんと、譜面を演奏した音をWAVやMP3形式でエクスポートできるようです。

見ての通り、エクスポートのファイル形式はWAV、MP3、FLAC、OGG、MIDなどがあります。試しにWAVで出力してみたら、メディアプレーヤーで再生できました。

「Windows MIDI」で検索するとドライバやVSTなどのページがたくさん引っかかりますが、自分の用途にはMuseScoreだけで十分なようです。さらにメニューやツールバーを見るとMIDI-INやMIDI-OUTなどという項目もあり、たぶんMIDIインタフェースさえ用意すれば外部MIDI機器も使えるのではないかと思います。

もうひとつ、試しにフリー素材としてダウンロードしてみた「G線上のアリア」をMuseScoreで開くと、なんと楽譜形式で表示されました。これもすごい。至れり尽くせりです。

デジカメのビデオ録画時間。

商品の撮影でEOS7Dの動画機能を使ったんですが、30分で動画撮影が自動的に終了（というか強制終了）したので、ああそんなこともあったっけと思いだしたのでメモ。

実は各デジタルカメラメーカ（に限らず、撮影機能を持った製品を作っているメーカ）は、ヨーロッパにも製品を出荷する場合にこの30分制限をかけています。

JETROより、EU 関税制度に概要がありますが、EUではデジタルカメラとデジタルビデオカメラで関税が違います。デジタルカメラには関税がかかりませんがビデオカメラにはかかります。ところが、動画撮影機能を持ったデジタルカメラが増えてきたためにビデオカメラとデジタルカメラの分類を行う必要が出てきて、以下のように決まりました。

• ビデオの画質が800x600ピクセル以上
• フレームレートが23fps以上
• 動画の連続録画時間が30分以上

この3つの条件を同時に満たす場合にはビデオカメラに分類されることになり、10.5%の関税が課せられてきました。そして各メーカはそれを避けるために、動画の録画時間を29分59秒で終了することにしたのです。

現在の状況としては、当初10.5%だったビデオカメラ関税は2017年から7.0%に引き下げになりました。
また、上記条件に該当する場合でも静止画画質が5Mpix以下でFullHD/30fps以下のアクションカメラについては、2017年11月21日に関税が廃止されたようです。

また、来年2月には日・EU EPA発効と同時に日本製デジタルカメラに対する関税は即時撤廃されます。が、これに関して動画撮影機能がどうなるのかは詳細がわかりません。

qaacでCoreAudioToolbox.dllが見つからない場合。

余計なこと抜きで要点だけ。

CoreAudioToolbox.dllはWindows版iTunesのファイルです。ですのでこれを入手するためにはiTunesから抜き出す必要があります。が、現在ではiTunesはMicrosoft Storeからしかダウンロードできないようになっていて、かついきなりインストールされてしまいます。

インストールされた場所がわからないとファイルを抜き出すこともできないため、一旦iTunesを起動してからタスクマネージャーでファイルの場所を開きます。

すると "C:\Program Files\WindowsApps\AppleInc.iTunes_12091.4.37126.0_x64__nzyj5cx40ttqa" なる場所にあることがわかりました。どうやらStoreからのアプリはこの WindowsApps フォルダに入るようです。

ここから以下のファイルを抜き出して、qaac.exeと同じフォルダに入れます。

• ASL.dll
• CoreAudioToolbox.dll
• CoreFoundation.dll
• icudt55.dll
• libdispatch.dll
• libicuin.dll
• libicuuc.dll
• objc.dll

以上です。

スチールデスクの引き出しのベアリング修理。その2

ちょっとナッターはモノタロウに注文しているのですが、付属分だけではナットが足りないかもしれないのでジョイフル本田でエビローレットナットを追加購入してきました。一般的にはブラインドナットの名称です。

ちょっとナッターも売ってましたがモノタロウより高め、かつM6のものは売り切れでした。ちなみにこれは10個入りで910円でした。

エビローレットナットは、スリーブのところにローレット加工がしてあり、ストレートのものよりは締め付けるのが楽なように見えます。スチールだから強度はアルミよりも高いはずなので、引き出しの保持にはちょうどいいかと。

エビローレットナット含むM6のブラインドナットは下穴径がφ9.1だそうですが、ステップドリルには9.1というのはなさそうで、そうなると円錐形のリーマーでちょっと削るか丸ヤスリを持ってくるか、それともルーターで軽く削ってやるかしないと入らないかもしれません。実際にエビナット外径を測ってみるとローレット部分が9mmちょうど、先端近くは8.9mmでした。

今回、φ9.0の穴を正確にあけるためステップドリルを購入しました。モノタロウの六角軸チタンコーティングというやつです。
まず10mmのところにマスキングテープで目印を付けます。それでベアリングが固定されていた穴を拡げます。

実際には脚の幅が狭いため、7mmまで掘ったところで突き当たってしまいました。なので反対側に4mmの鉄工ドリルで逃げを掘って、ステップドリルでφ9mmまで掘り進めます。

ピンぼけですがちょっとナッターにマンドレルとエビナットをセットして、掘った穴にセットしてみました。実際にはステップドリルが正確にφ9の穴を開けたのでそのままでは入らなかったのですが、そのまま回しながらちょっと揺すってやるとエビナットが入るサイズになりました。ヤスリとかは不要でした。
それからちょっとナッターのパッケージの裏が使用方法の説明になっています。そこには「マンドレルには毎回潤滑油を塗布してください」と注意書きがあるので、注油はちゃんとしておきます。

締め付け中の写真はぼけぼけで使えませんでしたが、自転車用に愛用しているSWISS TOOLSの5mmのアーレンキー（六角レンチ 柄の長さ17cm）を使いました。ローレットナットとはいえスチールなせいか、締め付けるのにかなり力が必要で、短いやつだとすごく大変でしたが、長いと楽です。およそ2.5回転で締まりきりました。それ以上締めるとマンドレルが逝ってしまいそうでした。ちなみにパッケージの裏にかしめ量の参考表があって、厚み1mmで4回転、2mm厚で3.2回転、3mm厚で2.5回転となっています。
締め終わったら17mmのメガネレンチを外さずに、アーレンキーで逆方向に緩めてからちょっとナッターを外します。

ちなみに手応え的には締めればどんどん閉まるのですが、最初はグラグラしていたちょっとナッターが固定され、回転遊びがなくなったところで十分に締まっていると判断しました。

最後にねじ付きの樹脂ベアリングをねじ込んで終了です。しっかりと固定されました。

ところでちょっとナッターですが、本体はネジの切っていない六角ナットで真ん中にゴムリングがあります。同心円の筋が入っている方をエビナット側にしてセットします。

ところで、右側の六角穴付きマンドレルなんですが、どうも普通の六角穴付ボルト M6x30（全ねじ）に見えるんですけど。
たぶんこれ、ネジ山が逝っちゃったらボルトを買ってくれば使えると思います。

スチールデスクの引き出しのベアリング修理。

これから材料を揃えるので、まずは忘れないようにメモ。

会社のスチールデスクですが、引き出しの部分の支えになっているベアリングローラーがボキッと折れてしまいました。ちょっとよろけて引き出しに手をついた拍子に。
そうすると引き出しががくんと下がって、持ち上げないとちゃんと閉まらないようになってしまいます。

元のベアリングは引き出し両脇の脚の部分にリベットで固定してあり、1.5mm厚の鉄板です。最初はここに2mmから3mmの薄型ナットを瞬間接着剤で固定して、ネジ付きのベアリングをねじ込めばいいかと思ってたんですが…。

購入したのは、モノタロウの樹脂ベアリング DR-B（ネジ軸タイプ）TYPE7 トップベアリング製です。直径22mmの樹脂ベアリングで、M6のネジ軸となっています。ネジは並目で1mmピッチ。ところが薄型ナットは厚さ2mmの細目になっていて、ちゃんとハマりません。

しかたないので、ドリルで6φの穴を開けてそのままベアリングを差し込んで、宙ぶらりんで使用しています。ないよりマシ、という程度。

ちょっと気になってはいたので、ホームセンターでいいものないかなと眺めていたら、よさそうなのがありました。ハンドリベッターという工具で、片面からリベットを打ち込んで反対側をカシメることができる工具です。ハトメパンチのように両側から挟む必要がなく、片側からリベット打ち込んで固定できるもののようです。が、そこでM6のネジをねじ込めるリベットなんてあるんだっけ、とリベット自体を確認してみると、ハトメのような穴開きではなくてやっぱりリベットはリベットでした。

だめかー、と思いつつ同じ棚を眺めていると、「エビナット」というのを見つけました。ロブテックスという会社の製品で、ナット＋リベットの両方の機能を持ったブラインドファスナーです。筒状になっており、中が雌ねじになっています。これならいけそうです。
そしてこのエビナットを固定するツールがハンドナッターです。M6まで対応するのがトラスコ、SK-11、ロブテックスなどから出ています。これで薄板にナットを固定でき、ベアリングをねじ込むことができそうです。ただし、片手のものはスチールの6mmは厳しいようです。
その他、ロブテックスから「ちょっとナッター」という簡易工具が出ています。これは六角レンチとめがねレンチで締め付けていくタイプのようですが、安価なのが魅力です。

ナットの方では、ロブテックスのエビナット、新潟精機のブラインドナット、ポップリベットのポップナットなどがあります。エビナットではKとDの2種類があり、違いはフランジ（縁）の幅がDタイプは大きくKタイプは小さいということのようです。思うに、ナットを固定する板の強度に応じてDかKを選べということでしょう。プラスチックなどに固定する場合にはフランジの大きいほうがよいと思われます。

エビナットなどの構造としては、奥の方に雌ねじが切ってあり、ボルトを入れて締め込むことで手前の筒の部分が外に潰れてリベットとして作用する構造です。このため、板の裏側にはナットが飛び出している形になります。このナットは並目1.0なので、すでに購入したベアリングがしっかるハマるはずです。

それから薄板に9φまたは9.1φの穴をきれいに開ける必要がありますが、通常の鉄工ドリルで開けるとおむすび型にゆがみます。これはドリル刃の断面を見れば理由がわかります。なのでステップドリルか薄板用ドリルが必要になります。

ということでちょっとナッターを注文してみます。

その2に続く。

FreeCADからLibreCADに図面をエクスポートする。

FreeCADは3D CADですが、一応2D図面もTechDrawワークベンチなどを使用すれば作成することができます。
ところが現状ではどうも寸法の記入が好みじゃなかったり、この寸法のを入れたいのにできない、というような、かゆいところがたくさんあります。

そんなとき、2D CADとしてこなれているLibreCADを使って三面図や平面図を作ると、かなり楽ができます。もっともユーザインタフェースと操作方法がぜんぜん違うため、慣れるまでは戸惑いますが…。

前置きはこのくらいにして、実際の方法です。

まずFreeCADで作成したデータから2次元CADにデータを取り込む必要があります。この部分は、FreeCAD export 3D 2Dというビデオで結構解説されていました。

1. FreeCADで図面に落としたいオブジェクトを選択して、BREP形式でエクスポートします。
2. FreeCADで新規プロジェクトを作成し、エクスポートしたBREPファイルを読み込みます。
3. Draftワークベンチで投影図 (Create Shape 2D views of selected object) を3面分作ります。
4. 3Dオブジェクトを非表示にして、三面図を適切に並べ直します。
5. 三面図を選択して、DXF形式にエクスポートします。
6. LibreCADを起動して、エクスポートしたDXFファイルを読み込みます。
7. 寸法や図枠を編集します。

3のDraftワークベンチがミソです。

実際にやってみます。
まず適当な図形をPartワークベンチで作ってみます。

次にオブジェクトを選択し、BREPフォーマットでエクスポートします。

新規図面を開いてエクスポートしたBREPファイルをインポートします。あるいは単純にBREPファイルを開きます。

次に正面ビューにします。正面ビューになったら、テンキーの"1"または"Front View"を選びます。その状態でツールバーの "Auto" ボタンを押します。するとグリッドがX-Z平面になります。

"Create Shape 2D views..." のボタン（立方体の下に四角形が描かれたアイコン）をクリックします。

するとX-Y平面上に投影図が描画されます。

次にTopビューにして、ツールバーの "Auto" ボタンでグリッドをX-Y平面にします。オブジェクトを選択し、"Create Shape 2D..." ボタンを押します。オブジェクトを非表示にすると、2つの投影図が重なっています。

さらにRightビューにして同じことを繰り返します。再度トップビューにして作業プレーンをTopにし、斜めから見ると下のようになっています。

それぞれの投影図を適切に回転させて配置すれば、以下のようになります。

並べ終わったらDXFフォーマットでエクスポートします。

セーブしたDXFファイルをLibreCADで開くと、ちゃんとエクスポートできています。随時、寸法レイヤとか補助線レイヤとか図枠レイヤなどを追加して編集するか、あるいは予めレイヤを定義したテンプレートを開いてからそこにDXFファイルをインポートすればOKです。

EXEファイルからアイコンを取り出す。

事の起こりはKiCADのアップグレードでした。

KiCADがメジャーアップデートを行い、これまでの4.0.xから5.0.xになりました。内容としてはけっこう変わっているようで、特に大きいのは回路図シンボルとフットプリントのライブラリ関係。これがごっそり変わってしまうと、これまでの図面からライブラリの参照ができなくなるという問題が発生します。これが発生してしまうとけっこう問題が大きく、回路図ではシンボルの再指定が必要ですがピン番号や位置、サイズなどが変わっていると回路図自体のレイアウトを調整する必要があります。またフットプリントが変わってしまうと、これも再読込が必要となりますが、もしも原点が変わっているとせっかく配線した基板図がガチャガチャになってしまいます。

なので、データリリースするまではアップグレードを見合わせていましたが、一段落したのでアップグレード作業を行いました。

そうは言ってもKiCADでは過去のアップデートでもいろいろとライブラリ関係は仕様変更があって痛い目を見ているので、4.0.xの環境も当面は残しておきたいということもあり、Installing KiCad v4 and v5 side by sideを参考にしました。

やっていることはそんなに難しくなくて、

1. %USERPROFILE%\AppData\Roaming\kicad\kicad_common ファイルをデスクトップなどに退避コピーする
2. システム環境変数に KICAD_* という環境変数があればすべて削除する
3. インストール先を %ProgramFiles%\KiCad ではなく、%ProgramFiles%\KiCad5 にしておく
4. デスクトップに作成されたKiCadのショートカットのプロパティを cmd.exe /c "set ^"KICAD_CONFIG_HOME=C:\Users\MyUserName\Documents\kicad5\^" && start /d ^"C:\Program Files\kicad5\bin^" kicad.exe"に変更する
5. %ProgramFiles\KiCad\bin\kicad.exe のショートカット（KiCAD 4.x）を新たに作り直す

でインストール自体は終わりです。

ところで、上記の方法だと4で cmd.exe を呼び出しているため、ショートカットのアイコンが cmd.exe のものになってしまいます。そこで KiCAD5のアイコンにしようかと思ったのですが、それだと4と5の区別がつきにくい。アイコンのデザインは変わっていないからです。

ということでKiCADのアイコンをEXEファイルから取り出して、Kritaで加工しようと思い立ちました。

さてどうやってアイコンを取り出そうかと検索したところ、Windows Power ShellのモジュールでIconExport 2.0.0というのを見つけました。インストール方法はこちら。特に管理者権限などは必要なく、"-Scope CurrentUser" を引数に足せばインストールできます。

PS> Install-Module -Name IconExport -Scope CurrentUser

使い方は、

PS> Export-Icon -Path [exeファイルへのフルパス] -Directory [出力先]

です。

これで取り出したアイコンファイルを編集して、ショートカットのアイコンの変更で設定すればOK。

ボール盤台車の材料を揃える。

ジョイフル本田とモノタロウで購入したものは以下のとおりです。

品名	数量	価格
防腐レッドウッド 2x4 2440mm	1	880
加工代	2カット	100 (@50)
ユニクロ六角ナット M6	32	160 (@5)
ユニクロワッシャー M6	64	256 (@4)
ユニクロ六角ボルト M6x90	16	816 (@51)
ユニクロ六角ボルト M6x55	16	320 (@20)
ユニクロ六角ボルト M10x110	2	180 (@90)
ユニクロ六角ナット M10	2	16 (@8)
ユニクロワッシャー M10	2	12 (@6)
ナンシン 自在車 STC-50EM S-1 ストッパー付	2	478 (@239)
ナンシン 固定車 SKC-50EM	2	338 (@169)

しめて3,556円でした。その他に、6.5mmのミドル木工ドリル（@898）と10.5mmのショート木工ドリル（@698）を購入しています。
また、電動丸ノコをドイトでレンタルして500円かかっています。その他の工具類は手持ちのものを使いました。

ユニクロではなくてステンレスにするとボルトナットの値段が10倍近く跳ね上がるので、けっこうお高いものになってしまいますが、今回はユニクロにしたので思ったよりも安く上がった感じです。木材も安かったですし。

ちなみに丸ノコのレンタル費用は通常は1,000円なのですが、MAJICA会員になると半額の500円になります。会員になるのに100円かかりますがそれでもお得なので、この機会に会員になっておきました。

時間優先だったので途中経過は写真を撮っていないのですが、一応組み上がりました。組み上がったんですが…。

M6x55のボルトは長すぎました。板厚38mm、ワッシャー1枚1mm、ナット高さ5mm、車輪の支持部厚さ2mmとして合計46mmなので、せめて50mmにすべきでした。とりあえず干渉はしていないのでよいことにしておきます。

当初はキャスタの固定は木ねじにしようかとも思ったのですが、重たいものを載せるため、段差などで車輪に前後方向のショックがかかるとまずかろうと思いボルト締めにしています。板の重なり合う部分は、木工ボンドで接着しているので木ねじでも十分なのですが、ツーバイ材の表面はきれいな平面ではないためにこれもボルト締めにしています。

できあがったのでボール盤をばらして載せ替えようと思ったのですが、ヘッド部が外れないため無理でした。さすがに67kgを一人で移動させるのは危険です。
たぶんヘッド下部にある六角ボルトを外せば取り外せると思うんですが、なにしろマニュアルがNSD-13Rのものしか手に入らず、NSD-13は若干構造が古いため細かい部分が違うのです。台座の固定穴も13RはM12だけど13はM10ですし。

レッドウッドとボール盤台車。

とても幸運なことに近所にジョイフル本田があって、そこでレッドウッド材を置いていたので、9時の開店時刻すぐを狙って買いに行ってきました。10時を過ぎるとDIY人気のためか工作室の順番待ちがすごいことになってしまうので、朝一番に飛び込むのか、平日の17時以降を狙うのがいいかと思います。

今回購入したのは防腐レッドウッドの2x4で長さは2,440mm。必要な長さは650x2と400x2だったので、カットを900mmと700mmでお願いしました。1カット50円なので計100円です。カットされたものは持ち帰り、最終的な長さにするのは自分で行います。ちなみに丸鋸を持っていないので、今回はレンタルで済ませようと思っています。

材料の会計を済ませて工作室に持ち込むと、住所氏名電話番号と、どういう加工をしたいかを紙に書いてくれと言われてその通りにしました。上記の通り、900と700でカット位置を記入して渡すと、20分くらいかかるよ、とのこと。カットが終わったらカートに入れてそこに並べておくので、時間になったら取りに来て会計してくれとのことなので、その間に必要なボルトナットを買うことにしました。

無駄な待ち時間をなくすためには、

1. あらかじめ材料の選定と必要なカット長さを明確にしておく
2. 他のものは後回しにして、とにかくカットしてもらう材料を購入していち早く工作室に持ち込む
3. 工作依頼が終わってから、その他の必要なものを買う

ということですね。

今回はボール盤用の台車を作るのですが、ステンレスや黒色酸化皮膜などは錆びにくいけれど高いので、ユニクロねじにしました。使っていて錆がひどくなるようならまた考えます。

ボルト・ナットとワッシャー、ついでに6.5の木工ドリル（ミドル - 150mm程度）を購入して工作室に戻るとカットは終了していたので、会計をしておしまい。効率的です。

ちなみにうちにはボッシュの18Vバッテリーがあるので、もし工作熱が上がるようなら160mmの丸鋸を購入することも考えようかなとも思っていますが、最大100x100の角材を切ることも考えられるので、その場合には190mm以上のテーブルソーかスライドソーが欲しいかも。ちなみにスライドソー（丸鋸）は日立（現在はHiKOKI）やマキタがありますが、おすすめは日立です。というのも日立のスライド方式は1段、マキタは2段となっていて、1段のほうが精度がよく出るからです。これは機構的な問題なので、いくら丸鋸自体がよくてもどうしようもないですね。
もしも本格的に始めるなら、それに加えて集塵機も必要となるでしょうし、ちょっとペンディングです。

さて、自宅に戻ってボール盤台車の図面を仕上げます。アプリはLibreCADを使います。

今回は外注するわけでもないので、長さとドリル位置さえ正確に出せればよいため、全部実線で書いてしまいますが、とりあえず貼り付けておきます。DXFがアップロード出来ないようなのでPNGで。

キャスターはナンシンのものを購入しましたが、ナンシンのサイトにユーザ登録すればCADデータをダウンロードできるのでありがたく使わせてもらいました。

ボール盤の固定穴は板の端に近いですが、ブレ止めなどではなくて位置固定がメインなのでよしとしました。不安なようであれば2x6材などを使って幅を稼げばいいかと思います。
ちなみに台車の形はこちらを参考にさせていただきました。

明日は工作です。