Hallo,
bei meinem Projekt besteht die Aufgabenstellung darin zeitkritisch alle 50ms eine CAN Message an ein Gerät zu senden und in einer parallelen Schleife ankommende CAN Messages zu erfassen und zu interpretieren.
Nun ist es so, dass der gesamte CAN Bus Traffic angezeigt werden soll. Ich dachte dabei an eine Tabelle oder ein Listenfeld welche(s) kontinuierlich mit jedem Durchlauf anwächst. Das Schreiben mache ich wie üblich mit Property Nodes.
Dabei tritt folgendes Problem auf:
Durch den relativ hohen Takt von 50ms wächst diese Liste natürlich sehr schnell an. Die ersten 2000-3000 Messages sind problemlos. Danach stelle ich allerdings über meinen Sendezeitstempel fest, dass scheinbar das Beschreiben des Anzeigeelements mir mein Timing versaut und keine sauberen 50ms mehr sendet sondern mit irgendwelchem Delay.
Kann es sein, dass das Beschreiben größerer Datenmengen mit Property Nodes schlechten Einfluss auf mein Timing hat? Was ist denn die eleganteste Möglichkeit größere Datenmengen oder Arrays an Tabellen oder Listenfelder zu übergeben? Oder wie visualisiert man sowas am besten?
Vielen Dank im Voraus für praktische Hilfe!
Andy
Das beste ist, wenn Du es nicht anwachsen lässt.
Oder Du schaust Dir mal eine "Producer Consumer Loop" an.
Gruß Markus
Hallo Andy,
Zitat:welche(s) kontinuierlich mit jedem Durchlauf anwächst
Das ist der Kardinalfehler: alles, was ungehindert "anwächst", sprengt dir früher oder später dein Programm - entweder per "Out of Memory" oder durch die Schleifenzeiten...
Zitat:Durch den relativ hohen Takt von 50ms wächst diese Liste natürlich sehr schnell an.
So schnell kann niemand mitlesen! Außerdem ist man dauernd am Scrollen, wenn man eine bestimmte Message sehen will...
Zitat:Was ist denn die eleganteste Möglichkeit größere Datenmengen oder Arrays an Tabellen oder Listenfelder zu übergeben? Oder wie visualisiert man sowas am besten?
Es gelten die sonst auch üblichen Ratschläge:
- Trenne Datenerfassung und Datenaufbereitung/-darstellung voneinander.
- Verwende parallele Schleifen.
- Verwende Queues.
- Limitiere die UI-Updaterate auf ein vernünftiges Maß.
- Limitiere die Menge der Daten im Speicher...
Tabellen/Listen sind schon "schön anzusehen", aber ist es wirklich sinnvoll, alle 50ms erneut mehr als 2000 Einträge hineinzuschreiben?
Tipps: Es gibt einiges, was du optimieren könntest...
Das hier [
attachment=44827] funktioniert auch ohne String-Vergleiche und nachfolgendes Select!
Nachtrag:
- Wieviele verschiedene CAN-Botschaften erwartest du denn? Reicht es nicht aus, immer nur die aktuellsten Werte jeder Botschaft anzuzeigen? (Meine Anwendungen kommen mit ~20 Botschaften aus, die ich auch in einem Array/Tabelle darstellen lasse...)
- Guck dir an, wie das in anderen Programmen (CANalyzer und Konsorten) gelöst wird...
(28.05.2013 22:20 )derherrk schrieb: [ -> ]Das Schreiben mache ich wie üblich mit Property Nodes.
Extrem tödlich, vor allem bei zeitkritischen Schleifen.
Das Setzen von PropertyNodes erzwingt ein Update des Frontpanel, und je mehr Daten du in deiner Tabelle hast, um so länger dauert so ein Update dann.
Gruß, Jens
Bei einer Listbox bleibt ihm nichts anderes übrig. Value ist in dem Fall ja "numerisch".
Gruß Markus
(29.05.2013 08:37 )jg schrieb: [ -> ] (28.05.2013 22:20 )derherrk schrieb: [ -> ]Das Schreiben mache ich wie üblich mit Property Nodes.
Extrem tödlich, vor allem bei zeitkritischen Schleifen.
Hi Leute,
vielen Dank für die rege Anteilnahme.
Tatsächlich habe ich das Programm bereits mit einer Art Producer/Consumer Architektur ausgestattet. Dabe laufen drei Schleifen parallel:
1. Schleife: Timed Loop zum Schreiben der CAN Messages
2. Schleife: Timed Loop zum Lesen der CAN Messages
3. Schleife: While Loop mit Event Struktur zum Handhaben von Buttons und Programmsteuerung
Nun habe ich das Programm so verändert, dass ich sowohl die gesendeten als auch die empfangenen Nachrichten in eine Queue einfüge und diese Queue dann per Knopfdruck über die Eventstruktur auslese und darstelle. Das funktioniert soweit. Auch mit ms genauem Timing.
Ich würde jedoch gerne eine völlig autonome Protokollierung ohne Knopfdruck machen.
Ich dachte dabei vielleicht an eine vierte Schleife die ausschließlich diese Queue verwertet und darstellt.
Aber ein Problem bleibt: Spätestens nach ein paar tausend Messages wird auch hier ein Performanceproblem beim Beschreiben der Tabellen/Listenfelder auftreten... Gibt es denn bei Tabellen oder Listenfeldern nicht die Möglichkeit NUR neue Daten hinzuzufügen (so dass nur Eintrag 2001 hinzukommt, während die ersten 2000 eh schon da sind?)
Wie protokolliert man eigentlich sowas wie Bus Traffic denn professionell?
Viele Grüße
Andy
lv10Hallo!
Kann dir bei deinem eigentlichen Problem nicht helfen, möchte aber auf etwas anders hinweisen, da du mit Table/Listbox arbeitest.
Sind die Schreibzyklen zu kurz, kann es beim Table zu einem Flickern kommen. Falls du die Listbox wegen der recourcenfressenden Listbox nicht nehmen kannst, geht als Workaround: Gestaltungselement über die Tools-Palette transparent machen und über den Table legen.
Habe Dir ein Beispiel angehängt (als LV 2010 Version).
Ansonsten: Musst du ständig alle Werte anzeigen? Auch in Excel-Tabellen wirst du in kaum bis zum 3000ten Wert scrollen, oder? Kannst ja alle Werte in einem Array speichern, aber anzeigen lässt du eben nur einige wenige.
MFG,
Frontpanel
(29.05.2013 12:39 )derherrk schrieb: [ -> ]Gibt es denn bei Tabellen oder Listenfeldern nicht die Möglichkeit NUR neue Daten hinzuzufügen (so dass nur Eintrag 2001 hinzukommt, während die ersten 2000 eh schon da sind?)
Wie protokolliert man eigentlich sowas wie Bus Traffic denn professionell?
Alten Inhalt lesen...nach Message suchen...wenn schon da, Inhalt ersetzen...wenn noch nicht da, unten anfügen...Inhalte wieder schreiben
A.