Leider noch nicht gelöst! Habe mal alle zeitgesteuerten Schleifen durch Whileschleifen mit manuellem Timing ersetzt. Dabei bleibt der Absturz an der selben Stelle und zusätzlich läuft der Arbeitsspeicher voll. Also hab ich alles wieder auf die vorherige Version zurück gestellt. Dann habe ich versucht den Speicher von Hand wieder freizugeben. Dafür habe ich das VI Speicherfreigabe anfordern überall dort eingebaut, wo SubVIs regelmäßig ausgeführt werden. Das hat gar nix geändert. Als nächstes werde ich alle Umgebungsvariablen durch FGVs ersetzen.
Leider hänge ich parallel noch an einem Modbus-Problem. Deswegen schiebe ich diese Baustelle ein wenig vor mir her. Vielleicht löst sich das Problem wenn ich nächste Woche eine neue LabVIEW Version installiere.
Ich melde mich, wenn es weiter geht!
Mit "Speicher freigeben" denke ich nicht das du Volllaufen von Arbeitsspeicher lösen kann. Mir ist jedenfalls noch kein Fall untergekommen. Vielleicht mal noch eine Idee um der Ursache auf den Grund zu kommen. Wie wäre es besagte Funktion mit einem Logging zu versehen welche die einzelnen Schritte sinnvoll mitloggt. Zum Beispiel nach folgendem Muster:
- Beginn Aufruf VI (direkt bevor das fragliche VI gerufen wird)
- Ende Aufruf VI
- Subfunktion 1
- Subfunktion 2
- ...
- Subfunktion n
- Ende VI
Das Logging könnte z.B. eine FGV sein welche an eine Datei direkt einen Eintrag anhängt und jedesmal die Datei öffnet und schließt damit auch sichergestellt ist das du definitiv alle Logeinträge siehst.
Ergebnis wäre du würdest genau sehen können wo er wirklich hängt. Bevor du noch weiter im Nebel rumstocherst und sonstwas probierst könntest so den Übeltäter dingfest machen.
Hallo, wir hatten auch mal so ein Problem das wir nicht gefunden hatten.
Bei uns waren es Reihenweise nicht geschlossene Referenzen...seit wir diese schön nach Gebrauch zu machen läufts wunderbar.
Alle Referenzen werden brav geschlossen (so oft und ausführlich wie in diesem Projekt habe ich das noch nie vorher kontrolliert!).
Das Debuggen fällt recht schwer, da das Programm wie gesagt durchläuft. Nur ein Unterprogramm nicht. Wenn ich mir nur das Unterprogramm ansehe, dann hängt es immer an der selben Stelle. Das aktive SubVI wird im Main aufgerufen, aber im SubVI startet nichts!
Da komme ich auch mit einem ActionLogger nicht weiter.
(05.06.2013 12:02 )TSchAC schrieb: [ -> ]... Dabei bleibt der Absturz an der selben Stelle und zusätzlich läuft der Arbeitsspeicher voll. Also hab ich alles wieder auf die vorherige Version zurück gestellt. Dann habe ich versucht den Speicher von Hand wieder freizugeben. Dafür habe ich das VI Speicherfreigabe anfordern überall dort eingebaut, wo SubVIs regelmäßig ausgeführt werden. ...
Zeigt denn der "Profile Performance and Memory..." verdächtige VIs an die viel Speicher brauchen oder geht nur der Speicherverbrauch der Applikation insgesamt nach oben? Das Speicherfreigabe anfordern wird dir afaik nur was bringen, wenn es "VI-Speicher" ist (und da bringt das nur _ganz_ selten etwas).
Hier die Lösung:
1. VI bei dem der Geisterabbruch auftritt öffnen
2. Alles kopieren
3. VI schließen und von der Festplatte löschen
4. Neues VI und Strg+V
5. Neues VI unter altem Namen speichern
Alles läuft, dank der vielen Speicherfreigaben habe ich jetzt keinen konstanten Speicher mehr. Er fällt regelmäßig um ca. 1MB und steigt dann kontinuierlich wieder an. Dann fällt er wieder. Also im Mittel über die Zeit dann doch wieder konstant. Ich denke ich nehme die Speicherfreigaben wieder raus. Und dann mal sehen, ob ich timed Loops nehme oder nicht. Wenn sie keine Probleme machen, finde ich sie ziemlich geil. Habe mir einen kleinen Loopadmin programmiert. Da registriert sich jede Loop wenn sie gestartet wird. Im Admin kann ich mir dann alles mögliche ansehen. Verspätete Beendigung, letzte Ausführung und Ausführungssdauer, ich kann einzelne Loops manuell beenden.
Naja, was ich jetzt da oben gezaubert habe? Keine Ahnung! Aber es geht und ich schiebe es einfach mal auf einen Bug im LabVIEW-Inneren! Danke an alle die mir geholfen haben! Habe dann auch tatsächlich wieder bissl was gelernt und kann jetzt nooooch besser debuggen als vorher.
Auf gehts zur nächsten Baustelle!
Grüße,
Totti
(06.06.2013 10:38 )TSchAC schrieb: [ -> ]Und dann mal sehen, ob ich timed Loops nehme oder nicht. Wenn sie keine Probleme machen, finde ich sie ziemlich geil. Habe mir einen kleinen Loopadmin programmiert. Da registriert sich jede Loop wenn sie gestartet wird. Im Admin kann ich mir dann alles mögliche ansehen. Verspätete Beendigung, letzte Ausführung und Ausführungssdauer, ich kann einzelne Loops manuell beenden.
Kleine Ergänzung, weil das gestern beim Anwendertreffen ein Thema war. Ich habe die Timed Loop auch ein bisschen missverstanden als "Beschleuniger" für gewisse Aufgaben...was aber so nicht stimmt...siehe hier:
http://digital.ni.com/public.nsf/allkb/F...9C001EB323
Außerdem war ne generelle Aussage: Nicht mehr Timed Loops in einer Applikation als man "Cores" hat...sonst müssen sich zwei oder mehr "zeitkritische" Loops evtl. einen Core teilen...
Gruß
Achim
Guter Artikel, nützliche Infos! ABER:
meine Projekte sind alles andere als zeitkritisch. Ich arbeite nicht im Millisekundentakt sondern meist im Sekundentakt manchmal sogar im Minutentakt. Die Ausführungsdauer eines Loops beträgt meist unter 10 ms. Da spielt es keine große Rolle, ob ein Kern mal grade belegt ist und ich ein paar ms warten muss, bis die Loop dann ran darf. Was Timed-Loops beschleunigen, ist der Programmieraufwand wenn man eben mehr will als nur eine Schleife die im Takt läuft. Und logisch, das kostet Zeit. Wie bei allen ExpressVIs: mit Vorsicht genießen, weil sie meist viel mächtiger sind, als man es eigentlich bräuchte.
Man muss also wirklich immer den Einzelfall betrachten denn es gibt Immer Ausnahmen und wenn man zumindest grob versteht, was man tut, bzw. was die TimedLoop tut, dann kann man auch mit den Negativen Aspekten Leben!
Mein Programm läuft übrigens immer noch unglaublich stabil! Traue mich gar nicht, es zu unterbrechen und weitere Module einzubauen!