Konfigurationsdaten verwalten

Hallo Zusammen,

ich arbeite gerade an einer Messsoftware die über einen Multimeter Temperaturdaten von Thermoelementen empfängt und aufzeichnet. Da das Program schon existiert, der Programmierer jedoch nicht mehr verfügbar ist, ist es meine Aufgabe das Programm zu verbessern.
In diesem Programm kann man die Kanäle für die einzelnen Thermoelemente konfigurieren, d.h. Namen, Sensortyp, Range, Einheit usw. Im Augenblick wird das so gelöst: Es wird zuerst die Datenbank ausgelesen, anschließend werden die Daten in eine Sub-VI reingeschrieben, teilweise über Schieberegister weitergegeben und anschließend wieder in die Datenbank reingeschrieben.

Gibt es denn hier eine schönere Lösung, denn ich finde das eigentlich recht unübersichtlich und schwer zum handhaben. Mir würde da als erstes das reinschreiben in Queues einfallen. Ist das eine sinnvolle Möglichkeit?

Anzeige

Lad' doch mal Dein(e) VI(s) hoch.

Gruß Markus

Hallo Markus, das Programm besteht aus insgesamt 193 VIs, das wird ein bißchen schwierig werden. Ich versuche mal ein paar Screenshots von den entsprechenden Stellen zu machen.

Hallo mez,

Zitat:In diesem Programm kann man die Kanäle für die einzelnen Thermoelemente konfigurieren, d.h. Namen, Sensortyp, Range, Einheit usw. Im Augenblick wird das so gelöst: Es wird zuerst die Datenbank ausgelesen, anschließend werden die Daten in eine Sub-VI reingeschrieben, teilweise über Schieberegister weitergegeben und anschließend wieder in die Datenbank reingeschrieben.

Worum geht es dir hier eigentlich? Der Thread heißt "Konfigdaten verwalten" - das scheint das Programm ja ganz anständig zu machen, wenn man jeden Kanal über eine DB konfigurieren kann. In deiner Frage ist mir nicht ganz klar, warum die Konfigdaten wieder in die DB zurückgeschrieben werden - aber diesen Punkt wirst du eher erforschen können...

Zitat:Gibt es denn hier eine schönere Lösung

Definiere "schöner"!
Die Lösung mit einer DB ist doch prima. Was erwartest du (oder deine User) hier? Ich habe das gleiche Problem über eine Excel-Datei gelöst. war halt Wunsch/Erwartungshaltung der User. Grundsätzlich gilt aber: irgendwo musst du die Daten ablegen/speichern, ob nun lokal in einer Datei (egal welches Format) oder serverseitig (?) in einer DB. Dein Programm muss diese Daten einlesen/abfragen können und intern weiterverwenden. Das "subVI mit Schieberegistern" dürfte wohl eine FGV sein - auch das bekommt von mir immer Zustimmung.

Zitat:denn ich finde das eigentlich recht unübersichtlich und schwer zum handhaben.

Dann denke dir ein übersichtlicheres und leichter zu handhabendes Konzept aus! Noch einmal: definiere "schöner"...

Hallo Zusammen,

leider ist es mir auch nicht gestattet screenshots raufzuladen .

Dass ich mich mit dem Programm auseinandersetzen muss, ist mir klar. Ich hätte nur gerne gewusst, welchen Weg man hier optimalerweise geht, wenn man das neu programmieren würde. Denn das Programm hier läuft alles andere als stabil und gut. Wenn man sich nicht an eine genau vorgeschriebene Reihenfolge hält, kann es schnell zu einem Absturz führen. Es werden an bestimmten Stellen Daten geladen, wo nicht auf Anhieb ersichtlich ist warum und woher diese Daten kommen. Mein Ziel ist es einfach nur die Komplexität dieses Programmes soweit wie möglich zu nehmen so dass das Programm stabil läuft. Und hierzu wollte ich wissen, was der normale Weg ist, um solchen Konfigurationsdaten zu verwalten. Denn hier sind mMn mehrere Wege auf einmal realisiert worden, was das Programm nur schwer lesbar macht, und bei der Ausführung die Stabilität massiv drunter leiden muss.

Hallo mez,

Zitat:Ich hätte nur gerne gewusst, welchen Weg man hier optimalerweise geht, wenn man das neu programmieren würde.

Normalerweise setzt man sich mit dem Kunden oder Projektleiter zusammen und schreibt die Anforderungen an das Programm auf. In deinem Fall: wo und in welchem Format sollen die Konfig-Daten gespeichert sein.
Dann (und erst dann!) setzt du dich hin und programmierst die dafür nötigen Funktionen: Daten einlesen, intern (in einer FGV?) speichern, in allen nötigen Routinen auf diese Daten zugreifen...

Du zäumst dagegen das Pferd von hinten auf: du willst ein Programm, dessen Funktionsweise du nur ansatzweise verstehst, "aufräumen" bzw. "verschönern". Das ist mMn nicht sinnvoll...

Anzeige

(12.08.2013 09:42 )GerdW schrieb:  Dann (und erst dann!) setzt du dich hin und programmierst die dafür nötigen Funktionen: Daten einlesen, intern (in einer FGV?) speichern, in allen nötigen Routinen auf diese Daten zugreifen...

Ergänzung: Das FGV mit Methoden zum Einlesen und Speichern der Konfig-Daten auf der HDD ausrüsten.

Den Weg den ihr beschreibt halte ich ebenfalls für den richtigen Weg. Wenn ich allerdings ein Programm welches von einem anderen Programmierer geschrieben wurde, und ohne Doku daherkommt, vorgesetzt bekomme, dann habe ich nicht sehr viele Möglichkeiten. Trotzdem danke für die Ratschläge, da muss ich mich jetzt eben durchbeißen.

@jg: Hast du evtl. ein Beispiel für so eine Funktionale Globale Variable? Habe mir jetzt schon etwas gebaut was ganz gut funktioniert, aber ich bin mir sicher dass es noch optimiert werden kann ;-)

Hallo mez,

eine FGV ist ja beispielsweise nichts anderes, als eine einmal durchlaufende Schleife, in der ein/mehrere uninitialisierte Shiftregister Daten in jeglicher Form zur "Arbeitsspeicherlebenszeit" des Vis in dem sich diese Schleife befindet, vorhalten bzw. speichen kann/können.

Also quasi sowas wie angehängt:


Gruß, Marko