Schieberegister -> array-Kopie in jedem Durchlauf?

' schrieb:Die Betonung bei dieser richtigen Antwort liegt auf dem Wörtchen "selbst". Wenn nämlich der Inhalt des Schieberegisters bei jedem Durchlauf durch ein Sub-VI geschleußt wird, werden schon Kopien erzeugt.

Nicht notwendigerweise. LabVIEW ist da gar nicht so schlecht. Geschicktes Durchschleusen, auch durch ein SubVI, und es wird gar keine Kopie erzeugt.

Gruß, Jens

Anzeige

' schrieb:Optimal wäre natürlich, wenn der Compiler so clever wäre zu erkennen, daß das SubVI nur ein einziges Mal verwendet wird und er die Hierarche dann einebnet, so daß also der "Machinencode" gar keinen SubVI-Aufruf enthält.

Ja stimmt. Sofern das Debugging weiterhin so funktioniert, wie man es gewohnt ist, wäre das super.

' schrieb:OFFtopic zum Sonntag: Du bist ja noch gar noch so lange im LV-Forum, und bei Dir bin ich am meisten erstaunt über die Steilheit Deiner Lernkurve seit dieser Zeit. Wie hast Du das nur gemacht? Hattest Du vielleicht das Glück, daß Deine Firma Dir tausende von Euro für NI-Lehrgänge spendiert hat?

Danke.
Mit der LabVIEW-Programmierung habe ich erst im April 2010 angefangen. Ich habe begonnen, 2 Bücher durch zu arbeiten (parallel programmieren, nicht nur lesen), um die Grundlagen zu lernen.
Ich habe 2 Schulungen bekommen: "Core 2" (ist schon eine Weile her) und vor ein paar Wochen "Real-Time", da wir das in der Firma nun brauchen. Die Grundlagen beherrschte ich, weshalb die Schulung "Core 1" nicht nötig war. Von Core 2 wuste ich zwar auch ca. 75%, aber es gibt immer Dinge, die man noch nicht kannte.
Die Schulungen sind gut, um zu sehen, worauf man prinzipiell achten muss und was es gibt. Mehr Schulungen hatte ich nicht.

Dass ich in recht kurzer Zeit sehr viel gelernt habe liegt eher daran, dass ich fast den ganzen Tag mit LabVIEW arbeite und selbst Interesse an einem guten Programmierstil habe. Mein Ziel ist es, meinen Code wartungsfreundlich zu halten und daher suche ich immer nach Optimierungsmöglichkeiten etc. Da lernt man viel.
Sehr viel habe ich natürlich auch euch aktiven Mitgliedern aus dem LVF zu verdanken. Ohne euch wäre ich lange nicht so weit wie jetzt. Speziell den Einstieg habt ihr mir sehr erleichtert.

Da wir in der Firma einen netten Laborplatz haben, an dem ich experimentieren kann, macht das Ganze natürlich noch mehr Spaß, als alles nur theoretisch zu behandeln.

Die klassischen Programmiersprachen wie Delphi, C++, PHP, C# etc. programmiere ich übrigens schon lange. LabVIEW ist zwar schon anders, aber es gibt einige Gemeinsamkeiten. Von daher ist mir der Umstieg vielleicht nicht allzu schwer gefallen, auch wenn es Zeit benötigte, bis ich mich ans Datenflussprinzip und die Eigenheiten von LabVIEW gewöhnt habe.

Grüße
Matze

' schrieb:Melder und Queues funktionieren auf dem cRIO. Was viele jedoch nicht wissen: Diese sind nicht deterministisch.

Werden jedoch fortlaufend Messdaten von einer Schleife in eine andere übertragen, empfehle ich den Einsatz von Meldern und Queues nicht!
Hier sollte auf die RT-FIFOs zurückgegriffen werden.

Was ist da der Nachteil von Meldern und Queues? Overhead?

' schrieb:Geschicktes Durchschleusen, auch durch ein SubVI, und es wird gar keine Kopie erzeugt.

Gibt's da ein paar pauschale Tips auf die du achtest?


Gruß dimitri

Hallo

' schrieb:Was ist da der Nachteil von Meldern und Queues? Overhead?

Wie bereits geschrieben sind diese nicht deterministisch. Bei einer Windows-Anwendung ist das egal, aber da das Thema hier unter "Real-Time" steht, sollte man Melder und Queues nur dann einsetzen, wenn eine nicht-deterministische Ausführung akzeptiert werden kann.

Ich setze Melder auch auf einem cRIO ein, aber nur, wenn ich z.B. einer parallelen Schleife mitteilen möchte, dass nun Daten kommen, die gespeichert werden sollen. Daher ist es hier egal, wenn der Melder nicht deterministisch arbeitet, da das Speichern nie deterministisch sein kann.
Wenn ich fortlaufend mit parallelen Schleifen kommuniziere, läuft das bei mir ausschließlich über RT-FIFOs, auch wenn das recht aufwändig ist, sobald man verschiedene Daten wie Cluster austauscht.

Hat sich die Frage geklärt oder hast du etwas anderes gemeint?

' schrieb:Hat sich die Frage geklärt oder hast du etwas anderes gemeint?

Ok, jetzt musst ich doch so doof fragen:huh:Was heißt deterministisch in diesem Zusammenhang? Außerhalb der Informatik heißt es ja sowas wie "vorherbestimmt".

Was ist jetzt der Nachteil in einem RT-System, wenn man etwas vorher schon bekanntes (Messwerte werden auf jeden Fall gesendet), mit einer Methode versendet, die auch in Stande ist, nicht vorherbestimmt zu arbeiten?

' schrieb:Ok, jetzt musst ich doch so doof fragen:huh:Was heißt deterministisch in diesem Zusammenhang? Außerhalb der Informatik heißt es ja sowas wie "vorherbestimmt".

In der Informatik heißt es im Prinzip auch genau das: (zeitlich) vorherbestimmt.

Ist die Ausführung deterministisch, dann hast du einen bestimmten Zeitrahmen vorgegeben, der zum Ausführen benötigt wird (z.B. 1 - 2 ms). Und du weißt, dass die Ausführung immer 1 - 2 ms dauern wird.
Ist etwas nicht deterministisch, dann kann die Ausführung, je nach Umständen, auch länger dauern (muss es aber nicht).
D.h. in dem Moment bist du nicht echtzeitfähig, da die Ausführungszeit stark variieren kann.

In meinem angesprochenen Beispiel mit dem Dateizugriff ist es so, dass du nie genau weißt, wie lange das Schreiben in eine Datei benötigt. Daher sehe ich in diesem Fall keine Probleme, wenn Melder eingesetzt werden. Auf die paar Millisekunden hin oder her kommt's dann auch nicht an. Vielleicht handelt es sich auch nur um mehrere Mikrosekunden. Das hängt u.a. auch davon ab, was du in den Meldern überträgst. Bei großen Datenmengen (viele Messwerte) ist die Zeitspanne/Verzögerung größer als bei einem einzigen boolschen Wert.

Vielen Dank für die Antworten. Da waren eine ganze Reihe nützlicher Anregungen drin.

Zitat:Das Schieberegister selbst erzeugt keine Kopie. Das ist ja gerade der Vorteil eines SR (oder auch FeedbackNode). Wenn du mittendrin auch keine Kopien erzeugst (wonach es aussieht), ist alles ok.

Das mal eine Aussage.

Zitat:Wenn nämlich der Inhalt des Schieberegisters bei jedem Durchlauf durch ein Sub-VI geschleußt wird, werden schon Kopien erzeugt. Ich würde auf jeden Fall mal probieren, ob sich die Geschwindigkeit ändert, wenn man das bissel Zeugs im SubVI direkt im HauptVI macht.

Das auch.

Zitat:Nicht notwendigerweise. LabVIEW ist da gar nicht so schlecht. Geschicktes Durchschleusen, auch durch ein SubVI, und es wird gar keine Kopie erzeugt.

Hierzu wären nähere Infos wirklich interessant.


Funktionalität aus dem SubVI ins HauptVi zu portieren wollte ich gerne vermeiden, weil ich sonst erhebliche Übersichtlichkeitsprobleme befürchte. So eine Inline-Option wäre also super, aber wenn es die in der 2009er Version nicht gibt, bleibt das wohl nur ein Wunsch.


Könnte ich eigentlich auch den gesamten Ringspeicher mit RT-FIFOs machen? Also auf Arrays in diesem ZSH ganz verzichten?

Den Matlab-Skript-Knoten will ich auf jeden Fall drin lassen, wenn es irgendwie geht. Dieser Programm-Teil wird sich wahrscheinlich oft ändert und ich es viel flexibler finde, schnell neuen Code reinzuschreiben bzw. zu kopieren, als erst ein neues SubVIzu bauen, welches irgendwelche Berechnungen macht.

Auch wenn es ein anderes Thema ist: Wie kann man eigentlich rausbekommen, wie viel Rechenzeit der Matlab-Skript-Knoten konsumiert?


Danke,
Bastian.

Hallo

' schrieb:Könnte ich eigentlich auch den gesamten Ringspeicher mit RT-FIFOs machen? Also auf Arrays in diesem ZSH ganz verzichten?

Da ein FIFO ein Ringspeicher ist und sogar Arrays aufnehmen kann, ist das vermutlich möglich. Die Frage ist nur, was du davon hast.

' schrieb:Auch wenn es ein anderes Thema ist: Wie kann man eigentlich rausbekommen, wie viel Rechenzeit der Matlab-Skript-Knoten konsumiert?

Ganz allgemein so:

   

Das geht auf einem RT-System natürlich auch mit dem entsprechenden Express-VI, damit du den genaueren Hardware-Timer nutzen kannst.
Die Ausführungszeiten von ganzen SubVIs kannst du neben dem Real-Time Execution Trace Toolkit (falls vorhanden) auch über Extras -> Profile -> "Leistung und Speicher" ermitteln, zumindest die Größenordnung. Nur, falls dich das auch interessiert.

' schrieb:Auch wenn es ein anderes Thema ist: Wie kann man eigentlich rausbekommen, wie viel Rechenzeit der Matlab-Skript-Knoten konsumiert?

Hier haben wir ein Bsp, bei dem MathScript so richtig lahm ist gegenüber LabVIEW-Code:
http://www.labviewforum.de/index.php?sho...=18139&hl=

Also nach Möglichkeit wech damit.

Gruß, Jens