Error 201133 beim Nutzen mehrerer Counter

Hallo allerseits!

Ich versuche nun vergeblich seit geraumer Zeit den Fehler 201133 aus meinem Programm zu tilgen.

Zuerst eine Beschreibung der Wirkweise des Programms, danach die verwendete Hardware.

Ein Polygon-Scanner (Sechseckiger, sich drehender Spiegel aus einem Laserdrucker), dreht sich mit einer bestimmten Frequenz, die durch einen Counter-Output(Frequenz) Task gesteuert wird.
Ein Laser bestrahlt besagten Spiegel. Dieser Laser pulst mithilfe eines Counter-Output(Time) Tasks. Die high-low-Zeiten verändern sich mit jedem Durchlauf, um im Endeffekt über den Polygon-Scanner mit dem Laser eine Zeile eines Schwarz-Weiß-Bildes zu schreiben. Zuvor wandelt nämlich ein Programmteil ein Bild Zeile für Zeile in einen Cluster aus einem 2xY, wobei Y durch das Bild gegeben ist, Array von high-low-Zeit-Paaren und einem Boolean, ob zuerst eine high- oder eine low-Zeit vorliegt, um.
Das Programm schaut quasi, ist da ein schwarzes Pixel? -> Wenn ja, wann kommt das nächste schwarze nach etwaig folgenden weißen -> und wandelt dieses Paar aus soundsovielen schwarzen Pixeln und soundsovielen weißen Pixeln in Pulszeiten für den Laser um. -> Dasselbe Prozedere, bis die Zeile zuende ist.
Des Weiteren liegt ein Start-of-Scan Task als Digital-Input(Digital Bool 1Line 1Point) Task vor, der das Signal eines Lichtsensors abgreift, der den Beginn einer neuen Zeile markiert.

Soweit zum Programm, was ich hoffentlich auch halbwegs im Main.vi weiterhin dokumentiert habe.

Als Hardware liegt ein NI cDAQ-9174 mit eingestecktem NI 9401 vor. Die verwendete Software ist Labview 2014 mit MAX 14.
Weiterhin werden zum Ausführen der VIs neben dem Plugin DAQmx noch das Plugin Vision Utilities benötigt.

Folgendes Problem tritt nun auf:

Das VI wird gestartet, man startet den Polygon-Scanner mit einem Klick auf "Start" des entsprechenden Panels. Daraufhin startet man den Laser-Puls-Channel in gleicher Weise. Es erscheint ein Pop-up, ob man ein gesamtes Bild schreiben möchte, oder aber eine einzelne Zeile in wiederholter Weise (Demozwecke: Stehende Linien an die Wand werfen.). Wählt man eines aus und klickt auf "Go", sollte der Laser-Pulser eigentlich loslegen.
An dieser Stelle tritt allerdings der Fehler 201133 (http://digital.ni.com/public.nsf/allkb/0...30007EFD17 ) auf.
Obwohl ich meines Erachtens nach wie auf der NI Seite beschrieben alle Tasks der Reihenfolge nach reserviere und den zuerst startenden offen lasse, meckert das Programm. :/
Als letztes versuchte ich, den Laser-Pulse-Task vorher zu "commit"en, wie ich aus der Hilfe zum Control Task VI heraus verstanden hatte. Dies funktionierte allerdings ebenfalls nicht.
Ich schätze, es liegt daran, dass ich den Task zwischendurch in der Schleife immer wieder stoppe und starte, um die Property Node aufrufen zu können?

Vielleicht ist noch zu erwähnen, dass dieser Fehler nur mit der realen Hardware auftritt. Nutze ich die von MAX simulierte Hardware mit derselben Konfiguration, erscheint keine Errormeldung.


Ich hoffe, das Problem ist genau genug beschrieben und warte freudig auf etwaige Lösungsansätze.

Mit freundlichen Grüßen


Benedikt

Anzeige

(15.12.2015 17:32 )BenNie schrieb:  An dieser Stelle tritt allerdings der Fehler 201133 (http://digital.ni.com/public.nsf/allkb/0...30007EFD17 ) auf.
Obwohl ich meines Erachtens nach wie auf der NI Seite beschrieben alle Tasks der Reihenfolge nach reserviere und den zuerst startenden offen lasse, meckert das Programm.

Genau das machst du eben nicht, deine 3 Tasks werden in willkürlicher Reihenfolge gestartet.

Gruß, Jens

Mmh, ungewöhnlich. Meine drei Tasks werden doch alle "quasi-gleichzeitig" erstellt. Also alle außerhalb irgendwelcher Schleifen, weswegen ich annahm, dass diese vor den Eintretenden Schleifen ausgeführt werden. Abgesehen davon startet der nicht reservierte Task ohne eine Schleife zu betreten, wohingegen die anderen Tasks eine Usereingabe benötigen, bevor sie gestartet werden.

Andererseits sehe ich gerade, dass das Programm keinerlei Grund hat, den SOS- und den Laser-Pulse-Task zu reservieren, bevor nicht die "rechteste" Schleife einen Dateninput bekommt. Ist das vielleicht genau das Problem?

Vorliegendes ist mein erstes Zusammentreffen mit LabView, sonst bisher nur textbasiert gecoded.^^

---

So, nochmal angeschaut, was ich da fabriziert habe. Wenn ich das richtig verstehe, sollte ich entweder alle Tasks zuallererst einmal wirklich geordnet wie im Error-Beispiel starten (das ändert ja an deren späteren Funktion nichts), oder ich probiere, den Polygon-Scanner-Task unreserviert zu lassen, da dieser als erstes ausgeführt würde, wenn LabView die anderen Tasks nicht anrührt, bis die "rechteste" Schleife Dateninput verlangt.

Da ich allerdings momentan die Hardware nicht zur Hand habe, muss ich die Tests wahrscheinlich bis nach Neujahr verschieben.

Bis dahin danke ich schonmal für die Anmerkung und wünsch' noch was


Grüße

Benedikt

Hallo nochmal!

Wie im Error-Beispiel der offiziellen NI Seite beschrieben, habe ich jetzt alle Tasks zunächst einmal mit einer Flat Sequence geordnet reserviert und gestartet.
Beim Ausführen des VIs scheint diese Vorgehensweise zunächst auch zu funktionieren. Da ich allerdings bei den Tasks zwischendurch noch einige Parameter ändern muss, stoppte ich die Tasks nach der Flat Sequence erstmal wieder.
Vermutlich liegt genau dort das Problem, dass später dann, beim erneuten Aufrufen der Tasks, wieder der besagte Error auftritt, richtig?

Ich denke allerdings nicht, dass ich die nötige Startreihenfolge anderweitig einhalten kann. Sieht vielleicht noch jemand eine andere Möglichkeit?


Grüße

Benedikt

Ein erneutes guten Tag allerseits!

Ich habe nun ein weiteres NI 9401 Modul zur Verfügung und mir stellt sich nun die Frage, ob das oben beschriebene Problem (tl-dr: Error 201133 bei gleichzeitigem IO auf verschiedenen nibbles und häufigem Starten/Stoppen der Tasks) sich umgehen ließe, wenn ich den einzigen Input-Task auf das zweite Gerät auslagerte. Dadurch befänden sich auf dem ersten Gerät allein zwei Output-Tasks, wodurch die nibbles nicht mehr separat konfiguriert bzw. reserviert werden müssten, richtig?


Grüße,


Benedikt