C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[8]: 複数シリアルポートでの計測機器データ受信

(過去ログ 129 を表示中)

[トピック内 9 記事 (1 - 9 表示)]　 << 0 >>

■76376 / inTopicNo.1)

　複数シリアルポートでの計測機器データ受信

□投稿者/ jun (1回)-(2015/07/03(Fri) 16:19:38)

分類:[VB.NET/VB2005 以降]　

はじめまして。
パソコンにUSB接続のシリアルポート変換を接続して、複数のシリアルポートを監視し計測機器から送られてくるデータの記録しようとしています。

計測機器は秤で、重量安定後にテキストデータで重量のデータが送られてきます。
また、データの頻度は多くなく、早くとも５分～１０分、長い場合は１時間程度の頻度です。

こういった環境にてデータの収集を行う予定ですが、vb.netでシリアルポートを複数使う際には、シリアルポートを複数宣言して、それぞれのDataReceivedイベントでデータを収集するつもりですが、支障はありますでしょうか。

シリアルポートが１ポートの場合のプログラムは何度か作成していますが、同時に複数のポートというのは初めてで、勝手がわかりません。お分かりになるようでしたら、お答えいただけますと幸いです。

引用返信 編集キー/

■76377 / inTopicNo.2)

　Re[1]: 複数シリアルポートでの計測機器データ受信

□投稿者/ daive (62回)-(2015/07/03(Fri) 17:45:01)

＞DataReceivedイベント
多くの場合は、delegate を使う事になると思いますので、
delegate の御勉強も、忘れずに。

OS によって(XP以前、Vista以後）、シリアル機能のドライバによって、
RTC / CTS / DTR / DSR / DCD のイベントの挙動が、
異なりますので、確認するようにしてください。
⇒XP以前では、アプリ道連れに、ドライバが死亡するものもあったり。
USB-シリアル（アダプタだけでなく、機器としてUSBでも仮想COMな機器）でも、同様です。
USB-シリアルを使用する場合は、抜き差し時、電源ON/OFF時の、
状態が容易に発生しますので、検証を必ずしてください。
’
古い232 /422/485系機器では、電源ON/OFF 時に、TX / RX へ無効データが大量に流れますので、
無効データ、パリティーエラー等の、エラー処理は、必須です。
’
安めで、簡単に検証可能なのは、
USB-シリアルを備えたマイコン系（Arduino:本家、互換、シリアルチップ違い / Mbed / STM32 など）
’

引用返信 編集キー/

■76379 / inTopicNo.3)

　Re[2]: 複数シリアルポートでの計測機器データ受信

□投稿者/ jun (2回)-(2015/07/03(Fri) 18:50:46)

ご返答ありがとうございます。

■No76377 (daive さん) に返信
> ＞DataReceivedイベント
> 多くの場合は、delegate を使う事になると思いますので、
> delegate の御勉強も、忘れずに。

ありがとうございます、別スレッドからのUI操作となるからですね。
以前に１対１のシリアル通信プログラムを作成した際に、勉強させていただきました。

> RTC / CTS / DTR / DSR / DCD のイベントの挙動が、
> 異なりますので、確認するようにしてください。

秤の仕様を調べますと、それらのピンは全て結線されておらず、GND/RXD/TXDだけの結線です。
現在は１対１のシリアル通信プログラムで稼働しておりますが、こちらは特に問題は見られていません。
このプログラムが動いているパソコンにUSB－シリアル変換を接続し、複数ポートの監視を組み込む訳ですが、基本的には前にも書きました通り、安定後テキストデータが流れてくるという流れです。

ひとまずは実機にて検証してからじゃないとなんとも言えなそうですね(^_^;)

引用返信 編集キー/

■76383 / inTopicNo.4)

　Re[3]: 複数シリアルポートでの計測機器データ受信

□投稿者/ daive (63回)-(2015/07/03(Fri) 21:41:08)

＞GND/RXD/TXDだけの結線です。
俗に云うところの垂れ流し結線ですね。
'
いま、ちょっと遊んでいる装置は、
Arduino - USBシリアル接続、115200 bps、
ノート：CELERON743,1-core,Windows7 x32,マウスコンピュータLB-L300
不定期に、受信のみ行っています。
VB.NETでは無いので条件は異なりますが、
仮想COM４ｃｈで、通信できています。
検証用に、わざと遅いノートPCを使っています。

引用返信 編集キー/

■76385 / inTopicNo.5)

　Re[4]: 複数シリアルポートでの計測機器データ受信

□投稿者/ jun (3回)-(2015/07/06(Mon) 00:39:14)

■No76383 (daive さん) に返信
> ＞GND/RXD/TXDだけの結線です。
> 俗に云うところの垂れ流し結線ですね。
> '
> いま、ちょっと遊んでいる装置は、
> Arduino - USBシリアル接続、115200 bps、
> ノート：CELERON743,1-core,Windows7 x32,マウスコンピュータLB-L300
> 不定期に、受信のみ行っています。
> VB.NETでは無いので条件は異なりますが、
> 仮想COM４ｃｈで、通信できています。
> 検証用に、わざと遅いノートPCを使っています。
>

ありがとうございます。Arduinoですか、温度センサ等のデータをやりとりしてるのでしょうか。私は電子回路等門外漢ですので、そうやって遊べるのは羨ましいですね。

現在はReadlineでCR+LF待ちでテキストデータを変数に蓄積し、タイマーにてデータをDBに取り込んでいます。このような手法を採っているのは、一旦安定後、再度安定となり、二重に重量を記録してしまう環境だからです。

ところで、すこし話は逸れますがタイムアウト時の処理というのはどういったものが定石なのでしょうか。シリアル通信プログラムは経験が浅く、今はDiscardInBufferにてバッファをクリアしていますが、これだと続いてデータが届いた場合に、後続のデータまでクリアされてしまう危険性があると思うのです。
現行のプログラムでも時たまにタイムアウトが発生してしまう場合があり、その際に上記方法を採っています。

引用返信 編集キー/

■76386 / inTopicNo.6)

　Re[5]: 複数シリアルポートでの計測機器データ受信

□投稿者/ daive (64回)-(2015/07/06(Mon) 11:54:30)

2015/07/06(Mon) 15:26:29 編集(投稿者)

＞DiscardInBufferにてバッファをクリアしていますが、これだと続いてデータが届いた場合に、後続のデータまでクリアされてしまう危険性があると思うのです。
私は、こういう使い方はしませんが？
バッファをクリアしなければならない事態は、データの受信残しがあったり、
書いてあるように、受信処理完了前に、次のデータが来た場合、
不良データの場合に、おこるはずですが、何を懸念して、
バッファクリアをしていますか？
’
受信データ数の状態は、
受信データ数正常
受信データ数過小
受信データ数過大
が、考えられますよね、
’
例えば、
１．コマンドレスポンス型が使えるならば、そちらへ設定変更。アプリ側と測定器側でやりとりが出来るので、確実です。
２．ハードウェアとしての、通常のCOMチップは、数バイト～８バイト程度しか、バッファを持っていません。
　　COMドライバの設定で、バッファ量が変更できる場合もあります。
　　特別な後付カードでは、数KB～　のバッファを持った物もあります。
３．垂れ流しで、計測器から来るデータであり、データ量が、アプリ側で用意する受信バッファに十分に収まる程小さいのであれば、
３－１．アプリ側で、受信バッファを持ちます。
　　受信プログラムは、ひたすら受信バッファにデータを受信します。データ有効先頭アドレス、データ次回書込アドレス、データ数等の必要な情報を持つようにします。
　　リングバッファが良いかどうかは、頻度と、量によりますが、数MB程度の容量までであれば、いまのPCスペックでは何とも無い事ですので、リングバッファで無くても可能です。
　　データ受信不良の場合の処理は、このプログラム内で、考慮します。
　　ボーレート設定不良、ストップビット設定不良、パリティ有無設定不良、データ受信上のドライバ側から報告される不良など。
　　必要であれば、受信不良データ等を握りつぶす、ログ報告する、エラー処理するなども。
３－２．アプリ側では、受信したデータを、装置の仕様によって切り出します。
　　この時に、バッファ上に、何ブロックデータがあるのかとか、ブロック単位で処理します。
　　アプリで用意した受信バッファの内容は、受信済みデータですから、アプリ側でいかようにも、加工が可能です。
　　普通のシステムからの受信データであれば、ASCII手順であれば、ＣＲ、ＬＦや、バイナリ手順でも、STX / ETX , STB / ETB , SYN / EOT
　　などの何かしらの、データ区切りがあるはずですから、ブロック分けは可能な筈です。

計測器からのデータが、固定長や、あからじめ、仕様上で、データ長が解る場合は、
都度処理でも、可能ですが、アプリ側で受信バッファを持つ方が、
考え方が、受信は受信、データ処理はデータ処理と、分離できるので、楽だと思います。
今回の場合は、無通信時間が長くありそうですから、
アプリ側の受信バッファクリアのタイミグは、
データ受信中でない＆規定の無通信時間経過後
と、すれば良いのではないでしょうか？
（無通信時間が短い場合は、リングバッファを考慮します。）

引用返信 編集キー/

■76403 / inTopicNo.7)

　Re[6]: 複数シリアルポートでの計測機器データ受信

□投稿者/ jun (4回)-(2015/07/07(Tue) 10:25:31)

ご返答ありがとうございます。
お知恵拝借できて光栄です。

> バッファをクリアしなければならない事態は、データの受信残しがあったり、
> 書いてあるように、受信処理完了前に、次のデータが来た場合、
> 不良データの場合に、おこるはずですが、何を懸念して、
> バッファクリアをしていますか？

不良データ受信した際にCR+LFが来ない為、タイムアウトを起こす時があります。
それゆえタイムアウト時にだけバッファクリアをしています。
そもそも、この不良データがたまに受信される事も悩みの種なのですが・・・。
シリアルケーブル長が１０ｍと長く、限界である１５ｍにほど近い長さがある事も原因なのかもしれません。

> 計測器からのデータが、固定長や、あからじめ、仕様上で、データ長が解る場合は、
> 都度処理でも、可能ですが、アプリ側で受信バッファを持つ方が、
> 考え方が、受信は受信、データ処理はデータ処理と、分離できるので、楽だと思います。
> 今回の場合は、無通信時間が長くありそうですから、
> アプリ側の受信バッファクリアのタイミグは、
> データ受信中でない＆規定の無通信時間経過後
> と、すれば良いのではないでしょうか？
> （無通信時間が短い場合は、リングバッファを考慮します。）

DataReceivedイベントで来るデータは全てバッファに溜め込み、データ受信から一定時間でデータ処理をするという方式を採ってみようと思います。これでしたら、CR+LF待ちでのタイムアウトも無くなりそうです。
ひとまず全ての機器が揃いましたので、これからプログラムを組んでみようと思います。
ありがとうございました。

引用返信 編集キー/

■76411 / inTopicNo.8)

　Re[7]: 複数シリアルポートでの計測機器データ受信

□投稿者/ daive (65回)-(2015/07/08(Wed) 15:48:25)

＞不良データ受信した際にCR+LFが来ない為、タイムアウトを起こす時があります。
＞それゆえタイムアウト時にだけバッファクリアをしています。
＞そもそも、この不良データがたまに受信される事も悩みの種なのですが・・・。
ラインモニタなどで、実際に発生しているのか、（外部機器をつなぐと、状況が変わるので、でなくなることもあります。）
ソフトウェア側の受信問題なのか、確認する必要があります。
（昔は、ビッツなどで、低価格ラインモニタがあったのですが、現在では、ＰＣ横取りケーブルか、数１０万～１００万単位の機器かも）
⇒状況が変わるの覚悟で、ソフトウェア的でない証明をする為の、横取りケーブルの手法は、
　手作りでも、可能な場合があります。
＞シリアルケーブル長が１０ｍと長く、限界である１５ｍにほど近い長さがある事も原因なのかもしれません。
これに関しては、
１．可能であれば、光ケーブルを用いたアダプタにする。ネットワークサプライ：Ｏｐｔ－２３など、システムサコムなど、類似品。
２．光と、どっちが、御高いかになるのですが、高性能シリアルケーブルにする。
　　１ピン毎に、シールドしたケーブルは、特注で作成可能です。
３．ＵＳＢ－シリアルアダプタは、２３２系の電圧でも、低い方で動作している場合があるので、
　　余り距離は稼げなかったような。

引用返信 編集キー/

■76417 / inTopicNo.9)

　Re[8]: 複数シリアルポートでの計測機器データ受信

□投稿者/ jun (5回)-(2015/07/09(Thu) 10:32:17)

ご返答ありがとうございます。

> ソフトウェア側の受信問題なのか、確認する必要があります。
> （昔は、ビッツなどで、低価格ラインモニタがあったのですが、現在では、ＰＣ横取りケーブルか、数１０万～１００万単位の機器かも）
> ⇒状況が変わるの覚悟で、ソフトウェア的でない証明をする為の、横取りケーブルの手法は、
> 　手作りでも、可能な場合があります。

ラインモニタ、高い物しかありませんね。
それだけ需要が先細りしているという事でしょうか。

> ＞シリアルケーブル長が１０ｍと長く、限界である１５ｍにほど近い長さがある事も原因なのかもしれません。
> これに関しては、
> １．可能であれば、光ケーブルを用いたアダプタにする。ネットワークサプライ：Ｏｐｔ－２３など、システムサコムなど、類似品。
> ２．光と、どっちが、御高いかになるのですが、高性能シリアルケーブルにする。
> 　　１ピン毎に、シールドしたケーブルは、特注で作成可能です。
> ３．ＵＳＢ－シリアルアダプタは、２３２系の電圧でも、低い方で動作している場合があるので、
> 　　余り距離は稼げなかったような。

ご助言ありがとうございます。
ソフト側なのかケーブルなのは秤なのかを見極めたいので、まずはソフト側の改良を進めました。
ケーブルの問題については、ケーブルを作成していただけるメーカーがございますので相談してみようと思います。

受信とデータ処理を切り離して処理する方向で再コーディングいたしました。
バッファを多めに取って、そこにDataReceivedイベントが起こる度にバンバン受信データを格納し、一方でデータ処理はタイマーにて一定時間毎にバッファを１バイトずつ検査し、１レコードの把握と重量データの記録するように致しました。
クロスケーブルでのテストにて、1ms毎に500回程ダミーのデータを飛ばしても取りこぼし無く記録できているようです。ノイズデータも混入させてみましたが、うまくスルーして記録もできています。
まだ細かな処理が必要ですが、ほぼコアとなるところは出来たように思います。

当初の質問から、結構話の内容が逸れてしまいましたが、数々の貴重なご意見ありがとうございました。
大変勉強になりました。シリアル通信ってなかなか難しいですね！

解決済み

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可