June 2009 Archives

Ealing Broadwayで工作用品を探してきました。 手ごろなPillar Drillを探してたのですが、ありませんでした。

その代わりに買ってきたものは以下です。

精密ドリル。3.50ポンドでした。 なんと0.30mmから1.00mmまでは0.05mmきざみであります。 相当丁寧に扱わないと、すぐに折ってしまいそうです。

こちらはDyamond Burr Set。1.99ポンド。 基板の銅箔の残りの除去にどうかなと思い購入。 試してみましたが、一応使えそうです。 ただ、今回の基板は対象となる面積が大きすぎるのでちょっと無理そう。

ようやっとインクジェット用のOHPシートを見つけました。 Staplesにありました。 20枚で13ポンド強と結構高いですが、仕方なし。

機材の都合で、出力6Wの蛍光灯、基板との距離は約16cmになりました。 キットの説明書には、27Wの蛍光灯で15cmの距離のときに露光時間30分ということなので、露光時間を長く取りました。およそ45分です。

現像時、やはり露光ムラがけっこうあったことが発覚しました。 中央部分はきれいに銅箔が露出しても、周辺部分に露光しきれてない部分があります。 一応蛍光灯を動かしながら露光したのですが、ちゃんと時間を計りながら一定時間ごとにムラなく光を当てるようにしたほうがいいようです。

後になってわかりましたが、現像後にかなり念入りにレジストの残りを検査するべきですね。 銅箔が露出していると思っていても、薄く残っている部分がけっこうあったようです。 そういう部分は、あとで網掛けのように銅が残ってしまいます。

そのため、エッチングがなかなか進まず苦労しました。 レジストがうっすらと残っているらしい部分の銅がなかなか溶けず、30分粘ったところで、パターンが痩せてきた部分があったので中止しました。

7～8割方はきれいに抜けたのですが、かなりきつく残っている部分もあり、仕方ないのでいったん仕上げを行ってから修正をかけることにしました。 本当はレジストが乗っている状態で修正をかけて、再度エッチングを行えばよかったことに後で気づいたのは内緒です。

なお今回、先日購入した赤外線温度計が大活躍でした。

現像液やエッチング液の液温を非接触で測れるので、大変便利です。 特に、液温を維持するために、液を入れた容器をお湯を張った大き目のタッパーに入れ、時々液温を測りつつ作業ができました。

当たり前ですが、「やってみなければ分からない」ことがいろいろ分かりました。

OHPシートはうちのプリンタ(HP)用のを買ってきて、高品質モードで印刷しました。 コントラストも高く、印刷面と基板を密着させてもレジストがはがれるということもありませんでした。 ちゃんと露光できれば、今回のピッチ(ライン幅10mil、間隔50mil)は十分に実用に耐えます。 慣れれば間隔25milでも十分いけそうです。

今回は成功したとは言えませんが、おおよその手順は理解できたので、次も頑張りたいと思います。

なお、穴あけも一応少しだけやってみました。 ドリルが重くかつスタンドがないので、基板のほうを水平に手で持って作業しました。 70milのパッドに1mm径のドリルで穴を開けてみましたが、特に問題は感じませんでした。 ポイントとしては、あらかじめ穴あけ(よくある6本セットに入っているやつ)でセンターに印をつけておくことくらいです。 50mil間隔の隣のラインに干渉もしません。

パターン印刷用にOHPシート(Transparency film)を探しているのですが、店頭では見かけません。 PC WorldもCurrysもMaplinもだめでした。 もちろん、web shopでは売られていますが、すぐに手に入れたいとなると店頭で見て買いたくなります。

写真用紙ならいくらでも売ってるんですけどね。 最近はみんなOHPなんて使わないからでしょうねぇ。

特殊な用紙のコーナーでは、名刺用紙やCDラベル用紙などのほかに、Tシャツに転写する紙なんかもありました。 これなんかは、ひょっとすると生基板を使うときに使えるかもしれません。

レーザープリンタならいいんでしょうが、まだ日本から輸送途中で届いてないのです。 他人のプリンタを使って壊したりしたくないですし。

昨日は透明シートがなくて挫折した基板作成。 今日帰りにスーパーに寄ったのですが、ありませんでした。 最近はOHP使わないので、専門店に行く必要がありそうです。

うちにあるいくつかの種類のクリアファイルで印刷を試してみましたが、どれもインクは乗らず、うまくいきませんでした。

さて、今回は初めてということもあり、サンハヤトのPK-6というキットを使います。 ポジ感光基板に現像剤、エッチング液とレジストペンやらパッド転写用シートやら廃液処理剤やら、関連グッズが一通り入っています。 千石で2300円くらいで買いました。

そもそも自分で作成する基板の仕組みというものがよく分かってなかったので、あちこちネットを彷徨ってようやくどういうものなのかが分かってきました。 サンハヤトのキットは、手順は書いてありますが、仕組みはあまり詳しく書いてないのです。

メモ代わりにここにも書いておきます。

基本的には、次のような仕組みになっています。

1. 銅箔が施してある生基板の上に回路として残したい部分をレジストペンなりOHPシートなりトナーなりで遮蔽(保護)する
2. 遮蔽していない部分をエッチング液で溶かす
3. 基板上で遮蔽して溶け残った遮蔽部分を磨いて除去し、銅箔を露出させる
4. これにより、銅箔部分が回路として機能するとともに、はんだを乗せられるようになる。

問題は「どのように回路部分を遮蔽するか」です。 生基板の上に直接レジストペンなどで手書きしてもいいのですが、あまり細かいパターンは作れません。 そこで、パソコン上で設計し、プリンタで印刷したものを使いたくなります。

この際、プリンタで生基板上に直接印刷できればいいのですが(業務用では実際そうするようです)、個人ではつらいものがあります。 中にはプリンタ、主にCDラベル印刷、すなわち堅い平面への印刷が可能なインクジェットプリンタ等を分解して直接印刷に挑戦する強者もいるようですが、なかなか難しいようです。

感光基板は、銅箔の上にさらに感光剤を塗布してあります。 これにOHPシートなどを印刷したパターンを重ねて感光させれば、パターンのないところの感光剤が反応し、現像処理により感光剤が除去されて銅箔が浮き出ます。 こうして浮き出た銅箔をエッチングで除去します。

一方生基板では、一般にパターンをレーザプリンタで出力した紙やシートを使います。 この紙やシートを基板に密着させ、アイロンをかけることでトナーがパターンどおりに基板上に移ります。 その後エッチングすれば、やはりパターンのない銅箔部分が除去されます。

このあたりを知らないままサンハヤトのキットの説明書を読んでも、意味がさっぱりでした。

キットに入っているポジ感光基板(P12K)は片面紙フェノールの100mm x 150mm x 1.6tのもので、これだけで500円ほどします(価格はいずれも千石、以下同じ)。 両面(G33KR)にいたってはガラエポですが、960円です。 生基板なら、同じサイズの片面紙フェノールのもの(12)が180円、両面(12R)でも240円です。

このようにポジ基板は高いので、いずれレーザープリンタから生基板に転写する方法を試したいと思います。 これなら感光する代わりにアイロンで転写するので、手順的にも楽になると思います。 まぁ、慣れは必要でしょうけど。

ExpressPCBでのアートワーク、一応ほぼ完成しました。 片面基板用に頑張りましたが、ジャンパを20本ほど飛ばす必要があります。 それでもユニバーサル基板に配線することを考えたら気が遠くなりそうなので、パソコンでデザインできるのは助かります。

結局、「PCBのデザインにあわせて回路を変える」ということを結構しましたが、なんとか形になったかな?

ジャンパ部分は反対面に描いてあるので、ほぼこのままExpressPCBで注文することも可能ではあります。 でも今回は自分で焼きます。 ちなみに、ツール上からの見積もりでは、価格は2枚で120ドル、10枚で200ドル強といったところでした。

今日さっそく焼いてみようと思ったのですが、プリンタに印刷できる透明シートがないことが判明。 クリアファイルで試してみましたが、いまうちにあるインクジェットプリンタではまったくインクが乗らないため、今日のところは諦めました。

せっかく今日はMaplinに行ってinfraredの温度計と、ついでにデジタルノギスを買ってきたのに。

なんとか今週中に1枚作って、うまくいったら来週の日本出張時に生基板を補充したいものです。

ちなみに、以下が今日買ってきた温度計(Thermometer)とノギス(Callipers)です。 どちらも電池式のデジタル。 温度計はこんなにいいものは不要だったのですが、これしかなかったのです。

価格は、温度計が29.99ポンド、ノギスが9.99ポンドでした。 温度計の電源はは006Pで、買うときに「これは電池が必要だけどいる? buy one get one freeだよ。つける?」と言われたので「いいよ」と言って買ったのですが、本体には最初から電池が入ってました...。 ノギスはLR44なのですが、最初から入っている上にスペアも同梱されてました。

え～ん、回路にバグ(未結線)が見つかって、ジャンパを足さなければならなくなりました。 これでジャンパはおよそ30本になります。 それ自体はいいのですが、まだ何かあるのかと思うと心配なのと、パッドを追加したことで焼付け時のショートの可能性が増したのが心配です...。

先日のトライアルで、Roleがtraitでないのが気になっていたのですが、これは以下のようにすれば簡単に解決できました。

val checkingRole = (new Object with Source)(checking)

Sourceはtraitにしておいて、ダミーのObjectと一緒に生成させるわけですね。

Roleに対してAccountのメソッドが発行できないのは相変わらずですが、これならとりあえず複数のRoleをひとつのオブジェクトに対して同時に使うことは可能です。 たとえば、

val currentRole = (new Object with Role1 with Role2)(obj)

のようにするわけですね。

以前設計したSDカードアダプタのアートワークにチャレンジしています。

使う回路CADはフリーのものです。 どのソフトにするか、いくつか試しました。 悩みましたが、まずはExpressSCHおよびExpressPCBにしました。

• PCBEは使いやすいが、PCBレイアウトに特化しているので回路図との連携が取れない。
• Eagleはオートルータもあって強力だが、使い勝手に癖があり、特にカスタムコンポーネントが作りにくい。

これまで回路はBSCh3Vを使っていたので、まずは回路をExpressSCHで書き直しました。 ExpressSCHの持つ部品はあまり多くないのですが、カスタムコンポーネントは簡単に作れるようです。 ライブラリ中の似たような部品を置いて、Ungroupしたあと、ピンを編集して再びGroupすれば部品になります。 ついでにカスタムコンポーネントにしておけば、使いまわしも楽です。

ExpressPCBでは、回路図で登場した部品を自動的にボードにおいてくれることも、ラッツネットの作成もしてくれません。 これはちと面倒といえば面倒ですが、逆に自由度も増しています。 というのは、回路図とボードデザインの間は部品番号とピン番号のみで連携しているようなのです。 そのため、やはりライブラリ中から似たようなな部品を引っ張ってきてUngroupし、適当に編集すればカスタムコンポーネントを作れます。

ハンドルーティングなのでかなり面倒ですが、これは練習だと思ってがんばります。 ツール上で配線チェック(交差している、全結線したかどうか等)ができないので、目視検査となりちと大変です。

ちなみに、手持ちのキットが片面基盤なので、とりあえず部品面に回路を引いて、実回路では半田面に焼き付ける予定です。 そうすると、反転してデザインする手間が減ります。 回路が複雑なので片面基盤で出来るレベルではないですが、その辺はジャンパを飛ばすなり何なりで対処します。 でも、なるべくならプリントしてしまいたいので結線を工夫します。この辺はやってみて初めてノウハウが身につく感じですね。 引き始めは結線の多さに呆然としていましたが、少し結線を進めていくとだんだん面白くなってきます。

今のところ、SDカードの部品がないのが少々困ります。 結線用のパッドを置く位置は問題ないのですが、固定用のパッド位置が分かっていません。

結構回路規模があるので、大きさが問題になりました。 通常のカートリッジ用の基板は縦が72mm程度です。 配線幅を50mil(1.27mm)で設計すると横はともかく縦があふれます。 配線の太さはデフォルトの10mil(0.254mm)です。 電源線は太くするとしても、このくらいでないとかなり厳しいです。 このあたりはもう少し練る必要がありそうです。

エッジカード部分も片面しか作れないので、これも何とかする必要があります。 とりあえず、部品面へはパッドで接続し、イージスペンで部品面の端子を作ることにします。

設計にあたっては、西田さんに教示いただいた「なるべく基板配置を考えた回路図にする」というのがとても参考になりました。 CPLDやSRAM、244などは利用する端子に自由度があるので、これらについて最初から配線にクロスが生じにくいように設計したのですが、おかげでアートワークがかなり楽になりました。 こういうのもノウハウがいろいろあるのですね。

DCI[1]はなかなか面白そうなんですが、一連の記事を読んだだけではいまいち感覚がつかめません。

ちなみに、ディスカッションは炎上してます。 一通り全部読んでみたのですが、確かにDCIが本当に"new architecture"と呼ぶに値するものなのかは議論の余地がありそうです。

読んでばかりでは埒が明きません。 Sebastian Kubeckのブログ[2]にはJavaのサンプルがあるので、これをScalaで試してみました。

まぁ、toy exampleなんですが、はじめの一歩ということで。

サンプルはCouplinやKubeckと同じ銀行の資金移動です。 せっかくScalaを使うので、なるべくノイズを減らすように努力します。

なおDCIについては、長いですが、Jim Coplienの本のドラフトもあります。 また、ベースとなる考え方としてRole Object Pattern[3]が参考になります。

データオブジェクトはきわめてシンプルで、データを保持するほかには単純なset/get等のメソッドしか持ちません。 Accountの場合、バランスとその増減となり、これがwhat-the-system-isの側面です。

Roleは特定のコンテキストでの役割をデータオブジェクトに与えます。 Accountはトランザクションにおいては送金元になったら送金先になったりします。 これらがRoleで、必要に応じてAccountにバインドします。

これらを動作にまとめるのがUsecaseとなります。

まずはデータオブジェクトとして、Accountを定義してみます。

trait Actor {
}
class Account extends Actor {
  var balance: Int = 100
  def decrease(amount: Int) = { balance -= amount }
  def increase(amount: Int) = { balance += amount }

  override def toString = balance.toString
}

ActorはKubeckの記事に出てきたデータオブジェクト用のベースクラスで、一応タグとして入れているだけで今はそれほど深い意味はありません。 Accountのバランスがいきなり100なのも、データベースアクセスなどのセットアップを省略するためのもので深い意味はありません。 いずれにしても、Accountクラスはきわめて単純なものです。

RoleをAccountにバインドする方法はたとえばmixinのようなプログラム上のテクニックとなります。 Couplinの記事[1]でScalaにおいてはtraitを使ってRoleを実装し、newする際に次のようにバインドしています。

val source = new SavingsAccount with TransferMoneySourceAccount

しかし、これはAccountオブジェクトが動的に与えられる(既にインスタンス化されている)場合は使えません。 実際のビジネスロジックでは、与えられたAccountのインスタンスにRoleをバインドしたいことのほうが多いのではないかと思います。

Kubeckの記事[2]では、Javaでオブジェクトに対してRoleをバインディングするようにしています。 こちらのほうが現実的に見えるので、動的にRoleをバインドする方向で考えます。 そうなると、以下のようななかなか美しいバインディングのための制約表現も使えなくなりますが、とりあえず置いておきます。

trait TransferMoneySourceAccount extends SourceAccount {
  this: Account =>
  ...
}

ここでは、次のように定義してみました。

trait Role[T <: Actor] {
  var _actor: T = _
  def apply(actor: T): this.type = { _actor = actor; this }
}

class Source extends Role[Account] {
  def transferTo(sink: Sink, amount: Int) = {
    withdraw(amount)
    sink.deposit(amount)
  }
  
  def withdraw(amount: Int) = _actor.decrease(amount)
}

class Sink extends Role[Account] {
  def transferFrom(src: Source, amount: Int) = {
    src.withdraw(amount)
    deposit(amount)
  }

  def deposit(amount: Int) = _actor.increase(amount)
}

Roleは特定の役割を演じるためのベースとなるtraitで、Actorを保持します。

SourceとSinkはそれぞれ資金の移動元および移動先の役割を持ちます。

Usecaseでひとつのユースケースを実装します。

object Saving {
  def apply(checking: Account, saving: Account, amount: Int) = {
    val checkingRole = new Source()(checking)
    val savingRole = new Sink()(saving)
    checkingRole.transferTo(savingRole, amount)
    println("checking=" + checking)
    println("saving=" + saving)
  }
}

ここでは与えられたアカウントデータに役割を与えるためにRoleをnewで作っています。

最後に、テストプログラムで実験です。

object Test extends Application {
  var checking = new Account
  var saving = new Account
  Saving(checking, saving, 30)
}

簡単な例ですが、この程度だとアーキテクチャというよりは実装のデザインパターンみたいに思えますね。 なお、やってみていくつか課題が見つかりました。

まず、RoleはActorをひとつのみしかバインドしてません。 複数のActorにまたがるRoleを実装するための方法は考慮が必要でしょう。

二つ目に、Roleが特定のActorに依存しています。 理想的には、さまざまなActorに使えるRoleを実装できるといいんですが、そのためにはデータモデル側のインタフェースをあわせる必要があります。 これはある意味当然ではありますが、Roleに依存してデータモデルを修正するようでは本末転倒になってしまいます。

あと、前述してますが、Scala的にはRoleのサブクラスにtraitを使えていないのが美しくないですね。 これは同時に、ActorのインタフェースとRoleのインタフェースが同じオブジェクトに対して使えないことを意味します。 Role Object Pattern[3]では、RoleがActorのインタフェースを実装し、RoleがActorにdelegateすることで対処しています。

Scalaの仕組み上、traitはクラスにmixinできますが、オブジェクトにmixinできません。 これが原因のひとつではありますが、もう少しエレガントな解決方法があるのではないかと思います。

私はAdobe Acrobat 7を使っているのですが、文書を開くたびにアクセシビリティ機能の読み上げタグ付けのダイアログが出てうざったくて仕方ありません。

調べてみたのですが、Acrobat 8ではオプションで設定できるみたいなのですが、7では同じ方法が使えません。

でようやく分かったのが、プラグインを外せばいい、ということでした。

プラグインはAcrobatのインストールディレクトリ(通常はC:\Program Files\Adobe\Acrobat 7.0、以下これを想定)以下にあるので、これを削除または別ディレクトリに移します。

C:\Program Files\Adobe\Acrobat 7.0\Acrobat\plug_ins\Accessibility.api
C:\Program Files\Adobe\Acrobat 7.0\Acrobat\plug_ins\Accessibility.JPN

2つめのファイルは言語設定なので、インストールしているAcrobatの言語環境によって異なるかもしれません。

同じ方法で、他に不要なプラグインを読み込ませないようにすることも可能です。 ただしプラグインの依存性に注意しましょう。 たとえば、

C:\Program Files\Adobe\Acrobat 7.0\Acrobat\plug_ins\MakeAccessible.api
C:\Program Files\Adobe\Acrobat 7.0\Acrobat\plug_ins\MakeAccessible.JPN

もアクセシビリティに関連するプラグインですが、これを削除すると、

SaveAsXML
TablePicker

の2つのプラグインがMakeAccessibleに依存しているので、起動時にエラーが出ます。

このような場合、メニューの「ヘルプ->Adobeプラグインについて...」を見て、プラグインの依存性を確認しましょう。

IBMが1981年にIBM PCをリリースしたとき、普及を狙って回路図からBIOSのソースコードまで公開したことは有名な話ですが、その実物があったので見てみました。

他の資料とともにアーカイブされています。 IBM PC/XT Technical Reference v2.02となっているものです。

確かに、システムユニットをはじめとして、キーボードやらディスプレイアダプタやら、各コンポーネントごとに回路図があります。 また、ROM BIOSのアセンブリソースリストも載っています。

このドキュメントと根性さえあれば、コンポーネントを集めてパソコンをまさに「自作」することも可能です。

ドキュメント全体は非常に膨大なページ量なので、最初の数ページで気づいたことだけ。

オリジナルのIBM PCおよびPC/XTのクロックは4.77MHzです。 PC-9801初代は8086を採用して5MHzのクロックでしたから、わずかに低い周波数となりますが、その理由は回路にありました。

ドキュメントでは、14.31818MHzのクリスタルを3分周してクロックを生成するよう書いてあります。 4分周すると約3.58MHzのNTSCテレビのカラーバースト信号用のクロックが得られるからなのですね。

Z80などを採用した8ビットパソコンでも、同じ理由で約3.58MHzのクロックを使ったものがありましたが、こんなところでもコスト削減をしていたのですね。 よくできています。

ちなみに、これに興味を持ったのは、手元に8088(OKIのM80C88A-2)の石があるからなのでした。 この石の定格周波数は8MHzですが、同じクリスタルを2分周してクロックを生成すれば約7.16MHzで動作するIBM PCが作れるのかな?

最近マシンのマイグレーションで設定をいろいろ移行しているのですが、Firefoxのプロファイルの移行をしたのでメモ。

ユーザのプロファイルはデフォルトでは以下のディレクトリに格納されています。

C:\Documents and Settings\(ユーザ名)\Application Data\Mozilla\Firefox\Profiles\(ランダムの文字列).default

このディレクトリの中にある、以下のsqliteのファイルをコピーすると、ブックマークのみならず、クッキーやブラウズの履歴、フォームへの入力履歴など、およそブラウザ上のアクティビティがほぼ完全に移行できます。

content-prefs.sqlite
cookies.sqlite
downloads.sqlite
dta_queue.sqlite
formhistory.sqlite
permissions.sqlite
places.sqlite
search.sqlite

なお、これらのデータはSQLiteを使っているので、中身はFirefoxのアドオンのSQLite Managerで管理することも可能です。 ただその場合、間違ってデータを削除してしまったりしないように、コピーを作ってからのほうが安全でしょう。