Kommunikation GC9300 - GC9310 hat nicht mehr funktioniert

[Melanie Hermann]

Die Kommunikation zwischen GC9300 und GC9310 hat nicht mehr funktioniert! Aufgetreten ist das Problem nach dem der Messgasdruck eine längere Zeit fehlerhaft war und somit keine neuen Analysen mehr gemacht werden konnten. Nachdem das der Messgasdruck wieder in Ordnung war, hat der GC9300 die Fehler quittiert und hat im Autorun weitergemacht. Allerdings blieb der GC9310 im Fehler und hat auch die neuen Analysenergebnisse nicht angezeigt. Aber die Status-LED des GCProtokolls war grün. Der GC9310 war generell sehr langsam und hat sich dann quasi aufgehängt. Hier hat nur ein Neustart des GC9310 geholfen...

[Melanie Hermann]

Kommentar:
Es ist aufgefallen, dass die Parameterübertragung zwischen GC9300 und GC9310 manchmal nicht funktioniert. Es muss unbedingt geprüft werden woran das liegt!

[Melanie Hermann]

Testaufbau:

• 1x GC9300 (Debug)
• 2x GC9310 (Release)

Beobachtungen:

• Beim Neustart des GC9300 erscheint Meldung "Params werden an GC9310 gesendet". Aber beim GC9310 erscheint nichts. Es wurden also keine Parameter empfangen.
• Zeitsync zwischen GC9300 und GC9310 funktioniert nicht. GC9300 durchläuft CGCProt::SendTimeToGateway(). Aber beim GC9310 kommt keine Uhrzeit an. Es wurde also kein Zeitsync durchgeführt.

• 1) Neustart des GC9300: Keine Veränderung.

• 2) Neustart eines GC9310: Neugestarteter GC9310 hat sofort Parameter und Uhrzeit empfangen. Der andere GC9310 hat weiterhin nichts empfangen.

• 3) Neustart des zweiten GC9310: Auch dieser neugestartete GC9310 hat sofort alle Parameter und Uhrzeit empfangen. Der andere GC9310 hat die Parameter ebenfalls nochmal empfangen. Die Uhrzeit hat er auch empfangen, aber es war kein Sync notwendig.

• 4) Zweiter Neustart GC9300: Parameter und Uhrzeit wird verschickt. Beide GC9310 empfangen die Daten.

Fazit:
Es scheint Fälle zu geben in denen sich die Kommunikation auf Seite des GC9310 "aufhängt". Es ist aber noch unklar woran das liegt.

TODO:
Szenarien erörtern, Fehler finden und beheben!

[Melanie Hermann]

Vorlage für Tests

[Melanie Hermann]

Problem ist auch bei der PTB aufgetreten!!!

[Melanie Hermann]

Änderungen:

• GcProt.cpp:
  • SendDataToGateway(): Wenn Matrixelement mit angegebenem MB-Register nicht gefunden wurde, wird die Funktion nicht mehr über return verlassen, sondern am Ende wird der Lock freigegeben! (Dies war vorher nicht der Fall! Grober Fehler!)
  • Synchronize(): Diese Funktion wurde komplett überarbeitet. Es war ein Denkfehler, dass die Synchronisierung durch das Leeren der Rx-Queue erfolgen kann. Die Synchronisierung muss direkt durch das Lesen des Socket-Buffers geschehen.
  • FillRxMessageQueue(): Wenn Funktion mit Fehlercode verlassen wird, dann muss auch der Lock aufgehoben werden! (Dies war vorher nicht der Fall! Grober Fehler!)

[Melanie Hermann]

Erklärung:
Problem war, dass sich das GW quasi "aufgehängt" hat, wenn ein fehlerhaftes (asynchrones) Telegramm empfangen wurde. Das bedeutet, dass Start- und/oder Endzeichen nicht, wie erwartet, empfangen wurden. Wenn so ein Fehler einmal passiert ist, dann hat sich das GW quasi "aufgehängt" da es seinen Lock nicht mehr freigegeben hat und nicht mehr mit der Rx-Queue arbeiten konnte. Es hat also keine Befehle vom Controller abarbeiten können. Grundsätzlich stand die Verbindung aber weiterhin. Deshalb wurde der Verbindungsstatus zum Controller als OK gemeldet.

[Melanie Hermann]

TODO:
Software wird im Testrack und allen Testrechnern installiert und so gut wie möglich getestet.
Überlegen ob Software zur PTB soll?!

Software wurde am 21.04.2016 ~ 14:30 in allen Geräten installiert.

[Melanie Hermann]

27.04.2016: Software läuft fehlerfrei.