BeagleBoneBlackのLinuxCNCから誤パルスを検出！！！

先日「BeagleBoneBlackにLinuxCNCをインストールしてみた」で紹介した制御装置の出力パルスを測定してみました。
（LinuxCNCのインストールやSSH接続は上記の記事で説明しています。）

ある程度設定を煮詰めてからパルスの確認をしてみたところ、設定値より1～2パルスほど余分にパルスが出力されていることが判明！！
いろいろ設定した後なので、もしかしたら設定ミスが原因かもしれません。
そこで、LinuxCNCを再インストールし、初期設定の状態でパルスを測定してみることにしました。

結果から言うと、どうやらBBBから安定したパルスが出力されていないようなのです。

BBBからのパルスが正確に測定できるようになりました。
原因はDir端子の接続方法とマイコンのプログラムに問題がありました。
修正しましたら正確なパルスが測定できるようになったのでとりあえず誤パルスは出力されていなかったようです。

BBBにインストールしたLinuxCNC

最新版を下記のサイトから入手してインストールしました
（bone-debian-8.5-machinekit-armhf-2016-06-19-4gb）
→　配布サイト：Beagleboard

最新版：https://rcn-ee.com/rootfs/bb.org/testing/2016-06-19/machinekit/bone-debian-8.5-machinekit-armhf-2016-06-19-4gb.img.xz
クラシック：https://rcn-ee.com/rootfs/bb.org/testing/2016-06-19/machinekit/bone-debian-7.11-machinekit-armhf-2016-06-19-4gb.img.xz

最新版を例に説明していますが、クラシックでも同様の症状が発生しているのでどちらをインストールしても同じです。

LinuxCNCの起動

Windowsパソコンと同じように「スタートメニュー」→「CNC」→「Machinekit」でLinuxCNCを起動することができます。

Configurationの選択

bbb用に予め用意されているサンプル設定ファイルを利用します。

「Sample Configurations」→「ARM」→「BeBoPr-Bridge」→「BeBoPr-Bridge」を選択します。

ちなみにBeBoPr-Bridgeは3Dプリンター用の設定ファイルのようで、スピンドルの制御は設定されていません。CNCフライス盤として利用する場合、[Xylotex]を利用すると一通りの設定が入っています。（Xylotexでも同様の誤パルスを確認しているのでどちらを選択しても同じかと思います。）

今回BeBoPr-Bridgeを選んだ理由はホームシーケンスの設定変更が不要なためです。

LinuxCNCの起動と準備

LinuxCNCが起動すると下の画像のようなウィンドウが立ち上がります。
1、E-STOPをクリックして停止を解除
2、仮想電源ボタンをクリックしてマシン電源をON
3、「Manual Control」の「Continuous」タブから10を選択します。

これで測定準備ができました。
「Continuous」タブの左にある「+」「-」をクリックするとX軸が10だけ動き、パルスが出力されます。キーボードの矢印キーでも同様の操作ができます。

ちなみに、デフォルト設定では10㎜あたり800パルスが出力されるはずです。

BBBのパルス検証

10㎜毎にパルスを進めています。
本来なら800パルスずつカウントされるはずですが、時折1、2パルス余計に出力されてしまっています。
なんと初期設定状態では正確なパルスが出力されていないことが判明

この不具合は、ソフトウェア上で原点復帰していないことが原因なのではないかと考えられます。
次に、ホームボタンを押してソフトウェア上の原点復帰してからパルスを出力してみます。

同様に10ｍｍずつ動かしてパルスを測定してみます。
原点復帰する前と比べ、誤パルスの発生頻度は低いものの、時折1、2パルス余計に出力されてしまいます。
この結果から、ホーム復帰をすると誤パルスの頻度は明らかに減少するもののやはりノイズといいますか誤パルスは相変わらず出力されてます。

ここまでの結果からほとんどお手上げ状態です。
ネットで検索しても（少なくとも日本では）この問題について論じているサイトが見当たりません。
もしかしたら私の測定方法（自作のカウンターやLinuxCNCの設定）に問題があるのかもしれません。

自作のパルス測定装置が問題なのかと思い、ステッピングモーターに繋いでパルスを入力してみると、累積誤差パルスによって徐々に軸がズレていくことを確認しました。
ということは本当に誤パルスが出力されているということです。

木製CNC自作さんにアドバイスをいただきました。

自力では解決しそうにないのでパルス測定器の自作の際、参考にさせていただいた木製CNC自作さんのサイトにお邪魔し、アドバイスいただくことに。
↓ここにコメントしているのは私です。
http://woodcnc300.blog.fc2.com/blog-entry-794.html

すぐにコメントに返信があり、詳しいアドバイスをいただけました。
アドバイスによると、ManualControlを使うとフィードエラーが出るのでそれが原因ではないかということ、ホームポジションにしてMDIでGコードにより直接動かせばパルスの誤差が出ないはず”多分パルス数の誤差が出てないはず、です。 ”とのことのようです。

早速アドバイス通りフィードエラーを確認してみると、マニュアルコントロールでは確かに数値が出ることを確認しました。

次に原点復帰させてGコードでパルスを動かしてみました。
アドバイス通り「G0X 100」と入力するとフィードエラーに数値が出てしまいます。
ところが。「G0X　0」で元に戻してみるとフィードエラーの数値は０になりました。

アドバイスの
>>フィードエラーの最終的な数値は０となります
とはこのことを言っているのでしょう。

BBBを再起動したら「G0X 100」でも”なぜか”フィードエラーが出なくなりました。
再現しようといろいろ試みていますが、再現性が無く原因は不明です。
（ただしやはりパルス異常は発生しているので根本的な原因は解決していないまま・・・）

そのうえで本題のパルスを測定してみることにします。
原点復帰してホームポジションにしてからGコードで駆動し、パルスを確認してみることにしました。
途中までパルス誤差が出力されないので解決かと思った矢先・・・
72000パルス目で2パルスの誤差、200000パルス目でさらに2パルスの誤差が出力されてしまいました。

ちなみに、誤差が出力されるのはBBBにインストールしたLinuxCNCの話で、パソコンにインストールしたLinuxCNCでは今のところ誤差が確認されないのでBBB特有の問題かと思います。

この件は情報が少ないので、BBBをお手持ちの方がいましたら同様の現象が発生するか検証していただけると助かります。
（上記の検証はほとんど初期設定状態で発生しているので再現性はあると思います。）

パルス異常値の件、木製CNC自作さんが追検証してくれました。
それによると先方のBBBでは誤パルスが出力されていないとのことです。
ということは、消去法的に自作のパルスカウンターに問題があるということになります。

が、

BBBにステッピングモーターを繋いで実際に駆動させてみると、やはり誤パルスが発生しているようで、モーターを一回転するGコードを数百行実行すると徐々にズレていってしまうのです。

これは明らかに何かがおかしい！！

パルス検証の考察

誤差が出て当然？

確かに加速度やデジタルのパルスを使っている以上、割り切れない値が出るのは当然で、そういった意味で誤差が出るという可能性も考えられます。
例えば加速中の”時間軸と座標軸”が理論値とある程度乖離するのは当然というか、理論値通りの制御ができるわけがありません。

しかし、移動途中の位置決めと、最終的な位置決めはでは話が別です。
最終的な位置決めに誤差が生じるような制御はCNC（数値制御）として欠陥ですし、いくらオープンウェアといえど、CNと言うからにはそんな制御はしないはずです。（原理的にも難しい制御ではないはずです。）

特に、今回Gコード上で100mm移動するという命令を出していますが、これは8000パルスという区切りの良いパルスを出力させています。
最終的に8000パルス出力すればよいのに、途中ゴニョゴニョしているうちにパルスがズレてしまうというのはあまりにもお粗末な話です。

 

ということで、これは明らかにおかしい！！
しかも原因はBBBにもありそうですし、私の自作カウンターにもありそう。
さらには第三者の検証では異常が見られないという厄介な問題・・・

過去の経験から、今回の問題は相当単純な部分を勘違いしているだろうとは思います。
さてさて、久々にはまったトラブルは解決できるのやら・・・

原因が分かりました。

Dir端子からの入力を遮断しているとノイズが発生するようです。
また、そのほかにもノイズが入っていたようで、こちらの修正方法なども併せて後日修正した箇所を説明しようと思います。
↓BBBのパルスが正確に測定できている様子。
このまま10時間ほど回し続けましたが、異常なパルスは検出されませんでした。