2017-01

最大級の寒波らしく・・・

猛烈に寒いですね・・・
こんばんわ。


さて、とりあえずソフト側は一応の完成を見ましたので、あとはケース作成して実際に動かして・・・といったところなのですが、その前に1つ。電源周りを改めて見てみると気になる点が1つ。
2017011501.png
ドライブ基板側はどのみち作業台の下あたりに据え置きなのでよいのですが、RaspberryPiから通信用のケーブルとともにRaspberryPi自身を動作させるための5V電源を接続する必要はあります。ディスプレイはGPIOコネクタ側から取っているのでいいとしても、ケーブルが2本つながっている・・・さらに操作用のUSBテンキーのケーブルも出ているので3本。

できればドライブ基板との接続はケーブル1本っていうのが、スマートなのかなぁ・・・というか、作業場でのケーブルの取り回しが面倒になるのはなぁ・・・ということでこんな接続にしてみました。
2017011502.png 
本当はUSB端子から直接RaspberryPiに給電できればよいのですが、GPIOと違ってUSB端子の電源には電流制限をかけるためのICが1枚嚙んでいるらしく、USB端子からの給電は無理と判断しました。

なのでUSB端子手前までは通信接続用のUSBケーブルの電源ケーブルで給電しつつ、端子直前で電源ケーブル部分のみを分岐させてRaspberryPiの電源端子に接続することとしました。

そんな無茶な配線をおこなうためのアイテムがこちらw
P1151107.jpg 
なぜかUSB-Aの基板取付用オス・メス端子が手持ちにあったので、信号線だけ中継して+5VとGNDは別口のUSB-マイクロBケーブルに分岐させる怪しげなアダプタを作成しました。

GPIOの+5Vから直接という手もありますが、各種安全回路等をバイパスしてしまうことになるので、それはやだな・・・ということでこんな形になりました。

これでドライブ基板とRaspberryPiはケーブル一本で接続されて、取り回しが良くなりました。
ただ、通信するとノイズが乗るのか、はたまた接続経路の抵抗値が高いのか、モーターの回転中はなんかディスプレイのバックライト輝度に若干の乱れが見られます^^;

で、そんな風に電源系をみつつ、実際の環境に持っていって、いざ接続・実機動作確認です。
P1151104.jpg 
結構、無茶な置き方ですw
この椅子の上に、いつもは操作用のMacbook Airが乗っかっています。机の下に見える青くてデカイのが現行のドライブ基板ですね。X軸のモーターケーブルを外してきて・・・接続。ピン配置は同じにしておいたのでつなぎ変えだけでOK。

で、実際に動作させてみたところ、ちゃんと電流は流れました。動作的にも問題なし。
P1151105.jpg 
やっぱりテストで使っているあの秋月モーターは電流が全然流れないモーターなんですね。とりあえず現行設定値の1.5Aまでの設定ができそうです。ただ、さすがにヒートシンク無しではIC焼き切れてしまうので設定電流は1Aに、動作確認は手短に・・・

で、こうやって作業していたら体調がみるみる悪化していきましたので、早々に切り上げ。
そしてまた微妙に発熱・・・やっぱりまだ寒いか^^;

さて次はケースおよび放熱系なんですが、どうしようかな・・・


スポンサーサイト

あけまして、おめでとうございます。

と、いってるそばから風邪です・・・治りませぬ・・・
少しでも寒い状況になると直ぐ体調が崩れます・・・
そんなわけで先週は更新お休みしてしまいました・・・


そんなわけでちょこちょこ触りつつ、ソフト側はようやく最低限までの実装を完了。とりあえずファイル選択したり、ファイルのプレビューでるようにして、最終的にファイルからGコード読み込み→動作までの処理ができるようになりました。
P1091102.jpg 
プレビューは正直、少々重いのですが、パスの確認という意味であったほうが便利かなと。あわせてX,Y,Z各軸の最大値、最小値も表示してステージに突き刺さる事故予防に^^;

ドライバ基板は電源系を整えたり、ベースボードに乗っけたりしてとりあえず1つにまとめました。
P1091099.jpg 
これで散らばらなくなったので実機傍に持っていって動作確認できそうです。

とりえあず今後は実機に接続しての動作確認でバグだしですかね。懸案事項としては、ドライブ電流がなんか設定値どおりに上がらないことでしょうか・・・設定電圧を調整しても設計値まで電流がぜんぜん流れないんですよね・・・モーター的にそこまでながれないのか、どうなのか・・・実際につないでみないと・・・

電流が流れなくてトルク足らない場合はドライバ回路を見直さないとですねぇ・・・

残すところ1週間・・・

そして今週末も絶賛発熱中・・・どうも週末になると発熱するという・・・精神的なものなのかなぁ・・

こんばんわ。


少しでも寒いところにいるとすぐに熱がでてしまい、もはや冬場の作業は絶望的・・・
基板が不安定な状態で机の上にほったらかしなのが微妙に不安です^^;

懸案だった円弧移動はようやくヘリカル移動にも対応して組み込み完了。

まずは修正前の円移動。円弧の始点と終点で数ピクセルのズレがでてしまっています。
2016122501.png 

コレ、作ってたときは円を縮小表示していたせいでズレが見落とされていたんですね・・・

で、改善後の描画がこちら。
2016122502.png 

はい、ばっちりです。これで安心して使えます^^

続いて、もう一つ。
動作の安定性に関する問題点の改善を試みます。

当初、短い距離を移動させているだけの間はあまり気づかなかったのですが、だいたい200mmくらいに1回、あるかないか・・・という程度でパルス送信が途絶える瞬間が発生するのです。

発生間隔が不定期なのでなにかしからのバックグラウンド処理が走っている・・・と予想していたのですが、結局原因はつかめずじまい。

で、回避策としてバッファサイズを大きくしてみたりといろいろやってみたのですが、改善せず・・・これはもう抜本的にハード側で対処が必要か・・・と考えつつ、送信処理部分を見返していいたところ・・・

await _dataWriteObject.StoreAsync().AsTask();

これ、仮想シリアルポートに向かってパルス情報を送信する一文です。シリアル通信のサンプル文そのままで使っていたりしますがw この「await」、シリアルへむかって送信が完了まで待機する・・・という意味でついています。

じゃぁこの「await」をとってしまったらどうなるか・・・というのをやってみたところ・・・パルス生成の処理は一瞬で終了し、そのあと非同期でモーターが動作しています・・・そこでようやく気付きます・・・

ああ、そうか・・・このシリアル通信にはバッファというものが存在しないのね・・・

つまり送ったパルス列がハード側ですべて取り出されるまで、上記の送信処理は待機状態になっていたのです・・・それでバッファサイズを大きくすると余計に安定度が下がったりしていたわけですか・・・

では単純にこの「await」をとってしまえばよいかといえば、そう済むわけもなく・・・とってしまうと計算だけが先にすんで途中停止ができないとか、座標表示の内容が一切更新されないとか・・・いろいろ問題なので別のバッファ方法を検討せねばなりません・・・

結局、この送信処理毎に生成されるタスクをキューで管理し、キューに3つ以上タスクが溜まったらタスクの完了を待つというように変更。

if (TaskQueue.Count > 2)
{
   await TaskQueue.Dequeue();
}
TaskQueue.Enqueue(_dataWriteObject.StoreAsync().AsTask());

ようやくこれで送信処理が安定しました。もっとも非常停止時もバッファ分は止めることができない状態にもなるわけで・・・目視では大体4分の1回転くらいは進んでしまうようです。このあたり送信の安定性との兼ね合いでバッファサイズを調整する必要がありそうです。

あとはファイルの取り扱いのみとなりましたが・・・来年かな^^;




もう~いくつねると~

お正月・・・もう今年も残り2週間ですか・・・それにしてもいまだに風邪を引きずったままなんですが・・・これはもうそろそろ風邪じゃなくて別の病気なんじゃなかろうか・・・

こんばんわ。


今週あまり時間取れずだったので、ほとんど進捗ナシといいますか・・・やっぱり円弧の処理に納得できなくて、いろいろやり直してます^^;

当初つかっていたアルゴリズムとは別のものを使って再チャレンジしてまして、なんとか誤差の少ない円弧が出るようになったのですが・・・話はそれで終わらない^^;

ヘリカル切削に対応できるように円弧移動+Z軸の移動をうまく処理せねばなりません・・・が、これが超面倒な処理なので今週はそこまでこなせず終了・・・

想定外のところで時間食ってるなぁ・・・^^;

師走ですか・・・

無事、火災報知器の点検も終えて、車も点検に出して、あれこれひと段落です。
ふぅ。

こんばんわ。


さて、今週も主にソフトがらみの作業のみです。

まずはバックラッシュ設定やら反転やらの細かい設定を追加。
3軸分あるから何気に面倒なんですよね・・・^^;

続いてファイルを扱う部分を作りこみ開始。

とりあえずはローカルのフォルダにネットワーク越しにファイルを配置する方法で作成するという、少しヘタレ気味な状態に^^;

で、この部分を作りこんでる際、移動範囲とか、切削パスのプレビューとかみれたら便利かな?と思ったりしてパルス生成部分を見直していたりしていたのですが・・・

G02、G03のパルス生成部分・・・拡大してよく見てみると結構な誤差がでてて、これそのまま使おうかどうか悩ましい状態に・・・誤差の量は十数パルス程度なので0.01~0.02程度なのであんまり気にしなくてもいいかな?と思いつつ、やっぱり気になるので現在使っている、普通に三角関数とかを使うバージョンも実装してたりしてました。

結果的には思ったよりも負荷を食うこともなく、なんかいけそうな感じ・・・今使っているものとほぼ同じアルゴリズムで安心なのでこっちを使おうかな^^;

あ、そうそう。RaspberryPi公式ディスプレイのタッチパネル機能ですけど、指で操作すると滅茶苦茶な挙動ですが、スマホ用とかのタッチペンを使うとちゃんと操作できますね・・・指だと接触面積が広すぎるのですかね?

«  | ホーム |  »

日付から日誌を見る

12 | 2017/01 | 02
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -

最新の日誌

最新のコメント

最新のトラックバック

カテゴリ

3Dプリンタ開発記 (68)
新モータ駆動装置 (20)
集塵機 外郭編 + モータ制御実験 (17)
集塵機 (42)
Android ADK (3)
CNC改善 (2)
iPhoneスタンド習作 (6)
Webカメラ表示用ソフト (11)
備忘録 (0)
作業日誌 (18)
そのほか (76)
キーボードの製作 (9)
スピンドルモータ交換 (7)
鉄道模型 (9)

リンク

このブログをリンクに追加する

当日誌の閲覧総数