Empfangspuffer zu klein für HTTP_GET

[lostmind]

Hallo!

Folgende Situation:

Ich nutze Oscat Network (v1.21) mit e!COCKPIT (Codesys 3.5 mit WAGO-Anpassungen) auf einer WAGO PFC 200 (750-8206). Ich möchte von einer Web-GUI (mit htaccess-Schutz) Betriebsdaten auslesen und visualisieren. Dazu muss ich eine Webseite parsen. Ich habe das bisher mit Codesys 2.3 und WagoLibHttp gemacht, möchte das Program aber auf e!COCKPIT mit Oscat Network portieren (WagoLibHttp gibts dort nicht).

Nach einigem hin und her habe ich erfolgreich ein Beispielprogramm zusammengebaut und Oscat Network erweitert, damit Auth Basic funktioniert (http://www.oscat.de/community/index.php/topic,1934.0.html war da ein guter Anlaufpunkt).

Leider liefert HTTP_GET beim Status kein "DONE", weil die abzurufende Webseite größer ist als die Größe des Empfangspuffers (R_BUF: NETWORK_BUFFER hat "nur" eine Größe von 4 KB). Versuche ich NETWORK_BUFFER unter den globalen Konstanten in Oscat Network zu vergrößern, dann stürzt Codesys/e!COCKPIT nach dem Übertragen des Programms auf den Controller ab. Ich schätze mal, dass sich diese Konstante nicht leichtfertig vergrößern lässt. Mit Codesys 2.3 und WagoLibHttp konnte ich an der Stelle einfach das TCP-Daten-Limit auf 10 KB vergrößern.

Wichtig: Ich suche nicht nach einem "Hack", um von HTTP_GET ein "DONE" zu bekommen, sondern ich möchte den gesamten Webseiten-Inhalt auslesen können!

Wie lässt sich dieses Problem mit Oscat Network lösen?

Viele Grüße,
Mario

[peewit]

hallo

die anpassung die du bei den globalen variablen gemacht hast ist prinzipiell richtig und sollte auch die einzig notwendige sein.

das dein controller beim übertragen abstürzt ist eher ein software/firmware fehler
Wenn du das programm fehlerfrei compilieren kannst du sollte es auch fehlerfrei übertragbar sein
sollte es dann bei der ausführung ein problem geben, dann ist das eine andere sache und sollte auch dementsprechend gemeldet werden

machst du eine online-änderung oder löschen und übertragen ?
das ist meiner meinung nach ein fall für den SPS-Support

[lostmind]

Hallo!

Firmware-Fehler klingt gar nicht gut. Der Fehler tritt jedenfalls auf, sobald das Programm übertragen wird. Ich habe es so gemacht: Übersetzen -> Einloggen -> Download (d.h. kein Online-Change, sondern löschen und neu übertragen).

Ich bin trotzdem wegen der Änderung an den globalen Variablen besorgt, weil in diesem Thread (http://www.oscat.de/community/index.php?topic=1784.0) für die Nutzung unter Codesys 3 auf folgenden Punkt besonders hingewiesen wird:

2. Had to change NETWORK_BUFFER_LONG_SIZE : UINT := 1999; //Changed from 3999 else socket would not work when reading

Aus welchem Grund ist der NETWORK_BUFFER im Auslieferungszustand der Oscat Network-Bibliothek 4 KB groß? Gibt es evtl. die Möglichkeit den R_BUF schrittweise zu füllen?

Ich komme erst am Donnerstag wieder dazu an der WAGO-SPS zu arbeiten. Wenn der Fehler wieder auftritt, dann poste ich mal einen Screenshot der Meldung von e!COCKPIT/Codesys.

[peewit]

hallo

die oscat nwtork ist nur auf codesys 2.x von mit entwicklet und getestet
das heikle daran ist der ip_control, den der kapselt die hardware abhängigkeiten und leider mancht hier jeder was er will
darum ist es auch notwnedig die network für codesys 3.x auf seiner plattform anzupassen und zu testen

Wenn die bibliothek aber mit standard buffer groesse läuft aber mit vergroesserten nicht dann gibt es keinen wirklich sinnvollen grund dafür.

Stell doch mal die sps auf stop
dann download machen
Ist das system dann noch am leben ?
was ist wenn du danach die sps startest
Fehlermeldung ?

[teichhei]

Hi,

Ich hatte auf dem Raspi ein Problem, da kam vom IP_Control beim einlesen einer Website (json) von 3870 Bytes ein Fehler 0000EF00  und es kam kein Body an. Aber Done wurde immer gesetzt.
Nachdem ich den Puffer vergrößert hatte ging das ganze wieder. Das ging auch vorher schon mal aber es kann sein dass das json größer geworden ist.
Würde ein Baustein der größere streams verarbeitet überhaupt gehen? Mit ewig langen strings kann man ja auch nichts anfangen.

Gruß

Heinz

[peewit]

groesser http_get sind prinzipiell kein problem  wenn du dazu den buffer vergreosserst
mit string längen hat das nichts zu tun, da die header und bod< daten in einen byte array liegen
und diesen musst du je nach dateninhalt auswerten und interpretieren

aber es wird niemals der ganzen body-teil als ein string betrachtet