Queues oder Melder mit Variant Daten

Hallo zusammen,

ich habe gelesen, dass man bei Queues am besten einen Cluster aus Enum-Steuerelement und Variant-Daten verwenden soll, da das sehr multifunktionell ist. Das stimmt natürlich, nur frage ich mich, ob das stets notwendige Konvertieren der Daten aus Variant nicht zu Performanceeinbußen führt. Schließlich ist bei jedem Schreiben und Lesen des Clusters eine zusätzliche Operation notwendig. Das mag bei selten verwendeten Queues nicht so gravierend sein, aber wenn ich bspw. eine Datenerfassung mit hoher Abtastrate programmiere und die Daten über eine solche Queue übertrage kann ich mir schon vorstellen, dass es sich bemerkbar macht.

Kann mir da jemand zustimmen? Oder ist die Daten-zu-Variant-Funktion (und umgekehrt) so systemoptimiert, dass sie zu keiner nennenswerten Zusatzbelastung führt?

MfG
J_uri

Anzeige

Die von dir beschriebene Queue benutze ich auch, allerdings nur, um Kommandos mit optionalen Parametern zu versenden. Der Datentransfer läuft bei mir immer im nativen Datentyp der Messdaten.

In einem meiner Prüfstände läuft eine Messkarte mit 8 Kanälen und 10kHz. Ich kann mir durchaus vorstellen, dass die Prozessorlast merklich steigt, wenn ich alles in Variant und wieder zurückwandle.

' schrieb:aber wenn ich bspw. eine Datenerfassung mit hoher Abtastrate programmiere und die Daten über eine solche Queue übertrage kann ich mir schon vorstellen, dass es sich bemerkbar macht.

Wenn du nur alleine die Sampledaten per Queue verschicken willst, musst du ja nicht einen Variant nehmen. Nimm halt für die Sampledaten einfach eine eigene Queue mit 2DArrDBL.

Meistens verwende ich einen (verschachtelten) Cluster als Queue-Daten. Da können dann für jede Zielfunktion die entsprechenden Parameter drinnen stehen. Nur wenn dieser Cluster zu unübersichtlich wird, verwende ich Variant.

Ich halte den Overhead, der durch Variant entsteht, nicht für relevant.

Mach dir keine Sorge, es nimmt nich zu viel Performance. Ich nutze es überall mit vielen Abtastungen (zuletzt hatte ich 8 geräte mit bis zu 1000 Hz). Zwar nehme ich ENUM+String statt ENUM+Variant, da Variant nicht so verbreitet wie Binary String ist. Aber im Prinzip nimmt die Umwandlung der Daten nach Variant nicht viel mehr Performance, wie Flatten to String. Meine Meinung

Mach Dir mit dem Umwandeln in Variant keine Sorgen.
Das wird auf den Schulungen von NI auch so vermittelt und die müssen ja wissen, was sie machen.

Gruß Markus

' schrieb:Wenn du nur alleine die Sampledaten per Queue verschicken willst, musst du ja nicht einen Variant nehmen. Nimm halt für die Sampledaten einfach eine eigene Queue mit 2DArrDBL.

Ganz genau! Wenn du ja weißt, was du versenden willst...dann musst du doch nicht zwanghaft alles "flexibel" halten.

Und mal ehrlich: Wenn eine Anwendung mal steht, wie oft wird dann wirklich eine derartige Änderung notwendig, dass der bis dahin getätigte Aufwand, alles so flexibel zu halten, gerechtfertigt war?

Gruß
Achim

' schrieb:Zwar nehme ich ENUM+String statt ENUM+Variant, da Variant nicht so verbreitet wie Binary String ist. Aber im Prinzip nimmt die Umwandlung der Daten nach Variant nicht viel mehr Performance, wie Flatten to String. Meine Meinung

Wobei Variant nochmal deutlich schneller als String ist, AQ hat dazu auf lava mal ein Statement abgelassen ...

aber wenn man jetzt nicht gerade schnelle Messdaten über so eine Queue streamt, dann wird man denke ich keinen Geschwindigkeits-Unterschied bemerken, und für das streamen von Messdaten würde ich dann sowieso eine Queue mit dem nativen Datentyl (DBL-Array, Waveform-Array, etc) verwenden ...

10kHz ist doch nicht schnell . Ich habe eine Datenerfassungskarte die mit 400MHz arbeitet :Pda bekomme ich immer graue Haare.

' schrieb:10kHz ist doch nicht schnell . Ich habe eine Datenerfassungskarte die mit 400MHz arbeitet :Pda bekomme ich immer graue Haare.

Der Unterschied dabei ist, dass deine Karte die Daten in Array sammelt und dir das komplette Datenarray übergibt. Bei mir muss ich die Daten einzeln über serielle Schnittstelle auslesen. Das macht verdammt viel aus...

Wieso wartest Du nicht bis z.B. 100 oder Messdaten im RS232 Speicher vorhanden sind, so das Du die alle mit einem mal auslesen kannst. Somit kannst Du eine Menge Zeit einsparren. Den RS232 Eingabepuffer kann man auch durch Eigenschaften vergrößern, so das 1 Million Datenpunkte reinpassen.

Es gibt aus RS232 USB Konverter die locker 250k anstelle von 115k baut schaffen. Die kazft man für 10€ steckt die einfach an den PC. Diese werden das als Comx erkannt und Du kannst die normalen Visa Funktionen benutzen. Nur muss Deine Gegenschnittstelle auch dieses Geschwindigkeit unterstützen.