So-net無料ブログ作成
ステッピング・モータ・コントローラ ブログトップ
前の10件 | -

受信タイミングを自動調整することにした [ステッピング・モータ・コントローラ]

(2012.10.31)
モーター・コントローラのシリアル受信タイミングを合わせ込んで、なんとか動くようになりました。しかし、フォト・アイソレータのバラツキを考えると、現状の方式(遅延時間固定)で対応できるかどうか心配です。

シリアル・クロックを出力しているコマンド・コントローラは、クロックを切り替える直前に受信データを読み取る方式で、(多分)大丈夫だと思います。問題はモーター・コントロ-ラの方で、データの変わり目から200μS辺りに受信タイミングを合わせたい(タイミング・マージンが最大になる)のですが・・・

あれこれ思案した結果、メイン・ループでシリアル受信データが変わる時刻を調べて、TMR2の設定を変えることにしました。

<こんな感じです>
    if( p_bit != SERIAL_IN )
    {
      change_time = TMR2;
      p_bit = SERIAL_IN;
      if( change_time >= 100 )
      {
        serial_delay -= ( change_time - 100 );
      }
      else
      {
        serial_delay += ( 100 - change_time);
      }
      if( serial_delay >= 200 )   //
      {                           // 
        serial_delay = 50;        // ここ重要!
      }                           //
    }

serial_delayがPR2(=200)以上の値になるとTMR2割り込みが入らなくなってしまいます。(最初はこれに気付かず、突然シリアル受信が出来なくなってあわてた)

これで多CH化の準備が整いました。

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ


サブレートの自動制御が動いた [ステッピング・モータ・コントローラ]

(2012.10.29)
サブレートの自動制御がようやく動くようになりました。途中で、コマンド・コントローラとモーター・コントローラのシリアル送受信処理を全面的に書き換える羽目に陥り、苦労させられました。一旦は、ホストPCからUSBコマンドでモーター・コントローラを制御できるようになって、『完成間近』と思ったのですが甘かった!

サブレートの自動制御は、コマンド・コントローラがモーターの起動停止タイミングに合わせて、モーター・コントローラのパルス・レート(サブレート)を増減させる機能です。スタート・コマンド送信時に50msインターバルでサブレートを(1から16まで)増加させ、停止する0.5秒前から(同じく50msインターバルで)サブレートを(16から1まで)減少させます。停止するタイミングはステータス応答に記された”残りステップ数”から算出します。

サブレートやステータスを動的にやり取りするので、デバッグの難しい機能です。動作をモニタするsnap_shot関数を作り、50msインターバルの制御をモニタしながら、ロジックを追いかけました。

最初の問題はステータス応答でした。停止中は”STBY”、モーターを起動すると"OPE"が返っていたのですが、いつのまにか起動すると"F_LIMIT"が返されるようになりました。受信処理の問題だとと思いこみ(実際は送信側に問題があった)、コマンド・コントローラのシリアル受信処理をいじり始めました。また、サブレート・コマンドとスタート・コマンドの連続送信が上手く行かないので、シリアル送信処理にも手を入れ始め・・・

ついにコマンド送信もステータス受信もまともに動かなくなってしまいました。orz

最初の不具合状態に戻すのも癪なので、シリアル送受信処理を全面的に(シンプルに)書き直し、単体のエコーバック処理まで戻って、デバッグし直すことにしました。モーター・コントローラを介したエコーバックを通すには、モーター・コントローラの受信タイミングの見直し(TMR2を使って読み取りタイミングを遅延した)が必要になりました。(それまで微妙なタイミングで動いていた?)

コマンド・コントローラが送信したコマンドのエコーバックをコマンド・コントローラで受信出来るようになって、ようやく送信コマンドの問題に気がつきました。

スタート・コマンド直前のサブレート・コマンドでstartビットを0にせず、送信していたのです。その結果、サブレート・コマンドがステータス送信要求コマンドに化け、コマンド・コントローラが予期しないタイミングにステータス応答が送られてきて、処理がぐしゃぐしゃになっていました。

他にも(色々)不具合は在りましたが、なんとか対処してサブレートの自動制御が動くようになりました。(パチパチパチ~)

しかし、ステッピング・モーターの起動停止が思ったよりギクシャクするのは(ちょっとだけ)がっかりです。
(動作を調整すれば、もっと良くなる?)

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ


サブレートの制御仕様を決めた [ステッピング・モータ・コントローラ]

(2012.10.22)
サブレートの制御仕様を決めかねていましたが、これ以上減らせない最低限のコマンドに絞って実装することにしました。

コマンド・コントローラがサブレートを自動制御する方式を基本として、ホストによる制御も受け入れる方式に必要なコマンドは次の三つと考えました。

サブレートAUTOコマンド
サブレートUPコマンド
サブレートDOWNコマンド

モーター停止中のUPコマンドでサブレートOFF相当、モーター停止中のDOWNコマンドでサブレートINIT相当の処理を行います。仕様が決まって、一気にコーディングを済ませました。暫くはデバッグ作業が続きます。

モーターの起動時と停止時にパルス・レートを複数のCHで同時に増減する”サブレート制御機能”はこのステッピング・モーター・コントローラの目玉だと思っていて、上手く動いてくれることを願っています。
さてどうなるか?

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ


サブレートの制御仕様で悩む [ステッピング・モータ・コントローラ]

(2012.10.22)
モーター・コントローラのコマンド制御テストはモールスLEDが威力を発揮して、順調に進みました。

STARTコマンドを送ると”... t t ”<=STT (BASE_PATTERNの組み合わせなら判る)
STOPコマンドだと”... t .tt. ” <=STP (STで始まる3文字の応答はSTTとSTPだけなので、消去法で判る)
限られた応答文字列であれば、こんな具合に何とか識別できることが判りました。パソコンからUSB経由でコマンドを送って、ステッピング・モーターを制御できるようになり、いよいよステッピング・モーター・コントローラの開発も終盤です。

実は、ここに至って”サブレートの制御仕様”が未だ決まっていません。複数CHの同期制御を実現する重要な機能なのですが、最初は”全部ホストにおまかせ”で済ますつもりでした。しかし、サブレート制御に必要な情報をいちいちホストに引き渡すくらいなら、コマンド・コントローラで面倒を見たほうがインターフェースがシンプルで良いと思った辺りから迷走し始めました。

で、今。
コマンド・コントローラがサブレートを自動制御する方式を基本として、”ホストによる制御も受け入れる方式が良いのではないか”と思っています。ただ、サブレート関連のコマンドが5つにもなるのは煩雑な気もします。

サブレートAUTO
サブレートOFF
サブレートINIT
サブレートUP
サブレートDOWN

このまま行くか、それとも少しコマンドを整理するか、仕様設計の悩み所です。

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ


シリアル・コマンド(一部)の受信まで動いた [ステッピング・モータ・コントローラ]

(2012.10.18)
ステッピング・モーター・コントローラの接続試験用にテスト冶具を作りました。
2012_1018.pngテスト冶具
手始めに、SW入力機能をテストします。
(1)SW1==ONのとき LED オン
(2)SW2==ONのときLED オフ
(3)両方OFFなら1秒間隔で点滅
こんなプログラムをコマンド・コントローラとモーター・コントローラのメイン・ループに組み込み、RESET==>RUNで起動して、LEDが1秒間隔で点滅、消灯時にSW1を押すとLEDオン、点灯時にSW2を押すとLEDオフすることを確認しました。

ここまでは順調でしたが、シリアル・コマンドの送受信テストで躓きました。最初のトラブルはシリアル・クロックで、コマンド・コントローラが出力しません。前回行った『フォト・アイソレータを介した双方向の信号線接続の確認』でTMR2をOFFしたことを、すっかり忘れていたのです。PICkit3をコマンド・コントローラにつなぎ替え、デバッグ・モードでプログラムの動作を追いかけ、ようやく以下のコードを見つけました。
// for DEBUG
   T2CONbits.TMR2ON = 0;           // stop timer2

これをコメント・アウトして、モーター・コントローラ側で、シリアル・クロック割り込みをテストしました。シリアル・クロック(2500Hz)の立ち上がりと立下りのそれぞれで割り込みフラグが立つので、割り込みハンドラの先頭に5000カウントでLEDを点滅するコードを組み込むと、1秒間隔で点滅しました。(パチパチパチ~)

立ち上がり割り込みのところでは2500カウントでLEDを点滅させ、さらに立ち下がり割り込みのところでも同様にして、それぞれ1秒間隔でLEDが点滅することを確認しました。(再びパチパチパチ~)

ここまで動いたので”今度こそ”と意気込みましたが、スタート・ビット検出処理に組み込んだ”LED=1"というコードが実行されません。LEDを点滅させるコードをあちこちに置いて、ジリジリと動作を追っていきます。そしてついに・・・


#define SERIAL_IN PORTAbits.RA5

#define SERIAL_IN PORTAbits.RA4

ピン番の間違いを見つけ、STEPコマンドでLEDオン、STOPコマンドでLEDオフする所まで確認できました。

ヤレヤレ

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ


接続試験をはじめた [ステッピング・モータ・コントローラ]

(2012.10.17)
あちこち寄り道しながら、少しずつ進めてきたステッピング・モーター・コントローラの開発作業ですが、コマンド・コントローラとモーター・コントローラの接続動作を確認する段階にたどり着きました。モーター・コントローラ(PIC16F1503を使用)はデバッガが使えないので、暫くはLEDチカチカを頼りに動作を確認します。
2012_1017.png二つの基板を接続した
先ずは、フォト・アイソレータを介した双方向の信号線接続の確認です。それぞれ1秒周期でON/OFFを繰り返し、テスターで送信ポートと受信ポートの電圧をモニタしました。

シリアル・クロックの入出力==>O.K.
コマンド2モーターの入出力==>O.K.
モーター2コマンドの入出力==>O.K.

問題ありません。これでステッピング・モーター・コントローラ基板(2種)の基本的な動作確認がほぼ(SW入力の確認がまだ)終わりました。

さて、ここからどうのように進めたら良いか?実は、まだ構想がまとまっていないのです。最終的なシステム・テストを見越して、簡単なテスト冶具を用意することから始めるのが良さそうです。テスト冶具などとおおげさな表現を使いましたが、ブレッド・ボードにLEDとSWを数個並べただけの代物です。ついでにテスト仕様書も書いておこうか・・・

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ


正常系テストで異常系のデバッグを始めた [ステッピング・モータ・コントローラ]

(2012.10.11)
温度コントローラ2用基準電源の検討はとても楽しい作業です。しかし、ステッピングモーター・コントローラの開発を忘れた訳ではありません。(得意ではありませんが)並行してコマンド・コントローラの開発も進めています。ホストとのUSB通信機能に続いて、モーター・コントローラとのシリアル通信機能を組み込み、コマンド・コントローラの骨格が出来上がりました。

コテ試しに、USB経由で受け取ったコマンドをモーター・コントローラに送信する”正常系”の動作テストを始めたのですが、USB通信のコマンド応答(コマンド文字列のエコーバックと解析結果)が返ってきません。

『ここは動く筈なんだけど、何が起きたんだ?』

デバッガでロジックを追いかけると、USBコマンドを解析して生成した応答文字列が送信バッファにセットされていました。

『ここまでは前回確認した通り』
『これをホスト側で受信しない訳は?』

さらにロジックを辿って・・・

『ん!』
『シリアル通信がBusy(バグ)で実行ステータスがエラーになった』
『で、ホストにエラー・ステータスを送信・・・し続けてる!』

コマンド応答が表示されない原因が判りました。rs232.exeは受信終了時に画面表示を更新するのです。今回のようにデータを送り続けると、いつまで経っても受信した文字列は表示されません。(と、思っているけどrs232.exe側の問題ではなく、MicrochipのCDCライブラリ側の問題かもしれない)

さらっと正常系の動作を試すつもりで、異常系の処理をちゃんと組み込まなかったスキを突かれました。暫く異常系のデバッグ作業が続きます。

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ



コマンド・コントローラ開発のプラットホームが出来た [ステッピング・モータ・コントローラ]

(2012.10.02)
簡単な作業と考えていたコマンド・コントローラ開発のプラットホーム作りがようやく終わりました。温度コントローラ2のプログラムから不要な部分を取り去るだけ(だから簡単な筈)だったのですが、思いの他時間を費やすことになりました。

親族SNS管理人の場合、新しいPICプログラムの開発は既存のフォルダ一式のコピーから始まります。今回はPIC18F2550でUSB通信を行った温度コントローラ2のフォルダ一式をコピーし、フォルダ名とプロジェクト名を替えて、使わない変数や関数を削除して・・・

コンパイル・エラーが出なくなるまで、コードをコメント・アウトして行きます。一通り作業が終わり、PIC18F2550に書き込んで実行したのですが、起動の様子がどうもおかしいのです。初期化関数が呼び出されません。初めて動かす基板だったので、最初は基板の不良を疑いましたが、温度コントローラ2のプログラムをそのまま書き込めば、ちゃんと初期化関数が呼び出されます。基板の不良では無く、書き込んだプログラムに問題があるようです。

消してはいけない”何か”を消してしまったに違いないと思い、もう一度フォルダのコピーから作業をやり直しました。今度は、コードのコメント・アウトも慎重に行いました。そして、再びPICに書き込んで実行・・・

駄目です。状況は改善しません。シミュレータでは、ちゃんと初期化処理が呼び出されました。電源はPICkit3から供給していて、特に大きな負荷は掛かっていません。デバッガでステップ実行すると、startupルーチンのコードと実行しているコードが一致していないように見えます。最後はSTKPTR=1(初期状態)でreturn命令を実行して吹っ飛んでしまうことが判りました。

『何故?』
『どうして?』
何がどういけないのか、見当もつかず、軽いパニックに陥りました。

しかし、”ちゃんと動くプログラムなら正しく初期化処理が行われる”ことを信じて、フル・スクラッチで書き直すことにしました。

(1)CONFIG設定とメイン関数のみ ==> O.K.
(2)上記+初期化処理 ==> O.K.
(3)上記+タイマー割り込みハンドラ ==> O.K.
(4)上記+1秒間隔でLEDピカピカ ==> O.K.
(5)上記+USB通信処理(Microchipのライブラリ) ==> N.G!
(5’)USB割り込みハンドラが抜けていることに気付き追加 ==> O.K.
(6)USB受信文字列をエコーバックするコードを追加 ==> O.K.

これがコマンド・コントローラ開発のプラットホーム(現在の到達点)です。

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ


モーター・コントローラ基板の導通をチェックした [ステッピング・モータ・コントローラ]

(2012.10.01)
部品実装したモーター・コントローラ基板でプリント・パターンの断線が見つかり、苦労して修理する羽目になりました。念のため、モーター・コントローラ基板の導通(当該箇所のみ)をチェックしてみました。

結果は全てO.K.で、製造上の不備によりパターン切れを起こしたのでは無いことが確認されました。想定した(期待した?)通りの結果なのですが、”部品実装でパターン切れを起こした”となると問題です。

2セット目を組み立ててこの辺りを確認したいのですが、6Pのコネクタが不足していて組み立てられません。orz

この件は暫くこのままで、コマンド・コントローラの開発を進めます。

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ


表面実装基板の配線修理について考えてみた [ステッピング・モータ・コントローラ]

(2012.09.29)

今回、表面実装部品を使った基板の配線を修理する羽目に陥って始めて気付きました。

表面実装部品のパッドになんとか線材をハンダ付けできても、反対側が基板の裏面しかハンダ付けできない(例えばICソケットとかコネクタとか)の場合、線材を基板の表から裏に回すことになります。適当な経路が見つかれば良いのですが、そうでないとかなりみっともない配線になります。
line_error1.pngここの導通が無かった

line_error2.pngそしてここも導通が無かった

今回の修理箇所がまさにそれで、一つはFETのゲート駆動信号でVIAホールを通る細線が使えましたが、もう一つはモーター駆動電流が流れるFETのソース側で、太い線が基板の縁を通って表面から裏面へぐるっと回り込む配線にせざるを得ませんでした。こんな配線を行ったのは(多分)初めてです。

表面実装部品に修理用線材をハンダ付けするのも大変で、いわゆる”チョン付け”するのが関の山です。表面実装部品を使った基板で不具合が見つかっても修理などせず、破棄するものなのでしょうか?

にほんブログ村 IT技術ブログへ
に

ほんブログ村 ネットブログ コミュニティサイトへ
にほんブログ村 IT技術ブログ オープンソースへ


前の10件 | - ステッピング・モータ・コントローラ ブログトップ