Hohe Systemauslastung beim Lesen von CANoe Variablen über ActiveX

Hallo,

ich möchte über ActiveX CANoe - Umgebungsvariablen lesen und schreiben.
Ein VI mit 4 Variablen habe ich als Grafik angehängt.

   

Ich habe nun das Problem, dass die Systemauslastung schon bei 4 Variablen um 10% liegt, ich muss aber mindestens 40 Variablen lesen oder schreiben.

Hat jemand eine Idee, wie das ganze effizienter gestaltet werden könnte?

Vielen Dank für die Hilfe
Vogster

Anzeige

Mit ActiveX kenn ich mich nicht aus.

Für den Fall, dass es lediglich um die Anzeige der vier/vierzig Variablen geht, würde ich zuerst mal die Warte/Metronom-Zeit von 20 auf 250ms erhöhen. Unter bestimmten Voraussetzungen würde ich einen Anzeigerefresh auch nur alle Sekunde machen.

Leider geht es nicht nur um die Anzeige, dieses habe ich nur für dieses Beispiel so dargestellt.
Später sollen die Werte in Globale Variablen geschrieben werden, diese dienen als
Basis für ein Mess- und Analysetool.
20ms als Wartezeit ist hier das Minimum, 10ms ist eigentlich mein Ziel.

Grüße, Vogster

' schrieb:Später sollen die Werte in Globale Variablen geschrieben werden, diese dienen als Basis für ein Mess- und Analysetool.

Hinweis:
Ich würde keine Globalen Variablen nehmen, sondern entweder einen Melder oder eine Queue. Oder ich würde die Daten in einem Array sammeln und das dann per Melder/Queue weitergeben.

Zitat:20ms als Wartezeit ist hier das Minimum, 10ms ist eigentlich mein Ziel.

Wie schnell ActiveX und/oder CANoe ist, weiß ich nicht. Ich weiß nur, dass NI-Can bzw. NI-CanOpen die 10ms schaffen.
Du kannst mal einen Test machen. Bau eine Schleife, die alle 40 Variablen einließt - und sonst nichts macht. Keine Darstellung am FP und kein Speichern der Daten. Dann versuchst du die Laufzeit der Schleife zu ermitteln (was u.U. nicht trivial ist).

[*grübel*]

Hast du denn überhaupt mal die Auslastung bei allen 40 Variablen überprüft?

Zitat:Hinweis:
Ich würde keine Globalen Variablen nehmen, sondern entweder einen Melder oder eine Queue. Oder ich würde die Daten in einem Array sammeln und das dann per Melder/Queue weitergeben.

Ich habe mich gerade mal über die Funktion einer Queue informiert. Diese eignet sich aber - so glaube ich - in meinem Fall nicht. Eigentlich interessiert mich immer nur der aktuelle
Wert der Variable. Die Daten werden in LabVIEW auch nicht zuwangsläufig verarbeitet sprich aus der Queue abgeholt, nur bei Bedarf. Melder könnten da schon interessanter sein, allerdings muss ich mich noch genauer mit der Materie auseinandersetzten. Haben denn Melder gegenüber globalen Variablen einen Performancevorteil?
Oder sind globale Variablen einfach nur unschön?

Zitat:Wie schnell ActiveX und/oder CANoe ist, weiß ich nicht. Ich weiß nur, dass NI-Can bzw. NI-CanOpen die 10ms schaffen.
Du kannst mal einen Test machen. Bau eine Schleife, die alle 40 Variablen einließt - und sonst nichts macht. Keine Darstellung am FP und kein Speichern der Daten. Dann versuchst du die Laufzeit der Schleife zu ermitteln (was u.U. nicht trivial ist).

Da habe ich Zweifel. Bei einem High-Speed CAN Bus mit 10% Buslast hat es nicht funktioniert, die Botschaften alle 20ms auszulesen. Allerdings benutze ich einen USB - CAN - Adapter. Diese Probleme sind auch ein Grund für den Umstieg auf CANoe.

Zitat:Hast du denn überhaupt mal die Auslastung bei allen 40 Variablen überprüft?

Nein, das habe ich noch nicht getestet. Allerdings finde ich die Auslatung bei nur vier Variablen schon viel zu hoch.
Ich werde dieses Szenario in den nächsten Tage mal testen, allerdings brauche ich dafür noch etwas Zeit.

' schrieb:Ein VI mit 4 Variablen habe ich als Grafik angehängt.

Ich habe nun das Problem, dass die Systemauslastung schon bei 4 Variablen um 10% liegt, ich muss aber mindestens 40 Variablen lesen oder schreiben.
Hat jemand eine Idee, wie das ganze effizienter gestaltet werden könnte?

also bei 40 würde ich das dann schon als Array behandeln und nicht dasselbe 40x coden.
Das Problem wird dadurch vermutlich nicht gelöst, aber "effizienter gestaltet" wäre es dann schon.
(ob 4 oder 40 oder 80 wäre dann in ein klacks)

Bin mir nicht ganz sicher, aber Variant und Wandlung des Variant ist nicht das effizienteste, wenn du das irgendwie vermeiden kannst....

' schrieb:Melder könnten da schon interessanter sein, allerdings muss ich mich noch genauer mit der Materie auseinandersetzten.

Zitat:Haben denn Melder gegenüber globalen Variablen einen Performancevorteil? Oder sind globale Variablen einfach nur unschön?

LabVIEW ist eine Datenfluss-orientierte Programmiersprche. Globale Variablen konterkarieren (<= Bah, ey!) dieses Verfahren!
Performance. Hmm. Es gibt natürlich Fälle, da sind Globale Variablen bestimmt "schneller" als Melder. "Gesamtprogrammtechnisch" gesehen haben GV aber mehr Nachteile als Vorteile. Nachteile: z.B. RaceConsition. Pro Instanz einer GV ist ein Speicher notwendig - der gehandelt werden muss!

Zitat:Da habe ich Zweifel. Bei einem High-Speed CAN Bus mit 10% Buslast hat es nicht funktioniert, die Botschaften alle 20ms auszulesen. Allerdings benutze ich einen USB - CAN - Adapter. Diese Probleme sind auch ein Grund für den Umstieg auf CANoe.

Ich verwende keinen USB-Can-Adapter, sondern drei PCI-Karten NI-CAN/2 mit insgesamt 5 Kanälen. Alle 5 Kanäle werden mit jeweils 5ms parallel abgetastet. Verwendet wird die Channel-API von NI. Wie viele Variablen pro Kanal der Kunde einstellt ist seine Sache. (Meine letzte Info liegt bei 25 Variablen. Mit wie vielen CAN-Messages das gemacht wird weiß ich nicht).
LV selbst und ein Standard-PC sind also ohne weiteres in der Lage, auch größere Mengen an Daten zu handeln.

Möglicherweise liegt dein Problem eher am USB-CAN-Adapter als an LV respektive den GV.

Zitat:Allerdings finde ich die Auslatung bei nur vier Variablen schon viel zu hoch.

Nunja, ich weiß ja nicht, was du noch alles so machst. Für nur alleine diese eine Schleife sind 10% doch recht viel.


Was ist nicht weiß ist folgendes: Performance eines NI-USB-Moduls, Performance einer ActiveX-Schnittstelle

Hallo zusammen,

ich habe eine Lösung für das Problem gefunden:

Umgebungsvariablen in CANoe können mit Hilfe von LabVIEW in einer Gruppe zusammengefasst und dann gemeinsam ausgelesen werden.

Es ergibt sich folgender Code:
   

Die Systemauslastung liegt bei 3 oder 15 oder 30 Variablen bei 2% (Periode: 20ms).
Das Verdoppeln der Variablen hat keinen Einfluss, das Verändern der Periode wirkt sich proportional aus.

Grüße, Vogster