Tasks streaming

Hallo zusammen,

in letzter Zeit kommt es ab und zu vor, dass mein Programm zur Steuerung eines Prüfstandes abstürzt.
Ursache hierfür scheint die Datenkommunikation mit dem cDaq-9188 bzw. DIO NI 9375 zu sein. Nach dem Abbruch ist
die Kommunikation mit den Drucksensoren NI 9237 unterbrochen. Zumindest ist das die erste Fehlermeldung die mir das Programm anzeigt.
Ein Neustart des 9188 ist notwendig.
Ich habe für jeden einzelnen I/O Kanal einen Task im MAX angelegt.
Im Hauptprogramm, welches auf Queued Messanger Handler basiert, ändere ich den Zustand nur durch ein schreiben oder lesen des Tasks. siehe "Kanal schreiben"
Es fand in Vergangenheit kein Starten oder Beenden der I/O Tasks statt.
Die Kanäle der Drucksensoren sind grundsätzlich anders und auch sauberer aufgebaut. Ansprechen, Konfigurieren, Kalibriertabelle einlesen.............starten........stoppen und löschen
Zurück zu den I/Os!
Mittlerweile weis ich auch, dass ist nicht so sauber Programmiert. Hat aber nie Probleme gegeben.
"Never cange a running system"
Jetzt würde ich das gerne besser machen und würde eure Meinung dazu wissen.
Das ganze wird ziemlich unübersichtlich wenn ich für jeden Task ein eigenen Datenstrang anlege.
Wenn ich zu Beginn über eine For-Schleife gehe kann ich jeden Task starten. Soweit ganz gut. siehe "Tasks starten"
Wenn ich jetzt einen Kanal schreiben möchte, muss ich ihn aus dem Array entfernen und ändern.
Frage: Muss ich ihn dann auch wieder in das Array zurückführen?
Da ich mehrerer Queues habe (mehrere NVS) ist das beenden der Tasks auch wieder so ne Sache.
Frage: Würde es reichen, alle Tasks beim Beenden in einer Nachrichtenverarbeitungsschleife zu beenden?


Grüße Fuchs

Anzeige

Hi...ich mache immer einen Task pro Richtung...z.B. 1x DI, 1x DO, 1x AI
Und in jedem dieser Tasks werden n Kanäle definiert.
Der Task wird 1x gestartet und 1x beendet....halt immer dann wenn er gebraucht wird.

Die Tasks laufen asynchron neben dem eigentlichen Programmablauf, und die Werte hole und sende ich über Queues.

Gruß
A.

Hallo Achim,

starten und beenden wenn benötigt ist doch für Dinge die bei jeder Interation abgefragt werden auch nicht im Sinne des Erfinders, oder?
Für Aktionen die nur zu bestimmten Zeiten oder durch eine andere Aktion ausgelöst werden evtl. ok.

Wie separierst du den entsprechenden Kanal in der Queue? Wird der Datenstrang im Ablauf unterbrochen?
Klar werden die Kanäle in den Speicher geladen und man kann sie einfach aufrufen. Das ist ja das was ich Programmiert habe.
Ich würde gerne wissen ob das eine "Geht schon so - Lösung" ist oder ist es besser den Datenstrang nicht zu unterbrechen.


VG Fuchs

(17.03.2026 11:32 )Fuchs schrieb:  starten und beenden wenn benötigt ist doch für Dinge die bei jeder Interation abgefragt werden auch nicht im Sinne des Erfinders, oder?

Ich habe nichts über die Häufigkeit gesagt! Wenn benötigt, bleiben sie "an"

(17.03.2026 11:32 )Fuchs schrieb:  Wie separierst du den entsprechenden Kanal in der Queue? Wird der Datenstrang im Ablauf unterbrochen?

Mehrere Kanäle sind ein Array of Waveforms.

Hallo Fuchs,

Zitat:Wie separierst du den entsprechenden Kanal in der Queue? Wird der Datenstrang im Ablauf unterbrochen?

Bleiben wir beim Beispiel der DO-Channels:
- Du hast einen DO-Task, der alle Channels beinhaltet.
- Du hast einen QMH, der sich um diesen Task kümmert.
- Du schickst dem QMH eine Message, in der du den Wert eines Channels angibst.
- Der QMH hat eine Tabelle, mit der er den Channel-Namen in eine Channel-Nummer umsetzt und das entsprechende Bit im DO-Task aktualisiert.
- Der QMH hält intern den aktuellen Zustand aller DOs.

Das gleiche Prinzip kannst du für alle anderen Tasks anwenden…

(Jedenfalls solltest du weniger FGVs, locals, etc. einsetzen.)

(17.03.2026 15:40 )GerdW schrieb:  - Der QMH hat eine Tabelle, mit der er den Channel-Namen in eine Channel-Nummer umsetzt und das entsprechende Bit im DO-Task aktualisiert.
- Der QMH hält intern den aktuellen Zustand aller DOs.

Ergänzung: Ich bau mir für die Kanäle ein TypeDef-Enum zum entnehmen der Tabelleninhalte...da hab ich jeweils im Programm schön den Klartext des Kanals, somit selbstdokumentierend und leicht zu handhaben.

A.

Hallo Achim,

Zitat:Ergänzung: Ich bau mir für die Kanäle ein TypeDef-Enum zum entnehmen der Tabelleninhalte...da hab ich jeweils im Programm schön den Klartext des Kanals, somit selbstdokumentierend und leicht zu handhaben.

Das funktioniert, solange man einen festen Aufbau automatisiert.
Bei einem variablen Prüfstand wird man solche Zuordnungen eher in eine (wie auch immer verwaltete) Konfigurationsdatei auslagern…

- DOs/AOs waren bei meinen Anwendungen eher fest verdrahtet, da ging es mehr darum, den Namen des Kanals anzupassen.
- AIs waren deutlich variabler, da wurde öfter mal ein anderer Sensor mit anderem Kanalnamen verbaut. Und da fängt die Konfiguration erst an: Skalierungen, Kalibrierungen, Einheiten, …

@Fuchs:
Tipp aus meiner Erfahrung: verwende ein festes (und dokumentiertes) Namensschema für alle Aufbauten. Deine Kollegen werden es dir danken, wenn sie anhand des Kanalnamens sofort wissen, wo der Sensor/Aktor im System eingreift…

Danke für eure Antworten.
Ich werde versuchen eure Anregungen umzusetzen, obwohl mir noch das Verständnis fehlt wie ich Tasks in einem QMH verarbeiten soll?
In erster Linie werde ich die Tasks nacheinander abarbeiten.
Ich werde die Anzahl der Nachrichtenverabeitungsschleifen reduzieren.

(18.03.2026 14:37 )Fuchs schrieb:  Danke für eure Antworten.
Ich werde versuchen eure Anregungen umzusetzen, obwohl mir noch das Verständnis fehlt wie ich Tasks in einem QMH verarbeiten soll?

Die Tasks laufen parallel/asynchron in separaten VIs, und bekommen von außen Kommandos...Config...Start...Stopp...Initialize...Measure (Collect values)...was immer du willst...z.B. über Queues...das sind also ebenfalls eigene QMH's...und melden ebenfalls ihren Status zurück an die "Haupt-QMH-Schleife"...z.B. dass diese erst gestoppt wird, wenn alle parallelen Schleifen fertig sind.

Wenn's etwas "advanced" sein soll, dann könntest du dich mal mit dem DQMH-Toolkit befassen.
https://dqmh.org/

A.

(17.03.2026 09:31 )Achim schrieb:  Hi...ich mache immer einen Task pro Richtung...z.B. 1x DI, 1x DO, 1x AI
Und in jedem dieser Tasks werden n Kanäle definiert.
Der Task wird 1x gestartet und 1x beendet....halt immer dann wenn er gebraucht wird.

Die Tasks laufen asynchron neben dem eigentlichen Programmablauf, und die Werte hole und sende ich über Queues.

Das funktioniert aber man muss aufpassen. Typisch benötigt jeder Task mindestens einen Counter auf der Backplane. Bei bestimmten Counter IO Modulen kann das sogar mehr sein, je nach gewählter Counter-Operation. Und die meisten cDAQ chassis haben nur 4 Counters (ich glaube eines hat 5 aber bin mir nicht mehr sicher). Das heisst bei 4 Tasks ist es meistens Schluss.