Parallele Datenaufnahme, Erz-Verbr verbraucht irgendwann nicht mehr

Hallo kix,

Zitat:1. Im Realtime-Mode ignoriert die C-Loop das letzte Element, welches durch die zweite Queue-Bedingung (Element einfügen bei Stop) eingefügt wird. Im Highlight-Mode klappt das. Ich vermute, dass im RT-Mode die Stopinfo zur C-Loop gelangt, bevor diese das letzte Element "anfasst", und somit die Queue "überschreibt". Kann man das beheben?

Realtime-Mode bedeutet wohl "normale Ausführung": Du zerstörst die Queue in der P-Loop. Dann ist sie auch, mitsamt aller noch enthaltenene Elemente, weg - die C-Loop hat schlicht nichts mehr zum Lesen...

Zitat:Ich habe in der P-Loop die Weitergabe von Elementen in die Queue geändert, sodass die Elemente ans ENDE der Queue gegeben werden (und in der C-Loop vorne abgenommen werden). Ich hoffte, dadurch die C-Loop dazu zu bringen, die Queue vollständig abzuarbeiten, auch wenn die P-Loop stoppt.

Du fügst nicht am Ende, sondern am Anfang ein. Die Funktion heißt "Element am Anfang einfügen"... Deine Hoffnung trügt, dies löst nicht das Problem, s.o.!

Anzeige

Hallo Gerd,
Danke für die schnelle Antwort!

(19.07.2012 10:58 )GerdW schrieb:  Realtime-Mode bedeutet wohl "normale Ausführung": Du zerstörst die Queue in der P-Loop. Dann ist sie auch, mitsamt aller noch enthaltenene Elemente, weg - die C-Loop hat schlicht nichts mehr zum Lesen...

Verdammt...
Wenn ich den "Release Queue" (hinter der P-Loop) stattdessen hinter die C-Loop setze, könnte das das Problem beheben? Dann zerstör ich bei einer Stopbedingung nichts und die C-Loop kann zuende laufen (und zerstört erst dann die Queue)?

Zitat:Du fügst nicht am Ende, sondern am Anfang ein. Die Funktion heißt "Element am Anfang einfügen"... Deine Hoffnung trügt, dies löst nicht das Problem, s.o.!

Hm, ja. Hab ich aufm LV-PC (mit Netzwerk, ohne Inet) bereits korrigiert, offenbar ohne sie hier zu updaten.


Hast du vielleicht eine Idee zu meinem 2. Punkt? Der bringt mich zugegebenermaßen mehr zum verzweifeln.

Danke+Gruß,
Niels

Hallo kix,

leider fehlen die ganzen subVIs, um das genauer zu beurteilen.

Wo stockt es denn? Wie lange stockt es? Immer oder nur sporadisch? Es fehlen Informationen...

(19.07.2012 11:55 )GerdW schrieb:  Hallo kix,

leider fehlen die ganzen subVIs, um das genauer zu beurteilen.

Wo stockt es denn? Wie lange stockt es? Immer oder nur sporadisch? Es fehlen Informationen...

Hallo Gerd,

Die SubVIs sind im Eingangspost (wurden nicht verändert).

Der Motor stockt (nachvollziehbar) alle 50 Schritte, bei der die Stopbedingungen geprüft werden und die For-Loop neu gestartet wird.
Es stockt (auch nachvollziehbar) alle 200 Schritte, wenn die Motorposition aus der P-Loop in die Queue gegeben wird.
Es stockt aber auch übermäßig stark (nicht nachvollziehbar), wenn die C-Loop arbeitet, also Berechnungen durchgeführt werden, Graphen dargestellt werden, etc. Gut zu sehen am FP: wenn die Graphen neue Messpunkte erhalten, hört man den Motor stocken. Mit nahezu leerer C-Loop passiert das nicht, es liegt also (mMn) an dem Arbeitsaufwand in der C-Loop.
So wie ich das verstanden habe, soll die P-Loop unabhängig von der C-Loop arbeiten, sie tut es aber offensichtlich nicht.
Keine Ahnung, ob das am etwas älteren PC liegt (2,4GHz Celeron, 2GB Ram), glaube ich jedoch nicht.
Mein Wunsch wäre es, wenn die P-Loop vollkommen unabhängig und "flüssig" läuft, also quasi auf höchster Prio, während die C-Loop sich durchaus etwas Zeit lassen darf - Graph-Updates dürfen durchaus >1s brauchen.

(19.07.2012 12:23 )kiX schrieb:  Mein Wunsch wäre es, wenn die P-Loop vollkommen unabhängig und "flüssig" läuft, also quasi auf höchster Prio, während die C-Loop sich durchaus etwas Zeit lassen darf - Graph-Updates dürfen durchaus >1s brauchen.

Hallo kiX

Du könntest mal versuchen die beiden Schleifen in jeweils ein SubVI zu packen und beim SubVI mit der Steuerung unter "File->Vi Properties->Category:Execution->Priority" auf "Time critical (highest)" setzten und sehen ob das was hilft.

Gruss Marc