Fehler Zeitüberschreitung beim Auslesen

Hallo,

ich lese mit einem Sub-VI über meine COM-Schnittstelle ein Messwertprotokoll von einem externen Gerät ein.
Mein Problem ist nachdem ich das Protokoll habe, soll das Auslesen der COM-Schnittstelle beendet werden
und der normale Programmablauf weiter geführt werden aber irgendwie funktioniert das nicht.
Es kommt immer erst folgende Fehlermeldung:
   
Wenn ich diese mit weiter bestätige, läuft das Programm sauber weiter und ich kann die Daten auswerten.
Allerdings hätte ich es gern, dass die Meldung nicht erscheint und das Lesen von COM einfach beendet wird.
Um eine Abbruchbedingung zu schaffen befindet sich in dem Protokoll am Ende der Zahlenwert 9999999.
Den wollte ich auch als Abbruchbedingung nehmen da der Wert innerhalb der Messwerte nie vorkommt.
Hat von euch jemand eine Idee wie das geht?

Hier mal mein VI:

  Serial_Kommunikation_Liste.vi (Größe: 67,56 KB / Downloads: 371)

und das Protokoll:

  probe5.TXT (Größe: 33,71 KB / Downloads: 334)


Selbes Problem habe ich auch bei DAQmx, auch hier kommt nach erreichen des Timeouts eine Fehlermeldung.
   

hier das VI dazu:

  Auslese_PSD_Schussliste.vi (Größe: 52,87 KB / Downloads: 284)

Die Auslese von DAQmx soll zeitgeleich mit dem Auslesen vom COM passieren und danach ebenfalls geschlossen werden.
Deshalb habe ich es als Sub-VI in das obere mit reingepackt in der Hoffnung dass es bendet wird wenn die COM-Auslese beendet ist.

Kann mir vieleicht jemand einen Tipp geben wie ich diese Fehlermeldungen umgehen kann,
denn wenn ich dort mit weiter bestätige läuft alles sauber weiter ohne Probleme.

Gruß Marco

Anzeige

zum Problem selbst kann ich grade nix sagen, aber evtl. findest du gefallen an diesem kleinen SubVI anstelle deiner "warten in sequenzrahmen"-struktur.


  Warten.vi (Größe: 9,77 KB / Downloads: 345)


  Warten.vi (Größe: 17,66 KB / Downloads: 245)


Es hat den Vorteil, dass du den Datenfluss durch die Errorline fortführen kannst und außerdem wird im Falle eines Fehlers nicht gewartet.

LG
Torsten

' schrieb:
zum Problem selbst kann ich grade nix sagen, aber evtl. findest du gefallen an diesem kleinen SubVI anstelle deiner "warten in sequenzrahmen"-struktur.

[attachment=47543:Warten.vi]
[attachment=47544:Warten.vi]

Es hat den Vorteil, dass du den Datenfluss durch die Errorline fortführen kannst und außerdem wird im Falle eines Fehlers nicht gewartet.

LG
Torsten

Hallo Torsten,

danke für den Tipp, aber leider bringt mich dass meinem Ziel kein Stückchen näher.

Gruß Marco

Der Fehler wird doch im vollem Klartext beim Namen genannt: Timeout bei VISA-Lesen, welcher bei Dir auf kurze 100 ms voreingestellt ist. Wenn über mehr als 100 ms keine Zeichen kommen, gibt es diesen Fehler. Der Fehler muß abgefangen und behandelt werden. Vielleicht reicht es auch, den Timout erst mal zu erhöhhen.

' schrieb:Der Fehler wird doch im vollem Klartext beim Namen genannt: Timeout bei VISA-Lesen, welcher bei Dir auf kurze 100 ms voreingestellt ist. Wenn über mehr als 100 ms keine Zeichen kommen, gibt es diesen Fehler. Der Fehler muß abgefangen und behandelt werden. Vielleicht reicht es auch, den Timout erst mal zu erhöhhen.

Hallo Lucki,

das mit dem erhöhen des Timeouts hatte ich auch schon gedacht,
aber da wartet das Programm nur länger bis dann schließlich der Timeout erreicht ist und bringt dann den Fehler.
Ich wollte aber, dass vor dem Timeout das SubVI abgebrochen wird und die Daten an das Hauptprogramm übergeben werden.
Gibt es den keine Möglichkeit vor dem Timeout das SubVI zu unterbrechen und den normalen Programmablauf weiter zu führen?

Gruß Marco

Wenn bis auf die Fehlermeldung alles richtig funktioniert und Du Deine Daten auch alle innerhalb der 100 ms bekommst, dann kannst Du die Fehlermeldung auch unterdrücken. Wobei es natürlich schöner ist, den Fehler zu beheben.

Gruß Markus

' schrieb:Ich wollte aber, dass vor dem Timeout das SubVI abgebrochen wird und die Daten an das Hauptprogramm übergeben werden.
Gibt es den keine Möglichkeit vor dem Timeout das SubVI zu unterbrechen und den normalen Programmablauf weiter zu führen?

Was Hast Du denn gegen einen Timeout? Der Timeout stört doch nur insofern, als er eine Fehlermeldung bringt. Das läßt sich mit Fehlerbehandlung ganz einfach verhindern. Oder Du brauchst nicht einmal Fehlerbehandlung, es kommt schon dann nicht zur Programmunterbrechung, wenn Du an den Fehlerausgang ein Stückchen Draht anschließt, der dann allerdings nicht in andere VIs reingeführt werden sollte.
Eine Möglichkleit könnte z.B. sein: Das Visa-Read läuft in einer While-Schliefe, bei Timeout versucht es immer wieder neu zu lesen, bis Du den Vorgang unterbrichst. Hier mal ein Beispiel zur Fehlerbehandlung in einem realen Programm:
   

@Y-P

Zitat:Wobei es natürlich schöner ist, den Fehler zu beheben.

Im Allgemeinen hast Du damit recht, nur hier nicht. Denn im Allgemeinen ist es so, daß ein Timeout keine Fehlermeldung bringt, sondern es gibt einen extra boolschen Ausgang für den Timeout. Nur hier im VISA Read haben sich die Macher von NI aus für mich nicht nachvollziebaren Gründen dafür entschieden, auf so einen Ausgang zu verzichten und den Timeout nur als Fehler zu melden. Es ist aber eigentlich kein Fehler, nur muß man hier leider das Geschütz der Fehlerbehandlung auffahren, um den Timeout zu behandeln.

Bei einem sinnvollen Protokoll ist es eben meist schon ein Fehler, wenn auch oft kein gravierender.

Dann gibt es meist entweder dass eine Meldung mit einem bestimmten Character abgeschlossen wird, hier hat VISA einen entsprechenden Mechanismus, bei dem Du den Termination Character konfigurieren kannst.

Oder es ist zum vorneherein bekannt wie lange die Message ist, etwa bei binären Protokollen wo oft ein Header mit fester Länge geschickt wird der auch umfassende Informationen über die noch zu folgenden Daten enthält.

Rolf Kalbermatter

Wegen all dieser Probleme und Diskussionen konnte ich mich bisher noch nie richtig für VISA für serielle Geräte erwärmen. Bei diesen Teilen bin ich immer irgendwie wieder zurück zu den super-einfachen seriellen VI's gegangen und habe immer in etwa so programmiert:
1. Frage den Seriellen Eingangspuffer wieviele Zeichen angekommen sind. Dafür gabs und gibts evtl. immer noch eine spezielle Funktion, "Number of characters on serial port" oder so ähnlich.
2. Wenn nichts angekommen ist warte irgendwelche 100ms.
3. Sobald mehr als null Zeichen da sind lies genausoviele ein und hänge sie an einen Stringbuffer an.
4. Nun könnte man z.B. den Endekennzeichen-Check einbauen und den vorhandenen Sting an das rufende Programm übergeben und danach den Buffer löschen um bei 1. wieder von vorne anzufangen oder das Sub VI zu beenden.

Das ganze in einer separaten While loop, die über eine occurence sofort beendet werden kann und selbst mit einem Wait von 10...100ms ausgebremst wird.

Im vorliegenden Fall müsste man immer nach dem Einlesen einer gewissen Datenmenge kontrollieren, ob ein Zeilenendekennzeichen vorhanden ist. Falls ja, kann man diesen Teil der Daten als Zeile z.B. in einem String-Array ablegen und den Rest dem folgenden Datenpaket voranstellen.

Diese Vorgehensweise ist übrigens aus dem Example VI LabVIEW<-->seriell direkt geklaut. Aber eben ohne VISA overhead, ca. 3 functions in einem while loop und ein paar cases. sehr übersichtlich...
Ich weiss momentan nicht ob es dieses Example noch gibt im aktuellen LV8.6.

' schrieb:Wegen all dieser Probleme und Diskussionen konnte ich mich bisher noch nie richtig für VISA für serielle Geräte erwärmen. Bei diesen Teilen bin ich immer irgendwie wieder zurück zu den super-einfachen seriellen VI's gegangen und habe immer in etwa so programmiert:
1. Frage den Seriellen Eingangspuffer wieviele Zeichen angekommen sind. Dafür gabs und gibts evtl. immer noch eine spezielle Funktion, "Number of characters on serial port" oder so ähnlich.
2. Wenn nichts angekommen ist warte irgendwelche 100ms.
3. Sobald mehr als null Zeichen da sind lies genausoviele ein und hänge sie an einen Stringbuffer an.
4. Nun könnte man z.B. den Endekennzeichen-Check einbauen und den vorhandenen Sting an das rufende Programm übergeben und danach den Buffer löschen um bei 1. wieder von vorne anzufangen oder das Sub VI zu beenden.

Das ganze in einer separaten While loop, die über eine occurence sofort beendet werden kann und selbst mit einem Wait von 10...100ms ausgebremst wird.

Im vorliegenden Fall müsste man immer nach dem Einlesen einer gewissen Datenmenge kontrollieren, ob ein Zeilenendekennzeichen vorhanden ist. Falls ja, kann man diesen Teil der Daten als Zeile z.B. in einem String-Array ablegen und den Rest dem folgenden Datenpaket voranstellen.

Diese Vorgehensweise ist übrigens aus dem Example VI LabVIEW<-->seriell direkt geklaut. Aber eben ohne VISA overhead, ca. 3 functions in einem while loop und ein paar cases. sehr übersichtlich...
Ich weiss momentan nicht ob es dieses Example noch gibt im aktuellen LV8.6.

Tja unter der Kappe ist halt immer noch VISA. Die alten seriellen VIs werden nur als Kompatibilitätslayer geliefert der darunter dann wieder alles mit VISA implementiert.

Deine Idee ist ja nicht so schlecht, nur machst Du Dir jeweils sehr viel Arbeit die von VISA ohne extra Mühe (ok Du musst nach der Initialisation der Resource einmal die entsprechenden Properties richtig setzen) einfach übernommen wird. Das einzige was Du hast was VISA (zumindest auf LabVIEW Ebene) (noch?) nicht automatisch hat ist die extra Occurrence. Dazu habe ich aber vor einer Weile hier im Forum ein VI gepostet, dass anstelle von VISA Close eingesetzt werden kann und dass alle noch wartenden IO Operationen abbricht, befor die Resource abgeschlossen wird. Damit brechen alle noch wartenden Readoperationen (bei Write solltest Du normalerweise nicht in ein Wait kommen bei Serial) mit einer Fehlermeldung ab. Es würde mich nicht verwundern wenn VISA Close in 2009 dies inzwischen auch macht, oder eventuel auch einen extra Boolean Eingang besitzt um das zu erzwingen.

Deine Verwendung von den "nicht" VISA Serialfunktionen ist für den grössten Teil einfach alles nochmal selber implementieren was in der darunterliegenden VISA Library doch schon vorhanden ist aber durch die Kompatibilitäts-VIs wieder wegabstrahiert wird.

Rolf Kalbermatter