INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.

Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Probleme mit Webconnect
21.08.2014, 19:13
Beitrag #9
RE: Probleme mit Webconnect
Hi,
ich versuch's mal...
Code:
client.stop();  
  client.flush();  
  delay(100);
Ich bin mir nicht sicher, ob das flush() nach einem stop() überhaupt noch was tut. stop() schließt den Socket und flush() versucht dann davon zu lesen. Ich vermute mal, dass das flush() bestenfalls überflüssig ist.
Das delay(100) danach erscheint mir ebenfalls überflüssig. Auf was soll denn gewartet werden?
Code:
delay(50);
    char c;
    int stoplauf = 0;
    
    while ((c != '<' ) and (stoplauf < 2000)) {
      stoplauf++;      
      c = client.read();    
    };
Was soll das denn tun? Erstmal 50ms warten. Dann 2000 mal client.read() aufrufen, außer es kommt ein "<". Die Schleife dürfte wohl ziemlich schnell abgearbeitet sein. Faktisch ist Dein Timeout also 50ms plus ein klein wenig. Sinnvoller wären meiner Meinung nach ein paar Sekunden als Timeout. (Vielleicht ist das Dein Problem. Manchmal kommt dann nach 150ms doch noch was und das haut dann irgendwie dazwischen.)
Außerdem ist es unschön mal so auf Verdacht zu warten. Das sollte man eher so machen:
Code:
unsigned long start = millis();
char c = 'x'; // definiert nicht "<", nicht nur zufaellig
while(millis() - start < 3000 && c != '<') {  // 3 sek Timeout
    c = client.read();    
};

Dann geht's später weiter mit:
Code:
for (byte zaehler = 0; zaehler < 5; zaehler++) {
        c = client.read();
Mich würde nicht wundern, wenn das auch manchmal unerwartete Ergebnisse liefert. Wenn die Leitung mal nicht so schnell ist, dann wird c = -1 (also wahrscheinlich char(255)). Da solltest Du vorher warten, bis client.available().
Danach versuchst Du wahrscheinlich, den Rest der Sendung abzusammeln (falls da noch was kommt).
Code:
client.stop();  
     client.flush();
Ich denke, erstens müsste das flush() vor dem stop() stehen.
flush() macht nur ein "while(available()) read()", ich hab mir's coding angesehen. D.h. dass Zeichen, die noch nicht im Puffer sind, kommen vielleicht doch noch irgendwie hinterher. Ich denke, da solltest Du Zeichen lesen bis "!client.connected()". Also in etwa:
Code:
while(client.connected()) client.read();
Vielleicht noch irgendein timeout einbauen, falls man sich nicht in eine Endlosschleife begeben möchte.

Außerdem: Was macht SetAutoReset() ?

Gruß,
Thorsten

Falls ich mit einer Antwort helfen konnte, wuerde ich mich freuen, ein paar Fotos oder auch ein kleines Filmchen des zugehoerigen Projekts zu sehen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
21.08.2014, 20:49
Beitrag #10
RE: Probleme mit Webconnect
Hallo Thorsten,

hab vielen Dank für Deine Antwort :-)

Zitat:Code:
client.stop();
client.flush();
delay(100);
Ich bin mir nicht sicher, ob das flush() nach einem stop() überhaupt noch was tut. stop() schließt den Socket und flush() versucht dann davon zu lesen. Ich vermute mal, dass das flush() bestenfalls überflüssig ist.
Das delay(100) danach erscheint mir ebenfalls überflüssig. Auf was soll denn gewartet werden?

Also ich habe es so verstanden, dass client.stop die Verbindung schließt und client.flush das was noch im Arduino-Puffer steckt und noch nicht abgerufen wurde löscht ... darum habe ich das so gemacht. Und mit den 100ms wollte ich dem Ardu Zeit geben die Verbindung wirklich zu schließen. Habe in meinem nächsten Testsketch das delay mal gelöscht.

Zitat:unsigned long start = millis();
char c = 'x'; // definiert nicht "<", nicht nur zufaellig
while(millis() - start < 3000 && c != '<') { // 3 sek Timeout
c = client.read();
};

Dazu brauche ich nicht viel zu schreiben - absolut schlüssig und sofort übernommen ;-)

Zitat:Mich würde nicht wundern, wenn das auch manchmal unerwartete Ergebnisse liefert. Wenn die Leitung mal nicht so schnell ist, dann wird c = -1 (also wahrscheinlich char(255)). Da solltest Du vorher warten, bis client.available().
Danach versuchst Du wahrscheinlich, den Rest der Sendung abzusammeln (falls da noch was kommt).

Dann müsste ich aber auch wieder mit einem Timout arbeiten oder? Unerwartete Werte fange ich momentan mit den if-Abragen ab (c == '1') ...

Zitat:Code:
client.stop();
client.flush();
Ich denke, erstens müsste das flush() vor dem stop() stehen.
flush() macht nur ein "while(available()) read()", ich hab mir's coding angesehen. D.h. dass Zeichen, die noch nicht im Puffer sind, kommen vielleicht doch noch irgendwie hinterher. Ich denke, da solltest Du Zeichen lesen bis "!client.connected()". Also in etwa:

Also stimmt das nicht, was ich mir eingars meines Postings hierzu überlegt habe - den Buffer vom Ardu mit flush zu leeren und vorher die Verbindung zu beenden, damit nix nachkommt?

Zitat:while(client.connected()) client.read();
Vielleicht noch irgendein timeout einbauen, falls man sich nicht in eine Endlosschleife begeben möchte.

Eigentlich möchte ich ja nur die 5 Zeichen nach dem '<' haben danach ist für mich Feierabend und ich möchte die Verbindung trennen und was noch im Puffer ist verwerfen.

Zitat:Außerdem: Was macht SetAutoReset() ?
Das ist eine Funktion von mir, die ein Softreset durchführt, wenn 3 Minuten lang kein erfolgreicher Webconnect stattgefunden hat. Hintergrund ist der, dass ich das System über DHCP laufen hab und wenn ich den Router mal neu starte, dann bekommt der Ardu danach keine Verbindung mehr. Damit ist es dann kein Problem.

Viele Grüße
itsy
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
21.08.2014, 21:08 (Dieser Beitrag wurde zuletzt bearbeitet: 21.08.2014 21:32 von Thorsten Pferdekämper.)
Beitrag #11
RE: Probleme mit Webconnect
(21.08.2014 20:49)itsy schrieb:  Also ich habe es so verstanden, dass client.stop die Verbindung schließt und client.flush das was noch im Arduino-Puffer steckt und noch nicht abgerufen wurde löscht ...
Kann sein, dass das auch nach dem stop() funktioniert, aber ich bin mir da nicht so sicher. Der Punkt ist, dass es eben nur das löscht, was schon im Puffer ist. Ich glaube, dass die Gegenseite das stop() nicht mitbekommt, d.h. sie sendet möglicherweise munter weiter. Da hilft das flush() sowieso nichts.
Zitat:Und mit den 100ms wollte ich dem Ardu Zeit geben die Verbindung wirklich zu schließen.

Was genau würde dann während dieser 100ms passieren?

Zitat:Dann müsste ich aber auch wieder mit einem Timout arbeiten oder?
Ja. Ich würde mir sowas wie ein "read mit Timeout" bauen, also eine Funktion
Code:
char readWithTimeout(Client* client, int timeout) // millisecs
...die maximal <timeout> auf ein Zeichen wartet und es dann liefert. Wenn es zu lange dauert, dann -1. Am Anfang rufst Du das Ding mit 3000ms auf, dann nur noch mit 10ms oder so.

Zitat: Unerwartete Werte fange ich momentan mit den if-Abragen ab (c == '1') ...
Ja, aber mit der for-Schleife machst Du trotzdem weiter, oder?
Zitat:Also stimmt das nicht, was ich mir eingars meines Postings hierzu überlegt habe - den Buffer vom Ardu mit flush zu leeren und vorher die Verbindung zu beenden, damit nix nachkommt?
Wo man genau das flush() sinnvoll einsetzen kann weiß ich auch nicht. Ich glaube, dass das eine unnötige Funktion ist. Auf jeden Fall verhindert es nicht, dass nichts nachkommt. Es leer ja nur den Puffer.

Zitat:Eigentlich möchte ich ja nur die 5 Zeichen nach dem '<' haben danach ist für mich Feierabend und ich möchte die Verbindung trennen und was noch im Puffer ist verwerfen.
Nicht nur das, was noch im Puffer ist, sondern auch das, was noch gesendet wird, oder? Deshalb ja lesen bis die Connection weg ist.

Zitat:Das ist eine Funktion von mir, die ein Softreset durchführt, wenn 3 Minuten lang kein erfolgreicher Webconnect stattgefunden hat. Hintergrund ist der, dass ich das System über DHCP laufen hab und wenn ich den Router mal neu starte, dann bekommt der Ardu danach keine Verbindung mehr. Damit ist es dann kein Problem.
Ah, ok. Die 3 Minuten werden in der Funktion selbst abgefragt, oder? Im von Dir geposteten Coding habe ich nämlich davon nichts gesehen.
Wie genau machst Du denn den "Soft-Reset"? Soweit ich weiß kann man eigentlich beim Arduino per Programm gar keinen so richtig ordentlichen Reset machen.

Gruß,
Thorsten

Hi,
mich hat das nicht losgelassen, da habe ich mal im Coding nachgeschaut. Also erstmal stop():
Code:
void EthernetClient::stop() {
  if (_sock == MAX_SOCK_NUM)
    return;

  // attempt to close the connection gracefully (send a FIN to other side)
  disconnect(_sock);
  unsigned long start = millis();

  // wait a second for the connection to close
  while (status() != SnSR::CLOSED && millis() - start < 1000)
    delay(1);

  // if it hasn't closed, close it forcefully
  if (status() != SnSR::CLOSED)
    close(_sock);

  EthernetClass::_server_port[_sock] = 0;
  _sock = MAX_SOCK_NUM;
}
Man sieht hier drei Sachen:
Erstens wartet das Ding bis zu einer Sekunde, beim Timeout wird dann zwangs-geschlossen. Also danach braucht man bestimmt kein Delay mehr.
Zweitens wird ein disconnect an die andere Seite gesendet. Keine Ahnung, ob die das interessiert, wenn sie grade am Senden ist.
Drittens wird am Ende der Socket auf MAX_SOCK_NUM gesetzt. (Das wird jetzt gleich wichtig.)
Hier jetzt flush() und available():
Code:
void EthernetClient::flush() {
  while (available())
    read();
}

int EthernetClient::available() {
  if (_sock != MAX_SOCK_NUM)
    return W5100.getRXReceivedSize(_sock);
  return 0;
}
D.h. wenn _sock = MAX_SOCK_NUM, dann macht flush() gar nichts. Das bedeutet, dass flush() nach stop() nichts tut.

Gruß,
Thorsten

Falls ich mit einer Antwort helfen konnte, wuerde ich mich freuen, ein paar Fotos oder auch ein kleines Filmchen des zugehoerigen Projekts zu sehen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
21.08.2014, 21:34 (Dieser Beitrag wurde zuletzt bearbeitet: 21.08.2014 21:34 von itsy.)
Beitrag #12
RE: Probleme mit Webconnect
Hallo Thorsten,

Zitat:Ich glaube, dass die Gegenseite das stop() nicht mitbekommt, d.h. sie sendet möglicherweise munter weiter. Da hilft das flush() sowieso nichts.

ok, dann sollt eich wirklich bis zum Ende alle Zeichen lesen ;-)

Zitat:Zitat:
Und mit den 100ms wollte ich dem Ardu Zeit geben die Verbindung wirklich zu schließen.

Was genau würde dann während dieser 100ms passieren?


Wie gesagt, wollte ich dem Ardu Zeit geben die Aktion durchzuführen - die die Initialisierung mancher Bauteile. Habe ich aber grade schon raus genommen.

Zitat:Code:
char readWithTimeout(Client* client, int timeout) // millisecs
...die maximal <timeout> auf ein Zeichen wartet und es dann liefert. Wenn es zu lange dauert, dann -1. Am Anfang rufst Du das Ding mit 3000ms auf, dann nur noch mit 10ms oder so.

Gute Idee :-)

Zitat:Unerwartete Werte fange ich momentan mit den if-Abragen ab (c == '1') ...
Ja, aber mit der for-Schleife machst Du trotzdem weiter, oder?

Ähm joa ;-) Aber schlimmstenfalls bekommt dann ein Relais keinen neuen Wert zugewiesen, oder? Falscher Wert-> wird beim Relais[zaehler] nicht gesetzt, nächste Abfrage setzt ja schon Relais[zaehler+1]

Zitat:Also stimmt das nicht, was ich mir eingars meines Postings hierzu überlegt habe - den Buffer vom Ardu mit flush zu leeren und vorher die Verbindung zu beenden, damit nix nachkommt?
Wo man genau das flush() sinnvoll einsetzen kann weiß ich auch nicht. Ich glaube, dass das eine unnötige Funktion ist. Auf jeden Fall verhindert es nicht, dass nichts nachkommt. Es leer ja nur den Puffer.

Zitat:
Eigentlich möchte ich ja nur die 5 Zeichen nach dem '<' haben danach ist für mich Feierabend und ich möchte die Verbindung trennen und was noch im Puffer ist verwerfen.
Nicht nur das, was noch im Puffer ist, sondern auch das, was noch gesendet wird, oder? Deshalb ja lesen bis die Connection weg ist.

Also besser so:

while ((millis() - start < 3000) or (client.connected() )) { // 3 sek Timeout
c = client.read();
};

oder so:

while ((millis() - start < 3000) or (client.avaiable() )) { // 3 sek Timeout
c = client.read();
};

?

[quote]Wie genau machst Du denn den "Soft-Reset"? Soweit ich weiß kann man eigentlich beim Arduino per Programm gar keinen so richtig ordentlichen Reset machen.[quote]

Da hast Du Recht. Bei funktioniert es, jenn ich an Position 0 springe und er den Bootloader neu startet:

asm volatile ("jmp 0");

Die Funktion von mir verwaltet nur ein Timer, wann dieser Befehl ausgeführt wird.

Viele Grüße
itsy
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
22.08.2014, 12:43
Beitrag #13
RE: Probleme mit Webconnect
(21.08.2014 21:34)itsy schrieb:  
Zitat:[quote]Unerwartete Werte fange ich momentan mit den if-Abragen ab (c == '1') ...
Ja, aber mit der for-Schleife machst Du trotzdem weiter, oder?

Ähm joa ;-) Aber schlimmstenfalls bekommt dann ein Relais keinen neuen Wert zugewiesen, oder? Falscher Wert-> wird beim Relais[zaehler] nicht gesetzt, nächste Abfrage setzt ja schon Relais[zaehler+1]
Ja, schon. Nur dass dann Relais[zaehler+1] unter Umständen den Wert bekommt, den eigentlich Relais[zaehler] hätte bekommen sollen, oder?

Zitat:Also besser so:

while ((millis() - start < 3000) or (client.connected() )) { // 3 sek Timeout
c = client.read();
};
Nein, statt "or" musst Du "and" nehmen (bzw. "&&"). Wenn Du "or" nimmst und durch einen Fehler der Client verbunden bleibt, dann bist Du in einer Endlosschleife. Das willst Du ja gerade vermeiden. Auf der anderen Seite willst Du ja nicht die 3 Sekunden erzwingen, auch wenn der Client schon dichtgemacht hat.

Code:
while ((millis() - start < 3000) or (client.avaiable() )) {  // 3 sek Timeout
    c = client.read();  
};
Nein, available() bezieht sich nur auf den Puffer, nicht auf das, was vielleich noch in ein paar Mikrosekunden nachkommt.

Zitat:Die Funktion von mir verwaltet nur ein Timer, wann dieser Befehl ausgeführt wird.
Dann hätte ich aber erwartet, dass diese Funktion gerade dann aufgerufen wird, wenn die Übertragung erfolgreich war, um den Timer wieder auf 3 Minuten zu setzen.
Vielleicht habe ich nicht so ganz verstanden, was Du da machst, aber so ganz richtig klingt das nicht.

Gruß,
Thorsten

Falls ich mit einer Antwort helfen konnte, wuerde ich mich freuen, ein paar Fotos oder auch ein kleines Filmchen des zugehoerigen Projekts zu sehen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
22.08.2014, 20:07
Beitrag #14
RE: Probleme mit Webconnect
Hallo Thorsten,

Zitat:Ja, schon. Nur dass dann Relais[zaehler+1] unter Umständen den Wert bekommt, den eigentlich Relais[zaehler] hätte bekommen sollen, oder?

Das ist eine gute Frage ... was passiert eigentlich wenn er c lesen möchte aber nichts im Puffer vorhanden ist?

Zitat:Nein, statt "or" musst Du "and" nehmen (bzw. "&&"). Wenn Du "or" nimmst und durch einen Fehler der Client verbunden bleibt, dann bist Du in einer Endlosschleife. Das willst Du ja gerade vermeiden. Auf der anderen Seite willst Du ja nicht die 3 Sekunden erzwingen, auch wenn der Client schon dichtgemacht hat.

Jao - werde ich direkt so umsetzen :-)

Zitat:Dann hätte ich aber erwartet, dass diese Funktion gerade dann aufgerufen wird, wenn die Übertragung erfolgreich war, um den Timer wieder auf 3 Minuten zu setzen.
Vielleicht habe ich nicht so ganz verstanden, was Du da machst, aber so ganz richtig klingt das nicht.

In meiner Funktion ist der Counter standardmäßig deaktiviert (=0). Gibt es einen fehlerhaften Connect wird Counter = millis+Intervall gesetzt. Ist Counter > 0 wird Counter-millis auf dem TFT angezeigt. Gibt es einen erfolgreichen Connect wird Counter=0 gesetzt. Ist millis > Counter gibt es den Jump.
Hätte hier auch die Funktion reinkopieren können, allerdings hätte das nur verwirrt, weil darin noch einiges Andere abgearbeitet wird.

Viele Grüße
itsy
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
22.08.2014, 21:04
Beitrag #15
RE: Probleme mit Webconnect
(22.08.2014 20:07)itsy schrieb:  Das ist eine gute Frage ... was passiert eigentlich wenn er c lesen möchte aber nichts im Puffer vorhanden ist?
Dann kommt -1 zurück, wie es in der Doku steht. Man sollte immer vorher auf available() abfragen, wenn das false ist, erst gar nicht versuchen, etwas zu lesen.

Gruß,
Thorsten

Falls ich mit einer Antwort helfen konnte, wuerde ich mich freuen, ein paar Fotos oder auch ein kleines Filmchen des zugehoerigen Projekts zu sehen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
22.08.2014, 21:42
Beitrag #16
RE: Probleme mit Webconnect
Alles klar - ich bin überzeugt - habe es auch grade in meinem Sketch geändert! Nun muss ich dann mal die delay-Zeiten testen und schauen ab wann das Problem nicht mehr auftritt. Auf jeden Fall habe ich viele Verbesserungen durch Euch umsetzen können.

Vielen Dank!!
itsy
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Möglicherweise verwandte Themen...
Thema: Verfasser Antworten: Ansichten: Letzter Beitrag
  ArduinoDroid Probleme Brother Tak 1 199 10.09.2016 22:12
Letzter Beitrag: Brother Tak
  Roboter-Bau Probleme blebbens 8 374 12.07.2016 07:35
Letzter Beitrag: Binatone
  Probleme mit sprintf() und dtostrf() GMBU 11 797 22.06.2016 10:52
Letzter Beitrag: GMBU
  Makeblock mit Scratch programmieren- Probleme Keinen Schimmer 6 945 06.05.2016 18:34
Letzter Beitrag: arduinopeter
  Programme vom UNO auf nano , mini Pro portieren Probleme anwo 19 1.166 17.04.2016 21:12
Letzter Beitrag: hotsystems
  Probleme beim Auslesen eines IR Empfängers linuxpaul 7 571 06.03.2016 14:44
Letzter Beitrag: hotsystems
  I²C vom NANO zum PI Probleme mit High/Low Bit Tobias1984 4 328 29.02.2016 00:00
Letzter Beitrag: hotsystems
  Probleme beim auswählen des Ports Levi 11 807 21.02.2016 18:00
Letzter Beitrag: hotsystems
  IRemote probleme mit abfrage schnutzkurt 18 1.140 20.02.2016 01:30
Letzter Beitrag: SkobyMobil
  Probleme mit SPI - Ethernet und nRF24L01 itsy 35 2.964 21.11.2015 19:59
Letzter Beitrag: ardu_arne

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste