昼に起きた。パソコンに向かって、gcode リファクタリングのプログラムを書く。綺麗に、また、エラーなくと、出来のよいものを目指して苦労した。とりあえず動いた。
夜、とある配信を見ていたら、気になる話題が 2つほど（作業しながらなのですべては把握できず）。
夜中、先日（200416）の作業の加工試験が行われていた（遅くまでありがとうございます）。うまく出来た用で何より。
1つ目は、自分で作ってみると、見え方や解像度が上がる。話の流れは、自分で DJ としてつなぐつもりで曲を聞いていると解像度が上がる、的な。まさしくこの通りで、やらなきゃ難しさもわからない。
2つ目は、概要を知っていることと、それらを使ってきちんと高い打点を出せることはぜんぜん違う。後者の人らの存在は尊く、打点は積み重ねによるところが大きいだろう的な話しであった。
これらは、僕が頻繁に使っている言い回しの「理論上できる」というものに近い。やり方はなんとなくわかるので出来そう、多分出来る、が、精度は不明というもの。
理論上できるものを実際に出来るかという問題については、正しい知見を多く溜めておいて近しい問題から正確な予想をする、予想が出来なければすばやく試す、ということで解決できる。
このような話は教員の、「『きちんと』やるのはとても難しいよ」、という表現を思い出す、心に刻みまくっている。
今回のハードウェアは、Marlin 等の汎用のファームウェアではなく、独自ファームウェアなので gcode の構文がわずかに違う。また、エクストルーダを主軸として扱うので、通常の E とは違う実装が必要っぽい。実際に動く gcode と、Cura から出力した gcode を一行ずつ見比べ、その辺をチェック。
1層目から 2層目にパスとしてつながっていて出力しながら移動するのか、分かれているので出力せずに移動するのか、で場合分け。少し迷った。
自分でゼロから gcode を出力する場合は、各行に XYZEF などすべての要素を書いてしまえば良いので、デバッグ用のプレビューが楽なので嬉しい。一般的な gcode では、変位しないパラメータは書かないことが多い。これは手修正の際に便利とかそういうものなのか、メモリの節約なのか、詳細は不明。