自作CPUで遊ぶ 29

コロナに感染以降、イマイチ体調が優れない。疲労感がハンパない。

また、天候(あるいは気圧？)とも関連するようで曇りの日とかは最悪だ。後遺症的なものなんだろうか？ 

現在、Gコードの処理プログラムを作成中だが、対応するコードを限定的にすれば多少楽できるかなと思ったのだがいざプログラムを組み始めるとそれなりにちゃんと組む必要がありそうなことが判ってきた。 それにしてもこのRS274の言語仕様は結構…、何と言うか…、美しくない。

プログラムはインタプリターとして組むつもりで、構造は２パス式で最初のパスで構文チェックと中間コードに変換し、次のパスで実行する。

そんな方針でプログラムを作成中だ。

自作CPUで遊ぶ 28

円弧処理

Gコードには円弧用のコードが定義されている。 矩形コーナのRや円形な図形はCAMツールが線分に変換してGコードに出力するのではなく円弧用のデータが出力される。 円形はよく使うので円弧処理の実装は必須だ。 円弧用のGコードはG2とG3の2種類ある。G2は時計回り用、G3は半時計回り用だ。 フォーマットもcenter formatとradius formatの2種類ある。前者はパラメータとして円弧の終点座標と、始点座標から中心座標へのオフセット座標を与え、後者は終点座標と円の半径を与える。turnsは円周をなぞる回数だ。 何れかのフォーマットでデータが入力されたらこれをX/Y軸のパルス数に変換してモーターを回す必要があるが、この処理をどこでやるか、つまり、ARMコアでやるかZumi32でやるかを検討する必要がある。変換に三角関数演算が必要な場合はARMでやるしかない。

center formatの場合は終点座標と、始点座標から中心座標へのオフセット値が与えられるので、下図のように中心座標と半径を求めてやればあとはXまたはY軸を増加しながら対応するYまたはX座標をピタゴラスの定理で算出していけば良いので三角関数は出てこない。

一方、radius formatはちょっと面倒だが、中心座標を求められればあとはcenter formatと同じ処理にできるハズだ。

検討した結果、以下のやり方で中心座標は求められそうだ。 Zumi32側にはルート演算器は入れてあるので、これならZumi32でも処理できそうだ。

自作CPUで遊ぶ 27

前回、Zybo側のPetalinuxではSimple frame bufferを使っているので3D表示できないと書いたが誤りだった。 Zybo単独でも3D表示できた。 PetalinuxはlibGLESライブラリがあるのでfreeglutをFREEGLUT_GLES=ONでビルドしてこれを使うようにしたら3D描画できた。 予想に反してレスポンスは悪くない。 上記動画で動きがモタツイているように見えるのは私の操作がモタツイているためだ。

自作CPUで遊ぶ 26

GUIアプリだが、 図形表示で3D表示も出来るようにした。 3D描画はOpenGLを使っている。

以下は開発用LinuxマシンからZYBO上のPetalinuxにssh -X でログインしZyboでアプリを動作させGUIは開発用マシンの画面に表示させている・・・が、ここである問題に気づいてしまった。 Zybo側のPetalinuxはsimpleframe bufferでX Windowも動くようになっているが、よく考えたらGPUの機能はないのでOpenGLは使えない。 

つまり、Zybo単独の状態ではこのアプリは動かない。。。 orz 

2D表示はOpenGLを使わないでも出来るが3DはOpenGLナシでは無理なので3D表示機能は諦めるしかないか。それとも必ず開発PCからログインして使うようにするか。

うーむ。悩ましい。

図形表示機能の他にGコードの処理プログラムも作らなければならない。

Gコードは正式にはRS-274と呼ばれる数値制御のためのプログラム言語であり、1960年代初期にEIAで開発され1980年2月にRS274D/ISO 6983としてISOで規格化されたようだ。(https://fabricesalvaire.github.io/pythonic-gcode-machine/gcode-reference/rs-274/index.html) 

Gコードの仕様についての知識が不足しているのでインターネットで検索してみたところLinuxCNCの文書に詳しい説明があった。（https://linuxcnc.org/documents/） 

正確な数は不明だが、規格ではGコードは100種、Mコードはユーザー定義を除くと20種程度定義されているようだが、多分全てをサポートする必要は無い筈だ。試しに過去にこのブログで作成したポンプや基板の切削データ等のGコードファイルで使われているGコードとMコードを調べたところGコードは13種、Mコードは6種だった。

但しこれはGコードを生成するCAMソフトによっても差異があるかも知れないのでこれらのコードだけで十分とは言えないかも知れないが、とりあえずこれらの実装から始めることにしようと思う。

自作CPUで遊ぶ 25

まだ制御ソフトが完成していないので今まではスピンドルを移動するために一々簡単なプログラムを書いて移動させていたのだが、非常に面倒なのでCNCペンダント的なものを作ることにした。 右側の縦に２つ並んでいるスイッチはZ方向の上下動のスイッチ、その左のひし形に配置されているスイッチはX/Y方向の前後動のスイッチだ。右上のスイッチはABORTスイッチで押下するとプログラムモードの動作を中止出来る。 左上のスイッチはリミットスイッチを一時的にOFFにするスイッチだ。 スピンドルがリミットスイッチが働く限界まで移動するとFPGAのロジックで強制的にモーターを止めるようにしてあるが、この状態になるとモータードライバのENをソフトで解除し手動でパルスモーターを回転させてリミットスイッチがOFFになる場所まで戻す必要があった。 このスイッチを押下するとリミットスイッチを切り離すので、スイッチ操作でスピンドルを安全な位置まで戻すことが出来る。実際使ってみると非常に便利で原点の位置決めも容易になった。

GUIアプリだが、スピンドルの軌跡をグラフィックスで描画するつもりだがその描画の部分のコードを書き始めた。 今回は昨日実機で描画したデータをグラフィックス描画させてみた。まだ配列のデータ列から描画しているだけだが、最終的にはガーバーデータの座標値かあるいはFPGAのモーター制御部のPCNT値で描画することになる。

自作CPUで遊ぶ 24

電源はCN4030のコントローラのやつを外して使うことにした。このコントローラはあまり分解したくなかったがしゃーない。 また、この電源は24V単出力なので別途5V用の電源も実装した。 これまではスピンドルモーターに鉛筆を括り付けて描画に使用していたが、圧をかけると傾いたりズレたりするので専用のペンを自作した。 φ4の真鍮パイプにボールペンの芯とスプリングを入れた。これでコレットチャックに装着できるようになった。 また、スプリングが入っているので描画面にテンションを掛けながら描くことが出来る。 前回のデータを描画させてみた。 こんどは旨く行った。やはり電源の容量不足が原因だったようだ。

 次は３倍の描画速度で描かせてみた。 これもＯＫ!!   ウェーイ  \(^_^)/

自作CPUで遊ぶ 23

昔、DDS IPを作りその応用としてFUNCTION GENERATORを作った。その時に出力をオシロスコープにつないで幾つかのリサージュ図形を描画させたが、その一つに下図のような図形もあった。 そのデータがまだ残っていたので、これを変換してCNCで描画させてみたのだがうまく動かない。 スピンドルの動きを見ると図形通りに動いていない。 パルス生成部から出力されるPCNT値を抽出して表計算ソフトで散布図を描かせてみた。 UARTを追加してZumi32のソフトからprintfで値をダンプできるようにしたおかげでこのようなことは容易にできる。 描画結果は合っているので、FPGA部分は問題なさそうだ。

色々調べた結果、どうも電源の容量が足りていないようだ。 もっと容量の大きい電源に交換しなくては。。 

 ちょっとまだ速い気もするが、上記と平行してGUIアプリの画面を作り始めている。 なんかまだ機能を入れ忘れている気もしているのだが。。。

今作っているCNCの動作モードとしてはプログラムモードとマニュアルモードがある。前者はガーバープログラムを実行するモード、後者は手動でスピンドルの位置などを操作するモードだ。 画面の左側はプログラムモード用だ。ガーバープログラムは複数を登録できるようにする。最上段のChoice部で実行するプログラムを選択する。 選択されたプログラムの内容はその下のエディタ部に表示される。ここで編集も可能だ。最下部のボタン類でプログラムをロードしたり、編集したり、編集したものをファイルに出力したり、実行したり、中止したり出来る。 

画面の右側は主にマニュアルモード用だ。 最上部のEM STOPは非常停止用ボタンだ。その下の黒い部分はスピンドルの軌跡を描画する。その下のX lmt, ... はリミットスイッチ等の状態表示だ。このアプリはwxWidgets ライブライを使っているが、wxWidgetsにはLED表示器のようなのがないのでcheck boxで代用している。果たして旨く行くかどうか。。　 その下の左側はX, Y, Zの移動量と速度、及び各軸の原点設定用のボタンだ。X/Y/Zボタンをクリックするとその時の各軸の位値が原点に設定される。ORIGINボタンをクリックすると３軸が同時に原点設定される。 右側のX+, X-, ...はスピンドルの位置を手動で移動させるためのボタンだ。ボタンを押下している間その方向に移動する。 最下部のModeボタンはプログラムモードとマニュアルモードを切り替える。Goto Zをクリックするとスピンドルを原点に移動する。Auto ZはZ軸の自動原点設定用ボタンだ。Spindleはスピンドルの回転のON/OFFを設定する。PumpはポンプのON/OFFを設定する。 

パルスモータの加速度やDI/DOの極性設定などは常時表示させる必要はないので別ダイアログで操作させるつもりだ。

このアプリはZYBOのPetalinux上で動かす。PetalinuxはSimpleframe bufferでX Windowも動くようになっているのでZYBOのHDMI出力にモニタをつないで表示させることも出来るし、別PCからssh -Xログインして別PC上のXサーバーに表示することも出来る。

… と、まぁこんな感じで構想しているのだが、うまく行くかな？

その前に電源をなんとかせねば。

自作CPUで遊ぶ 22

今使用しているモータードライバはDM556Dというものだが、このドライバはMicro Stepが 800 [pulse/rev] 〜 40000 [pulse/rev]の範囲で設定できる。 Micro Stepが大きければ大きいほどパルス当たりの移動量が小さくなり分解能が上がるが、軸の移動速度とは反比例の関係になるので最高移動速度が下がってしまう。また、最高速度はパルスモーターの回転数の上限とも関係する。Micro Stepが800, 1600, 3200, 6400の場合の上限値を実機で探ってみたところ以下のような結果になった。但し、この値は無負荷（切削していない）状態の値なので、実負荷では下がる可能性がある。 3200以上のMicro Stepの場合の最高移動速度が遅く感じたので今回は1600を設定することにした。 

次に以下のプログラムをzumi32で走らせ、移動速度を色々と変えてX方向150mm, Y方向50mmの矩形を描画してみた。

X方向 60000 [pulse/sec]、Y方向 56000 [pulse/sec]の場合

実際に切削する場合はもっと遅い速度で動かすことになる。 X方向が脱調しているように見える部分もあるが描画した矩形の寸法はほぼ150mm×50mmだった。

自作CPUで遊ぶ 21

コロナに感染してしまった。 ... orz 

最初は妻が発熱の症状になり、二日後に私も発熱した。発熱の具合としては私のほうが重く40℃超まで上がった。全身は痛むし・ガタガタ震えるほど悪寒はするしで非常にシンドかった。熱は３日目位から下がり今は平熱に戻っている。鼻水や喉の痛みや疲労感があり、頭が少しクラクラしているが回復して来ている。 5日間の休養期間も終わったので月曜からは仕事に復帰できそうだ。

さて、CNCだが当初は下図のように*_en信号で動作のON/OFFを制御するようにしていた。

この方法だけだとX/Y軸を同時に加減速制御しながら正確にパルス数のパルスを発生させるのが面倒なので、生成するパルス数（ = 移動量）と起動パルスを与えて動作するモードも追加することにした。また、手動送りで移動させる場合などは前者の方法が向いているので両方の制御方法に対応させることにした。前者が手動送り用、今回追加するのがプログラム動作用だ。

以下はプログラム動作モードをシミュレーションした結果だ。 スピンドルがP0(x0,y0)からP1(x1,y1)への移動指示が来た場合ソフトウェアはこれをX, Y各軸の移動量に変換しその値を設定してkickすることになるがこれをシミュレートした。 この例ではXの移動量（= パルス数）を1000、Yのそれを3000とした。P0→P1への送り速度を1000000、加速度を100とした。（テキトーな値） これからX/Y各軸の設定値を図のように求めた。

波形最下部のXY-AXIS speedはX/Y各軸の速度をテストベンチで合成（y = sqrt(X速度^2 + Y速度^2))した結果だ。 以下は加速部の拡大。X/Y軸の加速期間は一致しており、定速時の速度は設定値に一致している。

以下は減速部の拡大。X/Y軸の減速期間はほぼ一致しており、停止時の総パルス数（*_pcnt)は設定値（*_pnum）に一致している。

以下は手動送り動作をシミュレートした結果。 速度や加速度などのパラメータは上記のままで、x_feedを1にしてX軸のみを動作させている。x_feedが1になると加速し、設定速度に達すると定速動作に以降しx_feedが0になると減速して停止する。総パルス数は加速開始から減速終了（停止）までなので、この動作の場合はx_feedが1の期間よりも余分にパルスが発生（移動する）ことになる。

上記以外にもRTLに若干の変更を加えた。具体的にはzumi32のプログラムのデバッグ効率を上げるためにUARTを追加した。これをZYNQ-PSのUART0と接続した。

これでzumi32側のプログラムからのデバッグメッセージをPS側（Petalinux）で見ることができる。 以下はプログラムの例だ。１秒周期のタイマー割り込みの割り込みハンドラ内からprintf関数を使って"Hello World 数字\r\n"文字列を送信させている。 このprintfは30〜40年くらい前にスクラッチから作成したもので最終的にsend_str()をコールする。（引数は表示する文字列） 浮動少数型には対応していないが今回のようなデバッグ用途には十分使える。

Petalinux側はminicomを動かした。 正常にメッセージを受信している。

自作CPUで遊ぶ 20

本体からのリミットスイッチケーブルのコネクタの接触不良が見つかったり色々とトラブルったが最終的に動かすことができた。 まだRTLの作り込みは必要だが、これでソフトウェアの実装作業に入れる。

自作CPUで遊ぶ 19

前回からの続き、 PMODコネクタで余っている信号はヘッダコネクタに出しておくことにした。それとリレーの接点と端子台間の配線は太いのに変えた。

この基板は脳内で回路設計しながら作ったので、PMODの信号との接続関係の確認も兼ねて回路図を起こした。そして、この回路図の情報を元にVivadoのプロジェクトを変更してDI/DOが制御できるようにした。

DI/DOをUターン接続し、DOの出力がDIからリードできるか確認した。結果はOK、問題なし。

これで漸くコイツを動かしながらのプログラム開発に進められそうだ。

今回作ったコントローラはここに置く。

スピンドルモータのコントローラはまだ接続しない。X/Y/Z ３軸の制御が出来るようになってから接続するつもりだ。 その時はちゃんとした筐体に収納するつもりだ。

自作CPUで遊ぶ 14

前回の続き、 

ウィンドウマネージャだが、ネットで軽量ウィンドウマネージャについて調べたところ幾つもあることが判った。 この中で、icewm、fluxbox、fvwmをインストールしてみた。 3種のソフトをビルドしてインストールするのにメチャクチャ時間がかかったが何とかインストール出来た。

以下は各ウィンドウマネージャの画面表示だ。 上からicewm、fluxbux、fvwmだ。画面の画素数は1024x768にした。

 

icewm

fluxbox

fvwm

どれも似たようなもんだがicewmが若干好みなので、icewmを採用しようと思う。 また、画面の画素数は1280x1024に増やすことにした。 petalinux-image-fullには**gears**という3Dで歯車が回転するプログラムが含まれている。その中のX11用のgears_x11を動かしてみた。 これを動かすことに特に意味は無いが、simple frame bufferでも3Dのアニメーションプログラムが動作するので何か嬉しい。

 

… ということで、ユーザーランドもpetalinuxのまま行くこととし、ウィンドウマネージャはicewmを使うことにした。

自作CPUで遊ぶ 13

最近 exhausted 気味で全ッ然作業が捗らない。 ... orz

FPGAボードにZYBOを使うことにしたので、今回はPetalinuxとzumi32用クロスGCCのインストール等を行った。 また、ZYBOはVGAとHDMIのコネクタを持っており将来的にはGUIのアプリも作りたいので、simple-framebufferも入れてX11が立ち上がるようにもした。デバイスツリーのsystem-user.dtsiは以下のようにした。 simple-framebufferを使うためには、Kernel ConfigurationのDevice Drivers -> Graphics support でSimple framebuffer driverとFrame buffer Devices の Support for frame buffer devices を有効にする必要がある。 vivadoのblock designは以下のようにした。今日は時間が無かったのでZYNQ-PS部とzumi32部間はUART接続にしたが、後に共有メモリ方式に変更するつもりだ。

petalinuxはpetalinux-image-fullを16GBのSDカードにインストールして動かしていて、FAT32部を2GB、ext4部を14GBにしているのだが、今回使用したバージョン2022.2はサイズが巨大でこれだけで使用量が97%位になっている。そのため、追加のアプリやクロスコンパイラ等が入らないので別のUSBストレージを繋いで /usr/local にマウントし使用することにした。これも後にインストールするアプリを選別してサイズの縮小を図ろうと考えている。 また、petalinux-image-fullにはmatchboxっていうwindow managerが入っているのだが何かショボくて実用性は無い。軽量のウィンドウマネージャーを自分でインストールするか若しくはユーザーランドはubuntuにしたほうが良いのかも知れない。以下はmatchbox-window-managerの表示画面だ。

GTKWaveのアイコンが写っているがこれは後からインストールしたもので最初から入っている訳ではない。

 zumi32用クロスコンパイラもインストールした。ビルドに数時間かかったが何とかビルドに成功しインストールできた。 今回画面の解像度を1900x1200にした。一応、X Windowも動くが解像度が高すぎるためかウィンドウをマウスでドラッグして動かす場合のレスポンスが非常に悪い。下げたほうが良さそうだ。