Modulare Datenerfassung für Delphin Messkarte

Servus th13,

danke für die Tipps,

(20.06.2022 17:22 )th13 schrieb:  Der Suchbegriff für Goolge lautet Hardwareabstractionlayer (HAL) und da finden sich durchaus einige interessante und detailierte Beiträge.
Viele nutzen das ActorFramework für diesen Zweck, ich bin aber kein Freund davon. Auch zur Umsetzung mit DQMH gibt es Artikel, zb hier.

mit HAL habe ich mich noch nicht befasst, werde mir den Beitrag mal zu herzen nehmen. Aber ist das denn sinnvoll bei nicht wechselnder Hardware?

(20.06.2022 17:22 )th13 schrieb:  Sicher hat jeder, ... Die sind aber meist in größeres Toolset eingebetet und können nicht ohne weiteres extrahiert werden, ganz abgesehen davon, dass die meisten das für ihre Firmen entwickelt haben und nicht einfach rausgeben dürfen.

Mir ging es mehr um Tipps, Probleme auf die man stößt, Fehler die man vermeiden sollte oder andere Anmerkungen.
Da LabVIEW bei mir doch eher etwas nebenher ist und nicht meine Haupttätigkeit fehlt mir einfach die Erfahrung, auch wenn ich LabVIEW in der Zwischenzeit 11 Jahre verwende..

(20.06.2022 17:22 )th13 schrieb:  Mach es nicht zu kompliziert, ... Wenn du tatsächlich unterschiedliche Zykluszeiten hast, mach ein process.vi mit 4 paralellen Schleifen, in dem die SubVIs mit jeweils eigenem Timing aufgerufen werden.

Das ist ein großer Teil meiner Bedenken, ich mache es mir zu kompliziert
Wie kann ich mir ein process.vi vorstellen, 4 Schleifen die in eine (, 2 oder 4?) FGV schreiben, diese lese ich dann in einem QMH Modul und übergebe die Werte? oder lese ich lieber direkt die FGV? Vorallem mit "lose zu koppeln" im Hinterkopf.

(20.06.2022 17:22 )th13 schrieb:  Wenn du mehr als die eine Komponente hast oder später vermutlich haben wirst, kannst du über einen Manager nachdenken, der alle Komponenten verwaltet.
...
Wir verwenden Klassen .., die alle eine eigene process.vi haben und parallel laufen. Ein HardwareManager startet und initialisiert alle DAQ-Objekte, die Werte von der Hardware abholen (NI-Karte, Beckhoff usw) und sie via Event an einen ChannelManager senden, der diese auf Kanäle (physikalischer oder virtueller Sensor) schreibt. Jeder Kanal hat eine Skalierung und wenn ich einen Wert brauche rufe ich getValue() oder getMean() auf.

Bisher habe ich für jede Komponente (Messkarte; UUT; zusätzliche UART Sensoren) immer ein eigenes Modul, eben um es in anderen Systemen leicht einbinden zu können. So ist zumindest mein Plan auch für dieses neue Modul. Das wird jetzt aber deutlich größer und ich fühle mich bei der Planung sehr unsicher.
Quasi ist der (Hardware-)Manager dann ein eigener je Projekt und sammelt die Daten, skaliert und evtl. verrechnet schon Werte? Das klingt nach einer guten Idee, was triggert denn das Event um es weiterzusenden?

(20.06.2022 17:22 )th13 schrieb:  Wenn deine SW komplexer wird, musst du dir Gedanken über Nebenläufigkeit machen. Wenn du zB alle aktuellen Werte in einer Anlagenübersicht darstellen willst und parallel dazu im Prüfablauf mit aktuellen Sensorewerten arbeiten musst, kann readValue nicht mehr direkt mit der Komponente kommunizieren. Dann brauchst du ein process.vi dass die Werte abholt und zB in einer FGV speichert, readValue() gibt dann nur den aktuellen Wert zurück.

Bisher frage ich immer wieder ab, werde das mal im Hinterkopf behalten und beobachten ob es hier vielleicht zu viele Zugriffe/Abfragen gibt.

(20.06.2022 17:22 )th13 schrieb:  Wenn du Mittelwerte über eine Messung brauchst, muss das nicht jedesmal im Prüfablauf erfolgen. Über start/stopBuffering kann das die Komponente selber.

Das habe ich so ähnlich mal umgesetzt, der Hinweis mit dem buffer könnte das etwas vereinfachen.

Vielen Dank für die Tipps.
Nur unter dem Begriff 'process.vi' kann ich mir noch nicht so richtig etwas vorstellen.

MfG Timo