labviEWタイマーについて話す

Talking About Labview Timer

Labviewは5種類のタイマーを提供します：3種類の通常のタイマー：ティックカウント（ms）、待機（ms）、次のミリ秒まで待機msマルチプル（次のミリ秒の整数倍を待機）

2つのAPI関数タイマー：時間遅延と経過時間。

以下に、違いにおける各タイマーの役割の詳細を示します。

1、ティックカウント（ms）-------ミリ秒タイマーの値を返します

参照参照時間（0ミリ秒）は定義されていません。つまり、返されるミリ秒を実際の時刻と日付に直接変換することはできません。この関数を比較に使用すると、ミリ秒タイマーに到達することに注意する必要があります。2 ^ 32-1は0に逆になります。参照参照時間は未定義であり、ステートメントはあいまいです。乱数ですか？それは明らかに不可能です。乱数の場合、TICKCOUNTを2回呼び出して差を求めることはできません。沿ってミリ秒数。いずれにせよ、時間の出発点がなければなりません。

API関数にも同様の関数GetTickCountがあります。これは、コンピューターが起動されてからのミリ秒数を返します。 9Xでは、BIOS、初期のPCに保存されたティック数を読み取りますROMは、Intel 8259タイマーチップを初期化して、ハードウェア割り込み08Hを生成します。この割り込みは、「タイマーティック」割り込みと呼ばれることもあります。割り込み08Hは、54.925ミリ秒ごと、つまり1秒あたり約18.2ミリ秒ごとに生成されます。タイムズ。BIOSは、割り込み08Hを使用して、BIOSデータ領域に格納されている「時間」値を更新します。これが55MSの起源です。 NTオペレーティングシステムの場合、従来のステートメントは10MSまで正確です。これは、1MSでは精度が正確ではないことを意味します。。

実際のテスト後、LABVIEWのTICK COUNTの戻り値は、コンピュータが起動してから経過したミリ秒数であるAPIの戻り値と同じです。ミリ秒数が2 ^ 32-1に達すると、0に反転され、その数が表示されます。値の形式はU32で、最大値は2 ^ 32-1で、49。7日に相当します。継続的に実行されているコンピューターの場合、このノードを比較に使用すると、49。7日間の継続的な操作の後、値は自動的にゼロに復元されます。この時点で比較すると、間違った結果が得られる可能性があります。

2、待機（ms）------指定されたミリ秒数待機し、ミリ秒タイマーの値（上記のコンピューターの起動からのミリ秒数）を返します。

指定されたミリ秒数待機し、ミリ秒タイマーの値を返します。待機時間は、待機時間をミリ秒単位で指定します。関数の待機時間は0x7ffffff、つまり2147483647ミリ秒を超えません。長く待つために、関数を再度実行できます。
ミリ秒のタイマー値入力に0を接続すると、現在のスレッドはCPUの制御を放棄します。
この関数は非同期システムコールを実行しますが、関数ノードは同期しています。したがって、関数は指定された時間の終わりまで実行を停止します。
この組み込み関数は通常、プログラムでタイマーまたは遅延として使用されます。その入力は予想されるタイミング値（ミリ秒単位）であり、その出力はミリ秒タイマーの値を返します。
wait（ms）はLabVIEWの組み込み関数であるため、プログラム内でどのように、またはどのように実行されるかを理解することはできません。しかし、さまざまなプログラミング形式の結果を通じて、間接的にそれを理解し、理解することができます。
次の例を見てみましょう。図1-2を参照してください。

図1-2では、wait（ms）組み込み関数に1000msのタイミング値を設定しています。プログラムの実行後、その出力「ミリ秒タイマー値」には、未決定のデータのセットが表示され、各プログラムの実行後に表示されます。出力値はすべて異なりますが、傾向は増加しています。ここで、待機（ms）タイマーの開始時間が常に変化する値であることは明らかです。どうしてこれなの？

図1-3の操作の結果は、この時点で入力セットポイントと同じ「ミリ秒のタイミング値」を取得できることを示しています。明らかに、wait（ms）組み込み関数には、「タイムカウンター」と同様の組み込み関数が含まれており、特定の時間に同期して操作を開始するため、出力で安定した「ミリ秒のタイミング値」を取得できます。待機時間（ミリ秒）。 '。

これで、待機（ms）組み込み関数とタイムカウンター組み込み関数の開始稼働時間は、コンピューターが起動してからのミリ秒数であると言えます。プログラムの実行後、図1-2を参照してください。「ミリ秒のタイミング値」を出力すると、未決定のデータのセットが表示され、実行ごとに出力値が異なりますが、傾向は増加しています。図1-3に示す出力は、実際にはタイマーのミリ秒のタイミング値です。
この分析から、次の2つのプログラムは完全に同等である必要があることは明らかです。（注意：この時点で組み込み関数の次の倍数を待つことで同じ結果が得られます）

ただし、いずれにせよ、これらはソフトウェアタイミングに基づいており、タイミング精度が高い場所では使用しないでください。リアルタイムシステムではハードウェアタイミングを使用する必要があります。比較すると、組み込み関数の次の整数倍を待機するタイミング精度は、待機（ms）組み込み関数よりも高くなります。次の図の手順を使用して、この結論を検証しました。
図1-7（注意：停止するには停止ボタンを押す前に、プログラムを再度サイクルする必要があります）
図1-8プログラムを変更した後、停止ボタンを押した直後に停止できます。
タイミングが10msを超える場合、上の図を使用して、組み込み関数の次の整数倍とテスト用の待機（ms）組み込み関数を待機します。その結果、前者は後者よりも約1桁高くなります。タイミングが10ms未満であっても、タイミング精度は後者よりも優れています。

WAIT（MS）接続0が、現在のスレッドに制御を放棄させる場合。WAIT 0MSは非常に重要な機能であり、実際にはオペレーティングシステムに制御を戻し、キュー内の他のメッセージを処理します。メッセージを処理する必要がありますシステムはすぐにこのスレッドを制御し、実行を継続します。

2つのケースがあります。処理する必要のあるメッセージがシステムメッセージキューにない場合、メッセージはすぐに返されます。システムメッセージキューに処理する必要のあるメッセージがあり、それが時間のかかる操作である場合、LVスレッドがいつ再び制御を取得するかを予測することは不可能です。 LVとWait0MSの速度を比較します。

実験中に他の操作は実行されなかったため、他のメッセージの影響は回避されました。 2つの間のギャップは驚くべきものです。これはLabviewの利点も反映しています。これは、ハードウェア制御される傾向のあるプログラミングソフトウェアに対して強力なタスクプリエンプティブ機能を備えています。

ループ内で並列に待機を実行する方法は、非同期か同期かに関係なく、累積時間、つまり最長の実行です。実験してみましょう。

これらの3つの待機が同時に実行されていることがわかります。 WAITはスレッドベースであるため、ループ内の待機は、同時に実行されている他のスレッドの動作に影響を与えません。

3、次のミリ秒まで待つマルチプル（次のミリ秒の整数倍を待つ）

ミリ秒タイマーが指定された時間の整数倍になるまで待ちます。 1つのループでループの実行速度を調整するために使用できます。ただし、最初のループは短くなる可能性があります。 0をこのノードに直接接続して、現在のスレッドに制御を放棄させることができます。そうです、CPUに戻りました。
WAIT MSと比較して、このノードはループでより一般的に使用されます。同じパラメータを持つ複数のWAITUNTIL NEXT MS MULTIPULEの場合、不正確な同期を実現できます。 LABVIEWループの特性により、すぐに実行されるため、最初のループは同期を保証できません。同期を確保する必要がある場合は、ループ内で初めて空のループを実行することで、この問題を回避できます。
LABVIEEWEXPRESSでは2つの高速VIも利用できます。1つはWAITMSに相当し、もう1つは非常に複雑なタイミング機能に相当します。

このviをよりよく説明するには、システム（少なくともWindowsでは）にミリ秒タイマーなどのタイマーがあり、このタイマーと密接に関連していることを知っておく必要があります。つまり、このviは、msタイマーが入力値の整数倍になるまで待機します。これは、次の例（デモ1.viまで待機）でよりよく理解できます。プログラムでは、最初に50msを入力してWait untilを入力し、最初のWait untilの時間を計算してから、50msを入力し、2番目のWaitUntilの時間を計算します。

各実行の結果は異なりますが、最初の待機時間は50ミリ秒ではなく、2回目は間違いなく50ミリ秒であり、タイマー値は通常50ミリ秒の2倍です。この状況は次のように説明されます。以下：まず、プログラムの実行中、システムのタイマー値は正確に50の倍数ではありません。10450935の場合、プログラムは15msの操作後に10450950（50の倍数）に達します。次の50倍（10451000）を完了した後、最初の待機を終了し、次に2番目の待機まで中断します。

したがって、WaitUntilがWhileループで並列に配置されている場合、2つの問題が発生する可能性があります。まず、その最初のサイクルは未定義です。以下の例のように（並列デモ1.viまで待機）：

Wait untilを使用する場合、最初の時間（つまり、2番目の値）は20ms未満ですが、Waitを使用する場合、Timer値が最初ではないため、最初の時間は20msであることが保証されます。プログラムの。整数倍の結果。次のmsまで待つMultiple.viの2番目の質問も非常に明確です：http：//zone.ni.com/devzone/cda/tut/p/id/4120
最後に、例を見てみましょう。待機までをシーケンシャルモードにすると、おおまかに待機の並列モードとして機能しますが、コード時間が設定値を超えても大きな違いがあります。