見出し画像

3Dプリンター　Marlinの主要機能の実際。走り書き

鳥ゴリラ

現在配布されているMarlinには色々な機能が載っていますが、市販品の3Dプリンターでは新製品であっても機能が有効にされていないので、なんでかな？なんて思っていましたが色々と事情があるようです。
具体的にはファームウェアをビルドする際のコンパイラの最適化が思ったように働かずに上手く動かないROMが出来てしまう見たいです。

ココまでとココからも中途半端な知識で適当に書きますので話半分でお願いします。


Junction deviation 
S_CURVE_ACCELERATION 
ADAPTIVE_STEP_SMOOTHING
MIN_STEPS_PER_SEGMENT 6 
Linear Advance 

Junction deviation（以下JD）は印刷時のカーブでの速度調整を従来のJark制御よりも高度化した新しいアルゴリズム。

3DプリンターってG-CODE一行毎に移動の指令を出して動いているのかと思っていましたが、実際にはG-CODEを解釈してJDとかS_CURVEとかの動作を考慮して実際の動作の指令を印刷エンジンが生み出して動いているようです。
で、JDを使用するとG-CODEに対して細切れなステップの駆動キューの乱発が発生してしまい、ステップモーターの指示とか内部の処理（割り込み処理らしい）とかが上手くいかなくなって印刷品質に悪影響が出るようです。致命的なトラブルではなく些細なバグ程度の問題なので印刷結果にプツプツが多く出るとか積層が少しずれるとか、中途半端な不具合になるみたいです。

スライサーでも印刷品質に問題が出る場合は解像度を下げると上手くいくなんて解決方法も良く見ますので、基本的には3DプリンターのCPUには負荷を掛けない方向の配慮が現在のMarlinには必要のようです。この辺は32bitでも8bitとでも同じみたいです。ただarmの方がクロック数が高いのでパルス発生の安定性には有利な点があるようです。割り込みのオーバーヘッドもArmの方が低いのかな？

JDを有効にしたTRIGOLLIRA（8bit機）でMBLが有効になっていると40mm/S程の印刷スピードが処理能力の限界のようです。MBL無効では50mm/Sが限界かな？それを超えると印刷に連続性がなくなりプチフリしながら印刷が続きます。
microstepも32や64に設定を変更すると途端に調子が悪くなるので、駆動キューの処理だけで無く駆動ロジック周りにもこれっぽっちの余裕も無いようです。

JD有効　→実行形式の駆動キューが高精度（細切れ）になる。　→キューの処理で割込みを利用していて、細切れだとオーバーヘッドが大きくなり過ぎる。　←ボトルネック。
32bitにしてみる　→cortexM3に浮動小数点ユニットがない＆8bitほどに最適化されたライブラリがなくコンパイラ任せ　→制御の骨格はAVR時代のまま何も変わっていない。ARMの性能を発揮できない。　→割り込み周りのパフォーマンスも悪いケド作動クロックでカバー？　→メモリバスを使用したLCD駆動とかも入って来ちゃった。　→思った程パフォーマンスが上がらない。

なので最近では不要とも思えるcortexM4(浮動小数点ユニット付き)の200MHzに迫るようなCPUを搭載したMarlin機が登場しているんですね。(ATMEGAにFPUが付いているのが奇跡的？なのかな)

Marlinを使用して快適な3Dプリントをするためには、今のところ駆動キューのスループットがボトルネックに成っているようなので、駆動周波数がなるべく高いCPUを使うのが「吉」かな。

MIN_STEPS_PER_SEGMENTは設定値以下のSTEP数の指令は次の指令と統合して実行する機能

MIN_STEPS_PER_SEGMENT の値はJDとかが標準になる前は1とか2がデフォルトだったんでしょうか？2年ほど前の海外の記事ではJDかS_curveの中にバグがあるみたいだから「3」にすると調子いいよ。と言うのを目にします。あとは「16」とかも見かけますね。今では「6」がデフォルトになっているので、やっぱりJDの制御系に洗練されていない部分が含まれているのか？複数の指示を纏めて実行する様な誤魔化しを行うような設定になっています。 1mm/80step×6＝ 0.075mmなので、6stepって結構大きな値です。　この機能もうまく動いているのかいないのか？ JDの問題か分かりませんがE軸との連携にも影響が出ていて、相性問題とかもあるみたいです。設計はclassicjarkやs_curveの時代の物でしょうから、JDとの相性も疑わしきかな？

ADAPTIVE_STEP_SMOOTHINGは、こういうレベルでCPUに余裕があるときには細かなステップで処理する機能なんでしょうね。余裕が無くても働いちゃう様ですが。、、、これもClassicJarkを念頭に設計されているのかな？

S_CURVE_ACCELERATION はJDよりも前にリリースされた機能みたいですが、こちらも計算が複雑になってCPU負荷が高くなって、、、と言う問題が当時あったみたいです。ですがこちらは職人によるアセンブラでのコーディングのおかげで最適化やボトルネックの影響を受けずにうまく動く様になったみたいです。ClassicJarkと合わせるのが良いのでしょう。


そして、JDと S_CURVEと ADAPTIVE_STEP_SMOOTHINGは 互いに干渉して不具合を起こすみたいですが、LIN_Advanceは干渉しないみたいです。たしかにE軸はmicrostepを32にしても調子悪くなりません。若干印刷が良くなるくらいです。E軸周りの処理には余裕があるみたいです。


Marlinのビルドは結構「沼」なんですね。


こんな事なら一掃の事 8bitと32bitは分けて、8bitは今まで通りの伝統芸能のコンセプトで、32bitは更なる飛躍を求めてチャレンジングに発展してくれれば良いのにな。なんて思ったりします。




Classic Jerk制御
&
S_CURVE_ACCELERATION 無し 
& 
ADAPTIVE_STEP_SMOOTHING 無し 
& 
MIN_STEPS_PER_SEGMENT 大きめ


現状の格安系市販品の機能選択は安定動作としては最高のセッティングの様です。


要するに、 


「Prusaしか勝たん。」


てこと~~~。

最近のベッドの重たく、ローラーのフリクションの大きい機種にはJDはとても相性が良い機能なので、安価なCPUでも普通に動くようになってほしい物です。


JD_HANDLE_SMALL_SEGMENTS に問題がある何て記事もあるので

//#define JD_HANDLE_SMALL_SEGMENTS

コメントアウトすると良いようです。どうなんでしょうかね。あまり変わらない気がします。

2.0x系へ移行してから大分経つようですがまだbugfixが続いているのかな？ klipperなどにリソース移ってしまったのでしょうか？やっぱり完成している8bitMarlinを32bitに移植するのとバグの片付け仕事はexcitingでは無いので、klipperチームに行っちゃうよなぁ~。　頑張って欲しいですね。



最後にMARLIN開発の胴元のおじさんへのインタビュー動画です。　


日本語で要約すると、

「Prusa さえチャント動けば良いしそれが理想的なんだ。だいぶ後援して貰ってるからね。 エンダー3がしっかりと動いてしまったらPrusaの価格の根拠が無くなっちゃうじゃない。それじゃぁダメなんだよ、 皆んな仲良くやってるんだからね www  そんな生やさしい物じゃないんだから ! 多くの人を動かしているんだからねぇ、、、分かるだろう君にも…？　新進の格安系企業は売価が安いからって◯を出さないのに適応の依頼とかウルサイからキラキラのTFTをプレゼントしてやったぜぇ !!  奴らは見てくれが良いのが好きだからね w その為のArm32bitさwww！」


って言ってるのかな？　正確には翻訳字幕を参照下さい。










ブラックジョークすみません。

いいなと思ったら応援しよう！