MOTO+4 Applocations のブログ

弊方ではOSクリーン状態、古いOSでののアプリ動作確認に、Hyper-Vで仮想OSで実施することが多いです。機能は VmWare には敵いませんが、Windows Pro版なら無償で使えます。特にOSのロールバックができるので、OSクリーン状態でのアプリ動作確認に重宝します。仮想OS側はMSDNに加入していれば XP まで使えます。しかし Hyper-V の仮想OSウインドウは使いにくいので、リモートディスクトップで仮想OSを使います。その設定の覚え書きです。設定方法の一つであって他の方法があるやもしれません。

仮想ネットワークアダプタの作成

ホストOS側でリアルPCと仮想OSを一つのLANに入れるたのネットワークアダプタを、 Hyper-V の管理機能から以下のように作ます。この手順は、リアルネットワークアダプタを変更した場合も必要です。

ホストOS側のネットワーク接続にアダプタが以下の様に追加されます。

仮想OS側の設定

次に仮想OS側で、Hyper-V の管理機能の仮想OSの設定にて、ネットワークアダプタの仮想スイッチを作成したアダプタに切替えます。

仮想OSを起動して、下記のようにTCP/IPの設定をします。古いOSはネットアクセスしないようにしておきます。

PingがホストOSに飛ぶか仮想OS側で確認します。

PingがホストOSから飛ぶかホストOS側で確認します。

ファイル共有の確認

リモートディスクトップでのファイルのコピペは使えますが、仮想OSとファイル共有もできた方がよいので確認します。

仮想OS側:

ホストOS側:

ログイン

あとは普通にリモートログインします。

Hyper-V覚書き

• ディスク容量はかなり食うので専用のストレージを追加した方がいい。
• OS起動中に、ディスクが足りなくなると壊れる。ただ壊れたらロールバックすれば治る。
• MACアドレスを任意に固定できる。
• 仮想OSでUSBデバイスは使えない。

電子コントローラとシリアル通信で通信するWindowsアプリを作成する場合、弊方では動作が軽く、細かくコントロールしたいため大体Win32APIを直接使います。

Windows用製シリアル通信コントロールは、自主トライや既存コードが使っていた場合に使用しています。その際に気づいた事項の覚書です。

.NET SerialPort の場合

.NET の標準コントロール SerialPort は以下の特徴があるようです。

• 当然ですがMFC や VB6 では使用できない。
• Windowsレジストリ登録は不要。
• 受信イベントは画面と別スレッドで動作する。
• 特に多機能ではない。

以下留意点です。

留意点1: 受信イベント内でUI操作を行う場合はデリケートが必要。

受信イベントは別スレッドで動作するためデリゲート( Swiftのデリゲートとは異なる物です )が必要になります。 そのままだとbuildエラーか実行時にエラーが出ます。デリケートは .NET の特有のややとっつきにくい部分、理解してもたまに使う程度なのでよく忘れてしまいます。以下コード例です。

private:
delegate void formatReceiveData_Delegate(void);	    // デリゲートの型宣言
formatReceiveData_Delegate^ formatReceiveData_Obj;  // デリゲートのインスタンス宣言	
    :
    :

private: System::Void Form1_Load(
   System::Object^  sender, 
   System::EventArgs^  e
) {
    :
    :
   // UI操作を行うmethodのデリゲートを生成、生成は一度でOK
   formatReceiveData_Obj	= gcnew formatReceiveData_Delegate(this, &Form1::formatReceiveData);
    :
    :
}

private: System::Void serialPort1_DataReceived(
   System::Object^ sender, 
   System::IO::Ports::SerialDataReceivedEventArgs^ e
) {
	if ( dgrdReceive->InvokeRequired ) {		// thread排他が必要か、対象UIで判別。

		// デリゲートを排他無しで呼び出す
		this->BeginInvoke( this->formatReceiveData_Obj );
	}
	else {
		formatReceiveData();			// 受信値表示
	}

	procReceivedAfter( serialPort1 );  // 受信後処理
}

private: System::Void formatReceiveData(void) {
    :
    :
    UI処理 ....
    :
    :

留意点2: 受信イベントを高周期で発生させるとフリーズ状態に至る。

ASCIIコード通信など不定長フレーム通信にて、msecオーダーで受信イベントが発生すると、忙しすぎて画面操作イベントが受付けられずフリーズ状態に至ってしまいます。 .NETでもこんなもんなんですね。PC は core i7 です。特定のシステムであれば、ReceivedBytesThresholdプロパティで調整も可能か漏れません。汎用ツールを作成する場合は苦しいです。

対策するには、受信専用Thread立てます。以下コード例です。

private:
		Thread^	recvTheard = nullptr;
		static	System::IO::Ports::SerialPort^  _serialPort1;

private: System::Void btnOpen_Click(
   System::Object^ sender, 
   System::EventArgs^ e
) {
  	_serialPort1	= serialPort1;  // Thread内で参照用にstaticにインスタンス退避
		serialPort1->Open();
		recvTheard = gcnew Thread( gcnew ThreadStart( this->RecvThreadMain ) );
		recvTheard->Start( );
}

public: static System::Void RecvThreadMain( 
	void
) {
	char rcvBytes[8192];

	while( 1 ) {
			Byte	rcvByte;
			Int32	rcvLen;
			try {
			  // 不定長の場合はその時々で受信した分を読む
 				 rcvByte		= _serialPort1->ReadByte();
				 _serialPort1->Read( rcvBytes, rcvByte );  
			}
			catch (System::TimeoutException^ exp) {
				// タイムアウトはスルー
			}
	}

受信の都度、UIに表示するとマトモに見えないので、表示内容は変数にキャッシュしておいて、Timerコントロールで0.5秒周期程度で、キャッシュした表示内容をまとめて反映させるようにします。これで下図くらい改善されます。

秒オーダーの応答性でよい場合以外は、受信インベントは使わない方が無難なようです。

MS Commコントロールの場合

2000年以前から存在しているVB6標準のコントロール、まだ使用されている場合かあるようです。弊方では最近まで使ったことはありませんでした。以下の特徴があるようです。

• たぶん MFC か VB6 でないと使用できない。
• 実行するPCにて、Windowsレジストリ登録が必要。
• 通信用スレッドは立てないので、通信周期によっては画面処理の応答性が落ちる。
• 使い方がシンプル。
• ナゾが多い。

以下留意点です。

注意1: 60byteづつしか受信できない

普通に受信させると下図のようになってしまいます。

これによる具体的弊害は、

• 60byte超えるパケットを読む場合、ロジックでバッファリングする必要がある。
• シリアルポートOPEN直後、60byte受信バッファに溜まるのでアプリが応答しなくなってしまう。

その半面メリットも考えられます。

• 受信イベントが多発しないため、.NETの様に大量受信時にフリーズ状態になりにくい。

ActiveComm の場合

ActiveCommはかつて販売されていたサードパーティのコントロールです。これもかなり古いものです。以下の特徴があるようです。

• たぶんMFC か VB6 でないと使用できない。
• 実行するPCにて、Windowsレジストリ登録が必要。
• 通信用スレッドは立てないので、通信周期によっては画面処理の応答性が落ちる。
• MS Comm よりは普通に使える。

昔々使った印象ですと、購入して使うほどメリットはないと感じていましたが、MS Comm の奇妙さを目のあたりにすると有用性はあったのかと思います。

jSerialComm 

java には、jSerialComm というものがあるようですね。今度また。

補足情報

あまり知られた情報ではないかもしれませんが、リアルRS232C、USBシリアル変換器の種類によって、単位時間あたりの ReadFile API で読めるサイズが変わります。1フレームを受信長で十分なタイムアウト時間で受信ストリームバッファを活用してRead待ちしている場合は関係ないですが、1～数byteづづ受信都度読みをしている場合はこの影響をうけます。アプリ側に作りによっては、RS232Cの種類によって動作がかわってしまいます。この影響か、上記コントロールにどこまで影響を与えているかは分っていません。このことが「USBシリアル変換器の相性問題」の要因かもしれません。

以上、Windows用シリアル通信コントロール新旧の留意点です。何にしても用途に応じてWin32APIを直接使い 内部Thread動作する.dllコントロールを作成するのがベストです。組込み機器との通信となると、どうしても応答性が求められてしまいます。 この主のWindowsアプリケーションで、不安定、遅い、応答性悪いが、対策時間ない/対策する自信がないなどお困りの場合は、こちらまでご相談してみてださい。アプリは本体は作るが、.dll 側だけ頼みたい場合でも製作したします。