Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
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
13.10.2014, 12:02 (Dieser Beitrag wurde zuletzt bearbeitet: 13.10.2014 12:03 von GerdW.)
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…
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.
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.
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.
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.