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!
28.09.2011, 14:59 (Dieser Beitrag wurde zuletzt bearbeitet: 28.09.2011 15:00 von gottfried.)
ich gehe im Kreis: ich muss eine Bildfolge mit 20fps (und schneller) abspeichern. Dabei laufen noch 2 Motoren, aus deren Position (serielle Kommunikation 115200Bd), und der Buffernummer baue ich einen String damit ich die Bilder später zu einem großen Bild zusammennageln kann.
OK technische Details: die Kamera ist getriggert (20Hz), wartet also auf den Impuls (profiler avg 0,8ms), dann lese ich die 2 Positionen aus (je profiler avg 0,4ms) - damit das gleichzeitig passiert via errorline vom getImage. Vom gewonnen Bild mache ich ein Extract (profiler avg 0,5ms) und schreibe das ganze via AVIWriteFrame (profiler avg 0,5ms). Bei allen drei Profiler Angaben is MAX 15,6ms.
Die Impules kommen (praktisch) vom ExampleFinder GenDigPulseTrain-Continuous.vi
Bei 20fps habe ich offensichtlich 50ms Zeit um die Daten zu holen und loszuwerden. Der Profiler meint ich brauche 2,2ms - habe also mächtig Zeit. Wenn ich den zeitlichen Abstand der Bilder untersuche habe ich bis zu 400ms Intervalle (selten aber immerhin). Diagramm: 50=Sollabstand
Ich habe schon versucht dem AVIWriteFrame eine höhere Priorität zu geben, das bringt nichts. Der Profiler meint auch nichts auffälliges zu den Buffern (27kB oder 61 Blocks ... na und)
Ich bin ratlos, ich brauche alle Bilder und nicht nur "die meisten". Ich habe auch schon das FP in die Taskleiste "geschickt" - besser aber nicht weg.
Das Blockdiagramm ist eines, das vom herumprobieren stark gelitten hat ...
Ohne die Details zu kennen...
Ich würde versuchen:
- File IO aus der Schleife zu entkoppeln.
- entfernen der Ausgangindizierungen, die sorgen für gelegentliche Speicherallokationen
- sind die VIs zu Positionsbestimmung reentrant (nicht shared)
- Platform in Frage stellen... ich vermute mal es handelt sich um Windows, da darf es schon manchmal etwas länger dauern. (ggf. mildert eine WindowsTask Prio > 10 das verhalten gut genug)
(28.09.2011 17:42 )macmarvin schrieb: - Platform in Frage stellen... ich vermute mal es handelt sich um Windows, da darf es schon manchmal etwas länger dauern. (ggf. mildert eine WindowsTask Prio > 10 das verhalten gut genug)
Wie macht man das? Übern Taskmanager händisch? Oder geht das gar aus dem LV Code heraus?
Mir sind zwei Varianten bekannt in LV Prioritäten zu setzen: 1) VI Eigenschaften 2) TimedLoops
Was ist da der Unterschied? Hat das eigentlich einen nennenswerten Effekt? Da bin ich irgendwie nie richtig dahinter gekommen ... Aus einigen Gesprächen mit dem NI Support hab ich immer zu hören bekommen: "LV ist auch nur ein Task unter Windows ... die Prioritätenvergabe in LV kann man sich schenken."
@Gottfried:
- Das ganze String bauen lässt sich bestimmt auch mit einem einzigen "In String formatieren" VI realisieren. Müsste eigentlich alles im Formatstring unterzukriegen sein.
- (hat nix mit dem Thema zu tun) Vergleiche nie Fließkommawerte auf Gleichheit!
Gruß
„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
die Autoindizierung ist leicht herauszunehmen, da kann ich vorher das Array initialisieren. Das FileIO aus der Schleife nehmen ist schwierig: das einzige was mir einfällt ist ein Image-Queue die ich mit einer zweiten Schleife wieder abarbeit. Aber das Verschicken von Bildern in der Queue muss als U8-2D-Array geschehen und brauch auch wieder dauernden Speicherallokieren - also das finde ich nicht erstrebenswert oder ich habe den Ansatz missverstanden.
Und jetzt brauche ich ein Nachhilfe: was ist der Unterschied zwischen reentrant und shared?
Vielen Dank
Gottfried
29.09.2011, 09:07 (Dieser Beitrag wurde zuletzt bearbeitet: 29.09.2011 09:11 von dimitri84.)
(29.09.2011 08:50 )gottfried schrieb: Und jetzt brauche ich ein Nachhilfe: was ist der Unterschied zwischen reentrant und shared?
shared: Das VI kann nur einmal gleichzeitig aufgerufen werden (zb FGV - eine globale Instanz)
reentrant: Es können mehrere Instanzen des selben VI aufgerufen werden. Es werden entsprechend Kopien angelegt.
(29.09.2011 08:50 )gottfried schrieb: Das FileIO aus der Schleife nehmen ist schwierig: das einzige was mir einfällt ist ein Image-Queue die ich mit einer zweiten Schleife wieder abarbeit. Aber das Verschicken von Bildern in der Queue muss als U8-2D-Array geschehen und brauch auch wieder dauernden Speicherallokieren - also das finde ich nicht erstrebenswert oder ich habe den Ansatz missverstanden.
Nein nicht dauernd. Die Queuegröße legst du doch am Anfang fest und hantierst anschließend nur mit den Referenzen.
Gruß
„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
(29.09.2011 08:50 )gottfried schrieb: Und jetzt brauche ich ein Nachhilfe: was ist der Unterschied zwischen reentrant und shared?
Reentrant sollten sie bei deinem Usecase eh sein.
Da gibt es dann noch die Möglichkeit "shared clones" und "preallocate clones" zu wählen. Ersteres kann zu erhöhtem Jitter führen. Siehe auch VI exection properties / reentrant
(28.09.2011 20:31 )dimitri84 schrieb: Wie macht man das? Übern Taskmanager händisch? Oder geht das gar aus dem LV Code heraus?
Zum Testen erstmal händisch, wenn es was bringt, dann über ein paar Windows .dll-aufrufe siehe Internet
> Nein nicht dauernd. Die Queuegröße legst du doch am Anfang fest
> und hantierst anschließend nur mit den Referenzen.
das ist ein "falscher Irrtum" ... oder? Wenn ich zum Bildaufnehmen immer die selbe Referenz verwende kann ich sie nicht in die Queue stellen da die selbe Referenz dann immer auf das selbe (letzte) Bild zeigt - das ist nicht ganz das was sich meines Vaters Sohn vorstellt.
Wenn ich immer eine neue Referenz aufmache (kein Problem) kann ich die Referenzen in die Queue stellen und sie "außen" abarbeiten und wieder löschen. Das macht aber auch mächtig viel Allokierungsstress - oder?
Das Abarbeiten von 5 Formatierungsaufrufen statt einem bringt m.E. nicht wirklich etwas - ist aber viel schöner - klar & stimmt.
Eine timed Loop würde ich gerne nehmen aber das Timing kommt von der Kamera und ich muss auf die Kamera warten.
Was mir erst jetzt auffällt: manchmal fehlt auch ein Frame ... wie denn das? offensichtlich kommt der Puls und das IO oder sonst etwas ist noch nicht fertig.
Jedenfalls bin ich mit meinem Latein am Ende - ich versuche noch ein nackes AVI-Aufnehmen mit 20fps getriggert. OK gemacht ... "Grab and Save to AVI" umgearbeitet auf dx mit 20fps also 20Hz Impulsfolge - was soll ich sagen, kein Problem. Nach 1000 Bildern: kein verlorener Buffer und das Timing war 50ms +/-4ms
Allokierung hin - Allokierung her. Parallelisierung kann nie schaden. Ich wette die Kiste auf dem das Programm läuft ist mindestens ein Dual-Core. Wenn du eine Schleife hast - läuft die auch auf einem Kern. Haste zwei kann der Compiler die Abarbeitung verteilen.
Alleine schon die Tatsache, dass es der erste Punkt ist, den macmarvin vorschlägt, würde mich zum blinden Ausprobieren veranlassen.
„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
