KiCadでのレイヤーの使い方。

自分でもあやふやだったので、公式のドキュメントから抜粋して和訳。

レイヤと言うのはグラフィックエディタとは異なり、実際の基板製造のための「層」のことです。基板とはプリプレグと呼ばれるグラスファイバーとエポキシを混合したプラスチック層と、銅箔を利用した配線層、レジストと呼ばれる絶縁素材の層、シルクと呼ばれるマークや文字の層からなっていて、基本的にpcbnewなどの基板エディタはプリプレグ以外の層をそれぞれデザインしていきます。
よくある基板は1.6mm厚で、2層だと1.0mmや1.2mm、6層だと1.8mmというのもあります。ここでいう2層とか4層、6層は銅の配線層のことです。

[抜粋和訳はじまり]
5. レイヤー
5.1 イントロダクション
Pcbnewは50の異なるレイヤで作業できる:

• 配線のための1から32層までのカッパー(銅箔)レイヤー
• 用途固定の14のテクニカルレイヤー:
  
  • 12のペアレイヤー(Front/Back): Adhesive()、Solder Paste()、Silk Screen()、Solder Mask()、Courtyard()、Fabrication()
  • 2つの独立したレイヤー: Edge Cuts()、Margin()
• 好きなように利用できる4つの補助レイヤー: Comments()、E.C.O.1()、E.C.O.2()、Drawings()

5.2 レイヤーのセットアップ
(略)

5.3 レイヤーの解説
5.3.1 カッパーレイヤー
(略)
5.3.2 ペアレイヤー
12のテクニカルレイヤーがペアになっている:1つはフロント(前面/部品面)、1つはバック(背面/はんだ面)。これらは名前の後の"F"または"B"のプレフィクスで識別できる。これらのレイヤーのうちのフットプリントを構成する要素(パッド、描線、テキスト)は、フットプリントをひっくり返されたときには自動的に対となるレイヤーに反転移動される。
テクニカルレイヤーのペアーは次の通り:

• Adhesive (接着剤)(F.Adhes and B.Adhes)
  These are used in the application of adhesive to stick SMD components to the circuit board, generally before wave soldering.
  一般的にウェーブソルダリング(はんだ槽内でのスルーホール部品のはんだ付け)の前に、回路基板に面実装部品を突き刺して固定するための接着剤を指定するために利用される。(スルーホールには通常面実装部品は使用しないので意味不明。スルーホール部品でも面実装部品でも大きいものはボンドを使用してリフロー前に仮固定することがあるので、SMDという単語は余計。)
• Solder Paste (はんだペースト)(F.Paste and B.Paste)
  Used to produce a mask to allow solder paste to be placed on the pads of surface mount components, generally before reflow soldering. Usually only surface mount pads occupy these layers.
  一般的にリフローソルダリング(リフローはんだ付け)の前に、面実装部品のパッドにソルダーペーストを塗布するためのマスクを生成するのに使用される。(ソルダーペーストの塗布は、0.1〜0.2mm厚程度のステンレス製メタルマスクを基板上に置いてスキージーでペーストを塗布するシルクスクリーン印刷に似た工程である)
• Silk Screen (シルクスクリーン)(F.SilkS and B.SilkS)
  They are the layers where the drawings of the components appear. That’s where you draw things like component polarity, first pin indicator, reference for mounting, …
  部品の位置を示す描画を行うためのレイヤー。部品の極性や、1番ピンの位置、実装のためのリファレンスなどを描画する。(通常ではシルクと省略されることが多い。発音的には絹のシルクではなく、ク↑ラブ的な感じ)
• Solder Mask (はんだマスク)(F.Mask and B.Mask)
  These define the solder masks. All pads should appear on one of these layers (SMT) or both (for through hole) to prevent the varnish from covering the pads.
  ソルダーマスクを定義する。すべてのパッドはFかBのどちらか(面実装)あるいは両方(スルーホール)のレイヤーになければならない。
• Courtyard (中庭)(F.CrtYd and B.CrtYd)
  Used to show how much space a component physically takes on the PCB.
  部品が基板上で物理的に専有するスペースを表示するために使用される。(JEITA ET-7501では「部品本体とランドパターとを組み合わせた境界の周囲に、電気的及び機械的な最小クリアランス領域(製造許容領域)を加えた長方形領域」となっている)
• Fabrication (製作)(F.Fab and B.Fab)
  Footprint assembly (?).
  フットプリントの実装(?)

5.3.3 独立したテクニカルレイヤー
(略)
5.3.4 一般用途レイヤー
これらのレイヤーはどんな使い方をしてもよい。実装方法を指示するテキストやワイヤリング、組立図、実装やマシニング用ファイルの生成用途などなど。レイヤーの名前は以下の通り:

• Comments
• E.C.O.1
• E.C.O.2
• Drawings

[抜粋和訳おわり]


…だそうなので、5.3.4の説明によればこれら4つのレイヤーを使って、寸法図や中心線、補助線などをいれ、最終的に外形図などを出力するときに印刷すべきもの(寸法図やキリなどの指示)と印刷しないもの(中心線、補助線)を別レイヤーにするのがよいと思われます。

ということを考えて、自分的利用分類を以下のようにしました。

• Comments コメント、高さ方向クリアランスの計算根拠とかいろいろ
• E.C.O.1 寸法線、寸法補助線、引出線
• E.C.O.2 基板製造及び実装指示におけるコメント
• Drawings 中心線、基準線、ピッチ線など
• Adhesive (接着剤)(F.Adhes and B.Adhes)
  実装時、基板を移動させたりリフロー炉での加熱中に動いたり落ちたりしないよう、回路基板に部品を固定するための接着剤塗布の場所を指定するために使用する。
  
• Courtyard (中庭)(F.CrtYd and B.CrtYd)
  部品が基板上で占有するスペースを描く層。他の部品との干渉を避けたり、実装のためのスペース(自動実装でも手実装でも必要な余裕)を確保したりするのに使用する。(JEITA ET-7501では「部品本体とランドパターとを組み合わせた境界の周囲に、電気的及び機械的な最小クリアランス領域(製造許容領域)を加えた長方形領域」となっている)
• Fabrication (製作)(F.Fab and B.Fab)
  部品の実際の外形を描く層。部品外形。
  基板上には表示されず、基板エディタ上でのみ利用される。

ということは、FabとCrtYdではFabのほうが外側(フットプリントシンボルでは最外周)で、その内側にシルク、さらにCrtYd(部品外形)がくるということですね。

SyncTeX対応のPDFビューワ。

TeX WikiのSyncTeXのページに対応ビューワがまとめられています。

このうちWindowsで利用できるのは、

• TeXworks - TeX Live付属の統合環境。
  ただし、キーワードの補完などはなく編集機能としては貧弱。
• TeXstudio - TeX統合環境。
  ただ、upLaTeXを指定しているのにXeLaTeXを使ってくれたりして、なかなかままならない。たぶん、自分の使い方がタコい。
• SumatraPDF - ちょっと前までNeovimと組み合わせて使おうと躍起になっていたPDFビューワ。
  軽くていいのだけれど、Neovimと組み合わせたときに inverse search がうまくいかない。Neovim側の --remote-* オプションが削除されてしまったため、neovim-remoteモジュールを利用する必要があるが、それでも完璧にはいかず、Windows環境はサポートしない(できない)、とのこと。gVimは --remote-*引数を受け取るのでパーフェクトに動く。また、Visual Studio Codeとの組み合わせもうまくいかない。
• Okular - KDEベースのPDFビューワ。
  PDF、DVI、PSファイルも表示できる。ただし、WindowsでのインストールはChocolateyを利用する以外の方法はなさそう。Cygwin版もあるが、パス名の解釈の関係かドラッグ＆ドロップができないため、実質使えない。
• Visual Studio Code - Microsoftの提供するエディタ。
  PDFビューワも組み込まれているようで、LaTeX-Workshopをインストールして内蔵ビューワで表示した場合にはSyncTeXが有効になる。

その他のPDFビューワでも、SkimはMacOS専用、Evince (Gnomeベース)はMSYS2上での利用は可能のようだがWindowsネイティブはなし (どうもあるっぽいけれど、ftpサーバへのリンクが切れていて、win32バイナリのディレクトリにevinceはない)、zathuraはWindows版はなし、という感じで、現状でWindows環境でのスタンドアロンのPDFビューワとしてはSumatraPDFかOkularのみ、という状況です。

また、エディタと一緒になった環境ではVisual Studio Codeがかなりいい感じで、内蔵ビューワとの連携もしっかりできているので、設定さえできればサクサク使えそうです。ただ、場合によってはダンマリ状態になることもあり、またタイプセットに失敗してもどこでどう失敗したのかログ表示もヒントもないため、けっこう設定が大変です。

SumatraPDFはNeovimとの組み合わせが今ひとつ。外部からカーソルをジャンプさせる (SyncTeX) コマンドを送り込む際に、どうもSumatraPDF側でおかしなことになっている感じです。Neovim以外ではVS Codeでも試してみましたがうまくいきませんでした。gVimやNotepad++などでは問題はありません。なので、Neovimを使いたい、という場合には現状では選択肢からは外れます。

OkularはインストールするのにChocolateyが必要なのがいやらしい感じ。Okularを使うだけのために別のパッケージ管理ソフトをインストールするのはちょっとためらわれます。が、Okularはいじってみた感じでは軽くて使いやすそうだし、DVIファイルを表示する機能もあるようなので、もう少し見てみましょう。

Inverse Search between LATEX Editors and Okularにあるように、標準ではエディタとしてKateが指定されています。

さらにOkularのEditorの設定を見ると、ファイル名は "%f"、行番号は "%l"、桁番号は "%c" で指定できるようです。なので、エディタによって違いますが以下のように設定すれば、Shift+マウス左クリックでカーソル位置に飛ぶはずです。

• 秀丸エディタの場合:
  "c:\Program Files\Hidemaru\Hidemaru.exe" /j %l,%c %f
• Visual Studio Codeの場合:
  code -g %f:%l:%c
• Notepad++の場合:
  "c:\Program Files\Notepad++\notepad++.exe" -n%l -c%c %f
  

ところがどうしたわけか、どうやっても動きません。
synctexのファイル拡張子も、*.synctex.gz、*.synctex (非圧縮)、*.pdfsync (上記ページに書いてあったもの)と試しましたが、ダメなようです。ということで、選択肢はSumatraPDFかOkularと書いたのですが、スタンドアロンのPDFビューワは現実的にはSumatraPDFしか選択肢がない、ということになりました。

LaTeXでプログラムコードを扱う。

プログラムコードをLaTeXで扱うにはlistings環境を使いますが、日本語のコメントなどに関してはうまく扱えないことがあるようで、それを修正してくれる jlisting.sty も併用します。

ところでWEB上での jlisting.sty のインストール方法は、直接TeX Liveの texmf-dist ディレクトリに置くような書き方をしているものが多いですが、本来ローカルなstyファイルなどは texmf-local に置くべきものです。なんでローカルなファイルをdist (本来はdistribution すなわち配布物)に置こうとするかな。

インストール方法は以下の通り。

1. jlisting.styはmyTeXpertからダウンロードできます。
2. BZ2形式で圧縮されているので7zipなどで展開してから、出てきた jlisting.sty ファイルを C:\texlive\texmf-local\tex\latex\local\listings ディレクトリに置きます。
   C:\texlive\texmf-local\tex\latex\local までのディレクトリはありますので、そこに listings ディレクトリを作成してその中にコピーまたは移動します。
3. 管理者モードのコマンドプロンプトなどから mktexlsr c:\texlive\tekmf-local を実行します。

LaTeX Workshopを使ってみる。

LaTeX Workshopというのがあるようです。

• Build LaTeX (including BibTeX) to PDF automatically on save.
• View PDF on-the-fly (in VS Code or browser).
• Direct and reverse SyncTeX. Click to jump between location in .tex source and PDF and vice versa.
• Intellisense, including completions for bibliography keys (\cite{}) and labels (\ref{}).
• Syntax highlighting (colorized code) for .tex / .bib files and more.
• LaTeX log parser, with errors and warnings in LaTeX build automatically reported in VS Code.
• Real-time linting of LaTeX with ChkTeX to pick up common LaTeX issues as you type.
  
  • Code Actions (automatic fixes) are offered for many issues found by ChkTeX.

え、これもしかしてTeXstudioいらなくない?

ということでLaTeX Workshopをインストールして使ってみます。

BloggerでMathjaxを使ってみる。

やっぱり数式を書くならLaTeXが一番美しく書けますね。実は太陽の重力はどれくらいなんだろうとふと考えたのがこのエントリを書くきっかけ。
BloggerでMathJaxを使ってTeXっぽく数式を入れる方法を参照させていただきました。

で、Wikipediaの重力加速度より、

球対称な天体を考え、自転の影響を考えない場合には、天体の質量を M、半径を R とすると、地表付近での重力加速度の大きさは、万有引力の法則から万有引力定数を G として

$$g=\frac{GM}{R^2}$$

と表すことができる。半径方向の単位ベクトルを\(e_r\)とすれば

$$g=-\frac{GM}{R^2}e_r$$

と表される。自転による遠心力を考慮すれば、自転の角速度を\(\omega = \omega e_z\)として

$$g=-\left(\frac{GM}{R^2}-R\omega^2\right)e_r-R\omega^2e_z \sin \phi$$

となる。ここで\(\phi\)は観測点の緯度である。重力加速度の大きさは緯度によって変化し、赤道で最も小さく、極で最も大きい。また、その方向も球の中心からずれる。

だそうです。
地球の場合には、Particle Data GroupのデータASTROPHYSICAL CONSTANTS AND PARAMETERSによれば、地球の質量は\(5.9724(3)×10^{24}\)kg(ただし(3)は３の循環小数)、半径(nominal Earth equatorial radius)は\(6.3781×10^6\)m、万有引力定数は\(6.67408(31)×10^{−11}\)m³ kg⁻¹ s⁻²ということなので、自転を考えなければ\(9.79851528...\)m/s²となります。
公式には地球の重力加速度は\(9.80665\)m/s²なので、ほんのちょっと違いますが、およその値としてはかまわないでしょう。

そして肝心の太陽です。
Wikipediaによれば、太陽は質量\(1.9891×10^30\)kg、半径\(6.96×10^8\)mですから、自転を考えなければおよそ\(274.05\)m/s²となります。つまり地球の28倍です。
そしてそんな太陽からの脱出速度は617.7 km/s。地球からの脱出速度は11.186 km/sですから、地球の55倍の速度が必要となり、太陽の重力圏に捕まったらものすごい勢いで太陽に落ちていくんだよ、ということになります。
ちなみに音速のマッハでいえば、マッハ1は340 m/sですから、地球からの脱出にはマッハ33、太陽からの脱出にはマッハ1817と、もう想像することも困難な数字になってきます。時速になおせばマッハ1=1225 km/hとなります。
参考までに成田-サンフランシスコの距離は8236 km、マッハ1なら7.3時間、マッハ33なら0.22時間=13分30秒、マッハ1817なら14.5秒…というとんでもない速度ということになります。

なんというか、天文学ではほんとに天文学的な数字を扱うんだなぁ。

もうちょっとicsをいじってみる。

PyPiでicalendarというのを見つけてちょっといじってみたんだけれど、icalendarは今ひとつドキュメントが足りてないのと、「テストコードがあるから使用方法はそっちを見てね」的な感じだけどカバーしきれていない感じなのとで、やっぱりicsをもうちょっといじってみることにしました。

さて、GoogleカレンダーのエクスポートをCSVにする。では浅瀬でパシャパシャやってただけなので、もうちょっと深いところまでいってみましょう。

GoogleカレンダーのエクスポートをCSVにする。

Android端末を使っている関係で、Googleカレンダーを使用してスケジュール管理しているわけですが、これをエクスポートするとiCalendar形式のファイルになります。
iCalendar形式はxmlでもCSVでもなくて、

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:<ちよすけのメールアドレス>
X-WR-TIMEZONE:Asia/Tokyo
BEGIN:VTIMEZONE
TZID:Asia/Tokyo
X-LIC-LOCATION:Asia/Tokyo
BEGIN:STANDARD
TZOFFSETFROM:+0900
TZOFFSETTO:+0900

こんな感じにフィールド名:値という形式になっています。

これを容易に扱えるようにするには、「何かと都合のいい」CSV(カンマ区切り形式)が便利ですから、ぜひとも変換したい。

そしてこういうテキストを扱うのに適しているのは、昔ならsedやawk、perlなどでしたが、pythonでやればオブジェクト指向的にぱっぱと処理できるではないか、と思ったのでやってみました。

python2でもpython3でもどちらでもいいんですが、新しいことをやるのにはpython3のほうがいいです。

そして、iCalendar形式をpythonで扱うためのライブラリがすでにありました。
PyPi(ぱいぱい)よりicsです。

===
Ics.py is a pythonic and easy iCalendar library. It’s goals are to read and write ics data in a developer friendly way.
===

Windowsのpython3ではpipが標準で同梱されているので、コマンドプロンプトまたはPowerShellを開いて
pip install ics
でインストールできます。

そこでIdleを起動してちょっといじってみました。
まず、Googleカレンダーからエクスポートしたスケジュールデータはzipファイルに入っていますから、これを解凍し、さらに利用しやすいように名前を変更します。ここではchiyo.icsにしました。
まずはカレントディレクトリを移動します。chiyo.icsは/Users/chiyoに置いてあるとします。

>>> import os
>>> os.getcwd()
'C:\\Program Files\\Python36'
>>> os.chdir('/Users/chiyo')
>>> os.getcwd()
'C:\\Users\\chiyo'

pythonではパス区切りに '/' も使えるんですね。
では早速chiyo.icsを読み込んでみます。

>>> import ics
>>> f = open('chiyo.ics', 'r')
>>> c=ics.Calendar(f.read())
Traceback (most recent call last):
  File "", line 1, in 
    c=ics.Calendar(f.read())
UnicodeDecodeError: 'cp932' codec can't decode byte 0x86 in position 770: illegal multibyte sequence
>>> f
<_io.TextIOWrapper name='chiyo.ics' mode='r' encoding='cp932'>
>>> f.encoding
'cp932'

エンコードが違いますと怒られました。なんでデフォルトのファイルエンコーディングがcp932なんですかね。Windowsシステムの設定を参照してるんでしょうけど…。
そこで、標準ライブラリのcodecsを使用します。

>>> import codecs
>>> f=codecs.open('chiyo.ics', 'r', 'utf-8')
>>> c=ics.Calendar(f.read())
>>> c
<Calendar with 1588 events>

読み込めました。

cはiCalendarのBEGIN:VEVENTからEND:VEVENTに囲まれたそれぞれのスケジュールデータを保持していて、引数で指定できます。

>>> c.events[5]
<Event '岡山出張' begin:2008-12-10T00:00:00+00:00 end:2008-12-12T00:00:00+00:00>
>>> 

という感じ。

表示されているのはSUMMARY、DTSTART、DTENDの3つのフィールドだけですが、フィールドには他にもLOCATION、DESCRIPTIONなどがあります。
これらはそれぞれ、Calendar.name、Calendar.begin、Calendar.end、Calendar.location、Calendar.descriptionになります。

なので、プログラムとしてはc.events[]の添字を1から最大数まで増やしながら、上記のそれぞれのメンバを書き出すだけになります。

>>> for i in range(1, 100):
 print (c.events[i].begin, c.events[i].end, c.events[i].name, c.events[i].location, c.events[i].description, sep=',')

2008-12-10T00:00:00+00:00,2008-12-12T00:00:00+00:00,岡山出張,,

実際にはこんな風にどんどん出力されます。
日付形式とかちょっとアレな感じですが、これで出力できそうです。エンコーディングの問題があったので、出力用のファイルもcodecs.open()で開きます。

>>> fout=codecs.open('chiyo.out', 'w', encoding='utf-8')
>>> for i in range(1, 1588):
 print (c.events[i].begin, c.events[i].end, c.events[i].name, c.events[i].location, c.events[i].description, sep=',', file=fout)
 
>>> 

これでファイル 'chiyo.out' に出力できました。

実際には、どうもエンコーディングの違うフィールドがあるようで、データの一部が文字化けしてたりしましたが、一応目的は達成できました。
この文字化けはもしかしたらAndroidで使ってるカレンダーツールが悪さしているかもしれません。ちょっと注意してみましょう。

もうちょっとicsをいじってみる。 に続く。