Baumkuchen’s Workshop

バイオリンと電子工作、DIY、ジョギングなど。

作りかけの自作CNCを完成させます#6-コントロールソフト4

コントローラソフトの続きです。Grblのコードの移植で問題となったメモリ容量不足をどう解決するかを考えます。

baum-kuchen.hatenablog.com

打開策#1

どの案を取るにしろ、一旦全部のソースコードを取り込んでビルドしてみます。ということです、案1の仮版を試行。目的は単にビルドするだけですので作動確認はしません。

まず、MLAのソースコードを一旦全部外してビルドです。例によって、リンク切れなどは、全てundefin.c/.hで対処します。

この状態でビルドすると、メモリ容量は57%の消費です。

Memory Summary:
    Program space        used  24ACh (  9388) of  4000h bytes   ( 57.3%)
    Data space           used   1A9h (   425) of   300h bytes   ( 55.3%)

次に、Grblのソースコードを全部、組み込んで行きます。system.cを組み込み込むと、cpu_map_pic18f14k50のIO定義のいくつかをAtmega328のものから、PIC用に変えてあげないと未定義でエラーになります。今回は、動作確認をする訳ではなにので、適当でかまわないですが、一応対応がとれそうなIO定義に変えることにしました(DDRD→TRISCなど)

この様に、少しずつ取り込むソースコードを増やしていった結果、ついにビルド出来なくなりました。限界の様です。

Memory Summary:
    Program space        used  3C68h ( 15464) of  4000h bytes   ( 94.4%)
    Data space           used   1D6h (   470) of   300h bytes   ( 61.2%)

Grbleのコアとも言える、次のソースファイルを組み込む前で、メモリ容量が94%となってしましい、どれ1つを組み込んでもビルドが通りませんでした。

  • gcode.c(GCode解釈)
  • planner.c(GCode解釈結果からstep動作に分解)
  • stepper.c(ドライバへのコマンド生成、割り込み)
  • settings(設定)
  • eeprom.c(設定の保存用)

と言う事で、打開策案1は、このままでは採用不可となりました。

今後について

次は、打開策案2の方向で考えてみることにします。

今回も短いですがこれで終わりです。御覧いただきありがとうございました。今後も、試行錯誤が続くとは思いますが、よろしかったらお付き合い願います。

 

作りかけの自作CNCを完成させます#5-コントロールソフト3

コントローラソフトの続きです。Grblのコードの移植を続けます。

baum-kuchen.hatenablog.com

Grblの骨組みをPICに実装する第一ステップクリアしたので、順次、組込み範囲を拡大していく構想でした。

コマンド解析部

早速、protocol_execute_line()以下を組み込んでいきます。できたら、system.c全体を組み込んでいきたいところですが、まず、一番中心となるsystem_execute_line()から、関数単位で組み込んでいきます。組込み先は、仮にundef.cに置きました。また、未組込み関数をダミー関数として、undef.cに仕込むため、最初のビルドを実施。

f:id:Baum_kuchen:20210907213554p:plain

ダメです。

たった一つ関数を追加しただけで、もうメモリが足りないと出ます(エラーコード1347)。普通はコンパイラが上手くやってからているわけですが、メモリ総量は足りてるが、連続したスペースが無いとのエラーです。

仕方がないので、関数内に手を入れて、ビルドが通るまで、コード量を減らして見ます。結局、ヘルプコマンドの解釈部分だけくらいまでコードを減らすと何とかビルドが通りました。

system.c

uint8_t system_execute_line(char *line) 
{   
  uint8_t char_counter = 1; 
  uint8_t helper_var = 0; // Helper variable
  float parameter, value;
  switch( line[char_counter] ) {
    case 0 : report_grbl_help(); break;
    case '$': case 'G': case 'C': case 'X':
      if ( line[(char_counter+1)] != 0 ) { return(STATUS_INVALID_STATEMENT); }
      switch( line[char_counter] ) {
        case '$' : // Prints Grbl settings
          if ( sys.state & (STATE_CYCLE | STATE_HOLD) ) { return(STATUS_IDLE_ERROR); } // Block during cycle. Takes too long to print.
          else { report_grbl_settings(); }
          break;
/* DELETE */
      }
      break;
    default : 
/* DELETE */        
      break;
  }
  return(STATUS_OK); // If '$' command makes it to here, then everything's ok.
}

ビルド結果ですが、メモリ使用量がほぼ96%行ってますので、もう無理です。

Memory Summary:
    Program space        used  3D9Ch ( 15772) of  4000h bytes   ( 96.3%)
    Data space           used   2BAh (   698) of   300h bytes   ( 90.9%)

一応、動きはします。最初がヘルプコマンド($)

f:id:Baum_kuchen:20210907215904p:plain

次が、設定表示コマンド($$)です(中身が繋いでないので全部0ですが)。

f:id:Baum_kuchen:20210907220053p:plain

ちなみに、config.hで、

//#define REPORT_ECHO_LINE_RECEIVED // Default disabled. Uncomment to enable.

コメントアウトすると入力をエコーバックしてくれるのでUSB経由できちんとデータが渡っているか確認できます。

打開策

ここまで、割と順調に進んで来ましたが、メモリ容量という超えられない壁にぶち当たってしまいました。予想通りと言えば、予想通りです。ただ、このまま、諦めるのも癪です。

選択肢としては、次が考えられると思います。

  1. USB シリアルエミュレータを捨てて、シリアル通信に変える
  2. USBエミュレータも乗るメモリ容量の大きいPICに載せ替える
  3. grblを大改造して必要メモリ量削減
  4. 素直にarduindoを使う

1は、USBエミュレータを削除しても容量が足りるか不明。USB-シリアル変換回路の追加も必要(まるで、Aruduinoハードを作っている様)

2は、PIC24FJ64GB002あたりを使うことになりますが、 作動電圧が3.3Vでレベル変換が必要というのも面倒

3は、Grblの大幅改造という手間。こうなると、Grblの流用のメリットも半減。大幅改造の1つとして、大幅機能縮小で、ひょっとしたらメモリ容量も足りるかもしれませんが、やってみないと分かりません。

4は、安直だが確実。自作CNCを一旦完成させるという目的にはかなうが。

どれも妙案がないので悩むところです。

今後について

ということで、もう少し考えたあとで決めます。案4をとるとしても、一時的なものにするつもり(多分)。

今回は短いですがこれで終わりです。御覧いただきありがとうございました。今後も、試行錯誤が続くとは思いますが、よろしかったらお付き合い願います。

 

作りかけの自作CNCを完成させます#4-コントロールソフト2

コントローラソフトの続きです。いよいよ、実際にGrblのコードの移植を試みます。

baum-kuchen.hatenablog.com

一気に移植する手は、ビルドが通るまで大変になると思われるので、徐々に取り込む範囲(ソースコード、関数他)を増やしていく戦法を取ります。 

 

ヘッダー

最初に、Grblのヘッダーファイルを全てインクルードした状態でビルドを通します。この状態でビルドが通るまでやれば、関数を必要な範囲で徐々に追加していけると思います。

前回も書いたように、Atmega328依存部は、大体cpu_map_atmega328p.hに定義されているので、これをpic用に書き換えます。といっても、できるだけ元ソースはいじらない方針なので、#ifdefでpic用の定義cpu_map_pic18f14k50.hを読み込ませる形とします。

cpu_map.c

    #ifdef CPU_MAP_PIC18F14K50 // 
    #include "cpu_map/cpu_map_pic18f14k50.h
    #endif 

cpu_map_pic18f14k50.hの中は、こに時点では修正しなくてもビルドは通りました。

あとは部分的に関数を追加していきますが、ソースコードファイル単位で追加していきたいので、一時的に未定義となると関数がある場合は、undef.cと言うファイルを作って関数定義だけ追加し、ビルドは通します。なお、ソースコード単位で追加すると、途中、使われ無い関数も出てくるが、敢えて削除せずそのまま(出来るだけgrblのソースコードには修正を加えない方針)としました。

また、IO定義もすべて、cpu_map_xx.hに定義されていないで、直接コード内でAtmega328のレジスタ類が呼ばれているところがあるので、そこについては、undef.hというファイルを作って、一旦、逃げることにします。

メインループ

前回も書いたがgrblの構造として、シリアルとタイマー割り込みとメインのGコード解析部からなるので、まずメインから攻めます。main()関数の中は、一連の初期化のあと、protocol_main_loop()関数が呼ばれるだけですので、まず、この関数を取り込むため、ソースコードとして、plotoco.cをPICプロジェクトに追加してビルドします。

main.c

/* GRBL code ******************************************************************/ 
// Start Grbl main loop. Processes program inputs and executes them. protocol_main_loop();

このとき使用するundef.cとundef.hは次の通り。

undef.c

#include "grbl.h"
///////////////////////////////////////////////////////////////////////////////
//global variables
parser_state_t gc_state;
system_t sys;
settings_t settings; ///////////////////////////////////////////////////////////////////////////////
//unincluded functions void report_status_message(uint8_t status_code){}
void report_realtime_status(){}
void report_init_message(){}
void report_alarm_message(int8_t alarm_code){}
void report_feedback_message(uint8_t message_code){} uint8_t serial_read(){return 0;}
void serial_write(uint8_t data){}

未登録の関数に加え、グローバル変数も追加。

undef.h

#include <xc.h> /* XC8 General Include File */
#include "grbl.h" /////////////////////////////////////////////////////////////////////////////// //register substitute #define SREG STATUS /////////////////////////////////////////////////////////////////////////////// //undefined macro #define sei()
#define cli()

SREGは、nuts_bolts.hに定義されているマクロで使用されていますが、Atmega328のステータスレジスタなので、PICであればSTATUSレジスタに相当するので#defineで置き換えます。あとは、sei()、cli()は割り込み許可、不許可のマクロですが、当面使わないので#defineだけして、逃げます。

これで、一応ビルドは通ることができました。ただし、何にも動きませんが(実際には、serial_read()からGコードが来るのをひたすら待っている状態)。メモリ使用率も結構行ってます。

Memory Summary:
Program space used 19C8h ( 6600) of 4000h bytes ( 40.3%)
Data space used 269h ( 617) of 300h bytes ( 80.3%)

シリアル入出力部

次に、シリアル入出力関数を実装して、PCのターミナルから何かしら反応が返ってくるようにします。

シリアルエミュレータCDCのサンプルコードを一部流用し、PCからデバイスが入力する関数

   getsUSBUSART(uint8_t *buffer, uint8_t len)

と、デバイスからPCへ出力する関数

   putUSBUSART(uint8_t *data, uint8_t Length)

を使って、それぞれserial_read()、serial_write()を実装します。

serial_read()

uint8_t serial_read() {
uint8_t c;

	if (RS232_Out_Data_Rdy == 0)  // only check for new USB buffer if the old RS232 buffer is
	{						      // empty.  This will cause additional USB packets to be NAK'd
		while( !(LastRS232Out = getsUSBUSART(RS232_Out_Data,64)) ); //until the buffer is free.
		if(LastRS232Out > 0)
		{
			RS232_Out_Data_Rdy = 1;  // signal buffer full
			RS232cp = 0;  // Reset the current position
		}
	}
    if (RS232_Out_Data_Rdy)
    {
//check if realtime command char exists       
        c = RS232_Out_Data[RS232cp++];
        if(RS232cp >= LastRS232Out) {
            RS232_Out_Data_Rdy = 0;
        }
    }
    LATCbits.LATC4 = 0;     //for debug
    return c;
}

RS232_Out_Data:シリアルデータのバッファ

RS232_Out_Data_Rdy:バッファにデータがあるかどうか

なお、変数名が_Outとなっていますが、PCからCDCデバイスへの出力の意味で、Grblへの入力に相当します。

また、まだ実装はしていませんが、実施のGrblのシリアル受信割り込みでは特別なリアルタイムコマンド(?(ステータス)、!(一時停止)、~(再開)、@(ドア開)、crl-X(リセット))に対する処理がありますが、ここは未実装です。USBのCDCデバイス処理に手を入れたくないので、serial_read()内で判断できないかと思っています。

serial_write()

void serial_write(uint8_t data)  {
//serial_write()
    //We need to buffer it up for eventual transmission to the USB host.
	if(NextUSBOut < (CDC_DATA_OUT_EP_SIZE - 1))
        {
		USB_Out_Buffer[NextUSBOut] = data;
		++NextUSBOut;
		USB_Out_Buffer[NextUSBOut] = 0;
	}

    //If any bytes are waiting, and the endpoint is available, prepare to
    //send the USB packet to the host.
	if((USBUSARTIsTxTrfReady()) && (NextUSBOut > 0))
	{
		putUSBUSART(&USB_Out_Buffer[0], NextUSBOut);
		NextUSBOut = 0;
	}

    //actual tx service
    CDCTxService();
}

USB_Out_Buffer:シリアルデータのバッファ

USBUSARTIsTxTrfReady()でUSB通信が可能か(送信可能か)を確認し、可能であれば、Host側にデータを送る(設定をする)。実際の転送は、CDCTxService()で処理されるらしく、これはメインで定期的にコールする必要があるようですが、今回はserial_write()の中で呼ぶことにしてます。

コマンド応答

USB-シリアルからのコマンドに反応するようにします。

protocol_main_loop()は、シリアルデータを受信して処理するだけ(今はダミー関数で何もしない)なので、report.cとprint.cを組み込むことで、多少、反応するようにしてみます。これができれば、コマンド解析の大きな流れが確認できて、あとは、各部のソースまたは関数を追加していけば全体を構築できます。

ビルドは、以下の定義を追加することで、割とすんなりできました。これは、AVR用のマクロで、ともにプログラムメモリへの割つけに関するものですが、詳しくはマニュアル*1を参照願います。

//def for report.c
# define PSTR(s) ((const char *)(s))

//def for print.c
#define pgm_read_byte_near(a)  (*a)

ただし、ビルドは通っても、メモリもほぼ余裕がありません。

Memory Summary:
Program space used 35C6h ( 13766) of 4000h bytes ( 84.0%)
Data space used 2BAh ( 698) of 300h bytes ( 90.9%)

動作確認

早速、コントローラに焼きこんで動作確認します。

コントローラのUSBポートとPCのUSBポートを接続し、TeraTermを立ち上げ。COM6を選んで接続まで完了。ちなみに、コントローラ内では実際のシリアル通信が行われているわけではないので、ボーレート等は何でもOKです。

f:id:Baum_kuchen:20210828172000p:plain

接続後、画面上は、何も出ていませんが、ここでキーボードのエンターを押したら次の様に反応がありました。ここまでは、成功です。

f:id:Baum_kuchen:20210828171258p:plain

 

Gコード解析部

ここから先は少し、苦労しそうです。

protocol_main_loop()で、シリアル入力1ライン分を切り出し、protocol_execute_line()で処理します。ここまでは実装済みですが、そこから、コマンドを解析するのが、system_execute_line()で、report.c、setting.c内の関数群及び、gcode.c内のgc_execute_line()関数となります。このほか、protocol_execute_line()からは、リアルタイムコマンドに対応するprotocol_execute_realtime()を呼び出しています。

f:id:Baum_kuchen:20210828204740p:plain

(図注:system_execute_line()以下は表示していません)

本丸のsystem_execute_line()、gc_execute_line()の前に、すでにファイルとしては組み込んでいるreport.c内の関数あたりから攻めようかと思います。ただし、ソースコードsystem.cを組み込んでしまうと、一気に範囲が広がりそうなので、思案が必要です。

今後について

ということで、次に登る山(Gコード解析部)が大きそうなので、今回は、ここで終了です。次で、なんとなくGrblの動きっぽくなれば良いかなと思います。

今回も最後まで御覧いただきありがとうございました。プログラムメモリ量で暗雲がたれこんでいますが、まだまだ続けますので、よろしかったらお付き合い願います。

 

*1:MPLAB® XC8 C Compiler User’s Guide for AVR® MCU

作りかけの自作CNCを完成させます#3-コントロールソフト

制御基板(ハード)ができたので、コントローラソフトの製作に着手しています。 

baum-kuchen.hatenablog.com 

Gコード・センダー

また、ちょっと寄り道です。コントロールソフトができた暁には、GIUを担うGコードセンダーとの連接が必要になりますが、GitHubには複数のものが紹介されていますが、その中からいくつか試しに動かしてみました。これは、実際に作りこむコントローラソフトをどこまでGrblに準拠すればいいかの下調べと、デバッグ中の作動確認のために使うためというのもあります。Gコードセンダーの条件としては、Windowsで動いて、CNCの軌跡がビジュアル化できるもの程度。それと、Grblとのやりとりがモニタ出来ると良いですね。あとはイメージかな。

以下、GitHubからダウンロードしたものを紹介(ただし、途中の開発サンプルでの評価ですので、深いところまでは見ていませんので、あしからず)

Universal G code sender

シンプルなGコード(G1コマンドで円を書かせるもの)を読み込んだ状態。右の座標表示(Visualizer)もマウスで自由な角度から見られるので、割とイメージし易くてよいかと。難点としては、直接Gコードの修正ができないこと(PlugInを入れるとできるみたいですが)。あと、Grblとつないでないので、エラーになって何も動きませんが(これは他のものも同じ)。

f:id:Baum_kuchen:20210815155836p:plain

bCNC

pythonベースのソフト。表示部分のインターフェースが若干難。自由に回転できないのと表示中心の移動がメニューボタンを押してからでないとできないところ。良い所は、Gコードエディットが充実していて右の座標表示と連動しているので分かりやすいです。あと、ファイルアクセスが通常のWindowsのダイアログでなくて、C:ドライブしか見れません。何か設定があるのかもしれませんが、ファイルを一々myDocumentに移しながらの作業になりそうで面倒くさいです。

f:id:Baum_kuchen:20210815165756p:plain

Candle

Visualizeもマウスで簡単に操作できるので良い。各windowも位置、サイズを自由に変更できるのも良いかも。ただ、Gコード編集ができるものの、Visualizerからの選択などはできないところが若干残念。

f:id:Baum_kuchen:20210816092541p:plain

結局、どれも長短ありますが、コントロールソフトが少し出来上がったら、少し詳しく見てみます。(どのソフトも、Grblが立ち上がったことを認識できていないので、その後の動作も見られていないので)

Grblの構造解析

いきなりGrblを力業で移植するにしても、まずは、ソフトウェア全体構造の把握が必要と考えました。GitHub上に詳しい情報があるかなとか、有名なソフトなのでネット上にないだろうかとか、すこし検索してみましたが、これと言ったものは無しです。

どこかのQ&Aサイトに、”授業の演習でGrblをPICに移植する課題がでたけど良い情報ないか”といった質問が投げかけられていましたが、”無理じゃない”的な解答で終わってました*1

ということで、自力で解析します。といっても、手作業では時間ばかり掛かってしまうので、ソフトウェア構造解析ツール(ソフト)を使うことにしました。

Sourcetrail

少し調べたところでは、フリーソフトでSourcetrailというものがありましたので、それを使ってみます。

www.sourcetrail.com

ソースコード一式を登録して、”解析”をすると、宣言、変数、関数等の依存関係をビジュアル的に表示してくれるので、複数ファイルを渡り歩いて見る手間だけでもだいぶ楽になります。操作も、GUIベースで直感的に分かりやすくて良いです。

Sourcetrailを起動して、New Projectで解析用のプロジェクトを作ります。Projectの作り方は、以下の様な流れです。

  1. New Projectを押し、Sourcetrail Project Nameに適当なプロジェクト名、Sourcetrail Project Locationにプロジェクトの保存場所を入力し、Add source groupボタンを押す
  2. NEW SOURCE GROPUダイアログで出てくるので”Empty C Source Gropu”を選ぶ
  3. Files & Directories to Indexに、ファイルを登録(+ボタンを押してフォルダ内のファイルを全登録)
  4. Global Include Pathsに、ATmega用のインクルードファイルのありか(C:/Program Files (x86)/Microchip/xc8/v2.10/avr/avr/include)を登録。なお、これが無くても動きます。
  5. 最後にCreateボタンを押す
  6. これでプロジェクト登録は完了ですが、引き続きStart Indexingダイアログが出てくるので、All filesを選んでOKで解析完了です。

解析結果は、こんな感じ。

f:id:Baum_kuchen:20210816142541p:plain

Sourcetrailの解析によると、Grblは、49ファイル、388マクロ、12の構造体、149の関数、グローバル変数は33、5つの型定義があるそうです。

f:id:Baum_kuchen:20210816143028p:plain

例として、main関数から、protocol_mail_loop()への参照を確認しているものです。全体の構造が分かりやすいです。(中身の紐解きは、別ですが)

割り込み関係

移植する上で全体の構造を左右するであろ割り込みについて確認してみました。Aruduino に搭載しているATmega328のCコンパイラ(実はこれ、MicrochipのXC8でした。全然知りませんでした。ちなみに、全Grblのソースコードをビルドしたらアッサリビルドできてしまったので驚きです。知らないってことは、恐ろしいですね!!)では、ISR()で記述するので、Sourcetailで調べるとあっと言う間です。全部で6か所ありました。

  • system.c :システムレベルの割り込み(リアルタイムコマンド:リセット、サイクルスタート、フィードホールド、Safty Door)入出力ピンの変化検知
  • serial.c:シリアル入力あり、シリアル出力が空の2つ。USARTからの割り込み
  • stepper.c:Grblのメインの割り込み(whorkhorseとの表記あり)30KHzのタイマー割り込み 
  • limits.c:各軸がリミットSWがONになったとき発生。入出力ピンの変化検知

PICにも同様な割り込みはあるので、置き換え可能と考えられます。ただ、30KHzが実現できるかというと、何ともわからないですね。

Aruduino(ATmega328)依存部分

できるだけgrblのソースコードを修正しないで何とかしたいと思います。

IO定義は、cpu_map_atmega328p.hに殆ど記載してありすが、各関数内で直接IOを操作しているため、IO定義のみでPICに置き換えができない場合は、各関数の内部を直接修正する必要がありそうです。以下、IOの種類ごとに見ていきます。

・ディジタルIO

GrblのディジタルIOの使い方として、STEP、DIR、LIMITの種類毎に同じIOポートの異なるBITを使っているため、PICへの移植もIOの使い方を同様にしないと大改造になります。幸い、制御基板の設計のところでも書いたように、たまたま、そのような割付をしていたので、何とかなりそうです。ちなみに、左がAruduino、右がPICです。

   STEP: PORTD bit2,3,4 → PC bit0,4,6

   DIR: PORTD bit5,6,7 → PC bit1,5,7

   LIMIT: PORTB bit1,2,3 → PB bit5,6,7

   RESET/FEED HOLD/CYC START:PORTC bit0,1,2 → 未定(使わない?)

この他、DRIVEイネーブル、SPNDLイネーブル、COLANTは、1bit毎にPORT指定があるので問題なしです(SPNDLイネーブルしか使わないが)。

デジタルIOの設定も基本は、各ポート毎のレジスタで、chに対応するbitで入力/出力設定、同じく、対応するbitで入力or出力をするという形式は、AtmegaもPICも変わりがないのでうまくいくでしょう。

・タイマ/カウンタ

タイマーモードの設定と周期の設定が主ですが、これは、stepper_init()関数、st_go_idle()関数とsettper.c内のISR(割り込み)の中でダイレクトに記載されていました。よって、ここはPIC用に書き換えるのが早道のようです。

Grblは、タイマ0とタイマ1を使って、AMASS(Adaptive Multi-Axis Step-Smoothing)

という低速時にゆっくり動く側の軸がスムーズに動く仕組みを導入しているとのことで(stepper.cのコメントによる)、タイマの使い方が若干複雑になっているようです(まだ、ソースコードをよく読んでいないので、感触です)。

また、スピンドルを可変とする仕組みにPWMを使っていますが、これはタイマ2を使っています。spindle_control.cで直接PWM関連のレジスタを扱っており、Atmega固有なので、移植するときは注意が必要ですが、今回は、そこまでは出来ないだろうと思っています。構想としては、スピンドルの回転速度は段階的に行うくらい。

・シリアル入出力

今のところ、USBシリアルエミュレータを実装しているので、serial_init()、serial_read()、serial_write()関数は、完全書き換えと思ってます。ただ、プログラムメモリ容量の懸念があるので、USBデバイスを諦めたら真面目に考えますが、ぱっと見たところ修正は、初期設定を除けば、定義ファイル位で行けるかもしれません。所詮、受信割り込みと送信エンプティーの割り込みくらいですから。

・割り込み

これは、PIC用に書き換えないとだめでしょうね。ただ、割り込み許可を行うところ位は、マクロ定義で何とかならないかなと思ってますが、美しさを追及しなければ何とかなるでしょう。

ということで、ソースコード解析ツールを使って、Grblの中身(というか触り)をざっと見て回って、内部構造の細かいところはさておき、移植は可能かなといった感触を得ました。実際やってみると、そんな簡単にはいかないかなと思いますが。

今後について

次から、部分的に実装しては確認を繰り返していきます。まずは、手始めに、Gコードセンダーとのインターフェースを取りたいので、シリアル通信からGコードパーサまでをつないで、何かしら反応するようにしてみたいと思います。

今回も最後まで御覧いただきありがとうございました。かなり途中の説明を飛ばしているところがありますが、何かのお役に立てれば幸いです。

 

<お断り>Grblの中身の解析結果は、私の勝手な解釈ですので、内容を保証するものではありませんので、ご承知おき願います。

*1:ここGrbl to PIC18にあります

作りかけの自作CNCを完成させます#2a-制御基板

前回、ドライバボードについては、何も書きませんでしたが、コントローラソフトができるまで時間がかかりそうなので、ちょっと寄り道(ドライバボードの実験結果)です。

 

baum-kuchen.hatenablog.com

ドライバボードの結果

GrblをAruduinoに載せるという安直な方法は敢えて避けることにしましたが、実際、Aruduino(NanoとUno)は買ってしまっていました。これを使って、ドライバボード&ソフトを改修した結果を確認しました。写真は、Nanoを使った試験セットアップ。

f:id:Baum_kuchen:20210815003944j:plain

Aruduinoから、X軸、Y軸にそれぞれ2000パルス(=10mm)づつ交互に出力して、正方形を書かせてみました。

f:id:Baum_kuchen:20210815004055j:plainf:id:Baum_kuchen:20210815004518j:plain

ほぼ寸法通りの正方形がかけました。ただ、正方形が、少し歪んでいるのは、ペン先のバックラッシュの問題と、ドライバ用PICのちょっとしたソフトの問題(*)のためです。(使った紙が電気工事士の過去問の裏紙ですいません)

(*)マニュアル制御のため、目標位置へのフィードバック制御を組み込んだことで、実際のパルス入力に対して、遅れが出たため。

今後について

一応、基本的なところは出来たということで、あとは、コントロールソフトの作成にいそしみます。ただ、メカ系の脆弱性は、如何とも、し難い感じです。

作りかけの自作CNCを完成させます#2-制御基板

まず、制御基板&コントローラソフトから着手します。

 

baum-kuchen.hatenablog.com 

システム構成

方針を受けて、もう少し具体化します。全体のシステムブロックを書くとこんな感じです。Aruduinoの代わりにPICを使っただけだろうって言えばそれまですが。

 

f:id:Baum_kuchen:20210812111552p:plain

ドライバボードの整理

作りかけのドライバボードは、機能をシンプルに、

  • コントローラからのSTEP/DIRコマンドに対応
  • リミットスイッチが入ったらコントローラに出力
  • マニュアルでのExtend/Retract機能は残す

とし、一部回路、ソフトを改修しました。(細部割愛)

コントロールボード製作

USB PICの選定

Controller用として、USBの使えるPICは幾つかありますが、最も基本的な(というか使ったことのある)PIC18F14K50を使うことにします。IOピンが足りるか、ピン割り付けを最初に考えましたが、なんとかギリギリで行けそうです。ちなみに、DIP28のPIC18F2455の方がIO数多いはずですが、ピン数増加に対し使えるIO数があまり増えないのと、余分なIOがあってもあまり用途が思いつかないので、最小構成で行くことにしました。

f:id:Baum_kuchen:20210812112151p:plain

 回路図

f:id:Baum_kuchen:20210812112611p:plain

基板設計&製作

例によって、小型のユニバーサル基板上に回路をレイアウトしました。f:id:Baum_kuchen:20210812113004p:plain

実際に製作した基板です。

f:id:Baum_kuchen:20210812153033j:plain

コントロールソフト製作

USB CDCデバイス構築

以前、データロガーを作ったときと同じく、MLA(Michrochip Libraries for Aapplication)の中から、CDC(Communication Device Class)のSerial Emulatorのサンプルコードを使って、USB→シリアルの部分を実装します。実際には、シリアル出力する代わりに、そこにGrblをベースとしたコントローラソフトに出力するつもり。  

baum-kuchen.hatenablog.com

MLAの最新バージョンは、v2018-11-26ですが、 今回使うのは、v2017_03_06版です。フレームワークとして、framework/usbフォルダ以下の次のファイルを、プロジェクトに登録(コピーは不要)。

  • src/usb_device.c
  • src/usb_device_cdc.c
  • inc/usb_device_cdc.h

 また、apps/usb/device/cdc_serial_emulator/framework/demo_src/フォルダのサンプルプログラムから、下記をコピーしてプロジェクトに登録。これで、一旦は、Buildが通るはず。 

  • app_device_cdc_to_uart.c - Grbl実装に合わせ修正予定
  • app_device_cdc_to_uart.h - 基本変更なし
  • usb_config.h - 基本変更なし
  • usb_descriptors.c - 基本変更なし
  • usb_events.c - 基本変更なし

 でしたが、今回、はまったのはxc8コンパイラーをv2.10にバージョンアップしていたことによるものです*1

以前通っていたプロジェクトのビルドも、Framework部分で次のようなエラーが出てコンパイルが通りません。

f:id:Baum_kuchen:20210812164815p:plain

結局、コンパイルオプション(C standard)をC90としないといけませんでした。xc8のデフォルトはC99になっていました*2。MLAは、C90対応だったみたいです。

原因が分かって、ビルドは通りましたが、Program spaceの使用率が54.8%とUSB部だけでかなり行ってます。Grblは、Aruduinoに使われているATmega328Pのメモリ(16Kbyte)の大半を占めるようですので、かなり無理筋のように思えてきました。

f:id:Baum_kuchen:20210812164552p:plain

Grblの実装の課題はありますが、まずはテスト。ビルドが通ったら、あとは簡単。USBをつなぐと、PCから無事COMポートとして認識されました。

f:id:Baum_kuchen:20210812183716j:plain

f:id:Baum_kuchen:20210812183154p:plain

今後について

まずは、GrblのPICへのポーティング*3を進めます。懸念としては、PICのメモリ容量をオーバするかもしれませんが、どこまでコードを削減できるか分かりませんが、試行を続けます。

 

*1:パソコンを更新し、最新版をインストールしてました。ちなみに、現時点での最新版は、v2.32

*2:正確に言えばMPLAB Xがプロジェクトを作るとき、デフォルトでC99設定としている

*3:ネットで探したけど、あまり例が無さそうでした

作りかけの自作CNCを完成させます#1

作りかけのCNCを形にしようと思います。 これを作り始めたときは、今の様に1,2万もすれば、それなりのキットが手に入る状況ではなかった(多分)ですが、このままジャンクとするものもったいなのので、完成までもっていきます。そもそも、自作って作ること自体ば目的ですから。

baum-kuchen.hatenablog.com

 現状整理

f:id:Baum_kuchen:20200216201856j:plain

今までできていることを簡単に整理。

機構部分は、加工容易性を考えて、ファルカタ材をベースに、あまり、まともな工具もないまま作ったので寸法精度は、はっきり言って悪いですが、なんとか3軸動くまでになってます。

スライド機構は、Φ10mmのステンレスパイプ(Y、Z軸)と引出し用のスライドレール(X軸)。

送り機構は、M6の長ネジ(ピッチ1mm)とM6ナット

ステッピングモータは、秋月で売っていたST-42BYG020(12V、1.8°ステップ)  

f:id:Baum_kuchen:20210801203157j:plain

コントローラというか、ステッピングモータのドライバは、PIC16F688とダーリントントランジスタドライバを使った自作。各軸にマニュアル操作とリミットスイッチも組み込んでいます。

f:id:Baum_kuchen:20210801202654j:plain

f:id:Baum_kuchen:20210801202735j:plain

スピンドル部は、これも、大型のマブチモータRS-380H(定格6V、13W)をつかって途中まで作っていますが、小型ドリルチャックとの接合部分で苦労して途中の状態。マブチモータがΦ2.3、ドリルチャックがΦ2.35で、アダプタをΦ6のステンレス棒から作ろうとしたが、芯がブレて回転すると使いものにならない状態で挫折中。 

f:id:Baum_kuchen:20210801211229j:plain
スピンドルのドライバは、これまた自作でPICを使ったPWM方式。

CNCソフトは、作動確認レベルのため、WindowsVC++を使って自作したもの。簡単なGコードを解析し、USB-シリアル変換で自作ドライバに送り込む形。一応、簡単な図形は描けることまでは確認(XY制御の確認として、ボールペンをスピンドルの代わりにつけて確認)

f:id:Baum_kuchen:20210801203416j:plain

TODO

当面、やらないといけないもの。この中でも、CNCソフトをどうするかが問題。

  • ドリル部メカ
  • スピンドル制御回路
  • CNC全体制御回路(CNCソフトとのインターフェース)
  • CNCソフト

目標

このまま追及しても3Dの造形までもっていくには、精度や加工速度などの面から使いものになるかは、期待できないと思うので、最低限の目標として、次を設定。

  • プリント基板穴あけ
  • アクリル板加工
  • アルミ板加工

CNCソフト選定

フリー、有料も含め、大体こんなところでしょうか。

 

  • LinuxCNC

linuxcnc.org

  • grbl

github.com

  • MACH3

www.machsupport.com

  • USBCNC

www.originalmind.co.jp

LinuxCNCは、OSがLinuxということで多少扱い辛いのと、パラレルポートが必要というのがハードル高いです。

Grblは、Aruduino用のソフトなのと、シリアル(USB経由)でGコードを送り込む形なので、グラフィカルなユーザインタフェースは無しです。ただし、Gコードセンダーとて、いくつかあるので、それと組み合わせて作動させればよさそうです。

後の2つは、制御基板ごと購入しないといけないので(一応、MACH3は条件付きでフリーで使えますが、ソフトと制御基板のインターフェースが探しても出てきませんでした)、一応、自作はとしては一旦除外かな。

理想は、フリーのソフトでUSBでインターフェースというのが良いのだけれど。

全体構成

 全体を整理すると、次の様になります。LinuxCNC活用と市販ボード購入は無しとすると、最後の案しか残りません。GrblをAruduinoに入れたらそれで終わりというのもつまらないので、そこの部分をある程度自作する方向で行ってみたいと思います。途中で挫折したら、Aruduino使いますけど。

f:id:Baum_kuchen:20210801225338p:plain

 Gコードセンダーは、

Using Grbl · gnea/grbl Wiki · GitHub

 に沢山あるので、この中からどれか選んで使ってみます。

今後について

進み方は遅々としてしまうかもしれませんが、もし、興味をもっていただけたらお付き合い願います。