2016年6月26日日曜日

CNC4030 22 (チューブ式ポンプの製作 11)

去年の9月頃、世界最小クラスかも知れないFPGAボードでCANを動かそうとしていた頃にある方からコメントの書込がされていたのを3日前まで気づかないでいた。せっかくコメントを書いて下さったのに大変申し訳無いことをしてしまった。 コメントの書込があった場合にはメールで知らせるように設定していた筈なのだが、コメント管理の設定に問題があったんだろうか? よく判らないのだがコメントの書込があるのに気づいて何か操作をしたらそこで新規コメントが書き込まれましたというメールが送信されてきた。

さて、コントローラだがzyboをCAN通信の相手にしてのデバッグを開始した。

が、通信できない。
以前CAN IP実装時に作ったボード(上の写真の青色ソケットのボード)に装着して動作させると通信できるので、今回作ったコントローラ基板の配線がどこかミスっているのかも知れない。
CANトランシーバICのパスコンの電源側の配線を忘れているのは見つけたが、他にもあるかな?


PCB切削

CNC3040でPCBパターンを切削してみた。
QFN32パッケージ (0.5mmピッチ x 32ピン) のパターンで信号線の最小幅は0.3mm、パターン間ギャップの最小幅は0.2mmだ。

CNC3040Cの付属品で以下の彫刻用エンドミルが付いてきたのだが、これだと旨く削れなかった。先端部の幅がもっと狭く且つ角度ももっと鋭角でないと上記寸法は厳しいようだ。

そこで、以下のΦ0.2mmのドリルの刃でやってみたら、刃が撓ってしまい全く削れなかった。次に刃を根本から1mm位残して切断し、これでパターンを削ってみたら上の写真のように何とか削れた。

Z軸方向のバックラッシュがあるようで、最初にゼロ調整して切削しても最後の方のパターンが旨く削れなかったりして数回重ねて削り直しした。切削深さが数十μともなると、切削面の平面度とかバックラッシュ等がかなり効いてくる。うーむ。


2016年6月19日日曜日

CNC4030 21 (チューブ式ポンプの製作 10)

回転数と回転方向の手動制御が出来るようになった。

何故か映像と音のタイミングがズレている…

次はCAN busからの制御だ。

今回はiCE40でDCモーターコントローラを作った訳だが、ステッピングモーターの1軸コントローラーを作るのも良いかもしれないという気がしてきた。それを2つ使えばX-Yテーブルが作れるし、3つ使えばCNCや3Dプリンタが作れる。


FPGAでLチカ 2 (iCE40の場合)

前々回のブログで、水晶発振器やCR等の外付け部品を使わずFPGAのみを使ってLチカを実現する方法を考え、FPGAのSLICEでリングオシレータを作ってそれをクロック源としてLチカを実現した。その時使用したFPGAはLatticeのXO2だったが、世界最小クラスかも知れないFPGAボード搭載のiCE40でも同様の実験をやってみた。

以下のようにリングオシレータを3506段のトランスペアラレントラッチとして記述した。



XO2の場合はSLICE内のレジスタがラッチモードで使用されていたが、iCE40ではLUTが使われていた。iCE40のレジスタはラッチとしての動作モードを持っていないのかも知れない。トランスペアレントラッチ記述でリングオシレータを作成するという方法自体は旨く行った。

出力信号の周波数は118.5KHzだったが、RTLを見て判るとおりリングオシレータで生成した信号をクロックとして出力用F/Fをトグルさせているので発振周波数はこの2倍の237KHzとなる。

段数が最小の場合も見てみた。

発振周波数は155.3MHzの倍なので310.6MHzだった。



2016年6月12日日曜日

CNC4030 20 (チューブ式ポンプの製作 9)

基板が出来た。


いつもの事だが、昨夜完徹して作り上げた。
一週間の内で土日が一番疲れるというのも考えものだが・・・

おやっさんよー、オイラ燃え尽きてぇんだよ−、真っ白な灰によー。ハエじゃねーぞ。
みたいな感じか。

以前作ったCAN IP動作確認用のRTLにはPWMも含まれていて、デフォルトで2KHz、Duty50%のPWM信号を発生するのようになっている。そこで、これをFPGAに書いて動かしてみたところ、あっさりと、いとも簡単に動いてしまった。 と、とりあえず \(^_^)/やったー、ワーイ。

このままだと、回転数や回転方向の変更が出来ないので、A/Dとスイッチの状態を連続ポーリングして可変出来るようにRTLを変更しなければならない。 それができたら次にCAN 経由で制御できるようにするつもりだ。


2016年6月11日土曜日

FPGAでLチカ

FPGAでLチカというタイトルをネットで見る時がある。
マイコンやFPGAの動作確認等の目的でLEDを点滅させることをLチカと言うが、「FPGAでLチカ」と言う場合にどういうやり方がFPGAらしいのか、あるいは、FPGAならではと言えるんだろうか?と考えてみた。

まずは思いつくのは、

reg [xx:0] cnt;

always @(posedge clk)
begin
  cnt <= cnt + 1;
end

assign LED = cnt[**];

見たいな感じでクロックでカウンタを回して、カウンタの上位の方の、LEDの点滅が視認できる程度で変化するビットでLEDを駆動する方法だろうか。でも、これだと当たり前すぎて面白くない。

あるいは、FPGAにソフトマクロのCPUを載せて、

while (1) {
   LEDport = 1;
   msleep(n);
   LEDport = 0;
   msleep(n);
}

のようなプログラムを実行させてLチカする方法もあるだろう。また、リアルタイムOSを動作させてタスクを定期的に起床させてそのタスクでLEDを点滅させるという方法もあるだろう。
でも、これらの方法はFPGAでLチカというよりはマイコンでLチカだし、FPGAならではの方法とは言い難い。

こういうのはどうだろう。

FPGAの出力をCRで遅らせて、FPGAに戻しそれを反転してまたCRに戻す。CR発振回路だ。
FPGA側のRTLは以下のような記述になる。

assign CR_out = ~CR_in;
assign LED = CR_in;

LEDの点滅周期はCとRの時定数で決まる。
この方法はアナログちっくで、ソフトウェアでは実現できない。でも、CとRという外付け部品が必要になるのでFPGAならではの方法とはちょっと言えないかも知れない。

で、最後にこういうのを思いついた。
FPGA内にリングオシレータを実装する方法だ。

この方法の場合、CR等の外付け部品は勿論のこと、クロック源の水晶発振器さえも不要でFPGAの内部リソースのみで実現できる。LEDの点滅周期は直列になっているバッファと配線を含むパスの伝搬時間の2倍の時間となる。
RTL記述は例えば以下のように書けるだろう。

wire [LENGTH-1:0] ring;

assign ring = {ring[LENGTH-2:0], ~ring[LENGTH-1]};
assign LED = ring[LENGTH-1];

あるいは、バッファのプリミティブセルをインスタンスして、

wire [LENGTH-1:0] ring;

BUFFER BUFFER[LENGTH-1:0] (
    .A({ring[LENGTH-2:0], ~ring[LENGTH-1]),
    .Z(ring)
);

assign LED = ring[LENGTH-1];

しかしながら、これらの記述では旨くいかない。回路合成で最適化されて1つのバッファのみの回路になるか、または、エラーになるかだ。実際に試してみたところLatticeの場合が前者でXilinxのISEの場合は後者だった。
そこで、トランスペアレントラッチとして記述し、実動作ではゲートを開きっぱなしにすることにした。

wire [LENGTH-1:0] ring;

assign ring = (~EN)? {ring[LENGTH-2:0],~ring[LENGTH-1]}:ring;
assign LED = ring[LENGTH-1];

このようにringをラッチと見せかけることで合成ツールに最適化されなくなった。

この回路を以前自作した MY FPGA BOARDのFPGA (Lattice XO2 7000HE)に実装してみた。
実際のRTL記述は以下のようにした。 7000HEはSLICE内のregisterの数が6864個なのでringの長さは6864にしている。また、ENはinputとしてPINに出しているが、実際は何も接続せずPINの属性をPULLDOWNにしてLに固定している。

リソースの使用率はきっちり100%になった。


physical view
全てのSLICEのregisterが数珠つなぎになっている筈だ。

SLICEの中身を見てみると…

ラッチが生成されているのが判る。

FPGAに書いて動かしてみた。
D3を点滅信号で駆動しているが、肉眼では視認できない。点滅周期が速すぎるようだ。

オシロスコープで信号を見てみたところ、約90KHzの信号が出力されていた。

そこで、ringの段数を減らす代わりに分周器を入れてringで生成したクロックを分周してLEDを駆動するようにしてみた。

registerが4個未使用になってしまった。

で、FPGAに書いて動かしてみた。今度は視認出来るほどの点滅周期になった。
video
オシロスコープで測ると約2.7Hzだった。

水晶発振器等の外付けのクロック源を使わず、FPGAのSLICEだけを使ってLチカ出来た。
他にも方法があるだろうか? しかし、上に書いた全ての方法がFPGAで実現可能であり、この多様性というか懐の深さがFPGAならではと言えるのかも知れない。

最高周波数は?
ringオシレータの周波数はゲートの段数によって決まる。。。ということは段数を最小にした場合、どの位の周波数になるんだろう? ということで試してみた。

周波数は約580MHzとなった。


このringオシレータの周波数はFPGA内部素子の遅延に依存しているので、コア電圧や温度の変動の影響を受ける筈で安定度は余り期待は出来ないかも知れない。が、手軽にFPGA内の全てのSLICEを活性化できるので、FPGAボード等を作った場合の電源の供給能力の評価や、FPGAの診断等に応用できるかも知れない。

ということで、久しぶりにFPGAを触るのでリハビリを兼ねてこんなことをやってみたのだった。




2016年6月5日日曜日

CNC4030 19 (チューブ式ポンプの製作 8)

耐久性確認のためにポンプを25時間動作させてみた。
このポンプの故障の仕方で一番恐れているのはチューブが摩耗して穴が空いて冷却液(LLC)が液漏れを起こすシチュエーションだ。それだけは避けたい。避けられない場合は漏洩した液が周囲に飛散したり、台の上が液まみれにならないような対策をしておく必要がある。

動作前のチューブの状態は以下の通りで傷等は無い。






このチューブでこれまでに数時間ポンプを動かしているが摩耗痕などもなくまぁまぁ綺麗だ。

ポンプは水を貼ったモップ用バケツに以下のように設置して連続動作させた。

印加電圧は最初の14時間が24V、その後の10時間が12V、最後の1時間を24Vとした。
途中電圧を下げたのは、深夜だったので動作音を下げるためだ。
モーターの定格は300[rpm]@24Vなので、(300 x 60 x 15 + 150 x 60 x 10) = 360000回転したことになる。(回転数は電圧と直線比例の関係にあると仮定して12V時の回転数を150[rpm]とした。) また、ローラーは6個あるのでチューブは216万回ローラーでシゴカれている筈だ。

運転開始時200mA台だった電流値が12時間経過したころから増え始め最後の方では400mA〜500mA位になっていた。何らかの要因でモーター負荷が重くなったようだ。


25時間経過後のチューブの状態は以下のようになっていた。ローラーや壁との接触面がテカっている。




また、ローラーや壁にも同様のテカリが発生していた。


触ってみると粘性があり水の漏出によるものでは無いようだ。摩擦熱でゴム表面が溶けたか変質したようだ。ローラーは指で弾くと滑らかに回転するのでベアリングの焼付け等は起きていない。

チューブの方に戻って細かく見ていくと、以下のような小さい裂傷が無数できていた。




このチューブゴムの肉厚は1.5mmあり、また、現実的にポンプを24時間動かし続けることは無いのでこの程度の傷で直ぐに液漏れに至ることは無いだろうが、消耗品と捉えて定期的に新品に交換したほうが良さそうだ。


モーターコントローラ
ポンプを連続運転している間、その隣でモーターコントローラを作っていた。

モータードライバはTB6643KQ、コントローラは世界最小クラスかもしれないFPGAボードを使うことにした。このFPGAにはCAN IPを実装して動かすところまではできていたので、これに今回のモーター用のPWM回路を追加して使う。モーターの回転数はボリューム(摺動抵抗)で行う。これをI2C I/FのA/Dコンバータ経由でFPGAで読み取る。ボリュームの設定位置に依らずCAN I/F経由で回転数や回転方向を任意に設定できるようにもするつもりだ。

こ、、、これでやっとFPGAに戻ってこれる。。。(涙)  かな?

上の写真は部品取り付けが完了した段階で配線はこれからだ。
が、今日はこれまで。今日は体調が悪い。わしゃ疲れた。


TE0720 No.4 (BNN-PYNQを動かしてみる 2)

TE0720でBNN-PYNQを動かすことが出来た。 以下は前回に続いてBNN-PYNQが動くまでの記録。 gdb (GNU debugger)で例外が出る原因を調べてみた。 例外が発生しているのはシェアードライブラリ(python_hw-cnv-pynq.so)の中であ...