USB接続デジタル入出力の速度

 USB接続デジタル入出力基板などの製品は、パソコンのアプリケーションソフトから、どのような速度で動作させることができるのでしょうか。このページでは、アプリケーションソフトから、デジタル入出力などを動作させる場合の速度目安を解説しています。弊社製品を使用したシステムのご検討に参考としていただければ幸いです。

  以下に記載する内容は、弊社製品を使用した場合を前提としています。一般的なデジタル入出力動作に適合するものではありません。

USBインターフェイスのデータ転送速度

 弊社のUSBインターフェイス基板に使用しているUSBチップは、USB2.0およびUSB1.1のフルスピードモードで動作しています。フルスピードモードのデータ転送速度は、12Mbit/sec です。弊社のデジタル入出力製品 (DACS-1500など) は、9文字(9byte)のコマンドとレスポンスで動作します。9byteを12Mbit/secで転送する時間は、わずかに 8×9/12 = 6μs という計算になるのですが、アプリケーションプログラムからみた場合に、実際には、こんなに速く動作するわけではありません。マイクロ秒単位の時間は、全く関係なくなるほど、ミリ秒単位で、WindowsなどのOSサイドで動作する時間がかかります。

コマンド送信実行からデジタル入出力基板が動作するまでの時間

 WindowsのUSBポーリング時間はおよそ1msです。すなわち、WindowsはUSBのデータ送受信を1msの周期で監視しています。アプリケーションプログラムから、FT_WRITE関数にてコマンドを送信すると、OSはこの1msの周期にて送信要求を検出してデータ送信を実行します。OSサイドの諸々の処理を含めると、おおよそ 2～3ms の時間にて、デジタル入出力基板にデータがわたることになります。
 デジタル入出力基板がコマンドを受信してから、デジタル出力など受信したコマンドを実行するまでは、1μs以下の短時間です。

アプリケーションプログラムがレスポンスを受信するまでの時間

 デジタル入出力基板がコマンドを受信してから、その応答として、レスポンスデータの送信を準備するまでの時間 (データを送信バッファにセットし終わるまでの時間) は、約5μsです。例えば、デジタル出力コマンドを受信し終わってから(文字列最後のCRコードを受信してから)、デジタル出力を実行し、デジタル入力状態を、レスポンスデータとして送信バッファにセットし終わるまでの時間がこれにあたります。続いてデータ転送に数μsがかかりますが、これらの時間よりも、先にご説明した WindowsのUSBポーリング時間およそ1msが大きく関与します。すなわち、アプリケーションプログラムで、FT_READ関数にてデータ受信を実行しても、このポーリング時間以上に速くデータを受信することはできません。
 (注) 記述しているレスポンスデータ送信時間は、イベント文字をCRと指定した場合です。詳細は製品取扱説明書をご覧ください。

コマンド送信実行からレスポンス受信まで一連の動作時間

 アプリケーションプログラムにて、FT_WRITE関数でデータを送信し、そのまま、FT_READ関数でデータ受信完了を待つという処理は、Windowsがマルチタスクで動作していることを考えると、決してほめられた処理ではありません。FT_WRITE関数で送信したあとは、いったん処理を解放して、タイマーイベントなどのイベント処理で、データを受信するのが一般的な方法です。このような処理を含めると、コマンド送信からレスポンス受信完了までの一連の動作(ハンドシェイク)には、10～20ms の時間がかかることになります。

よくあるトラブル
    高速化と簡素化のために、レスポンスを受信しなければいいと考えるのは間違いです。

 例えば、デジタル出力のみを連続して実行し、デジタル入力の状態を読み取る必要がないような場合でも、デジタル入出力基板から送られてくるデジタル入力などのレスポンスを、その都度、きちんと読み取らなければ、いつかは受信バッファがオーバーフローしてしまいます。「起動してしばらくは動作するが、その後、アプリケーションソフトがハングアップしてしまう」というトラブルの多くは、この問題から生じています。
 必要なときだけ読み取るような動作とした場合には、先に受信したレスポンスがバッファに残った状態となるので、「デジタル入力がずいぶんと遅れている(?)」というようなトラブルが生じます。10msほどで動作するはずなのに、1秒近く遅れているというトラブルは、きちんとレスポンスを読み取っていないことが原因です。

動作時間を短縮する効果的な方法

 動作時間を短縮する方法としては、1回のFT_WRITE関数で送信するコマンド数を、複数にするのが効果的です。DACS-1500をはじめとする弊社のデジタル入出力基板などでは、コマンドの区切り文字が2種類あります。通常は、CR文字(ASCIIコード0dh)ですが、もう一つ、&文字(ASCIIコード26h)を用意しています。
 
  W0123456(CR) -------- 1コマンドのみ送信する例
  W0123456&W0234561&W0345612&W0456123(CR) -- 4コマンドを一度に送信する例
 
 送信するコマンド数を複数にした場合でも、USB伝送の1パケット単位となる64byte(64文字分)までは、転送時間は全く変わりません。また、仮に64byteを超えた場合でも、OSのUSBポーリング時間 1ms に比べれば、転送時間はわずかなものです。
 一方、一度に転送できる文字数は、基板に実装しているUSBインターフェイスICの、受信バッファサイズにより制限があります。この受信バッファサイズは256byte(256文字分)です。このサイズを超えて、一度にデータを送信すると、バッファーオーバーフローとなって、転送データが欠落する恐れが出てきます。これ以下の文字数のデータであれば、コマンド送信からレスポンス受信完了まで、複数のコマンド分でも、1コマンドと同じ時間の 10～20msにて処理することができます。例えば、モーションコントローラ基板では、1軸から6軸までの移動パルス数を一度に送信することで、実質的な処理速度を向上させることができます。

ハンドシェイクなしで、格段に速度を上げている製品もあります。

 コマンド送信とレスポンス受信を対としたデータ転送は、ハンドシェイク方式ともいわれていて、一般的なものです。ハンドシェイクではなく、送信か受信のどちらかを一方的に実行すれば、転送時間を格段に短縮することができます。
 パソコンから送信のみの実行は、先にご説明した通り、システムのハングアップにつながります。仮に、インターフェイス基板をレスポンス送信しない仕様として、実現できないわけでもありませんが、そのような不確実なシステムはつくるべきではありません。弊社には、パソコンから送信のみを実行する製品はありません。
 一方、パソコン側が一時的に受信のみとする方法は有効な場合があります。弊社の計測ユニット15BXシリーズでは、AD変換データの転送時間をこの方法で短縮しています。15BXシリーズでは、パソコンからAD変換開始コマンドを送信すると、停止コマンドを受信するまで、AD変換データを転送し続けます。最速で20μs (1個のAD変換データ) にて動作します。
 ところで、アプリケーションプログラムは、単にデータを受信するだけの処理を実行しているのではありません。最も処理時間がかかるのは、画面上の波形描画です。リアルタイムで画面をスクロールして描画を繰り返すのは、相当の処理時間が必要です。20μsで転送されるデータを処理して保存し、さらに波形描画するのは、一般的なパソコンでは精一杯 (ほぼ無理) というところです。処理が追いつかなくなると、2KbyteほどあるOS側の受信バッファがあふれて、AD変換データをそれ以上は連続して受信できなくなります。バッファサイズを大きくすることもできますが、平均的に処理が追いつかない状態となると、いくら大きくしても意味がありません。