Modulare Datenerfassung für Delphin Messkarte

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.

(14.06.2022 10:49 )TpunktN schrieb:  Hat denn niemand ne Datenerfassung als Modul zum wiederverwenden?

Sicher hat jeder, der schon länger größere Projekte entwickelt, sich eine mehr oder weniger große Bibliothek oder gar ein ganzes Framework angelegt, wie in jeder anderen Sprache auch. 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.

(14.06.2022 10:49 )TpunktN schrieb:  Ist das vielleicht sogar eine schlechte Idee?

Nein, ganz und gar nicht. Dein Konzept klingt doch schon sehr überlegt. Mach es nicht zu kompliziert, wenn du die Trennung der AI/AO/DI/DO erst mal nicht brauchst und alles sauber in ein VI passt, dann lass es weg. 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. Innerhalb der Komponente sollte DQMH nicht nötig sein. Betrachte ein DQMH-Modul eher als komplette eigenständige Komponente, die du starten/stoppen kannst.

Versuch deine Komponenten lose zu koppeln, d.h. wenig Abhängigkeiten zu anderen Teilen des Codes. Wenn im Prüfablauf ein Wert deiner Delphin-Komponente gebraucht wird, soll ein einfaches

Code:

d = getDelphinCom()
v = d.readValue()

reichen. Wenn du mehr als die eine Komponente hast oder später vermutlich haben wirst, kannst du über einen Manager nachdenken, der alle Komponenten verwaltet.

Unterschiedliche Komponenten sollten trotzdem gleich aufgebaut sein, also alle habe ein init(), dass beim Start die Kommunikation aufbaut, ein readValue usw.
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. Wenn du Mittelwerte über eine Messung brauchst, muss das nicht jedesmal im Prüfablauf erfolgen. Über start/stopBuffering kann das die Komponente selber.

Wir verwenden Klassen (G# Framework), 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.

(14.06.2022 10:49 )TpunktN schrieb:  Oder einfach nichts dazu zu sagen?

Es ist Urlaubszeit...