Rechendauer reduzieren, um Abtestrate von 1/s sicherzustellen

Hallo liebe Community,

ich bin noch ein Labview Neuling und habe von meinem Semesterarbeits-Vorgänger eine erstellte Labview-Datei erhalten, die auch funktioniert. (Siehe Screenshot)
   

In der For-Schleife werden die Signale zu einem Array zusammengefasst usw... Allerdings steigt mit laufender Laufzeit die Rechendauer meines gesamten Programmes, sodass die Abtastrate der Messignale und somit die Schreibe-Rate in meinem Excel-Dokument auf unter 1 Messpunkt pro Sekunde rutscht. Die Rechendauer wurde im Frontpanel implementiert, daher meine Erkenntnis bzgl. der Rechendauer.

Nun ist meine Frage, wie ich vermeiden kann, dass die Rechendauer exponentiell nach ca. 60s ansteigt.

Eine erste Idee aus einem anderen Forumsbeitrag war folgende: Die For-Schleife soll nur noch die Signalquellen und das zusammenführen des Arrays beinhalten. (Siehe Screenshot 2) Allerdings wird mir dann nur noch der letzte Eintrag des Arrays verarbeitet, das nur noch ein virtuelles Kanal gebildet wird. Also funktioniert das wohl auch nicht.

   

Es wäre super wenn ihr mir da helfen könntet.
Ob ihr auf eine Verbesserung zum Programm meines Vorgängers eingeht oder die Idee von mir passend verbessert, wäre mir egal! :-)

Liebe Grüße,
Michi

Anzeige

Hallo Michi,

das ist immer noch die gleiche (unsinnige) Routine wie in deinem letzten Thread?
Edit: Dieser letzte Thread war im NI-Forum - bitte immer selbst auf Crosspostings hinweisen!

Wieso muss man einen einzelnen Messwert auf ein Array mit anscheinend 12×(30+31)=732 Samples aufblasen???
Statt irgendwelche Folgefehler zu suchen, solltest du gleich am Start deines VIs aufräumen!
Allgemeiner Tipp: InsertIntoArray ist meist falsch verwendet, insbesondere bei Problemen wie deinem.

Außerdem: Anhand eines Bildes, welches nur einen kleinen Ausschnitt deines Programmcodes zeigt, lässt sich ein Problem meist nur schlecht bis gar nicht beheben. Warum hängst du kein VI an?

Hallo Michi,
kurze Anmerkung zum oberen Bild.
Die For-Schleife ist sinnlos, den sie wird immer nur den letzten Wert des Arrays ausgeben.
Warum also ein Array, dass nicht verwendet wird.

Gruß
Freddy

Hallo GerdW,

alles klar, ab jetzt immer auf Crosspostings hinweisen! Danke!

Das VI ist sehr groß und sehr unübersichtlich - ich denke die Code-Qualität wird auch nicht sehr hoch sein. Ich habe keine Zeit das aufzuräumen, ich möchte möglichst nur meinen Fehler behandeln. Aber anbei das angesprochene VI.

Zu deiner Frage: Es ist so, dass zu jedem Modul eine Kaltstellentemperatur ausgegeben wird. Meiner Meinung nach wird jede Kaltstellenspannung hintereinander in diesen Array geschrieben. Die Kaltstellentemperatur wird anschließend in eine Spannung umgewandelt. Diese Kaltstellenspannung wird danach in 732 Zellen des Arrays geschrieben, um diese Spannung zu den anderen 732 Spannungen zu addieren. Ich habe nämlich 732 Thermoelemente.
Geht das auch einfacher/kompakter/mit weniger Rechenaufwand?

Ich habe leider keine Fachkenntnisse bzgl. Signalen, Sensoren, etc. Mir wurde lediglich aufgetragen, das Problem bzgl. der Rechendauer bzw. der Abtastrate zu lösen. Dementsprechend hoffe ich auf einfache Lösungsvorschläge - ich bezweifel allerdings, dass das möglich ist.

@Freddy: Danke für deine Antwort! Ich glaube allerdings, dass die For-Schleife in dem nächsthöheren Struktur doch mehr als nur den letzten Wert ausgibt. Ich erhalte denke ich mehr als 1 Signal.

Das VI ist angehängt - ich wäre bei weiterer sehr sehr dankbar :-)

LG Michi


  Prozessleitsystem_Packungskolonne_DN600 - Update 02.08.19 - FFaktor in Formelknoten.vi (Größe: 1,01 MB / Downloads: 257)

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.

Hallo GerdW,

danke für die Kritik - ich habe nun viele SubVI eingefügt und alles soweit komprimiert, dass das Programm nun fast auf einen 24 Zoll Bildschirm auf einem Blick zu sehen ist.

Könntest du mir evtl. Tipps geben, wie ich nun zur Bereinigung meiner Problemchen fortfahren soll?

Viele Grüße,
Michi

Anzeige

Hallo Kaibe,

Zitat:Könntest du mir evtl. Tipps geben, wie ich nun zur Bereinigung meiner Problemchen fortfahren soll?

Was fällt als erstes auf: man entpackt ein ZIP und findet keine Projektdatei.
Was fällt als zweites auf: es ist für den unbedarften Betrachter kein VI als "MAIN" erkennbar. Also raten…

Dann öffnet man dieses "Umbau"-VI:
- lauter subVIs ohne aussagekräftiges Icon
- immer noch fehlende subVIs mit nicht aussagekräftigen Namen wie "A" und "C"…


Dann öffnet man mal das erste subVI und findet das hier:
   
Oben deine Version, unten meine Version des VIs: bei deiner Version mit nicht initialisiertem Schieberegister bekommst du bei wiederholtem Start deines Programms sehr schnell Probleme!

Deshalb:
Bitte alle VIs mit kritischem Blick durchgehen und nach den ganzen weiteren Fehlern und Rube-Goldbergs suchen und korrigieren.
Projektdatei erstellen.
Vernünftige Icons und VI-Namen verwenden. Dann im MAIN-VI die ganzen subVI-Namen wieder ausblenden, die belegen nur unnütz Platz!
Lerne den Unterschied zwischen Label und Caption bei einem Control: Labels mit gefüllt 100 Zeichen Länge sind auch sehr unübersichtlich! Und Ausblenden des Labels im Blockdiagramm ist dann auch nicht wirklich hilfreich!

Hallo Gerd,

danke für deine Antwort. Das Projekt ist erstellt und nach und nach suche ich die Rube-Goldbergs und bessere sie aus.

Kannst du dir in etwa vorstellen, wo die Rechenzeit vor allem verschwinden könnte? Bei einer Messzeit von 120 sek bekomme ich lediglich 93 Abfragen hin. Nach 120 sek liegen im Arbeitsspeicher bereits 1,5 GB. Woran könnte das liegen?

Du hast das rechte Ende meines Main-VI mal angesprochen - daran etwa?
Zitat von dir: '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?' --> Wie kann man das besser umsetzen?

Tut mir leid, dass ich mich zur zeit nicht viel mit diesem Thema beschäftigen kann, zur Zeit fahre ich nämlich Versuche mit der schlechten Software und hab deshalb zu wenig Zeit.
BTW: Ich muss das VI alle 120 sek neu ausführen - nerv...

Hallo Kaibe,

Zitat:Kannst du dir in etwa vorstellen, wo die Rechenzeit vor allem verschwinden könnte? Bei einer Messzeit von 120 sek bekomme ich lediglich 93 Abfragen hin. Nach 120 sek liegen im Arbeitsspeicher bereits 1,5 GB. Woran könnte das liegen?

An zu vielen Datenkopien im Speicher (aufgrund duplizierten Codes)?

Zitat:Du hast das rechte Ende meines Main-VI mal angesprochen - daran etwa?
Zitat von dir: '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?' --> Wie kann man das besser umsetzen?

Das könnte einer der Gründe sein. Die Umsetzung habe ich doch beschrieben: als subVI mit einem zusätzlichen Parameter als Input…

Zitat:Tut mir leid, dass ich mich zur zeit nicht viel mit diesem Thema beschäftigen kann, zur Zeit fahre ich nämlich Versuche mit der schlechten Software und hab deshalb zu wenig Zeit.

Ich habe für dein Programm auch keine Zeit…

Hallo Gerd,

danke für deine weiteren Anstöße.

Allerdings habe ich mein Main-VI mal nach und nach komplett ausgeschlachtet: Sprich zuerst den großen rechten Teil, der 12-mal aufgerufen wird. Danach alle Schieberegister, die dummerweise unendlich groß wurden, da der Array jede Sekunde mit den aktuellen Werten ergänzt wurden. Danach alle Features die mit Zeit zu tun haben. Am Ende funktionierte weder noch die Messwertaufzeichnung noch alle anderen Graphen und Anzeigeelemente, dennoch lief das Programm - aber dennoch zu langsam.

Somit würde ich das alles ausschließen. Folglich würde nur noch die Signalabfrage in Frage kommen. (oder?)

Oder denkst du es ist möglich, dass wir das falsche Equipment haben?

LG Michi