Programm funktioniert nur im Debugmodus?

Hallo zusammen,

Mein Ziel ist die Datenerfassung über eine analoge Karte mit 8 Eingängen über ein RT-Crio.
Ich habe mir dazu das "getting started" beispiel kopiert, und wollte es dann anpassen. auf das erste problem stoße ich aber bereits, wenn ich in der RT-schleife mehr als 2 Eingänge der Karte abfrage -- die Schleife hört nach ein paar Durchläufen einfach auf. Ich habe selbstverständlich die Variable "Loopcom" erweitert, dass sie mit der doppelt so großen Datenmenge klarkommt und den Anzeigecase in der unteren Schleife habe ich auch geändert.
Ich habe auch versucht, Fehlermeldungen anzeigen zu lassen, aber anscheinend gibt es keine, das Anzeigeelement bleibt auf dem grünen Haken.
Jetzt das Seltsame:
Wenn ich den Debug/Highlightmodus aktiviere, und die Schleife ein paar Durchläufe gezwungen langsam machen lasse und dann auf schnell schalte, läuft das Programm einwandfrei!

Hat jmd. selbiges Problem schonmal gehabt, bzw. weiß eine Lösung dazu? Gibt es evtl. irgendwelche Dinge, die man beachten muss wenn man in RT-Schleifen auf Messkarten zugreift?

P.s. hab das ganze programm auch von einem anderen Rechner aus auf das Crio gespielt und ausgeführt -- gleiches Ergebnis.

Hallo Meggi,

1. Du kannst Bilder auch direkt anhängen (als PNG) und musst sie nicht erst in einem PDF verpacken...
2. Du fragst über die ScanEngine 4 Werte in einer Schleife ab, die mit 1000Hz laufen soll. Das ist schon grenzwertig (meiner Erfahrung nach)...

Was passiert, wenn du die Messschleife als "normale" While-Loop anlegst und dort ein Wait mit 1ms hineinpackst?

Trägt zwar nicht zur Lösung bei, ist aber trotzdem fragwürdig:
- Warum wird in jeder Iteration der Messschleife erneut ein Array mit 4 Elementen überschrieben? Warum nicht einfach BuildArray nutzen?

Hallo GerdW,

mein Ziel ist es, irgendwann die Daten in Echtzeit abzufragen, ich brauche eine Garantie, dass ich jede ms einen Satz Messwerte bekomme. mit einer normalen While-Schleife funktioniert das denke ich nicht oder?

Zum 2. Punkt:
Da habe ich mich auch schon gewundert, und habe es in einer anderen Variante auch durch "Builtarray"/"Array erstellen" ersetzt. Ursprünglich kommt das Programm ja aus der Beispielhilfe. Das funktioniert genauso, bzw. genauso nicht ;-)
Vermutlich ist das ersetzen schneller, da der Speicher schon reserviert ist und nicht neu zugewiesen werden muss..

Zu dem Punkt, dass 4 Messwerte grenzwertig sind für eine Frequenz von 1000Hz -- wenn ich ca. die ersten drei Schleifendurchläufe den Debugmodus anmache, funktioniert das programm danach auch einwandfrei OHNE Debugmodus.. Selbst Chuck Norris weiß bis jetzt nicht wieso..

P.s. Ich bin ein hilfloser Mac-User an einem Windows-PC, da finde ich es ja schon sehr bemerkenswert, dass ich es geschafft habe einen screenshot zu machen ;-) Das nächste Bild kommt dann auch als png oder jpg daher.

Hallo meggi,

Zitat:mein Ziel ist es, irgendwann die Daten in Echtzeit abzufragen, ich brauche eine Garantie, dass ich jede ms einen Satz Messwerte bekomme.

Was bedeutet bei dir "Echtzeit"? Die Garantie bekommst du, wenn du den FPGA selbst nutzt...

Zitat:mit einer normalen While-Schleife funktioniert das denke ich nicht oder?

Die Frage ist eher, ob alle anderen Komponenten mitspielen:
- ist dein AI-Modul überhaupt schnell genug?
- ist die ScanEngine schnell genug?
- ist das cRIO schnell genug und nicht mit anderem "Zeugs" ausgelastet?
Wie schon gesagt: Sampleraten von 4kHz sind mit der ScanEngine grenzwertig...

Zum 2. Punkt:
Das Ersetzen in einem Array ist dem BuildArray üblicherweise vorzuziehen (aus Performance- und Resourcengründen). Aber in deinem gezeigten Bild ist es einfach "RubeGoldberg": in jeder Iteration wird das von InitArray bereitgestellte Array mit neuen Messwerten beschrieben, ohne dass das Array danach weiterverwendet wird - z.B. mit einem Schieberegister. Deshalb meine Anmerkung: nimm dort doch einfach BuildArray...

Zitat:wenn ich ca. die ersten drei Schleifendurchläufe den Debugmodus anmache, funktioniert das programm danach auch einwandfrei OHNE Debugmodus.

Dann programmiere das doch ganz einfach: die ersten 3 Iterationen mit einem Schleifentakt von 1000ms, danach dann mit einem Takt von 1ms laufen lassen. Die TWL bietet doch entsprechende In-/Out-Knoten an...

Zitat:P.s. Ich bin ein hilfloser Mac-User an einem Windows-PC, da finde ich es ja schon sehr bemerkenswert, dass ich es geschafft habe einen screenshot zu machen ;-)

Auch an einem MAC könntest du dir die LabVIEW-Hilfe zum Thema "Snippets" durchlesen und danach anwenden. Kein Grund, über evtl. nicht vorhandene OS-Tools (oder eine ungewohnte Arbeitsumgebung) zu sinnieren...

Das CRio unterstützt meines Wissens nach auch Echtzeit-Schleifen... Die FPGA-Programmierung ist aufwändiger und in manchen Punkten schwieriger umzusetzen, deswegen wollte ich das erst einmal umgehen.

Zu dem Built-Array: Wie gesagt in meinem normalen Programm ist das auch mit einem Builtarray gemacht, der Screenshot ist aus einem eben leicht modifizierten Beispielprogramm, das ich genommen habe um mein Problem möglichst einfach zu schildern.

Das mit dem Verlangsamen probiere ich morgen gleich mal aus.
Allerdings kann das ja nicht die einzige Lösung sein..
Wenn ich übrigens das CRio das erste Mal connecte und dann das VI das erste Mal draufspiele, läuft das Programm einwandfrei.
Meine Vermutung ist, dass das Problem irgendwie mit den Variableneinstellungen von Loopcom zusammenhängt.. gibt es dazu evtl. irgendwo eine Hilfe? In der Labview-Hilfe habe ich nicht sonderlich viel gefunden(was natürlich auch an mir liegen kann).

P.s. Mein P.s. war nicht besonders ernst gemeint...

4 kHz mit der Scan-Engine? Mich würde mal interessieren, ob deine Schleife dann tatsächlich alle 1 ms läuft...
Meiner Erfahrung nach schaffe ich mit der Scan Engine nichtmal 50 Hz stabil sobald da noch ne PID o.ä. drin ist.

Anzeige

NI selbst nennt ungefähr 1kHz als Grenze. Je nach Anwendungsfall kann auch mehr gehen. Ich selbst habe seit Jahren stabil im Einsatz 500 Hz. Die TWL kann dir sagen ob sie den Zyklus gehalten hat. Also ausprogrammieren und dann schauen ob es hinkommt.