Serielle Schnittstelle hängt sich nach mehreren Datenfehlern auf
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!
Serielle Schnittstelle hängt sich nach mehreren Datenfehlern auf
Hallo,
ich habe mal wieder ein Problem mit LV:
Ich möchte mit einem LV-Programm die Wechselrichter einer Photovoltaikanlage überwachen. Das ist auch eigentlich kein Problem, nur wenn die Anlage über Nacht keinen Strom mehr produziert, legen sich auch die seriellen Schnittstellen der Wechselrichter schlafen. Damit kommt dann ein Error in der Kommunikation zustande.
Einzelne Fehler kann ich ohne Probleme mit einer Case- Anweisung aus der Aufzeichnung raushalten, das Problem ist aber, wenn über Nacht ein paar tausend mal keine Kommunikation zustande gekommen ist, funktioniert sie auch nicht, wenn die Schnittstellen wieder online gehen, LV meldet weiter denselben Fehler. Anhalten und Neustarten des VIs beheben das Problem.
Anhalten und per Hand neu Starten kann aber nicht die Lösung sein, das ganze soll autark laufen.
Einen festen Start/Stop- Zeitpunkt möchte ich auch nicht festlegen, weil die Laufzeiten der Photovoltaikanlage von Wetter und Sonnenstand abhängen.
Ich möchte mich schon mal im Voraus bedanken, wäre schön, wenn ihr mir weiterhelfen könnt!
Serielle Schnittstelle hängt sich nach mehreren Datenfehlern auf
Ev. würde es genügen, die serielle Schnittstelle neu zu öffnen, statt das VI.
Nur lesen wenn Byte am Port.
Vielleicht kannst du den "DCD State" lesen. (Line detect Signal)
Ev. dann den Buffer leeren, oder eben neue Verbindung aufbauen.
Machst du das mit VISA + RS232?
Gruss
Roland
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
Serielle Schnittstelle hängt sich nach mehreren Datenfehlern auf
Hi Roland,
ja, das ist VISA+RS232.
Bis jetzt VISA öffnen -- Schleife mit Anfrage senden, Antwort lesen -- VISA schließen. Wollte nicht bei jedem Durchlauf (alle 10s) Port öffnen und schließen. Einen CLR Port hatte ich schon mal in der Schleife, hat dieses Problem aber nicht behoben.
Nur die Schnittstelle neu zu öffnen statt des VIs hätte glaub ich dasselbe Problem wie das VI neu zu öffnen, wie soll ich da das "Aufwachen" der Anlage finden?
Das mit dem "Nur lesen bei Byte am Port" ist ne gute Idee, aber kann ich dann trotzdem (fast) kontinuierlich meine Anfragen an die Wechselrichter senden? Ich hatte das so verstanden, dass bei der Option gewartet wird, bis Bytes anliegen oder gilt da dann auch der Timeout für die VISA-Operation und es geht nach der unbeantworteten Anfrage weiter?
Serielle Schnittstelle hängt sich nach mehreren Datenfehlern auf
' schrieb:Wollte nicht bei jedem Durchlauf (alle 10s) Port öffnen und schließen.
Musst du ja auch nicht...du kannst ja vor der Schleife öffnen, in der Schleife prüfen ob ein Fehler vorliegt und nur dann schließen und sofort wieder öffnen...und natürlich das normale schließen nach der Schleife!
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
13.02.2008, 13:18 (Dieser Beitrag wurde zuletzt bearbeitet: 13.02.2008 13:19 von RoLe.)
Serielle Schnittstelle hängt sich nach mehreren Datenfehlern auf
' schrieb:Hi Roland,
ja, das ist VISA+RS232.
Bis jetzt VISA öffnen -- Schleife mit Anfrage senden, Antwort lesen -- VISA schließen.
Das mit dem "Nur lesen bei Byte am Port" ist ne gute Idee, aber kann ich dann trotzdem (fast) kontinuierlich meine Anfragen an die Wechselrichter senden? Ich hatte das so verstanden, dass bei der Option gewartet wird, bis Bytes anliegen oder gilt da dann auch der Timeout für die VISA-Operation und es geht nach der unbeantworteten Anfrage weiter?
Normalerweise geht das so:
Anfrage senden, Prüfen ob Bytes empfangen wurden und erst lesen wenn Daten da sind. (mit einer Case)
Ich nehme mal an das dir bekannt ist was und wieviel (Byte) zurückgesendet werden. Ev. hast du/ist da ein Telegramm definiert.
Wird das beachtet, kann es fast kein Timeout mehr geben, ist jedenfalls besser als nur ein warten zwischen schreiben und lesen einzufügen, wie ich hier schon öffters gelesen habe.
Sollang 0 Byte sind (die ganze nacht) führtst du das Read nicht aus. Ev. musst du deine Anfrage nochmals senden.
Was ich mich auch noch Frage:
Deinem Sender geht ja irgendwann mal der Saft aus, also entläd sich bis zu einem bestimmten Wert.
Dort sollte schon eine elektronische Überwachung sein die das ausschaltet. Seriell ist ja ein TTL-Spannungspegel und irgendwo bei < 3 Volt ist das eine 0 > 3Volt eine 1. Unter dieser Grenze sollte das Sendergerät nicht mehr senden.
Ev. geht deshalb die Ser.Sch. nicht mehr. Kenne mich aber mit Elektronik nicht so aus.
Gruss
Roland
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
Serielle Schnittstelle hängt sich nach mehreren Datenfehlern auf
Hallo,
ich habe die Variante mit der Case-Anweisung und den "Bytes at Port" heute nachmittag ausprobiert (unpraktisch, wenn man das abends nicht testen kann!), beim ersten Aufruf (Auslesen Wechselrichter 1) klappt es prima, beim zweiten Aufruf (WR2) meldet LV "0 Bytes at Port" und geht logischerweise nicht in die Case-Anweisung, obwohl Werte vorliegen. Wenn ich dann die Voraussetzung für die Case-Anweisung negiere, liest es die Werte richtig aus (daher sollten doch wohl Bytes am Port liegen?!?). Wie kann das denn gehen, die Aufrufe sind identisch?
Auch wenns noch nicht richtig funktioniert, eine gute Idee, danke!
Nun ja, ich hoffe mal, dass die Schnittstelle der Geräte vernünftig gebaut ist, aber ein paar seltsame Sachen zeigen sie schon kurz vor der Abschaltung. Auf einmal werden Phantasiewerte ausgegeben, vielleicht kann man das über die Checksumme ausmerzen, aber wie man die berechnet hab ich noch nicht raus. Das Protokoll musste ich mir selbst mit einem Com-Sniffer herausfinden, weil Total Energie sich nicht gerade kooperativ gezeigt und mich nur auf ihren Kauflogger hingewiesen hat...