Messwerk-Timeout

[Melanie Hermann]

GC läuft mit Simulation und bringt dann Messwerk-Timeout.
Der Controller sendet folgende Befehle: H, SMB, J und C.
Es sieht so aus, als würden die Anfragen gar nicht bei der Simulation ankommen.
Läuft dann irgendwann von alleine wieder los.

TODO:

• Kommunikation prüfen.
• Service-Log befüllen

[Melanie Hermann]

Änderungen:

• CP4002Prot.cpp:
  • Trans(): DT_CP4002PROT_CAN_WRITE_FAILED
  • Recv(): DT_CP4002PROT_RECEIVE_FAILED

[Melanie Hermann]

TODO:
Mit echtem Messwerk testen.

[Melanie Hermann]

Hinweis:
Mögliches Kommunikationsproblem könnte an dem Recv-Event liegen, das beim Empfangen von Daten per CAN gesetzt wird.
Vielleicht ist es besser kein Event zu setzen, sondern die Daten direkt in RecvFomCAN() weiterzuverarbeiten. (Wie bei ERZChrom, RecvDataFromCP().)

[Melanie Hermann]

Änderungen:

• CCP4002-Klasse: Neue Membervariable CMyTimer *m_myTimer
• CCP4002Prot(): Erstellen des Timers
• ~CCP4002Prot(): Aufräumen des Timers
• Transmit(): Setzen der Timergrenze
• Trans(): Setzen der Timergrenze und Starten des Timers
• Recv(): Empfangen der Daten / Prüfen auf Timeout jetzt mit Timer realisiert
• RecvFomCAN(): Setzen des Receive-Events entfernt

[Melanie Hermann]

TODO:

• Mit Simulation testen, ob weiterhin unerklärliche Timeouts auftreten.
• Mit realem Messwerk testen.

[Melanie Hermann]

Änderungen:

• Transmit(): Set_MaxSecs() setzt Limit jetzt wirklich in Sekunden und nicht mehr in Millisekunden.
• Trans(): Set_MaxSecs() setzt Limit jetzt wirklich in Sekunden und nicht mehr in Millisekunden.
• Recv(): Wenn Timer abgelaufen ist, wird ret = -1; gesetzt. Timer wird nach jedem Receive gestoppt.

[Melanie Hermann]

TODO:

• Mit Simulation testen, ob weiterhin unerklärliche Timeouts auftreten.
• Mit realem Messwerk testen.

[Melanie Hermann]

Anmerkung:

• Seit mit MyTimer gearbeitet wird, läuft der GC stellenweise etwas langsam / ruckelig.

TODO:

• Verbesserung überlegen
• Doch wieder auf SetEvent-Variante umsteigen und nochmals nach den Timeouts schauen.

[Melanie Hermann]

Änderungen:

• Wieder auf SetEvent-Variante umgestiegen
  • Applikation läuft nun wieder viel flüssiger
• Nach Kommunikationsfehlern wird eine Pause von 200 ms eingelegt
• Nach drei Kommunikationsfehlern wird Messwerk-Timeout gemeldet und der normale Ablauf wird unterbrochen und der Ident vom Messwerk wird angefordert

[Melanie Hermann]

Hinweis:

• Während dem Spülen wird kein Timeout erkannt. Denn in dieser Zeit sendet das Messwerk keine Daten.

[Melanie Hermann]

ES IST WIEDER EIN TIMEOUT AUFGETRETEN!

[Melanie Hermann]

• CCP4002Prot::Trans(): wird ausgeführt
• WriteCanQueue(): wird ebenfalls ausgeführt und ruft CanWrite() auf
• CCanOut::ThreadFunc(): hier kommt Befehl nicht an! Kein Befehl mit diesem Identifier!

• CCanOut::cnt wächst über 150 an. Problem? Größere Pausen zwischen Senden?

[Melanie Hermann]

TODO:

• Prüfen wo Sendebefehl hängen bleibt.

[Melanie Hermann]

FEHLER KANN NICHT NACHGESTELLT WERDEN!
...

[Melanie Hermann]

Test: Alle Traces wieder entfernt und auf AUTORUN gestellt.

Diagnose-Log:
12:58:45 12.03.2014 CP4002Prot (COM2): CP4002Prot an COM2 geöffnet
13:25:11 12.03.2014 CAN-OUT: Write-Queue: 151 Overload
14:48:04 12.03.2014 CAN-OUT: Write-Queue: 151 Overload

NEUSTART

16:09:17 12.03.2014 CP4002Prot (COM2): CP4002Prot an COM2 geöffnet
16:10:09 12.03.2014 CAN-OUT: Write-Queue: 152 Overload

[Melanie Hermann]

Diagnose-Log:
08:04:25 13.03.2014 CP4002Prot (COM2): CP4002Prot an COM2 geöffnet
10:08:58 13.03.2014 CAN-OUT: Write-Queue: 151 Overload

[Melanie Hermann]

Test: PGC9000VC in Betrieb genommen und angeschlossen!

• Nach einer Weile wieder Timeout.
• cmIdentifier von Hand angepasst, Befehl wird auf COM3 rausgesendet.
• Receive funktioniert auf COM2, nur Transmit geht schief.

• Vermutung: Problem liegt an BIOS. Stephan schaut nach.

[Melanie Hermann]

Stephan hat eine BIOS-Testversion erstellt. Diese zeigt das Empfangen einer CP4002-CAN-Nachricht von der GC-Applikation und das Senden einer CP4002-CAN-Nachricht an das Messwerk per LEDs an.

Diese Version wird momentan nicht verwendet, da die Kommunikation momentan fehlerfrei läuft.