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!
bei der Erstellung eines recht aufwändigen VIs in LV 6.1 tauchen leider Probleme auf. Das VI dient der Messwerterfassung eines 4-kanaligen Messgeräts via serieller Schnittstelle. Ziel ist, die Kanäle separat mit unterschiedlicher Frequenz abzufragen. Für einen Kanal klappt das wunderbar. Die Verarbeitung der Benutzereingaben erfolgt in einer ersten Schleife, die Abfrage der seriellen Schnittstelle mittels VISA (s. Anhang) in einer zweiten Schleife, in einer dritten Schleife werden die Messwerte kontinuierlich zwischengespeichert. Alle Schleifen laufen unabhängig voneinander, zwischen den einzelnen Schleifen werden Informationen mittels queues ausgetauscht.
Nachdem das recht aufwändige VI für den ersten Kanal nun fertig ist, wollte ich den kompletten Code nun einfach kopieren, um so die Abfrage des zweiten Kanals zu realisieren. Im Wesentlichen muss anschließend nur der write-String für die Abfrage der seriellen Schnittstelle sowie der Pfad der Datei zum Zwischenspeichern geändert werden. Nach dem Kopieren stürzt Labview jedoch stets ab, sobald das VI ausgeführt wird. Teils werden noch Fehlermeldungen bzgl. fehlgeschlagener read- oder written-Vorgänge angezeigt (LabVIEW.exe - Fehler in Anwendung: "Die Anweisung in "0x7c9208f3" verweist auf Speicher in "0x005c003f". Der Vorgang "written" konnte nicht auf dem Speicher durchgeführt werden. Klicken Sie "OK", um das Programm zu beenden. Klicken Sie auf "Abbrechen", um das Programm zu debuggen.)
Wo liegt hier der Fehler? Wie gesagt: Für einen Kanal läuft das VI wunderbar; erst, wenn ich den Code kopiere, tauchen die Fehler auf. Dürfen die VISA-Funktionen mehrfach vorhanden sein? Müssen die Wartezeiten in den einzelnen Schleifen differieren? Wäre für einen Hinweis dankbar, da mir LV noch ziemlich neu ist.
ich kenn mich jetzt mit den VISA - Knoten nicht wirklich gut aus. Ich kann mir aber vorstellen, dass es bei dem doppelten Öffnen des VISA-Ports zu einem Fehler kommen könnte. Versuch mal den Port nur einmal zu öffnen und die Schritte, die darauf folgen einfach kopieren und parallel in das VI reinlegen.
Dann musst du aber auch noch am Ende dafür sorgen, dass der Kanal erst geschlossen wird, wenn beide "Sequenzen" abgearbeitet sind. Das kannst du zum Beispiel durch verwenden des Errorwires und zusammenführen des Errorwire nach dem read/write erzielen.
Hoffe, dass du damit was anfangen kannst.
Carsten hat recht. Die Visa Resource kannst Du nur einmal öffnen.
Wenn der duplizierte Code das erneut versucht gibt es einen Fehler.
Dein Code wäre geradezu prädestiniert für eine Action Engine.
So etwas ähnliches habe ich neulich auch für eine Kommunikation mit einem externen Gerät programmiert.
Die Action Engine sorgt für die Initialisierung, Datenempfang, Daten senden und Freigabe der Resourcen.
vielen Dank für Eure Antworten. Der Fehler entstand, wie Ihr schon geschrieben habt, tatsächlich durch das mehrfache Öffnen der VISA-Ressource. Nachdem ich diese nun nur noch einmal öffne, tritt der Fehler nicht mehr auf.
Allerdings habe ich jetzt das Problem, dass, sobald ich mehr als 2 Kanäle abfrage, die abgefragten Messwerte zum Teil falschen Kanälen zugeordnet werden. Ich mache es ja jetzt so, dass ich die VISA-Ressource einmal global öffne, und dann für jeden Kanal in einer separaten Schleife den Messwert abfrage. Angenommen, ich frage einmal Kanal 1 ab, indem ich zunächst mittels VISA-Write den Abfragebefehl ans Messgerät schicke und anschließend mittels VISA-Read den Messwert lese. Dann - so meine Vermutung - wird wohl zwischen diesen beiden Befehlen der VISA-Read Befehl von Kanal 2 ausgeführt und der angefragte Messwert von Kanal 1 irrtümlicherweise Kanal 2 zugeordnet. Gibt es eine Möglichkeit, dieses "Dazwischenfunken" zu verhindern? Müsste man dafür die Abfrage der einzelnen Kanäle nicht in separaten Schleifen durchführen, sondern sequentiell in einer einzigen Schleife?
Außerdem hab ich keine Ahnung, welchen Wert ich als Read-Bytes der VISA-Read-Funktion verwenden muss. Mir ist nur bekannt, dass das Messgerät 8 Datenbits und einen Stoppbit verwendet. Trial-and-error hat ergeben, dass bei weniger als 9 Read-Bytes der empfangene String abgeschnitten wird. Aber gibt es allgemein eine Möglichkeit herauszufinden, welche Anzahl an Read-Bytes einzustellen ist?
@Andreas:
Vielen Dank für den Hinweis mit der action machine. Ich schau mir das gerade mal im Detail an: Du nutzt einen Eigenschaftsknoten, um die Anzahl der am Port vorhandenen Bytes auszulesen. Falls bei "open" welche vorhanden sind, löschst Du diese (wieso?). Bei "aquire" liest Du ebenfalls die Anzahl der Bytes am Port aus, und falls diese einen Grenzwert erreichen, führst Du VISA-Read aus und akquirierst die Daten. Ist es nach jedem VISA-Read-Befehl nicht notwendig, die Bytes am Port zu löschen oder geschieht das automatisch? Bevor Du VISA-Close ausführst, löschst Du ebenfalls nochmals alle Bytes am Port. Ist das zwingend notwendig?
Danke und viele Grüße
Tim
16.04.2012, 08:09 (Dieser Beitrag wurde zuletzt bearbeitet: 16.04.2012 08:11 von A.Berndsen.)
(14.04.2012 07:49 )Tintin schrieb: Ich mache es ja jetzt so, dass ich die VISA-Ressource einmal global öffne, und dann für jeden Kanal in einer separaten Schleife den Messwert abfrage. Angenommen, ich frage einmal Kanal 1 ab, indem ich zunächst mittels VISA-Write den Abfragebefehl ans Messgerät schicke und anschließend mittels VISA-Read den Messwert lese. Dann - so meine Vermutung - wird wohl zwischen diesen beiden Befehlen der VISA-Read Befehl von Kanal 2 ausgeführt und der angefragte Messwert von Kanal 1 irrtümlicherweise Kanal 2 zugeordnet. Gibt es eine Möglichkeit, dieses "Dazwischenfunken" zu verhindern? Müsste man dafür die Abfrage der einzelnen Kanäle nicht in separaten Schleifen durchführen, sondern sequentiell in einer einzigen Schleife?
Wenn Du an unterschiedlichen Stellen im Programm auf die Serielle Schnittstelle schreibst und liest, dann kannst Du nie mit Gewissheit sagen, ob ein Programmteil bereits etwas geschrieben hat und Daten in den Empfangspuffer geschrieben werden, die dann vom falschen Programmcode gelesen werden.
Das ist im Prinzip auch eine Race Condition. Abhilfe kannst Du unterschiedlich schaffen. Entweder Du verwendest Semaphoren, löst es mit einer Action Engine oder denkst Dir etwas anderes abenteuerliches aus. Je nachdem welche und wieviele Daten da gelesen werden, könnte es auch eine ganz andere Lösung geben.
(14.04.2012 07:49 )Tintin schrieb: Außerdem hab ich keine Ahnung, welchen Wert ich als Read-Bytes der VISA-Read-Funktion verwenden muss. Mir ist nur bekannt, dass das Messgerät 8 Datenbits und einen Stoppbit verwendet. Trial-and-error hat ergeben, dass bei weniger als 9 Read-Bytes der empfangene String abgeschnitten wird. Aber gibt es allgemein eine Möglichkeit herauszufinden, welche Anzahl an Read-Bytes einzustellen ist?
Hast Du keine Beschreibung zu dem Gerät, mit dem Du kommunizierst? Das hängt ja letzlich davon ab, wieviele Daten gesendet werden.
(14.04.2012 07:49 )Tintin schrieb: ... Du nutzt einen Eigenschaftsknoten, um die Anzahl der am Port vorhandenen Bytes auszulesen. Falls bei "open" welche vorhanden sind, löschst Du diese (wieso?).
Da mein Gerät kontinuierlich Messdaten sendet (wenn es konfiguriert ist), und ich bei der Initialisierung der Schnittstelle nicht weiß, ob ich das gerade während einer Datenübertragung mache, werden die Daten im Empfangspuffer in diesem Fall gelöscht, da ich einen vollständigen Datensatz haben möchte.
(14.04.2012 07:49 )Tintin schrieb: Bei "aquire" liest Du ebenfalls die Anzahl der Bytes am Port aus, und falls diese einen Grenzwert erreichen, führst Du VISA-Read aus und akquirierst die Daten. Ist es nach jedem VISA-Read-Befehl nicht notwendig, die Bytes am Port zu löschen oder geschieht das automatisch?
Die Bytes verschwinden mit dem Lesebefehl aus dem Eingangspuffer und müssen nicht separat gelöscht werden.
(14.04.2012 07:49 )Tintin schrieb: Bevor Du VISA-Close ausführst, löschst Du ebenfalls nochmals alle Bytes am Port. Ist das zwingend notwendig?
