ERROR: Failed to spawn fakeroot worker to run ...

なにかと忙しくてなかなか趣味の時間を確保できない。 ...orz 

家の開発機のOSはLinux Mintなのだが、最近バージョンを22に更新したところ、myCNC用のpetalinuxをビルドできなくなってしまった。ビルドの途中で ERROR: Failed to spawn fakeroot worker to run ... というエラーメッセージが出て終わってしまう。

そもそもLinux MintはpetalinuxがサポートしているLinuxディストリビューションではないのだが、更新前のバージョン21.3ではビルド出来ていた。 ただし、XilinxのAnswerを見るとサポートディストリビューションのSUSEでも同様のエラーが出る事例があるようだ。 

ネットを検索してみたが対処法は見つからなかった。  とは言え、Mintのバージョンを21.3に戻すのも嫌なので Virtualboxに仮想マシンを作ってそれにLinux Mint 21.3とpetalinuxとpetalinuxのsstate-cacheを入れて動かしてみた。 インストールは問題なく出来たのだが、ビルドに非常に時間がかかる。以前 21.3 でビルドしていた頃は10〜20分位でビルド出来た気がするが仮想マシンだと１時間近くかかった。 

これはちょっと遅すぎる。 

他に方法がないかネットで調べたところDockerを使う方法があることを知り、やってみた。

PetaLinux 2020.2のDockerイメージを作成するというブログの記事を参考にさせて頂いた。 

有り難いことに、ブログの作者が必要なファイル一式をGitHubで公開されているので早速cloneして中身を見てみた。 

DockerのコンテナにUbuntu 18.4のライブラリとpetalinux自体もインストールするようだ。 しかし、私の場合、XilinxのVitis, Vivado, Petalinuxは複数のバージョンを/usr/local/eda/Xilinx/というディレクトリにインストールしており必要に応じて使用するバージョンを選べるようにしている。できればこの運用スタイルは変えたくない。かと言ってそれらのバージョンをDockerのコンテナ内で再インストールするのも面倒だ。また、ビルド出来ないのはOSのライブラリの問題であってpetalinux自体が原因ではない筈なのでpetalinuxは既にインストールしてあるバイナリを使いたい。 

ダウンロードしたファイルのrun_base.shを見ると、Dockerは--volumeオプションでホストOS側のディレクトリをコンテナ内のディレクトリにマッピング出来るようなのでこの機能を使用して/usr/local/eda/Xilinx/をコンテナ内の/usr/local/eda/Xilinxにマッピングすることにした。同様に私が普段開発作業するディレクトリ等も--volumeでマッピングすることにした。 

ということで、Dockerfileとbuild.shとfiles/entrypoit.shを以下のように変更した。 

Dockerfileでは.vimrcは現在の自分の設定を使いたかったのでそれをインストールするようにした。 また、bashのプロンプトにdocker文字列を入れるためにPS1の設定を.bashrcに書いた。 この時点ではこれらのファイルのownerはroot.rootになるので、entrypoint.sh内でchownでownerを変更している。

entrypoint.shでは.vimrcと.bashrcのowner変更の記述を追加した。 build.shは以下のようにした。

このやり方の場合、build.shで作成したコンテナをそのまま使用できる。オリジナルのようにbaseコンテナとpetalinuxが入ったコンテナを作る必要は無い。 dockerの起動スクリプトは以下のようにした。 これをplnx.shという名前にして~/bin/に入れて使用する。

作成したdockerの環境では17分程度でビルド出来るようになった。 

素晴らしい！！ \(^_^)/

プロジェクトの復旧

・・・という訳で、myCNCのRTL及びVivadoプロジェクトの再作成を進めているが９割程度出来てきた。 休日は色々と他にやることもあって作業時間があまり取れなかったのもあるが、再作成する量も結構あった。 チマチマと開発を進めてきていたのだが、いざ作り直してみるとけっこうな規模を作っていたんだと実感した。 もう少しでディスクが壊れる前の状態まで戻れそうだ。

災難

開発に使っているPCのディスクが逼迫してきたので容量の増量と高速化も期待してM.2 SSDの4TB品を購入してデータをすべてそこに移した。 購入して１週間位は普通に使えていたのだが、突然故障してPCに認識されなくなってしまった。 

BIOSの設定を変えてみたり、別のPCで試してみたり色々してみたのだが駄目だ。完全に故障してしまったようだ。 悪いことにそれまで使用していたHDDの中身はM.2への以降時に消してしまっていたのでバックアップが無く元の状態に戻せなくなってしまった。 数十年かけて集めた資料やデータ、それにこのブログを通して開発してきたIPやソフト等がすべて消えてしまった。 

非常に痛い。人生終わったも同然だ。

なぜ故障したのか良くわからない。普通の使い方をしていたつもりなのだが。。。 

petalinuxのプロジェクトのビルドを複数平行に走らせたりしていたので、もしかしたら発熱しすぎて熱暴走で故障したのかもしれない。 約4万円もしたのに。。。地獄だ。 

なんとか古いHDDにデータが残っていないかとジャンク箱のHDDの中を探しまくってIPのRTLは見つけることができた。 残念なことにGPIBやDDR2, DDR3 コントローラ等は消失してしまった。それと各IP開発時の実装例等も消失してしまった。 

いまやっているCNCのプログラムも直前まで書いていたソースコードは消えてしまったが、幸いZybo側のSDカードにもちょっと前のコードは残っているのでこれに関してはそれほどのダメージはない。 ただし、FPGAのプロジェクトと回路図などは消えてしまった。 zumi32のRTLはあるのでプロジェクトの再構築からやり直すことになる。。。 

なんか、賽の河原で石積みをやらされている気分だ。 

こりゃいったい何の罰なんだ？

ワシャ何か悪いことをしたんかい？ と問いたい気分だわ。 

自作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 ３軸の制御が出来るようになってから接続するつもりだ。 その時はちゃんとした筐体に収納するつもりだ。