Werte "Kollegen",
wir haben bei uns in einem "Langzeitschrank" folgendes Problem.
- wir messen kontinuierlich
- schreiben die Messdaten (ca. 360 Messwerte) in eine .txt
- nach 17.2MB stoppt die Protokollierung
- Programm läuft weiter, ohne Fehlermeldung
- es wird nur nichts mehr in die .txt geschrieben
Jemand nen Tip oder ne Idee?
Ich häng mal noch nen Ausschnitt eines Protokolls an, damit ihr die Log-Intervalle seht.
Hallo Scoop,
Zitat:- Programm läuft weiter, ohne Fehlermeldung
- es wird nur nichts mehr in die .txt geschrieben
Jemand nen Tip oder ne Idee?
Wenn es wirklich keine Fehlermeldung gibt: was hat das Debugging ergeben?
Wird das gezeigte subVI überhaupt noch aufgerufen?
Warum muss man die Datei ständig öffnen/schließen?
Ist jemand parallel damit beschäftigt, diese Datei zu öffnen/bearbeiten? (Was allerdings Fehler in deinem subVI provozieren sollte…)
Zitat:Wenn es wirklich keine Fehlermeldung gibt: was hat das Debugging ergeben?
- aktuell läuft auf dem System nur eine .exe, wo sich die Fehlersuche schwierig gestaltet, ist leider ein Programm von einem früheren Mitarbeiter
- Das Programm versuch ich gerade zu analysieren. die erste halbe stunde läuft es "tadellos". ABer wie gesagt der Fehler tritt immer zur selben Zeit auf und der PC hängt auch nicht im Intranet.
- 17.2MB
- oder 8206 Zeilen
- oder nach 545h Programmlaufzeit
Zitat:Wird das gezeigte subVI überhaupt noch aufgerufen?
- ja muss es. das läuft alles in ner while schleife: messen-speichern
Zitat:Warum muss man die Datei ständig öffnen/schließen?
Ist jemand parallel damit beschäftigt, diese Datei zu öffnen/bearbeiten? (Was allerdings Fehler in deinem subVI provozieren sollte…)
- ja da wird zwischen drin immer mal ins Protokoll gekuckt, wie du siehst, das läuft alles mit sehr großen Zeitintervallen
Bei meiner Firma haben wir mit ähnlich gelagerten Konstrukten früher schon gesamte Festplatten vollgeschrieben, das waren am Ende zig GByte große Textdateien, die sich mit keinem Text-Editor mehr öffnen ließen. An deinem Programm-Ausschnitt dürfte das Problem also eher nicht liegen.
Wenn ihr diese *.txt Datei auch nur mit einem Text-Editor öffnet, dann sollten auch keine Zugriffsprobleme auftreten. Aus meiner Erfahrung erzeugen Programme wie Notepad++ oder der Windows-Texteditor keine Zugriffssperre auf eine Textdatei, so wie es z.B. Excel oder Word machen würden.
Da muss IMHO eine andere Ursache in deinem Programm versteckt sein...
Gruß, Jens
Das mit dem Zeitintervall ist so eine Sache.
Wenn ich es richtig verstanden habe werden alle 10 Minuten große Mengen an Daten inner halb von Sekunden in eine Textdatei geschrieben.
Textdateien sind dafür als Datenspeicherung nicht geeignet.
Aber wenn es doch sein muss, dann solltest Du in Deinem Programm dafür sorgen, dass keine Datenüberschwemmung stattfindet.
Ich würde die Speicherung in ein eigenes Queue legen um immer die Zeit für die Speicherung zu haben.
So macht es auch nichts, wenn zuviel auf einmal kommt.
Mehr kann man nur sagen, wenn man das gesamte VI sieht.
Gruß
Freddy
Danke Jens
Danke Freddy
Das Programm umschreiben, wird nix, das ist alt, schlecht programmiert und sieht aus wie die typischen "so-nicht"-Beispielbilder, die Zeit hab ich leider nicht... Dachte die Fehlersuche gestaltet sich leichter.
Naja vielleicht stoß ich ja noch auf DEN "bug" oder jemand hat noch nen Einfall.
Aber vielen Dank allen Beteiligten
(18.05.2020 12:28 )Freddy schrieb: [ -> ]Das mit dem Zeitintervall ist so eine Sache.
Wenn ich es richtig verstanden habe werden alle 10 Minuten große Mengen an Daten inner halb von Sekunden in eine Textdatei geschrieben.
Textdateien sind dafür als Datenspeicherung nicht geeignet.
Aber wenn es doch sein muss, dann solltest Du in Deinem Programm dafür sorgen, dass keine Datenüberschwemmung stattfindet.
Ich würde die Speicherung in ein eigenes Queue legen um immer die Zeit für die Speicherung zu haben.
So macht es auch nichts, wenn zuviel auf einmal kommt.
Mehr kann man nur sagen, wenn man das gesamte VI sieht.
Gruß
Freddy
Achso, das Zeitintervall ist sehr flexibel, je nach Auftrags-Parametern. Das Programm springt von messen jedoch in Speichern und läuft erst weiter wenn der Befehl abgearbeitet ist. Das ist zwar schlecht programmiert, aber in dem Fall heißt das es gibt keinen Stau, da das Programm ja normal weiter läuft auch nach Wochen noch.
Hallo Scoop,
Zitat: ABer wie gesagt der Fehler tritt immer zur selben Zeit auf und der PC hängt auch nicht im Intranet.
- 17.2MB
- oder 8206 Zeilen
- oder nach 545h Programmlaufzeit
Das gibt folgende Möglichkeiten:
Festplatte o.ä. kaputt und die Datei wird deshalb nicht größer als 17.2MB: sehr unwahrscheinlich…
Festplatte o.ä. kaputt und die Datei wird deshalb nicht größer als 8206 Zeilen: sehr unwahrscheinlich…
Ein Programmierfehler, der an einer Zeiterfassung nach 545h Laufzeit scheitert: möglich, aber mangels VI nicht weiter spezifizierbar…
Zitat: ja da wird zwischen drin immer mal ins Protokoll gekuckt, wie du siehst, das läuft alles mit sehr großen Zeitintervallen
Was passiert, wenn man diesen Punkt mal verhindert?
Womit wird in das Protokoll geguckt?
Zitat:Wenn ich es richtig verstanden habe werden alle 10 Minuten große Mengen an Daten inner halb von Sekunden in eine Textdatei geschrieben.
Das halte ich für weniger relevant: es werden ja wohl nur 5 Zeilen mit zusammen weniger als 10kB geschrieben. "Große Menge" ist was anderes…
Leider darf ich keine Programmteile hoch laden, aber ich hab mal zwei screenshots gemacht
Hallo Scoop,
woher weißt du, dass kein Fehler auftritt, wenn es in der Protokollschleife keine sinnvolle Fehlerbehandlung gibt?
Ansonsten: viel zu viele lokale Variablen, viel zu viele Sequenzrahmen. Ja, das ist schlechter Programmierstil…
Zitat:Was passiert, wenn man diesen Punkt mal verhindert?
- genau das selbe. das Programm lief jetzt einen Monat ohne jeglichen Zugriff, leider fehlen nun die Daten
Zitat:Womit wird in das Protokoll geguckt?
- Notepad++
Zitat:Wenn ich es richtig verstanden habe werden alle 10 Minuten große Mengen an Daten inner halb von Sekunden in eine Textdatei geschrieben.
Das halte ich für weniger relevant: es werden ja wohl nur 5 Zeilen mit zusammen weniger als 10kB geschrieben. "Große Menge" ist was anderes…
- seh ich genauso
Zitat:woher weißt du, dass kein Fehler auftritt, wenn es in der Protokollschleife keine sinnvolle Fehlerbehandlung gibt?
- weil beim Programm beenden, der Fehlerstrang ausgegeben wird
Zitat:Ansonsten: viel zu viele lokale Variablen, viel zu viele Sequenzrahmen. Ja, das ist schlechter Programmierstil…
- sag ich ja
