LabVIEWForum.de - 3D Plot aus einem 2d-Array ist zu langsam

LabVIEWForum.de

Normale Version: 3D Plot aus einem 2d-Array ist zu langsam
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2
Hallo zusammen,

mit Hilfe einer 3D Kamera lese ich ein 2d-Array in mit 50x64 Pixel in Labview ein. Die Taktzeit der Schleife beträgt ca. 0,2s. Jetzt möchte ich aus dem Array eine Dreidimensionale Darstellung haben. Wenn ich aber einen 3D- Plot hinzufüge, verlangsamt sich die die Auswertungstaktzeit auf 0,9s. Dadurch erhalte ich ein stotterndes Bild. Kann ich irgendwie den 3D Plot beschleunigen ?


Danke
Hallo Ostfalia,

die Frage ist nicht, wie du das Anzeigeelement beschleunigst…

Wenn du Datenerfassung und -Auswertung voneinander entkoppeln willst, solltest du mit Queues und einem Producer-Consumer-Schema arbeiten. Wenn die Anzeige der Daten eher nachrangig ist, kannst du statt einer Queue auch einen Notifier verwenden…
Moin,

eine Lösung habe ich nicht, aber ein paar Tipps die vielleicht weiter helfen:

- Aktuell scheinst Du das laufende VI einfach abzubrechen. Stattdessen lieber eine Stop-Taste mit dem Bedingungs-Anschluß der Hauptscheleife verbinden. (F-Konstante löschen, rechten Mausklick auf roten Punkt und "create control" bzw. das deutsche Pendant wählen.)
- Beim TCP/IP-Teil ist es sinnvoller (und schneller) die Verbindung vor der Schleife aufzubauen, während der Schleife nur die Daten zu senden bzw. zu empfangen, und die Verbindung erst nach Beendigung der Schleife zu beenden.

Dann zum "eigentlichen" Problem, der 3-D-Darstellung. Hier würde ich erstmal irgendein Dummy-Array verwenden. Im einfachsten Fall die "Gesamtes Array"-Anzeige nach einem ersten Durchlauf in ein Bedienelement (oder Konstante) umwandeln und alles vor/in den For-Schleifen testweise löschen. Ebenso alles "oberhalb" der 3d-Sachen.

Ich habe das mal mit Zufallswerten für ein 50x64-Array ausprobiert und komme damit auf etwa 83ms pro Durchgang. Das scheint also nicht das begrenzende Element zu sein. Eher vermute ich, dass die TCP/IP-Geschichte durch die geringe Verzögerung in einem anderen Rhythmus läuft und deshalb deutlich mehr Zeit benötigt. Abhilfe: siehe oben.

Die nächste Optimierung wäre dann, Datenerfassung und Anzeige in zwei getrennten Schleifen zu machen und diese per Notifier oder Queue zu verbinden.

Hth
Danke erstmal für die schnelle Antwort,

wenn ich den Verbindungsteil die TCP/IP - Verbindung außerhalb der Schleife setzte, erhalte ich keine Daten mehr. Es erscheint dann der Fehler(62). Das mit den getrennten Schleifen(Notifier oder Queues) schaue ich mir gleich mal an.
Eine Kleinigkeit: Beim ersten 3D-ActiveX Graphen hast du 3D-Hardware-Beschleunigung nicht aktiviert.

Und das mit Open-TCP vor der Schleife und Close nach der Schleife muss eigentlich funktionieren, zeig mal, was du da verschoben hast...

Gruß, Jens
Hier die Änderungen
Spontan sieht die TCP/IP-Geschichte Okay aus. An welcher Stelle tritt der Fehler denn genau auf? Und passiert es bei der ersten Schleifenausführung oder "irgendwann" später?
(Einfach ein Anzeigeelement an Schleifenindex. Dann siehst Du wo das Programm "stehenbleibt".)

Ggf. mal die braunen Error-Leitungen (vorübergehend) auftrennen. Dann poppt der Fehler inkl. Quelle unmittelbar auf.
Der Fehler tritt beim zweiten Schleifendurchlauf auf und entsteht beim TCP write Baustein.
Hmmm, der Debugging-Modus dürfte ausreichend langsam sein, so dass ein Timing-Problem unwahrscheinlich ist. Könnte es sein, dass es an der Gegenstelle liegt und z.B. die Verbindung von dort beendet wird?

Vielleicht kannst Du ja den Befehl mit einem Terminalprogramm, Telnet o.ä. zweimal schicken und gucken ob es da funktioniert.
Weiß nicht was ein Terminalprogramm ist. Kannst du mir ein Beispielprogramm senden ?
Seiten: 1 2
Referenz-URLs