Hohe Systemauslastung beim Lesen von CANoe Variablen über ActiveX

' 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