TIA Leerer/ungültiger Json String per MQTT lässt Cpu in stop gehen

[Pharaun]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tag,
Ich lasse in TIA V18 via LMQTT Bibliothek (https://support.industry.siemens.co...ikation-für-simatic-controller?dti=0&lc=de-BG) einen Json String übertragen und benutze dann die Siemens LStream Bibliothek (https://support.industry.siemens.co...ek-für-daten-streams-(lstream)?dti=0&lc=de-CH) um diesen Json String "auszulesen". Es funktioniert soweit ganz gut, nur wenn kein korrekter Json String übermittelt wird (oder z.b. bei start des Programms gar keiner), geht die SPS sofort in Stop mit einem Übersetzungsfehler im LStream Baustein "LStream_JsonDeserializer".

Hier sieht man die erste Stelle im Schreibgeschützen LStream_JsonDeserializer Baustein die einen Übersetzungsfehler erzeugt. Ich verstehe die Zeilen nicht ganz, aber wird hier nicht gecheckt ob ein korrekter JSON Stream vorliegt oder so?

Wie kann ich verhindern das die SPS auf Stop geht? Vorher irgendwie den Json stream überprüfen bevor ich ihn an den Baustein weiterreiche? Ich finde es viel zu riskant diese Bibliothek in ein Programm einzubauen wenn sie jederzeit die gesamte SPS und somit Anlage Still legen könnte.

 

[DCDCDC]

Es ist immer sicherzustellen, dass wenn Messages published werden, die auch ein gültiges Json Format haben.

Auf der Steuerung kannst du ja bedingt deinen subscribe ausführend und danach auch vergleichen ob der Inhalt im Datenstrom ungleich Leer ist und damit dann erst das deserialisieren anstossen.

Zu hoffen, dass beide Systeme zu jedem Zeitpunkt das richtige tun wäre mir zu esoterisch

 

[Thruser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es ist immer sicherzustellen, dass wenn Messages published werden, die auch ein gültiges Json Format haben.

Falsch, der Empfänger hat sicherzustellen, daß er mit unerwartetem Ergebnis zurechtkommt und sich nicht einfach dadurch abschießen läßt.

Gruß

 

[DeltaMikeAir]

Es ist immer sicherzustellen, dass wenn Messages published werden, die auch ein gültiges Json Format haben.

Falsch, der Empfänger hat sicherzustellen, daß er mit unerwartetem Ergebnis zurechtkommt und sich nicht einfach dadurch abschießen läßt.

Ich würde ja beides favorisieren.

 

[DCDCDC]

Ich würde ja beides favorisieren.

Ich auch..

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Falsch, der Empfänger hat sicherzustellen, daß er mit unerwartetem Ergebnis zurechtkommt und sich nicht einfach dadurch abschießen läßt.

Gruß

Sollte aber auch im Sinne des Anwenders sein, sofern in seinen Möglichkeiten nur saubere Json Datenströme zu versenden.

Aber ja, du hast recht. Hatte bisher auch noch keine Probleme damit, dass mir bei leeren Topics die Steuerung in Stop geht.

Die Meldung aus dem Puffer der Steuerung wäre hier noch interessant.. wahrscheinlich ein Overflow.. @Pharaun

 

[Pharaun]

Hier ist der Fehler:






Dieser verweist dann via "Im Editor öffnen" auf folgende Stelle:





Jetzt ist nur die Frage, wie überprüft man vorher ob ein korrekter Json String vorliegt (das übersteigt meine Programmierfähigkeiten), oder wie lässt man das Programm trotzdem durchlaufen, darf ja dann auch gerne mist am Ende rauskommen, aber SPS in Stop gehen geht halt garnicht.

 

[DCDCDC]

Du kannst zB mit MQTT Explorer dir mal die Message auf dem Topic anschauen und entweder in Notepad++ mit Json Plugins arbeiten und nach fehlerhafter Formatierung schauen oder zB mit dem Online Tool https://jsonlint.com/

Wer ist denn der Teilnehmer welcher deiner Steuerungen die Messages bereitstellt und welchen Broker nutzt ihr/du?

Im Instanzdatenbaustein deiner Funktion solltest du auch schauen können welcher Wert aktuell die Variable statLastChar hat

Im Bereich receivedMsgPayload siehst du ja auch den Datenstrom als Bytes.

Ist der Empfangsbereich der Mqtt Funktion überhaupt groß genug gewählt um die Nachricht komplett zu empfangen?
Der muss nämlich mindestens so groß gewählt sein, wie die größte Nachricht, die du erwartest

Ein Zeichen sind ein Byte, in Notepad++ siehst du ja auch die Zeichenanzahl.

 

[Oberchefe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vermutlich hat #statLastChar im Fehlerfall einen Wert von 0. Die nachfolgende indirekte Adressierung (und evtl. weiteren Code) in diesem Fall nicht ausführen.

Evtl. liegt das Problem schon früher und #statCountOfRaw oder #statEawIndex haben unpassende Werte.

 

[Thruser]

Hi,

dem Baustein wird ja ein Bytearray übergeben, in dem die JSON Daten stehen (besser Array of Char und nullterminierter String). Im Abschnitt davor wird ermittelt an welcher Position das letzte Zeichen im Array ist.

Danach wird geprüft, ob der JSON String 'compressed' ist also ohne Zeilenumbruch (Anforderung laut Doku der Bibliothek). Dazu wird geprüft, ob vor dem letzten Zeichen '}' eines der Zeilenendezeichen vorhanden ist.

Wenn Du nun zu Anfang ein leeres Bytearray übergibst wird ja gleich das erste Zeichen als letztes Zeichen ermittelt und das Programm versucht auf das Zeichen davor zuzugreifen wodurch eine Speicherverletzung stattfindet. Das müßte man eigentlich in dem Programm noch abfangen. Prüfen, ob #statLastChar == 0 ist

Ich würde daher das Bytearray mit einem Dummy JSON String vorbelegen, eventuell würde sogar schon ein einzelnen Leerzeichen reichen.

Gruß

 

[maxder2te]

Wie kann ich verhindern das die SPS auf Stop geht? Vorher irgendwie den Json stream überprüfen bevor ich ihn an den Baustein weiterreiche? Ich finde es viel zu riskant diese Bibliothek in ein Programm einzubauen wenn sie jederzeit die gesamte SPS und somit Anlage Still legen könnte.

Realistisch betrachtet kannst du den JSON-Parser Debugger und absichern dass er mit unkorrekten Streams zurecht kommt.
Oder du schreibst dir deinen eigenen Parser.

 

[Pharaun]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

dem Baustein wird ja ein Bytearray übergeben, in dem die JSON Daten stehen (besser Array of Char und nullterminierter String). Im Abschnitt davor wird ermittelt an welcher Position das letzte Zeichen im Array ist.

Danach wird geprüft, ob der JSON String 'compressed' ist also ohne Zeilenumbruch (Anforderung laut Doku der Bibliothek). Dazu wird geprüft, ob vor dem letzten Zeichen '}' eines der Zeilenendezeichen vorhanden ist.

Wenn Du nun zu Anfang ein leeres Bytearray übergibst wird ja gleich das erste Zeichen als letztes Zeichen ermittelt und das Programm versucht auf das Zeichen davor zuzugreifen wodurch eine Speicherverletzung stattfindet. Das müßte man eigentlich in dem Programm noch abfangen. Prüfen, ob #statLastChar == 0 ist

Ich würde daher das Bytearray mit einem Dummy JSON String vorbelegen, eventuell würde sogar schon ein einzelnen Leerzeichen reichen.

Gruß

Also, das Problem habe ich gelöst in dem ich vorher überprüfe ob byte1 und byte 2 nicht null sind, im Array das verarbeitet wird.

Jetzt taucht natürlich ein neuer Fehler auf, viel tiefer im Programm, wenn kein richtiger Json String sondern z.b. nur "AB" im Array steht:







Wenn ich das Array komplett beschreibe, damit es nicht leer ist, taucht der Fehler dann hier auf:


Die Endgültige Lösung scheint zu sein, search zu aktivieren und ihn zu zwingen nach festen Begriffen im Json String zu suchen, dann crasht er auch nicht bei unlesbaren Daten.

 

[DCDCDC]

Ich weiß nicht was du machst, aber ich hatte noch nie Probleme mit den Bausteinen gehabt für die Mqtt subscription. Auch bei leeren Anfragen nicht. Auch nicht wenn ich einfach nur test als Message im Topic hinterlegt hatte. Da scheint ja auch beim anderen Client irgendwas schief zu laufen.

 

[Pharaun]

Ich weiß nicht was du machst, aber ich hatte noch nie Probleme mit den Bausteinen gehabt für die Mqtt subscription. Auch bei leeren Anfragen nicht. Auch nicht wenn ich einfach nur test als Message im Topic hinterlegt hatte. Da scheint ja auch beim anderen Client irgendwas schief zu laufen.

Die MQTT Bausteine sind ja nicht das Problem. Sondern die Lstream Bibliotheken.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die MQTT Bausteine sind ja nicht das Problem. Sondern die Lstream Bibliotheken.

Die meinte ich inbegriffen. Mir ist da noch keine Steuerung auf Stopp gegangen..

Da der Client ja geheim bleibt genauso wie der Inhalt von korrekten Messages und fehlerhaften, ist eine Diagnose halt schwierig.
Den Broker den du einsetzt kennen wir ja auch noch nicht..