+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Instrument IO & VISA (/Forum-Instrument-IO-VISA)
+---- Thema: Zeitproblem bei Schreiben/Lesen (/Thread-Zeitproblem-bei-Schreiben-Lesen)
Zeitproblem bei Schreiben/Lesen - atbab3 - 07.11.2012 11:53
Hallo zusammen,
folgendes Problem, das Programm soll 2 Befehle senden und die jeweils dazugehörige Antwort auslesen. Wenn ich das Programm mit "Highlight Execution" ausführe, sehe ich sehr schön wie er alle Schritte abarbeitet und mir am Ende die gewollten Werte liefert. Lasse ich das Programm normal laufen gibt er mir am Ende leider nur einen Wert aus.
Da durch Highlight Execution das Programm sehr langsam abläuft denke ich dass das ein Zeitproblem ist und er an irgendeiner Stelle noch Wartezeit benötigt oder so.
Sieht jemand das Problem oder hat eine Idee?
Danke schonmal!
RE: Zeitproblem bei Schreiben/Lesen - GerdW - 07.11.2012 12:57
Hallo atbab,
hast du dir schon mal die Beispiele im Examplefinder angeschaut?
Oder einen der unzähligen Threads zum Thema "Serielle Schnittstelle" und deren korrekte Handhabung?
Schau mal hier:
[attachment=42143]
- Warum jedesmal die Schnittstelle neu initialisieren?
- Wieviele Bytes erwartest du im Lesepuffer direkt nach Absenden deiner Gerätebotschaft?
- Was passiert mit den Ausgängen der Case-Struktur im Fall Bytes=0?
- Wozu die While-Schleife danach um die Speicher-Routine?
- So, wie du BytesAtPort verwendest, ist es falsch. Wahrscheinlich brauchst du diese Funktion nicht (siehe einen der erwähnten unzähligen Threads).
- Korrekte Verdrahtung hilft Fehler zu vermeiden.
- Für den Vergleich mit Null gibt es eine spezielle Funktion.
RE: Zeitproblem bei Schreiben/Lesen - jg - 07.11.2012 13:04
In diesem speziellen Fall liese sich das vermeiden durch Anwendung der NI-Modbus-Library.
(Es geht doch um Modbus ?!)
Gruß, Jens
RE: Zeitproblem bei Schreiben/Lesen - Lucki - 07.11.2012 14:01
Das passiert vermutlich in der Schleife:
1. Du sendest den ersten Befehl. Serial-Write braucht zur Verarbeitung 0ms, weil es selbst nicht sendet, sondern den Befehl nur in den seriellen Ausgabepuffer schiebt.
2. Da zu diesem Zeitpunkt noch gar nichts gesendet, geschweige denn geantwortet wurde, ist die Anzahl bytes at Board 0. Es wird ein leerer String aus dem true-Case gebildet.
3. Dann nach 50ms wird der zweite Befehl an den Ausgabepuffer gesendet. Inzwischen ist wahrscheinlich etwas im Eingangspuffer eingetrudelt, der false-Case mit Visa-Read wird ausgeführt.
4. Wenn die Antworten ein Zeilenende-Zeichen enthalten, warte Read so lange, bis das Zeilenende kommt und liest die Antwort aus.
5. Der Antwort-String-Array müßte also so aussehen:
Index 0: Leerer String
Index 1: Antwort auf das erste Kommando.
Die Antwort auf das zweite Kommando verschwindet im Nirvana. (Die Puffer werden bei der erneuten Initialisierung gelöscht)
So hingegen könnte es funktionieren:
[attachment=42148]