TIA Webserver - XMLHttpRequest schlägt fehl

Alde_Oma

Level-2
Beiträge
103
Reaktionspunkte
4
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

ich rufe via XMLhttpRequest Daten vom Webserver der SPS ab.
Beim Laden der Seite wird die Funktion aufgerufen und dann alle 1000ms erneut.
Code:
function updatePlcElements() {
            if (window.XMLHttpRequest) { //Google Chrome, Mozilla Firefox, Opera, Safari, IE 7
                xmlhttp = new XMLHttpRequest();
                
            } else { // Internet Explorer 6 und niedriger
                xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
                
            }
            
            xmlhttp.open("GET", "html/Main_Update_Data.json", true);
            xmlhttp.onreadystatechange = function() {
                if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {   
                    console.log("Response: " + xmlhttp.responseText);
                    var data = JSON.parse(xmlhttp.responseText);
                    console.log(data);
                    debugger;
                
                    var iStunde = data.usi_Stunde;
                    var iMinute = data.usi_Minute;
                    var iSekunde = data.usi_Sekunde;
                    
                    var iJahr = data.ui_Jahr;
                    var iMonat = data.usi_Monat;
                    var iTag = data.usi_Tag;
                    var sWochentag = data.usi_Wochentag;
                    
                    var iTemperatur = data.si_Temperatur;
                    
                    if (iStunde < 10) {
                        iStunde = "0" + iStunde;
                    }
                    
                    if (iMinute < 10) {
                        iMinute = "0" + iMinute;
                    }

                    if (iSekunde < 10) {
                        iSekunde = "0" + iSekunde;
                    }

                    if (iMonat < 10) {
                        iMonat = "0" + iMonat;
                    }

                    if (iTag < 10) {
                        iTag = "0" + iTag;
                    }
                    switch(sWochentag) {
                      case '1':
                        sWochentag = "So"
                        break;
                      case '2':
                        sWochentag = "Mo"
                        break;
                      case '3':
                        sWochentag = "Di"
                        break;
                      case '4':
                        sWochentag = "Mi"
                        break;
                      case '5':
                        sWochentag = "Do"
                        break;
                      case '6':
                        sWochentag = "Fr"
                        break;
                      case '7':
                        sWochentag = "Sa"
                        break;

                      default:
                        
                    }

                    document.getElementById("sZeit").innerHTML = iStunde + ":" + iMinute + ":" + iSekunde;
                    document.getElementById("sDatum").innerHTML = sWochentag + ", " + iTag + "." + iMonat + "." + iJahr;
                    
                    document.getElementById("sTemperatur").innerHTML = iTemperatur + " °C";

                       setTimeout("refreshOutputArea()", 1000);
                }
            }
            
            xmlhttp.send(null);
            
        }

Das klappt auch soweit gut. Nur dass nach ~100 Anfragen (egal wie lange die Wartezeit ist) folgender Fehler auftritt:
Fehler_1.PNG

Wie im unteren Log zu sehen ist, kommt die Zeichenfolge "CB" vor, was in den Logs zuvor nicht passiert.
Daher die Frage: Was kann zu diesem Fehler führen und wie behebe ich das Problem?

Ich habe auch schon in einem JS-Forum nachgefragt, was bisher aber keine Erkenntnisse geliefert hat.
Es liegt wohl am Server, war die Meinung.
 
Was hast du denn für eine Steuerung, Typ und Firmware-Version?

Ich habe nämlich eine alte 1200 mit FW2.2 bei der der Webserver das so gut wie immer macht wenn eine bestimmte http-header Option gesetzt ist.
Du kannst den Bug aber einfach umschiffen, in dem du bevor du die Antwort an den json-Parser übergibst, alle Zeichen bis zur ersten öffnenden geschweiften Klammer entfernst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

ich nutze aktuell noch PLCSIM-Adv.
Das ist dann wohl ein "Fehler" von der Software?
Weißt du auch welche Headeroption das Problem auslöst?

Dann schneide ich den String vor der Klammer ab.
 
Ich habe es nicht weiter nachverfolgt. Ich habe hier für eine Frage aus dem Forum probiert von einem Rechner mit php und file_get_contents() eine Webseite von der SPS auszulesen, da hatte ich auch sehr oft diese fehlerhaften Zusatzdaten. Ich habe etwas mit den Header-Optionen herumgespielt, aber konnte nicht lokalisieren woran es liegt. Wobei ich nicht weiß ob das sonst auch auftritt, auf einer reinen html-Seite fällt das nicht direkt auf wenn da zu Beginn bei manchen Aufrufen zwei Zeichen stehen.
 
Danke, das klappt wunderbar.
Den String zwischen den geschweiften Klammern via Substring ausschneiden. Bei mir tauchen davor und danach unnötige Zeichen auf.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das klappt auch soweit gut. Nur dass nach ~100 Anfragen (egal wie lange die Wartezeit ist) folgender Fehler auftritt:

Wie im unteren Log zu sehen ist, kommt die Zeichenfolge "CB" vor, was in den Logs zuvor nicht passiert.
Daher die Frage: Was kann zu diesem Fehler führen und wie behebe ich das Problem?

Ich habe auch schon in einem JS-Forum nachgefragt, was bisher aber keine Erkenntnisse geliefert hat.
Es liegt wohl am Server, war die Meinung.

Welche FW verwendest Du auf der CPU? - Sollte mit CPU FW 2.6 behoben sein:

CPU 1515 FW V2.5 - Web Zugriff
 
Welche FW verwendest Du auf der CPU? - Sollte mit CPU FW 2.6 behoben sein:

CPU 1515 FW V2.5 - Web Zugriff

Hier noch mal der Text von Siemens:
https://support.industry.siemens.com/cs/ww/de/view/109478459

"Wenn JSON und AJAX als Data Interface für den Datenaustausch zwischen Webserver und Webclient genutzt werden, dann kann es nicht mehr sporadisch dazu kommen, dass der Webserver beim Antworttelegramm Zeichen hinzufügt, so dass es beim Webclient zu einer Fehlermeldung im Parser kommt."

Die Fehlerbeschreibung ist aber mal wieder dürftig, weil es nicht an Ajax liegt (tritt bei mir auch ohne Ajax auf), sondern vermutl. an irgend einer http-Option die nicht korrekt verarbeitet wurde.
 
Ich lad mir jetzt mal die neuen Firmware-Updates runter und rüste auf V2.6 hoch. Habe die CPU noch auf V2.5.
Wie wirkt sich denn die Anzahl der an den Webserver übergebenen Variablen auf die Zykluszeit aus?
Im Link von JoGi65 wird ja darüber diskutiert. Habt ihr da zufällig auch ein paar Zahlen?
Ab wievielen Variablen würdet ihr sagen lohnt es sich, alles in einem String zu übergeben?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ab wievielen Variablen würdet ihr sagen lohnt es sich, alles in einem String zu übergeben?
Beim Lesen verwende ich maximal 4 Variable. Alles darüber wird in einen String übergeben.
Bei meinen Versuchen (vor den ganzen FW Updates) ist mir vorgekommen, das es je nach anzeigendem Endgerät (Tablet Wlan, PC Lan) bei den langsamen Tablets so ab 10 Variablen teilweise sehr zach war. Vor allem das erste Laden der Seite. Möglicherweise ist es jetzt schneller oder anders gelöst. Wenn Du einmal das Teilchen fürs Entstringen in javascript hast, geht's eh recht einfach.

Beim Schreiben hab ich alles auf eine AWP Variable? (ich weiß immer noch nicht ob das jetzt richtig so heist) pro Schreibdatei umgestellt. Siehe: https://www.sps-forum.de/simatic/90816-cpu-1515-fw-v2-5-web-zugriff-2.html#post683279
Das ist meines erachtens auch bei der Webseiten Programmierung viel einfacher, da nur ein Javascript Schreibteil programmiert wird, und die Tasten, auch wenn es 100 sind, einfach mit einem oder mehreren Indizis, ihre Funktion an den String übergeben. Theoretisch könnte man ein ganzes Projekt mit einer Kommunikations Variablen abbilden, was möglicherweise am schnellsten ist, und die geringste Code Menge in der SPS hätte.
 
Zurück
Oben