HARD_DISCONNECT

[SvenJoedicke]

Hallo Herr Dreyer,

wir haben das Problem, dass nach einem gewissen Datentransfer scheinbar der Socket wegfliegt. Die MQTT-Library meldet den Fehler "HARD_DISCONNECT" und vom MQTT-Broker (mosquitto) wird der Fehler geloggt, dass der Socket einen Fehler hatte. Kennen sie dieses Fehlerbild ???

we have a problem, that the socket has an error while running. The MQTT-Library report the error message "HARD_DISCONNECT" and the broker (mosquitto) logs the message "socket error". Do you know anything about this error?

MFG / with kind regards S Jödicke

[stefandreyer]

Hallo Herr Jödicke,

es gibt einige Möglichkeiten für den hard Disconnect. Bitte schauen sie in die ErrorHistory im HANDLE_MQTT FB. Da sollte der genaue Grund stehen.

there are some resons which could lead to a Hard Disconnect. Please have a look in the ErrorHistory in the HANDLE_MQTT FB. There should be exact reason.

BR Stefan

[SvenJoedicke]

Ok, danke für den Support. Ich werde es demnächst prüfen, aktuell komme ich nicht dazu...

Ok, thank you for support. I want to check your suggestion in the near future...

[SvenJoedicke]

Guten Morgen Herr Dreyer,

ich habe mal einen Snapshot gemacht, von den Fehlern, die gemeldet werden. Sagt ihnen dieses Fehlerbild etwas???

MFG Sven Jödicke

Good Morning Mr. Dreyer,

i've take a snaphot of the errorlog, which was reported. Do you know this error pattern ??? with kind regards Sven Jödicke

[SvenJoedicke]

Guten Morgen Herr Dreyer,

ich analysiere weiterhin den Fehler "HARD_DISCONNECT", konnte ihn aber jetzt die letzten Tage nicht mehr reproduzieren, bekomme aber nun eine andere mysteriöse Meldung und habe irgendwie das Gefühl, dass die beiden Fehlermuster zusammenhängen. Kennen sie die Gründe, wie diese Fehler zustande kommen???

Also ich als Leihe würde sagen, dass einer der beiden Teilnehmer auflegt, also die HMI oder die PLC. Ich versuche gerade nur herauszufinden wer. Haben sie eine Idee 1. was es tatsächlich ist und wenn einer auflegt 2. das herausfinden kann??

Meine nächste Idee/Handlung den Log vom Mosquitto-Broker analysieren.

Good Morning Mr. Dreyer,

my tests in last few days give me an another error patter. Can you tell me the meaning?

with kind regards Sven Jödicke

[stefandreyer]

Hallo Herr Jödicke,

das Timeout kommt nur wenn er sich verbinden(neu) will, und dabei keine Antwort vom Broker bekommt. Da muss noch was davor geschehen sein, Sollte in den ErrorHistory Array zu sehen sein. Mal mit Codesys rein schauen, speichert 1000 events.

Das mit dem Reorder ist nur eine Info, ohne Aktion danach.

The Timeout only trigger when the client try to(re)connect. There must something happend bevor, see ErrorHirstory Array, take a look with Codesys. The Array stores 1000 events.

The Reoder entry does have no evenct, only info.

Mit freundlichen Grüßen

StefanDreyer

[SvenJoedicke]

Also ich logge eigentlich alle Meldungen mit und zu dem besagten Zeitpunkt, kam tatsächlich nur die Meldung REORDER_PUBLISH_OUTGOING.

Generell hätte ich dazu mal ne Frage. Wo kann man denn nachlesen, was diese Meldungen denn bedeuten?

Des Weiteren könnte man ja eigentlich davon ausgehen, wenn der Client in den TimeOut geht und keine Verbindung aufbauen kann, der Fehler eigentlich beim Broker liegen müsste???

So, actually i am logging all messages and at the moment of error there was only the message REORDER_PUBLISH_OUTGOING.

In general i have question belongs to kinds of messages. Where can i read the meaning of the messages in a document perhaps???

Furthermore, one could actually assume that if the client goes into TimeOut and cannot establish a connection, the fault should actually lie with the broker ???

Mit freundlichen Grüßen / With kind regards Sven Jödicke

[SvenJoedicke]

Was bedeutet die Meldung "CONNECTION_REFUSED" ?? In welchem Zusammenhang wird diese Meldung gefeuert?

[stefandreyer]

Hallo Herr Jödicke,

um an die Quellen der Fehler zu kommen: Es gibt eine Aufzählung wo diese alle aufeglistet werden, von da aus können sie über die Querverweise abspringen: Da kann man aus dem Quellcode lesen was los ist, oder ich habe was dazu geschrieben:

Bei den Fehler CONNECTION_REFUSED wird noch der Fehler vom IP_CONTROL mit gelogt und steht im entsprechendem ERROR_HISTORY Eintrag. Die Bedeutung kann man dann in der OSCAT NETWOK LIB Anleitung nachlesen:

Wenn keine Verbindung aufgebaut werden kann, kann das auch ein Netzwerk Firewall etc. Problem sein. Da Bringt wohl nur ein Wireshark Mittschnitt Aufklärung. Weiterhin kann es sein das Pro Zyklus mehr als ein Fehler Auftritt, vielleicht geht das bei ihrem Log unter, meine History speichert da alle.

Viel Erfolg, wenn es ein Problem meiner Bibliothek ist, hoffe ich wir kommen dem auf die Fersen, wäre nicht der erste...

Mit freundlichen Grüßen

Stefan Dreyer

[SvenJoedicke]

Okay, daran hatte ich auch schon gedacht... So werde ich jetzt auch vorgehen... Ich tippe nachwievor auf den Broker... Wir haben auch schon rausgefunden, dass beim Versionssprung vom Mosquito MQTT Broker auf Version 1.6.12a mit dem Zusatz auf Bugfixes bezüglich memory leaks hingewiesen wird... Und wir hatten halt die Version 1.6.8... es ist ein memory leak nicht ausgeschlossen... Und bei unseren Test prügeln wir pro Nacht ca. 1million Nachrichten durch, also schon eine ganze Menge... Und wenn sich der handle_mqtt Baustein wieder fängt, dauert das reproduzierbar 25s... Wenn wir im Task Manager den Broker neustarten, dauert es lediglich 5 Sekunden... Meine Vermutung für die 25s ist, dass das Aufräumen des Speichers mehr Zeit benötigt...

Ich halte sie auf dem laufenden...

Mfg Sven Jödicke

stefandreyer notifications@github.com schrieb am Di., 10. Nov. 2020, 21:55:

Hallo Herr Jödicke,

um an die Quellen der Fehler zu kommen: Es gibt eine Aufzählung wo diese alle aufeglistet werden, von da aus können sie über die Querverweise abspringen: [image: image] https://user-images.githubusercontent.com/41088808/98730989-55b9a700-239d-11eb-8259-9f2e26e70dc1.png Da kann man aus dem Quellcode lesen was los ist, oder ich habe was dazu geschrieben: [image: image] https://user-images.githubusercontent.com/41088808/98732300-4176a980-239f-11eb-9e23-e3e58eeaf3c4.png

Bei den Fehler CONNECTION_REFUSED wird noch der Fehler vom IP_CONTROL mit gelogt und steht im entsprechendem ERROR_HISTORY Eintrag. Die Bedeutung kann man dann in der OSCAT NETWOK LIB Anleitung nachlesen: [image: image] https://user-images.githubusercontent.com/41088808/98731261-c2cd3c80-239d-11eb-87de-90df93f0c199.png [image: image] https://user-images.githubusercontent.com/41088808/98731843-99f97700-239e-11eb-916f-a3f595baa703.png

Wenn keine Verbindung aufgebaut werden kann, kann das auch ein Netzwerk Firewall etc. Problem sein. Da Bringt wohl nur ein Wireshark Mittschnitt Aufklärung. Weiterhin kann es sein das Pro Zyklus mehr als ein Fehler Auftritt, vielleicht geht das bei ihrem Log unter, meine History speichert da alle.

Viel Erfolg, wenn es ein Problem meiner Bibliothek ist, hoffe ich wir kommen dem auf die Fersen, wäre nicht der erste...

Mit freundlichen Grüßen

Stefan Dreyer

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stefandreyer/CODESYS-MQTT/issues/47#issuecomment-724961077, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCEVSBI5V3JEWBHV46QUJ3SPGSFTANCNFSM4Q7WPV2A .

[stefandreyer]

Hallo Herr Jödicke,

die 25s sind bei einem Spontanten Ausfall?

Auf Codesys Seite geht das Aufräumen schnell...

Mit freundlichen Grüßen

Stefan Dreyer

[SvenJoedicke]

Hallo Herr Dreyer,

ja das mit dem 25s betrifft wirklich nur den IPC mit dem Broker... Die PLC macht aus meiner Sicht alles richtig... Wir tappen halt gerade nur im Dunkeln und müssen herausfinden, wer wirklich auflegt. Meine Vermutung nachwievor, der Broker weil Memory Leak... Die PLC reagiert richtig...

[image: image.png]

MFG Sven Jödicke

On Wed, Nov 11, 2020 at 7:43 AM stefandreyer notifications@github.com wrote:

Hallo Herr Jödicke,

die 25s sind bei einem Spontanten Ausfall?

Auf Codesys Seite geht das Aufräumen schnell...

Mit freundlichen Grüßen

Stefan Dreyer

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stefandreyer/CODESYS-MQTT/issues/47#issuecomment-725235308, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCEVSCYLQIUDWLBBQIXVDTSPIXA3ANCNFSM4Q7WPV2A .

[SvenJoedicke]

[image: image.png] [image: image.png] [image: image.png]

On Wed, Nov 11, 2020 at 7:43 AM stefandreyer notifications@github.com wrote:

Hallo Herr Jödicke,

die 25s sind bei einem Spontanten Ausfall?

Auf Codesys Seite geht das Aufräumen schnell...

Mit freundlichen Grüßen

Stefan Dreyer

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stefandreyer/CODESYS-MQTT/issues/47#issuecomment-725235308, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCEVSCYLQIUDWLBBQIXVDTSPIXA3ANCNFSM4Q7WPV2A .

[stefandreyer]

Hallo Herr Jödicke,

ihre Bilder sind irgendwie auf der Strecke geblieben ;)

Vielleicht wollen sie mal alternativ diesen aufsetzten:

https://www.hivemq.com/docs/hivemq/4.4/user-guide/getting-started.html#download

Dann wissen sie obs der broker ist oder nicht.

MfG

Stefan Dreyer

[SvenJoedicke]

So, hier nochmal ein paar Bilder vom Log...

Also wir haben tatsächlich einen anderen Broker jetzt im Einsatz und leider muss ich sagen, dass der Verbindungsabbruch nach wie vor noch da ist... (Bitte nicht wundern, die RTC ist nicht richtig eingestellt)

Also ich debugge jetzt mal weiter. Aber nur kurz an Sie die Frage, werden Sie aus dem Log schlau?

An dieser Stelle wird bei CONNECTION_REFUSED das Feld ERROR_T auf 2 gesetzt.

Mit diesen Wert wird dann die lokale Variable aus dem HANDLE_MQTT Baustein "DoDisconnect" auf TRUE gesetzt, sodass der HARD_DISCONNECT eingeleitet wird:

Leider erschließt mich der Kontext nicht ganz. Haben Sie eine Idee?

MFG Sven Jödicke

[stefandreyer]

Hallo Herr Jödicke,

der Fehler kommt aus der Oscat network Bibliothek und da wird gemeldet:

Das verbirgt sich hinter dieser Zahl: Mit meinem HARD_DICONECT räume ich dann nur meine Ablauf auf, ist also nur eine Reaktion. Wie es zu dem Verbindungsabbau kommt ist also die Frage. Das kann auch ein PLC Thema sein, welche nutzen sie? Laufen auch andere Verbindungen auf der PLC?

Wie ist ihr Test Setup? Vielleicht kann ich das hier in meinem Umfeld laufen lassen.

MfG

Stefan Dreyer

[SvenJoedicke]

Hallo Herr Dreyer,

ich kläre das mal ab, wie wir eventuell ein Test-Setup bereitstellen können. Eine Teamviewer-Verbindung zu unserem Testsystem (PLC etc.) mit VPN und einem Codesys-Gateway, dem Projekarchiv müsste Ihnen ja reichen ?

MFG Sven Jödicke

[stefandreyer]

Das Projektarchiv wäre ein Anfang.

Meine E-Mail Adresse haben sie ja.

MfG

Stefan Dreyer

[SvenJoedicke]

Ich muss mal schauen, dass ich was aufbereite... Aktuell brennt hier nur die Hütte und ich komme gar nicht dazu, diesen Fehler endlich zu finden...

MFG Sven Jödicke

On Mon, Nov 23, 2020 at 9:14 AM stefandreyer notifications@github.com wrote:

Das Projektarchiv wäre ein Anfang.

Meine E-Mail Adresse haben sie ja.

MfG

Stefan Dreyer

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stefandreyer/CODESYS-MQTT/issues/47#issuecomment-732000782, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCEVSG4YM4ABERPXPRWJV3SRIKVLANCNFSM4Q7WPV2A .

[SvenJoedicke]

Hallo Stefan Dreyer,

Ich habe mit meinem Chef über einen Zugang gesprochen. Generell ist er nicht abgeneigt und daher habe ich auch schon Vorbereitungen getroffen. Aber bevor wir diesen Schritt gehen, soll ich nochmal Debuggen. Also das Zuschalten einer firmen-fremden Person als letzten Ausweg quasi.

Daher habe ich jetzt einfach mich mal versucht, was das debuggen angeht. Leider werde ich aus dem Quellcode nicht sehr schlau. Das liegt zum einen daran, dass wir die OSCAT NETWORK hausintern nicht benutzen (Wir benutzen ganz klassisch die SysSocket-Lib) und daher der Erfahrungsschatz fehlt und zum andern halt einfach fremder Quellcode ist und der bekanntermaßen immer etwas schwer zu lesen ist.

Wenn sie also sagen, dass der Fehler aus der OSCAT kommt, können sie das für mich vll eingrenzen? Also welcher Baustein (FunctionBlock) wirft diesen Fehler, sodass ich dort rein debuggen kann.

Bzw. möchte ich bei fallender Flanke der Variable MQTT_INFO.MQTT_CONNECTED auch andere Variablen tracen und da stellt sich für mich die Frage, welche Variablen aus der OSCAT-Lib würden sich da anbieten?

MFG Sven Jödicke

On Wed, Nov 18, 2020 at 10:16 AM stefandreyer notifications@github.com wrote:

Hallo Herr Jödicke,

der Fehler kommt aus der Oscat network Bibliothek und da wird gemeldet: [image: image] https://user-images.githubusercontent.com/41088808/99509124-ad4fa800-2985-11eb-925a-1d210e37b947.png

Das verbirgt sich hinter dieser Zahl: [image: image] https://user-images.githubusercontent.com/41088808/99509233-cb1d0d00-2985-11eb-830d-9c70039ca1b2.png Mit meinem HARD_DICONECT räume ich dann nur meine Ablauf auf, ist also nur eine Reaktion. Wie es zu dem Verbindungsabbau kommt ist also die Frage. Das kann auch ein PLC Thema sein, welche nutzen sie? Laufen auch andere Verbindungen auf der PLC?

Wie ist ihr Test Setup? Vielleicht kann ich das hier in meinem Umfeld laufen lassen.

MfG

Stefan Dreyer

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stefandreyer/CODESYS-MQTT/issues/47#issuecomment-729545559, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCEVSBYQU3NBRSR27RUH2TSQOGIFANCNFSM4Q7WPV2A .

[stefandreyer]

Hallo Herr Jödicke,

Ihr Chef macht das per se Richtig, Fremdzugriffe aufs Firmennetz sind weitesgehend zu Vermeiden.

Für Ihr Debuggen, ich bin nochmal in die Sache Eingetaucht. Die Stelle an der der Disconect triggert habe ich aus einem Beispiel der OSCAT Network Lib. Soweit so gut. Für Ihren Trace würde ich Folgende Punkte vorschlagen, da scheint das dann feiner zu Werden:

Aus Bibliothek CommonTypesAndFunction:IP_CONTROL (FB)

--> pResault

hier bytes_sent.

Für weitere Fragen stehe ich gern zur Verfügung.

Mit freundlichen Grüßen

Stefan Dreyer

[stefandreyer]

Hallo Nochmal,

was ich noch sagen wollte: Ich warte auf nen CODESYS Dongle, dann will ich auch mal nen Dauertest machen und mal schauen wie stabil es bei mir ist.

MfG

Stefan Dreyer

[annD-annD]

Hallo zusammen,

falls ich beim Testen etwas beitragen kann - ich nutze einen PFC200 und sende Daten an einen lokalen Mosquitto-Broker. Auf einem Proxmox-Server ist IoBroker installiert und hat alles abonniert. Mit meinen wenigen z.B. Temperaturwerten läuft das sehr stabil.

Gruß annD

[stefandreyer]

Hi,

ich habe ne neue Version hoch geladen. Funktionell hat sich nichts geändert. Die Reorder Einträge schaffen es aber nun nicht mehr im default in die History, kann man aber Einschalten.

Bitte testet mal den testLongTime(FB). testen.

Im Standart geht der gegen broker.hivemq.com und macht so 500 Telegramme pro Sekunde und Richtung. Im Aufruf könnt ihr den ziel Broker ändern.

@Sven, bitte mal gegen lokale Infrastruktur testen, mal sehen wie der Sich macht. @annD-annD einfach mal auf der PFC200 laufen lassen und mal in der ErrorHistory schauen, obs Verbindungs Abbrüche gibt.

Gutes gelingen

Ich seh mal zu das ich hier nen aktuellen mosquitto bekomme.

Grüße Stefan

[stefandreyer]

Hi,

hab nun nen aktuellen mosquitto(Windows) hier laufen. Ist schon beeindruckend:

Grüße

[SvenJoedicke]

Danke für die Unterstützung... Was ist denn die Erwartungshaltung, wenn ich das jetzt teste???

Mfg Sven

stefandreyer notifications@github.com schrieb am Mo., 30. Nov. 2020, 20:26:

Hi,

ich habe ne neue Version hoch geladen. Funktionell hat sich nichts geändert. Die Reorder Einträge schaffen es aber nun nicht mehr im default in die History, kann man aber Einschalten.

Bitte testet mal den testLongTime(FB). testen.

Im Standart geht der gegen broker.hivemq.com und macht so 500 Telegramme pro Sekunde und Richtung. Im Aufruf könnt ihr den ziel Broker ändern.

@sven https://github.com/sven, bitte mal gegen lokale Infrastruktur testen, mal sehen wie der Sich macht. @annD-annD https://github.com/annD-annD einfach mal auf der PFC200 laufen lassen und mal in der ErrorHistory schauen, obs Verbindungs Abbrüche gibt.

Gutes gelingen

Ich seh mal zu das ich hier nen aktuellen mosquitto bekomme.

Grüße Stefan

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stefandreyer/CODESYS-MQTT/issues/47#issuecomment-735991606, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCEVSBNZFZSQQMDHED7SOLSSPWWLANCNFSM4Q7WPV2A .

[SvenJoedicke]

Guten Morgen,

ich habe die Nacht mal ein Trace aufgezeichnet mit der vorgeschlagenen Variable.

Die Werte schwanken im Normalbetrieb zwischen 0 und 518 (Connection OKAY). Und wenn die Verbindung abreißt, dann fällt der Wert auf 0 zurück...

MFG Sven Jödicke

[SvenJoedicke]

Hallo Herr Dreyer,

ich habe gesehen, dass sich ein paar globale Variablen in der Benamung etc. geändert haben. Zu diesen Kontanten habe ich generell eine Frage. Sind diese globalen Konstanten zur Konfektionierung Lib gedacht, also soll man mit denen die Eigenschaften steuern der Lib steuern können? Falls ja, würde ich vorschlagen, diese globalen Konstanten als dynamische Konstanten auszulegen, sodass man auf Applikationsebene entscheiden kann, wie man sich die Lib konventionier und das von Applikation zu Applikation durchaus verschieden. Da müsste man dann nicht parallel Libs halten, wenn man das differiert konfektionieren möchte...

MFG Sven Jödicke

[SvenJoedicke]

Hallo an alle Tester,

ich möchte euch nur mal einen Richtwert geben, wieviele Nachrichten wir extrem asynchron (8 Topics, also 8 Publisher, unterschiedliche eventbasierte Notifies, durchaus mit 100ms RefreshRate) so über die Nacht über den Äther schicken...

Also ca. 1,5 Millionen Nachrichten drücken wir in unserem Test durch...

MFG Sven Jödicke

[stefandreyer]

Hallo Herr Jödicke,

Bei so einem Trace habe ich immer ein schlechtes Gefühl, ob da ein Wischer in einem Zyklus wirklich aufgezeichnet wird. Wie sind da ihre Erfahrungen? Vielleicht müsste man da wirkliche eine Fangschaltung machen, analog der ErrorHistory.

Die globale Konstanten die ich geändert haben sind nur für die ErrorHistory(ENUM ERRORS), haben also keinen Einfluss auf die Lib. Haben sie da solche Kandidaten wegen welchen sie die Bibliothek parallel halten? Packen würde ich die dann in MQTT_IN_OUT wie schon andere Sachen, da kann man dann mehrere Instanzen pro Applikation verwalten.

Zu dem Test FB: Erwartungshaltung: Standartisierter Belastungstest für Vergleichbare Ergebnisse. Ich habe ihn jetzt doch mal auf meinem häuslichen Raspi in Betrieb genommen und lasse ihn mal Laufen. macht Pro Minute 120000 Telegramme. Wenn der bei mir oder anderen ne Zeit lang ohne Probleme durchläuft ist es per se kein Problem der Bibliothek. Dann können wir uns auf anderes Sachen Konzentrieren, oder eben die Bibliothek Debuggen. Deswegen schreibe ich jetzt auch die gesendeten und empfangenen Bytes, sowie die Anzahl der Telegramm mit in die Error History. Habe jetzt in 45 min ca. 2Millionen Telegramme durch, ohne Abbruch, mal sehen wie sich das Entwickelt.

Passiert das Grundsätzlich in jeder Nacht in der Sie testen, das es zu einem Abbruch kommt? Welchen QoS Level der Telegramme benutzen sie für den Test? Bei mir läuft das immer mit QoS 2.

Mit freundlichen Grüßen

Stefan Dreyer

[SvenJoedicke]

Hallo Herr Dreyer,

das nenne ich mal nen Durchsatz, Respekt... Senden sie diese Telegramme nur über einen Publisher oder auch mehrere, und das asynchron?

Ja, im Prinzip kommt dieser HARD_DISCONNECT fast in jeder Nacht...

Wir arbeiten aktuell komplett auf QOS Level 0.

MFG Sven

[stefandreyer]

Hallo Herr Jödicke,

sind 46 publisher, 46 Verschiedene Topics mit zufälligen Payloads, alle Asynchron. Wie gesagt, der FB ist in der neuen Bibliothek zum Anschauen.

Sind jetzt 12 Millionen Pakete durch, kein Disconect. Ich lass das mal bis morgen früh weiter laufen, dann stelle ich mal auf QoS 0 um, vielleicht liegt da der Hase im Pfeffer.

MfG

Stefan

[SvenJoedicke]

Ok, klingt gut...

Im schlimmsten Fall liegt es an der Steuerung...

Wie kann ich beweisen, das es die Steuerung ist????

Leider haben wir das Problem nicht nur sporadisch sondern reproduzierbar, aber leider im Feld.

[stefandreyer]

Beweisen würde gehen: Raspi und Steuerung neben einander(Raspi bräuchte Lizenz). Beide an den selben Switch Beide Verbinden zu dem Selben Broker. Auf Beiden läuft ausschließlich mein Test FB(Eventuell Topics und Clientname differenzieren). Schauen wer Probleme macht.... MfG

Stefan

[SvenJoedicke]

Naja, der Raspi wird das schon rocken... Ich suche eher ein Beweis, den ich mit einem Trace machen kann.

[SvenJoedicke]

Eine wichtige Frage hätte ich noch... Ist die Lib Threadsafe????

Also der HANDLE_MQTT läuft in einem eigenen TASK mit 10ms und Prio 11 und alle Publisher laufen in einem anderen Task zusammen auf 20ms mit Prio 24...

[SvenJoedicke]

Ist das eigentlich normal, dass das pResult zwischen 0 und 518 flackert und scheinbar zufällig???

[stefandreyer]

Hallo,

naja ich glaube nicht das es einen Trace Nachweis geben wird. Solange nicht nachgewiesen wird, dass das gleiche Setup auf anderer Hardware Problemlos läuft, würde ich meine PLC als Fehlerfrei ansehen. Gibts vielleicht n Firmware Update für ihre PLC?

Hab gerade nochmal nachgeschaut. pResult wird bei einigen Aufrufen der SysSocket lib verwendet, also ist der Trace recht nutzlos(gerade gemerkt). man müsste für jeden Aufruf eine eigene Variable machen. Und dann noch meine Skepsis was Wischer angeht.

Nein, die Bibliothek ist explizit nicht Thread Safe, dachte ich hätte das irgendwo vermerkt. Auf eine Single Core CPU dürfte das nichts machen. Haben sie Multicore mit Multicorelizens?

Update: 27Millionen Pakete seit 09:45

MfG

Stefan

[stefandreyer]

Können sie mir Ihr Test Projekt per Mail zukommen lassen?

MfG

[SvenJoedicke]

Können sie mir Ihr Test Projekt per Mail zukommen lassen?

MfG

Ich weiß nicht, ob Ihnen das Projekt was nützt. Das würden Sie auf einem Raspi nicht zum Laufen bringen können, da es eine Eckelmann-spezifische Treiberschicht gibt...

Nein, bei uns ist das Single-Core... Ich habe den MQTTHandle-Aufruf jetzt in den Haupttask gelegt, sodass wir ein Threadproblem ausschließen können. Meine nächste Hypothese war/ist, dass es sich um ein Task-Jitter-Problem handeln könnte... Mir ist aufgefallen, dass ich einen HARD_DISCONNECT bekommen hatte, als ich einen Haltepunkt gesetzt hatte irgendwo im Quellcode... Gleiches Verhalten könnte ja durchaus auch JITTER verursachen.

Ich habe jetzt die PLC-Zykluszeit hochgesetzt, sodass der Scheduler genug Zeit hat, den Task deterministisch abzuarbeiten und der JITTER niedrig bleibt zusätzlich zu dem, dass ich alles in einem Thread laufen lasse...

[SvenJoedicke]

Okay, also JITTER scheint es nicht zu sein und auch nicht das Multithread-Problem. Habe mal die Zykluszeit relativ hoch gestellt, sodass der Scheduler das packt, und bisher war jeder Task im Rahmen. Und trotzdem ist es aufgetreten.

Was ich relativ unkompliziert anbieten kann, ist ein Aufschalten auf unseren Testrechner per Teamviewer, zu Zeiten, wenn es ihnen passt. Falls das auch in ihrem Sinne und Interesse ist.

MFG Sven Jödicke

[SvenJoedicke]

Guten Morgen, mit QOS-Level = AtLeastOnce (1) kam es die Nacht tatsächlich nicht zu einem HARD_DISCONNECT !!!

Eine Frage zu dem Durchsatz (27Millionen Pakete seit 09:45) hätte ich trotzdem. Wo läuft denn der Broker?? Auf den Raspi als localhost ??? Oder läuft der in einem Netzwerk ???

Bei uns läuft der Broker natürlich nicht auf der Steuerung, dass heißt wirklich durch den Äther und nicht localhost.

Stefan, kannst du mich heute noch mal telefonisch kontaktieren?

MFG Sven

[stefandreyer]

Hallo,

also, hier ein Kurzer Abriss, habe den test FB ca. 24h Laufen Lassen. Setup: TestFB auf nem Raspi - Consumer Switch - Windows PC- Windows VM - Mosquitto mosquitto-1.6.12a-install-windows-x64.exe als Dienst. Ergebnisse waren Folgende, ohne Verbindungsabbrüche auf QoS 2:

Ca. 91 Millionen Pakete ohne Fehler. Dann auf QoS 0 gestellt und es hangelt einen Verbindungsabbruch nach dem anderen auf dem Mosquitto broker. Ein test mit broker.hivwmq.com ist deutlich Stabiler! Nur mal ein Problem, das ein Ping Paket verlohren ging.

Scheint also eher ein Problem des Brokers zu sein, oder in Kombi. Ich werde mein Test Setup optimieren und dann den Wireshark dazwischen hängen. Im Wireshark habe ich auch schon ein Reset auf TCP Ebene von beiden Partnern gesehen.

Ich melde mich dann mal.

Grüße

[stefandreyer]

Hat es etwas gebracht?

Grüße

[SvenJoedicke]

Hallo,

also der Test gestern hat leider nicht so viel gebracht. 14:30 habe ich angestartet und 18:30 kam wieder ein HARD_DISCONNECT. Welchen wichtigen Stellen in der Common haben sich denn geändert? Würde es sich lohnen, dorthin zu schauen per Haltepunkt oder Trace?

MFG Sven

[stefandreyer]

Hi,

hat sich nur eine Stelle geändert: IP_CONTROL:

Dort würde sich nur ein Haltepunkt lohnen. Ob der Trace sowas mitbekommt ???

Ich werd mal ne VErsion machen, die mehr über die Gründe loggt.

Grüße

[stefandreyer]

Hi Sven

hast du meine E-Mails erhalten?

Grüße

[SvenJoedicke]

Bin leider bisher nicht zum Testen gekommen. Die Tests die ich mit der neuen Lib gemacht haben, haben aber wie schon erwähnt nicht zum Erfolg geführt.

[stefandreyer]

Könnt ihr mal nen Test mit HiveMQ machen?

Grüße

[SvenJoedicke]

HiveMQ ist entweder kommerziell lokal verfügbar oder halt in der Cloud kostenlos. Soweit ist mein Informationsstand. Beides können wir so nicht nutzen.

[stefandreyer]

Hi,

habe heut Nacht noch einen Test mit "test.mosquitto.org" gemacht. Habe meinen Test FB im 100ms Zyklus laufen lassen. 14Millionen Pakete, keine Abbrüche. Irgendwo liegt der Hase bei euch im Pfeffer. Vielleicht sollten wir nochmal Telefonieren. Grüße