作者別: chiyama

電子工作

冬休みの自由研究:基板の自作(4) DSPCBで作成したデータを印刷してみる

エッチング用のマスクデータを印刷するにはレーザープリンタを使用します。家庭にレーザープリンタがあることはなかなかないでしょうが、その場合コンビニのネットプリントが使えます。この季節は印刷するために外に出るのが億劫なので、そういう怠惰な人は Amazon でレーザープリンタをポチりましょう。私は一時間くらいかけて気合を入れてコンビニに向かいます。ネットプリントはどこを使っても同じではないかと思うものの、セブンイレブンで成功したという話を見かけたのと、自宅の最寄りのコンビニがセブンイレブンなので、私もセブンイレブンのネットプリントを使ってみます。

前回作成した PDF を使用して、印刷用のデータを用意します。今回は出力サイズが正しいかということも確認したかったので、パターンだけではなく寸法つきのものもあわせて配置しました。

印刷後、表示されている大きさと実際の大きさが合っていればきちんと出力されていることがわかります。これがずれていると IC の足が刺さらないとかいろいろ悲しいことが起きてしまいます。

セブンイレブンのネットプリントを使用する場合、PDF の用紙サイズをきちんとしておく必要があるようです。そのため、一度 Inkscape に読み込んでデータを配置してから A4 サイズの PDF として出力しなおします。これは、ページサイズとして A4 を指定し、PDF として保存するときに”ドキュメントのページサイズを使用する”にチェックを入れます。

そしてセブンイレブンで印刷してきた結果がこちら。

奇麗に左右反転され、さらに縦横ともにDSPCB上で設計したサイズのまま出力されていることが確認できました。ここまでできれば DSPCB を使ってマスクデータを作る部分は大丈夫そうです。

電子工作

冬休みの自由研究:基板の自作(3) DSPCBでマスクを作る方法を調べる

DSPCBを使うと決めたものの、そもそもマスクの出力方法がわからないと行き詰ってしまうのでまずはそのための方法を調べます。

使用するサンプルは、DSPCBをインストールして起動すると表示されているデータです。

今回は、DSPCBで設計したパターンをコンビニプリントで印刷してから生基板に転写する方法を採るので、回路パターンだけを選んで実寸で出力するのと、転写するために左右反転することができればよいことになります。

とりあえず何となく勘でFile→Print… メニューを選んでみると、そのまんま行けそうな内容が並んだダイアログが表示されます。

何となく、Output To: でPDFを選び、Settingsで  All Colors Black と Mirror にチェックを入れ、Layers で必要なレイヤを選べば行けそうな気がします。

レイヤはメインウインドウ右下にある Layers タブを選ぶと表示・非表示を切り替えられるので、ポチポチ切り替えると Top Solder Resist と Top Copper のみにチェックを入れると必要そうなパターンが表示されました。

サンプル回路自体は多層基板として設計されているため他のレイヤにも回路が含まれてしまっていますが、今回自作する基板は片面のみの一層だけなので、設計した回路に対してこれと同様なことをすれば十分だと思われます。

そのようにして出力したPDFは下図のようになりました。

これを印刷してみます。

電子工作

冬休みの自由研究:基板の自作(2) DesignSpark PCBの準備

基板を自作するにあたって、プリント基板設計ツールを使用する必要があります。今回は、 RS Components が公開している回路図面や基板パターンのアートワーク設計できる無料のCADツール、DesignSpark PCB(以下 DSPCB)を使用します。回路設計ツールとしては Autodesk EAGLEも無料版があり、「【アイロン不要】プリント基板を自作してみよう【生基板】」でもEAGLEが使用されているようですが、基板サイズや層数、非商用限定などの制限が多いようなので、今後使用することを考えるとちょっと躊躇してしまいます。(→と思ったら、EAGLE って Fusion360 との抱き合わせなんですね。Fusion360に課金すればEAGLEまで使えて機能無制限と考えると、かなり悩ましい。。。)

ただ、現時点ではDSPCBを使用して基板エッチング用のパターンをどのように出力するのかわかっていないので、ここで困りそうならその時点で方針を考えることとします。

DSPCBのインストール

DSPCBのサイトからインストーラを落とし、インストールします。また、DSPCBを使用するためには DesignSparkのアカウントが必要なようなので、アカウントも作成しておきます。このあたりは特にハマることも無く、サクサクッと進んで無事に DSPCB の起動までできました。

電子工作

冬休みの自由研究:基板の自作(1) 材料の用意

電子工作は小学生の頃からやっていて、なんやかんやで電子回路の設計とか実装とかの勉強もやってきていたものの、そういえば今まで自分で電子工作用の基板を作ったことなかったなぁということに気づいたので、人生で一度くらいは自作してみることにしました。最近はネットを探すとこういう情報も豊富にあるので、とても助かります。今回は

を参考にさせていただきました。

材料の用意

無水エタノール・塩・クエン酸は自宅にあるものを拝借します。それ以外は

  • 生基板
  • フラックス
  • オキシドール
  • アセトン
  • スチールウール
  • 油性ペン
  • エッチング用紙皿
  • スポンジ

を用意しました。アセトンは薬局でも在庫が無かったのですが、マニキュアなどを除去するための強力除光液としてアセトン100%のものがあったので、それを購入しました。普通の除光液を使うとどう影響するのかはわからないです。その他ちょっとしたものは100均で購入し、全部で大体3000円くらいで揃います。

明日以降、用意した材料を使って基板の自作をしていきます。

コンピュータ

bind を Docker で動かす

bind を Docker で動かすようにしたので作業メモ。

Dockerfile と初期イメージの作成

$ mkdir docker_bind
$ mkdir docker_bind/conf

$ cat docker_bind/Dockerfile
FROM centos:centos7
RUN yum install -y bind bind-utils && yum clean all
EXPOSE 53/udp
CMD [“/usr/sbin/named”, “-c”, “/etc/named/named.conf”, “-u”, “named”, “-g”]

$ docker build -t bind ./docker_bind/

$ sudo docker run -it bind /bin/bash
[root@148a28083361 /]#

named.conf を取得

$ sudo docker cp 148a28083361:/etc/named.conf docker_bind/conf/named.conf

リポジトリ作成

$ cd docker_bind
docker_bind$ git init
docker_bind$ git add Dockerfile
docker_bind$ git add conf/named.conf
docker_bind$ git commit -m ‘docker_bind initial import’
[master (root-commit) be44df1] docker_bind initial import
2 files changed, 66 insertions(+)
create mode 100644 Dockerfile
create mode 100644 conf/named.conf
docker_bind$

named.conf 編集

docker_bind$ git diff conf/named.conf
diff –git a/conf/named.conf b/conf/named.conf
index 89338bd..3027c20 100644
— a/conf/named.conf
+++ b/conf/named.conf
@@ -10,15 +10,18 @@
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html

options {
– listen-on port 53 { 127.0.0.1; };
– listen-on-v6 port 53 { ::1; };
+ listen-on port 53 { localhost; 192.168.0.0/24; };
+
+ // listen-on-v6 port 53 { ::1; };
directory “/var/named”;
dump-file “/var/named/data/cache_dump.db”;
statistics-file “/var/named/data/named_stats.txt”;
memstatistics-file “/var/named/data/named_mem_stats.txt”;
recursing-file “/var/named/data/named.recursing”;
secroots-file “/var/named/data/named.secroots”;
– allow-query { localhost; };
+ allow-query { localhost; 192.168.0.0/24; };
+
+ forwarders { 192.168.0.210; };

/*
– If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
@@ -56,6 +59,15 @@ zone “.” IN {
file “named.ca”;
};

+zone “example.net” {
+ type master;
+ file “/etc/named/example.net.zone”;
+ allow-update {
+ localhost;
+ 192.168.0.0/24;
+ };
+};
+
include “/etc/named.rfc1912.zones”;
include “/etc/named.root.key”;

conf/example.net.zone と conf/example.net.rev には通常おこなうようにホスト情報を記述する。

bind 起動

ネットワークインターフェースが複数ある場合、インターフェースを指定しないと下記のようなエラーになる。

docker: Error response from daemon: Conflict. The container name “/bind” is already in use by container “a75d2e62ccde7a0bc3fb07be84fd393607f1286fdacaafa828b06ed2789a32d7”. You have to remove (or rename) that container to be able to reuse that name.
See ‘docker run –help’.

私の環境では KVM も動かしている関係で複数のインターフェースが認識されるため、必要。

$ sudo docker run -d -e TZ=’Asia/Tokyo’ -p 192.168.0.34:53:53/udp -v /home/neo/Documents/docker_bind/conf:/etc/named –restart always –name bind bind

CG, USD

USD のビルドの進捗を確認する

以前、CGWorld の記事で USD のビルドの進捗がわかり辛いということを書いたのですが、最近のバージョン(?) では ${INSTALLDIR}/build/USD/log.txt にビルド時の stdout(stderrも?) の内容が出力されるようです。

そのため、tail を使ってこんな感じで進捗の確認ができます。

[chiyama@docker USD]$ tail -f log.txt
[ 85%] Building CXX object pxr/usd/lib/usdGeom/CMakeFiles/_usdGeom.dir/wrapBasisCurves.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdSkel/CMakeFiles/usdSkel.dir/cacheImpl.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdLux/CMakeFiles/usdLux.dir/diskLight.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdShade/CMakeFiles/usdShade.dir/debugCodes.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdUtils/CMakeFiles/usdUtils.dir/coalescingDiagnosticDelegate.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdShade/CMakeFiles/usdShade.dir/input.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdUtils/CMakeFiles/usdUtils.dir/debugCodes.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdUtils/CMakeFiles/usdUtils.dir/dependencies.cpp.o

CG, Maya

Mayaのノードで数学の演算を実現する

Maya Advent Calendar 2018 の記事です。@rt_sporty さんがリグっぽいネタ無いですかね~?とかつぶやいていた気がするので、リグっぽいけど関係ありそうな無さそうなネタを投下します。

リグを組むとき、sin とか cos とか abs とかベクトルの計算とか多用しますよね。

でも、Expression で書くと遅い。そしてダサい。ノードベースなんだし全部ノードで組みたいじゃん!って思うのが人情です。

組みましょう。

足し算, 引き算

まずは手始めにここからいきます。これはそのままノードがあります。数値もベクトルもこれで行けます。

掛け算, 割り算, a の b 乗

四則演算を揃えます。

うむ。チョロいチョロい。

逆数

これは割り算がそのまま使えます。

絶対値

これは Maya 上にはズバリそのもののノードはありません。どうしようか。。。ということですが、0 からの距離と考えれば簡単です。

floor

アニメーションカーブと、 Pre Infinity, Post Infinity を使えば実現できます。
アニメーションカーブは通常は input に時間が入力されますが、このように任意の値を入れることもできます。この辺りは結構使うテクニックですね。

Mod

mod(a, b) = a – b * floor(a / b) なので、既にあるノードを組み合わせることで計算できます。

三角関数

これはちょっと困りものです。そのものズバリなものも無いですし、既存のノードで代替するのも難しそうです。展開して近似とかもめんどくさいし重たそうです。
しかたないのでアニメーションカーブで近似します。Pre Infinite/Post Infinite を使えば一周期だけデータを用意しておくだけで対応できます。厳密な計算をする場合はもうちょっとちゃんとやる必要があるんでしょうが、リグ用とかならこれで十分かなと。sin, cos, asin, acos はこの方法で対応できますね。

tan は sin/cos で計算できます。

Log

これも良い感じに軽く計算できる方法が思いつかないのでアニメーションカーブで逃げます。ある程度の精度とデータの軽さを両立するために、キーフレームの打ち方を工夫したりして悪あがきします。あと、余り使わなさそうな部分は Linear で外挿しています。

これくらいあれば必要な演算は大体できるのではないでしょうか。(ゼロ除算は全く考慮してないですが~;;)

CG, USD

AL_USDMaya

PIXAR 標準の USD Maya プラグインとは別に、AnimalLogic が公開している AL_USDMaya があります。個人的には、Maya を中心に据えて USD ベースのパイプラインを組むのならこちらが本命じゃないかなと思っています。あんまり確たる根拠は無いですが。そこは勘ですよ勘!!セブンセンシズですよっ!

PIXAR 実装は Scene Assembly として USD の情報を扱う実装になっていますが、AL_USDMaya はそのあたりの扱いを自前でゴリゴリと頑張っているようです。.usd ファイルを読み込むと AL_usdmaya_ProxyShape ノードが作成され、単一のノードとして表示されるのですが、ビューポート上でオブジェクトをピックするとそこまでの階層がシーン中に現れて操作できるようになります。

このプラグインを使用している様子は “AL_USDMaya Layout and Animation Workflow” で見ることができるのですが、結構独自のツールを作って実現している機能が多いようなので、オープンソースになっているプラグインをビルドすればこれができると思ってしまうのは甘い感じです。そもそも、Hydra を Maya 上で使ってるっぽいことを言ってるんですがこれは一体。。。?

あと、手元でも環境を作ってみてはいるものの、まだ完全に動くようにはなっておらず試行錯誤しているところです。特に VP2 との相性が悪い様でオブジェクトのピック周りの問題が解決していないです。この辺りは PIXAR 版とは違って自前でゴリゴリ頑張っている弊害ですね。

もしかしたら Luma Pictures の outliner を併用すれば PIXAR 標準 Maya プラグイン(+ゴリゴリ自前開発)でも必要なことはできるのかもしれないですが。。。。このあたりは引き続き要調査です。

CG, KATANA

GroupStack

作業をする際、多くの種類のマテリアルをアサインしたり、ショットシーンで大量のアセットを読み込んでそれぞれに Lookfile をアサインしたくなります。
これまでやっていたように、一つ一つ MaterialAssign ノードなどを作成してそれを繋げてもできるのですが、ノードグラフが無駄に長くなりますし、管理も煩雑になってしまいます。

このような問題に対応するため、GroupStack ノードが用意されています。

たとえば、下図のように複数の MaterialAssign が連なっているケースを例にしてみます。

これでも要求は満たしていますが、見た目も良くありませんし、MaterialAssign ノードを増減するために Node Graph を更新しなければいけないので管理も煩雑です。

そこで GroupStack ノードを作って MaterialAssign ノードを選択し、Shift+中ボタンクリックでドラッグアンドドロップします。


すると、GroupStack ノードに MaterialAssign ノードの情報が登録されました。GroupStack ノードを元々あった場所に繋げると、元と同じ状態になります。

GroupStack ノードは一つのノードに対して同じ種類のノードを複数登録できます。反面、異なる種類のノード(MaterialAssign と LookfileAssign とか)を一つのノード中に含めることはできないです。また、登録できるノードの種類は一入力一出力のものに限られます。このあたりは、ノードの性質を考えれば妥当な仕様ですね。

CG, KATANA, USD

USD for KATANA

USD のリポジトリには KATANA 用プラグインも含まれています。ビルドも難しくなく、KATANA プラグインビルド用のオプションを追加して USD をビルドするだけですんなりいけます。

ビルドができたら、KATANA が USD プラグインを認識できるように起動スクリプトに手を加えます。私はこのようにしました。

#!/bin/sh

export KATANA_ROOT=/opt/Katana3.0v6
export DEFAULT_RENDERER=arnold
export USD_INSTALL_ROOT=/opt/usd

export KTOA_ROOT=/opt/KtoA-2.2.1.0-kat3.0-linux
export "KATANTA_TAGLINE=With KtoA 2.2.1.0"

export KATANA_RESOURCES=$USD_INSTALL_ROOT/third_party/katana/plugin:$KTOA_ROOT
export KATANA_POST_PYTHONPATH=$USD_INSTALL_ROOT/third_party/katana/lib:$KATANA_POST_PYTHONPAT

export PATH=$KATANA_ROOT/bin:$KTOA_ROOT/bin:$PATH
export PYTHONPATH=${KTOA_ROOT}/python:$USD_INSTALL_ROOT/lib/python:$PYTHONPATH

$KATANA_ROOT/bin/katanaBin "$@"

KATANA を起動すると、PxrUsd から始まる名前のノードが選べるようになっています。

PxrUsdIn でサンプルシーンを読んでみました。
※ZUp なようなので、TransformEdit で X 軸に -90° 回転を加えています

これで、KATANA でも USD を使用することができるようになりました。