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だった。