Rechendauer reduzieren, um Abtestrate von 1/s sicherzustellen

Hallo Kaibe,

Zitat:Das VI ist sehr groß und sehr unübersichtlich

Ja.
Zu groß. Eindeutig!
Zu unübersichtlich!

Zitat:ich denke die Code-Qualität wird auch nicht sehr hoch sein.

Nein.
Vieles viel zu kompliziert.
Viel zu wenig Struktur in deinem Code…

Zitat:Ich habe keine Zeit das aufzuräumen, ich möchte möglichst nur meinen Fehler behandeln.

Leider ist das eine wohl an das andere gekoppelt - aber wenn du nicht willst oder kannst…

Zu deinem bisher gezeigten Code-Ausschnitt - den könnte man z.B. so vereinfachen:
   
Die "25" an der FOR-Loop habe ich nur gelassen, damit man mal schnell die Anzahl der Kanäle limitieren kann.
Das ganze gehört dann auch in ein subVI…
(Die gezeigte Vereinfachung wird dein Problem nicht lösen.)

Zu deinem ganzen großen VI:
Vieles deutet auf eine Statemachine-Struktur hin, z.B. diese ganzen Sequenzen. Erstelle aus den einzelnen Frames einzelne klar definierte States, die man dann abarbeitet.
Erstelle mehr subVIs für dedizierte Aufgaben, siehe Bild oben.
Und ersetze diese ganzen Rube-Goldbergs durch "vernünftigen" Code, wie z.B. Pfad-Funktionen für Pfade statt String zu bearbeiten…
Warum muss man Code 12mal duplizieren (letzter Frame!), um alle Graphen zu erzeugen? Warum nicht ein subVI, welches man eben 12mal aufruft - mit nur einem unterschiedlichen Parameter als Input?
Vermeide gestapelte Sequenzen, die sind ganz schlecht für die Übersicht.
Vermeide vor allem die Funktion InsertIntoArray: die wird bei dir IMMER falsch verwendet! Nimm BuildArray!
Ständig DAQmxTasks zu starten und gleich wieder zu beenden ist nicht sinnvoll - hier dürfte einiges deiner Rechenzeit versenkt werden…
Ganz häßlich sind fehlende Labels an Terminals im Blockdiagramm: wie willst du hier jemals vernünftig lesbaren Code erzeugen?
Ich mag auch keine FormulaNodes, wenn es dafür fertige VIs gibt - siehe Bild…
Noch vieles mehr!
Versuche ExpressVIs (wie MergeSignal) zu meiden.