Modulare Datenerfassung für Delphin Messkarte

Servus Zusammen,

meine Technikerarbeit wird modernisiert (11 Jahre alte Anlage, Ventile werden getauscht und der Messbereich erweitert), dazu wird eine neue Software benötigt.
Fast alle unsere Anlagen verwenden eine Messkarte von Delphin, auch meine Technikerarbeit. Ich würde das gerne als (DQMH) Modul konzipieren, um die anderen Anlagen dann auch damit zu betreiben, jetzt hapert es aber bei der Planung und ich hoffe hier ein paar Tipps zu bekommen.

Ich bekomme von den Delphin VIs immer die aktuellen Werte als Array of Cluster (ein Cluster für jedes Signal), ich habe digital i/o (bool) und analog i/o (dbl).

Jetzt ringe ich mit mir selbst schon 'ne Woche ob ich alles (digital + analog, input + output) in einem Modul abarbeite oder ob ich das aufteile. Ich weiß einfach nicht welche Vor- bzw Nachteile das jeweils hat. Das lesen/schreiben sollte sehr schnell gehen, da es intern nur an eine dll geschickt wird, die mit einer Software auf dem PC direkt kommuniziert.
Die Outputs müssen nur bei Änderung geschrieben werden (wobei digital und analog unterschieden wird).
Die Inputs muss ich regelmäßig aktualisieren (alle 500 ms sollte reichen), da habe ich an eine Helper-Loop gedacht (DQMH).

Meine Idee bisher ist ein DQMH Modul für die Delphin Kommunikation
-welches dann evtl. Berechnungen macht
und auf 2 Module zugreift
-senden
Änderungen zuordnen und senden (gesendet werden immer alle Signale auf einmal)
-empfangen
über eine Helper-Loop konstant Daten abfragen
evtl Volumenstrom-/Impulsberechnung nebenher (1*)

Diese Aufteilung ist aber mehr für die Übersicht (auch der Programmcode innerhalb des DQMH Moduls) und ich sehe sonst keinen Nutzen.

Was habt Ihr so für Erfahrung dahingehend? (muss nicht Delacor sein).
Muss ich auf etwas achten, das mir bisher entfallen ist?
Allgemeine Tipps um soetwas besser/einfacher zu planen?
Verwendet Ihr Planungs-/Visualisierungstools für solche Planungen?

Ich bin für jeden Tipp Dankbar,
Timo

(1*) Um Volumenstrommesswerte zu erhalten verwenden wir Experimentier-(Balgen-)Gaszähler und Drehkolbengaszzähler, dort wird über die Impulse und Impulswertigkeit der Volumenstrom bestimmt. Frequenz ergibt Volumenstrom, hier gibt es aber eine Mindestimpulsanzahl. Die Frequenzmessung der Messkarte ist zu ungenau und die Messkarte steht auf Impulszählung, hier bekomme ich mit jedem abfragen die aktuelle Impulszahl mit Zeitstempel.

Hallo Timo,

Tipps zum Aufbau kann ich dir leider nicht geben, da bin ich zu wenig im Thema drin.

Bei der Planung schaue ich mittlerweile bei anderen Programmiersprachen, da man zu LV ja in dem Thema recht wenig findet.
Aktuell habe ich zu dem Thema noch nicht so viele Bücher gelesen, aber das Buch "Grundkurs Software-Engineering mit UML: Der pragmatische Weg zu erfolgreichen Softwareprojekten" von Stephan Kleuker fand ich ganz gut. Selbst wenn man nicht in OOP programmieren will, findet man dort echt gute Ansätze/Ideen um Projekte zu planen und Fehler früh zu finden.

Als Tool zur Planung habe ich mir StarUML angeschaut, schon recht umfangreich aber hier muss ich auch erst mal mit warm werden. Liegt aber auch daran, das ich noch nicht so super sattelfest mit UML bin.

Hoffe dies hilft dir ein Bisschen weiter.

Gruß Max

(14.06.2022 06:35 )MScz schrieb:  Bei der Planung schaue ich mittlerweile bei anderen Programmiersprachen, da man zu LV ja in dem Thema recht wenig findet.

.. aber das Buch "Grundkurs Software-Engineering mit UML: Der pragmatische Weg zu erfolgreichen Softwareprojekten" von Stephan Kleuker fand ich ganz gut. ..
.. ich mir StarUML angeschaut, schon recht umfangreich aber hier muss ich auch erst mal mit warm werden. ...

Danke Max, werde ich mir mal alles nach und nach anschauen.

Hat denn niemand ne Datenerfassung als Modul zum wiederverwenden? Ist das vielleicht sogar eine schlechte Idee? (Oder einfach nichts dazu zu sagen?)

MfG Timo

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...

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