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!
06.07.2018, 15:09 (Dieser Beitrag wurde zuletzt bearbeitet: 06.07.2018 15:22 von jg.)
ich frage über TCP Werte von einem Gerät ab. Manchmal gibt es einen Timeout, Error 56, liegt wohl an dem Gerät, denn mit einem anderen gibts keine Probleme.
Damit mein Programm nicht ganz hängen bleibt, hab ich eine Abfrage gemacht, damit bei Fehler die Verbindung geschlossen wird und dann wieder geöffnet. Hiermit funktioniert es wunderbar, mein Problem ist nur, dass der Benutzer eine Fehlermeldung bekommt, die quittiert werden muss und solange das Programm stehen bleibt. Das möchte ich nicht, das Programm soll autonom laufen. Gibt es eine Möglichkeit die Fehlermeldung abzufangen, oder - noch besser - gibt es eine elegantere Lösung für mein Problem?
Da du den Fehler intern über den Reconnect-Versuch selber behandelst, ist es ja gar kein Programm-Fehler mehr. Wieso gibst du ihn dann als Fehler-Ausgang weiter?
Gruß, Jens
P.S.: Anhänge wie Bilder in Zukunft bitte hier im Forum hochladen. Danke.
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Danke für die Antwort Jens.
Leider verstehe ich es nicht ganz:
Das was aus der Schleife rauskommt ist ja der Fehler von dem neuen TCP Open.
Wenn der Fehler am Eingang ansteht, dann kommt die Fehlermeldung vom Anhang. Sollte die eigentich nicht kommen, wenn ich den Fehler selbst behandle?
Du widersprichst dir gerade selber. Zwecks Datenfluss gibst du den Fehler nach TCP-Read raus (in der Annahme, dass Error-Out der Cluster ist, den du aus deinem SubVI weitergibst). Das zeigt ja auch der Text, Error in TCP-Read. Parallel zum Error-Out behandelst du den Fehler in einer Case-Struktur. Laut deiner Aussage funktioniert das ja wunderbar. Also: Datenfluss korrigieren, und alles wird gut:
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
jg schreibt "Also: Datenfluss korrigieren, und alles wird gut:" - auch wenn jenes wie nebensächlich klingt, so ist das Nicht-Sequenzieren von was auch immer einer der fatalsten Fehler, du du in LabVIEW machen kannst. Du musst davon ausgehen, dass alles, was nicht explizit sequenziert ist, im schlimmsten Falle parallel ausgeführt wird. Das Dumme an einer Nicht-Sequenzierung (dort wo sie notwendig ist) ist, dass sie nicht unbedingt zu einem Fehler führen muss - nur kann. Also: immer mindestens dort sequenzieren, wo es notwendig ist.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
(07.07.2018 20:39 )Philipp99 schrieb: Wenn eine Funktion keinen Fehlereingang bekommt, dann wirft sie auch keinen Fehler aus.
Das kann man sooo nicht sagen.
Wenn der Fehlereingang eines VIs beschaltet wird mit einem Datenfluss, der den Wert "Fehler liegt an" führt, dann wird im Normalfall das VI nicht ausgeführt (Methode: Case-Struktur, an deren Selektor der Errorcluster hängt). Vielmehr wird der Fehlereingang auf den Fehlerausgang gegeben.
Wenn der Fehlereingang eines VIs nicht beschaltet ist, liegt implizit der Wert "Kein Fehler" an (SW-technisch heißt das: optionaler Eingangsparameter, der eine Vorbesetzung hat). Demzufolge wird das VI ausgeführt. Und während dieser Ausführung kann ein Fehler auftreten, der dann am Fehlerausgang anliegt. Das VI kann also einen Fehler werfen, obwohl es keinen Fehlereingang hat.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
/
TCP Verbindung automatisch wiederverbinden
