Anregungen für eine Debug Console für Kunden-Software

Hi,

ich möchte gerne für die neue Version einer Kunden-Software eine Debug Console einbauen.
Diese soll eingeblendet werden, wenn sich ein entsprechender Eintrag in der Registry befindet.
Ich suche Anregungen für die Erstellung dieser Bibliothek...

Idee:
+ Consolenfenster mit einfacher Textausgabe
+ Protokollierung in Textdatei
+ Bedienelemente (Start, Stop, Email, Exit)
- Start und Stop sind wohl klar
- Email -> Ruft den Standard Emailclient auf und hängt die Textdatei an und trägt die Emailadressse ein, mehr nicht
- Exit schließt das Consolen Fenster

   

Umsetzung (Idee):
+ Queue mit Namen (dann sollte diese Queue auch in anderen VIs zu finden sein, oder?)
Ich bin nur uneinig was den Elementdatentyp angeht, bisher einfach ein String.
Es sollen nicht nur Nachrichten etc. ausgegeben werden, sondern z.B. auch Inhalte von Variablen oder Arrays.
Es bleibt wohl nichts über, als dann die Inhalte von Variablen und Arrays entsprechend als String darzustellen.

Fragen dazu:
1.) Gibt es evtl. schon sowas? Ich konnte mit Google nichts finden, denn eine Suche mit "Debug" gibt immer Treffer
für das Debugging mit der Entwicklerumgebung, die aber ja nicht beim Kunden installiert ist.
2.) Ist der Datentyp String für die Queue hier sinnvoll? Was würdet Ihr nehmen? Cluster mit zusätzlichen Inhalten z.B. Error, Variant?
Eine Umwandlung der auszugebenen Daten in einen String ist wohl notwendig. Es geht auch um COM Events, Send/Received Strings etc.
3.) In LV2012 gibt es ein paar Beispiel-Projekte, z.B. "Kontinuierliche Messung und Protokollierung". Ok, hier werden Messdaten
erfasst, aber es geht um den prinzipiellen Aufbau. Wäre das eine mögliche Aufbauvariante oder ist das für eine
"einfache Debug Console" zu übertrieben.

Bin sehr interessiert an Euer Feedback... egal ob positiv oder negativ
Gruß
Stefan

Anzeige

Hallo Stefan,

ich habe mir für unsere Prüfstandssoftware eine "SysLog"-Bibliothek programmiert, die alle Statusmeldungen, die intern erzeugt werden, in einer Datei abspeichert und die letzten 100 Meldungen (o.ä.) für eine Anzeige in einer Queue bereithält. Die Meldungen werden über ein subVI in die Queue eingetragen, dieses subVI ist dann jeweils dort zu platzieren, wo man die Meldung absetzen will. (Ähnliche Konzepte sind auch bei NI.com im Entwicklerbereich zu finden. Stichwort wäre SystemLog; es gab auch mal einen Programmierwettbewerb, wo eine solche Bibliothek teilnahm.)
Ich verwende intern einen Cluster pro Meldung, um (u.a.) Timestamp, ErrorCode & Text zu speichern.

Dies würde deinem Konzept sehr ähnlich sein. Nur für das "Email senden" musst du dir selbst was überlegen, spontan würde mir nur einfallen, irgendwie über DotNet den Email-Standardclient aufzurufen...

Hallo Stefan,

bei uns läuft es auch über so ein "SystemLog"-File.
Als Hinweis fällt mir dabei noch ein: Vorsicht bei Datei(Schreib-)Operationen in zeitkritischen Algorithmen! Am besten nur asynchron auf das LogFile zugreifen, damit zur Not gepuffert wird. Aber das hast du ja quasi schon vorgesehen, wenn du eine Queue verwenden willst.

Hallo,

wir haben in unseren Applikationen Syslog implementiert (grundlegende VIs können über VI Package Manager installiert werden).
Vorteile:
- Es gibt fertige Software die diese Logs auswerten und darstellen kann
- Man kann leicht unterschiedliche Log Level implementieren (Debug, Error, ...)
- Je nach "Ort" im Quellcode kann man eine unterschiedliche Kennung zur Identifikation verwenden
- Es können mehrere Systeme mit einem Syslog-Server "überwacht" werden
- Der Log Server muss nicht auf dem gleichen System installiert sein wie die eigentliche Applikation

Ich verwende diesen Syslog Server: TFTPD32
Der Loggt die Meldungen in ein Textfile und stellt die Logs tabellarisch dar.

Du kannst natürlich auch in LabVIEW einen Syslog Server schreiben, der dir dann die Möglichkeit gibt auch den Log dann per Mail zu verschicken.

Grüße
Bastian

Also, erstmal vielen Dank an alle.
Das mit dem Syslog ist eine interessante Variante. Hatte mich bereits
nach den ersten Posts hier für eine TCP Variante entschieden, weil die
Console als unabhängige EXE laufen kann und von jeder meiner Software
angesprochen werden kann.

Ich habe meine Variante mal als LV2012 VIs gezippt angefügt. Ist natürlich
noch nicht fertig, aber vielleicht kann das ja jemand gebrauchen.
Feedback zu meiner Umsetzung ist natürlich gerne gesehen.

Zur Geschwindigkeit kann ich bisher sagen, dass ca. 300kB Daten in 600ms
übertragen werden, dass reicht für mich vollkommen aus. Das, was die Console
bremst, ist die ständige Aktualisierung des Ausgabestrings. Das habe ich durch
eine Zeitschleife begrenzt, was aus meiner Sicht so ok ist.

Gruß
Stefan

Guten Morgen,

das ist eine kleine und feine Implementierung. Laufen Debug-Console und Hauptprogramm immer auf dem selben Computer? (Weil keine IP/Hostname für TCP spezifiziert)
Erweitern ließe sich das durch mehr Struktur-Info im anzeigenden Element im MainVI, ich denke da an eine Tabelle, oder eine Funktion zum filtern von Error-Code oä.

jetzt werde ich mir mal diese Syslog-Geschichte anschauen...

Gruß

€dit: kleine Frage: welche Pakete meine ihr wenn ihr vom "Syslog" im VIPM redet? Ich finde keines das so oder ähnlich heißt. Meint ihr "Message Queue Library"?

(09.09.2013 09:05 )eb schrieb:  Laufen Debug-Console und Hauptprogramm immer auf dem selben Computer? (Weil keine IP/Hostname für TCP spezifiziert)

Du kannst natürlich auch IPs angeben, dann sollte das eigentlich auch an andere PCs übertragen werden.
Ich werde in unserer Kundensoftware beim Inizialisieren eine Option einfügen, ob unsere Debug Console
als EXE bereits läuft (also in der Taskliste gefunden wurde) und wenn ja wird der Debug-Output aktiviert.
Das ist für den Kunden am einfachsten, da er die Konsole einfach nur zuerst starten muss und dann
das eigentliche Programm. Immer an die DAUs denken :-)

Stefan