CP4002 auf CAN-Com (COM2)

[Melanie Hermann]

TODO:

• Applikation muss noch mit original Messwerk getestet werden.
• Verhalten mit dem alten Controller vergleichen.

[Melanie Hermann]

• PGC9000VC wurde in Betrieb genommen
• Methode wurde aus GC9000-Controller entnommen

[Melanie Hermann]

Kommunikation mit Messwerk läuft nicht rund!

[Melanie Hermann]

Änderung:

• RecvFromCAN(): Sleep(200) eingefügt. > Keine Kommunikationsfehler mehr.

[Melanie Hermann]

Änderungen:

• RecvFromCAN(): Sleep(200) wieder entfernt.
• Alle TRACES entfernt
• m_bytesSollRecv (Anzahl Analysendaten) und m_recvTimeoutSec (Receive-Timeout) werden bei CP_START anhand der Runtime aus der Methode berechnet. Denn die Runtime ist variabel und nicht immer fix 70 Sekunden.

// Z.B.: 70Sec * 100Samples * 3Bytes pro Sample * 2Channels = 42000 Bytes
m_bytesSollRecv  = (AnalyseTime * Samples * 3 * 2);	

// Z.B.: 100Sec * 1000mSec + 5000mSec = 105Sec
m_recvTimeoutSec = ((SMethodBlock.sample_time*1000) + 5000);	

• In ProcessRecvData() werden die Analysendaten auch anhand der empfangenen Anzahl kopiert. Zuvor wurde die Kopierschleife CP_RECEIVE_MAX_LEN mal durchlaufen.

Kommunikation mit Messwerk und Simulation läuft im Moment fehlerfrei!

[Melanie Hermann]

Siehe auch #34.

[Melanie Hermann]

CCP4002Prot und CEZChrom sind jetzt Member von CGcCM und nicht mehr von CGcApp.

[Melanie Hermann]

TODO:
Woher stammen CAN-OUT Write-Queue Overloads in Diagnose-Log?

[Melanie Hermann]

Problem mit Timeouts besteht immer noch.

TODO: Testen mit Testversion des BIOS.

[Melanie Hermann]

Nach 5 Tagen Test mit der Testversion des BIOS ist das Timeout aufgetreten.
Die Alarm-LED blinkt im 10 Sekunden Rythmus. Die Warning-LED blinkt nie.
Sieht so aus als würde das BIOS die Sendebefehle von der GC-Applikation erhalten, diese aber nicht über die Schnittstelle nach draußen geben.
Nach ca 1 Stunde ging das Timeout von alleine wieder weg.
08:11:51 04.04.2014 - 09:13:02 04.04.2014

TODO: Stephan muss in BIOS nachschauen!

[Melanie Hermann]

Für Testzwecke RMGBus auf COM1 eingebaut
(allerdings RMGBus-Telegramm deaktiviert, da auf COM1 Debugausgaben von Bios)

Änderungen:

• mtx_tab.txt: Neue Menüelement RMGBOUT für COM1
• Bios.h: Definition von BIOS_COM1_RMGBOUT
• InOut.cpp:
  • WriteCanQueue(): case ComMode_0_RMGBOUT eingebaut, aber return (true) = kein RMGBus-Telegramm
  • FlushCanQueue(): case ComMode_0_RMGBOUT eingebaut
  • ReadCanQueue(): case ComMode_0_RMGBOUT eingebaut
  • SetSerBiosParameter(): case ComMode_0_RMGBOUT eingebaut
  • SetComModeAndParameter(): case ComMode_0_RMGBOUT eingebaut
• GcApp.h: m_RmgbCanCOM1 definiert
• GcApp.cpp:
  • CGcApp(): Null-Initialisierung von m_RmgbCanCOM1
  • InitInstance(): Initialisierung von m_RmgbCanCOM1
  • ExitInstance(): Zerstören von m_RmgbCanCOM1

[Melanie Hermann]

TODO: Bios-Debugausgaben interpretieren

[Melanie Hermann]

BIOS läuft jetzt schon seit mehreren Tagen auf einem (ab und zu auch auf beiden) GC9300.
Aber seitdem ist kein Timeout mehr aufgetreten!

[Melanie Hermann]

BIOS-TRACE: hh:mm:ss z1 z2 z3 z4 z5 z6 z7 z8

• Uhrzeit
• z1: Anzahl CAN-Telegramme, die von der GC-Applikation beim BIOS angekommen sind
• z2: Anzahl Bytes, die vom BIOS in den Sendepuffer geschrieben wurden
• z3: Gesamtzahl Bytes, die vom BIOS in den Sendepuffer geschrieben wurden
• z4: Restart-Flag: 0 = Normalfall, 1 = Sollte nie vorkommen
• z5: Sendeinterrupt-Flag: 1 = Sendeinterrupt wurde wieder scharf gemacht
• z6: Anzahl, wie oft Sendeinterrupt ausgelöst wurde (Bedeutet nicht, dass etwas gesendet wurde. Puffer könnte auch leer sein.)
• z7: Anzahl, wie oft Sendeinterrupt deaktiviert wurde
• z8: Anzahl Bytes, die automatisch in der Sendeinterrupt-Routine gesendet wurden (passiert, wenn mehr als 1 Byte gesendet wird)

[Melanie Hermann]

23.04.2014 ~ 13:00:00 Uhr:
Dauertest mit GC9300-CM + Laptop (GC9000-Simulation + Terminal) aufgebaut.
GC9300-CM macht Analysen und Terminal schreibt BIOS-Traces in Logdatei mit.

[Melanie Hermann]

Am GC_Unten ist ein Timeout aufgetreten!
14:42:28 23.04.2014 - 14:55:01 23.04.2014

Auswertung BIOS-Traces:
Es konnten keine Fehler festgestellt werden.
Die Daten werden in den Sendepuffer geschrieben.

[Melanie Hermann]

TODO:
Aufzeichnung des Sendesignals per Oszi.
Hier kann erkannt werden, ob tatsächlich ein Signal aus der Schnittstelle kommt oder nicht.

[Melanie Hermann]

Beide GC9300 an Oszi gehängt:

• D10 Pin 7 = GND
• D10 Pin 9 = TxD

TODO:
Warten bis Timeout auftritt und dann Signal an Oszi überprüfen.

[Melanie Hermann]

25:04.2014 ~ 10:45:00 Uhr:
Dauertest beendet, da die BIOS-Traces nicht weiterhelfen.

[Melanie Hermann]

GC9300:

• Original-BIOS: V1.34
• GC9300-CM-App: V2.000, SVN-Rev: 554, 134
• Oszi angeschlossen

Timeout aufgetreten!

• Nach ~ 2 1/2 Stunden ist ein Timeout aufgetreten, das nun schon mehr als 1/2 Stunde anhält
• GC zählt Zähler für unbeantwortete Anfragen hoch
• Oszi zeigt, dass tatsächlich Signale ('J') raus gesendet werden! Allerdings scheint das Senden der Signale zeitversetzt also zu spät zu kommen!
  Das Signal erscheint erst 1 - 3 Sekunden nachdem der Zähler im GC hochgezählt wurde! Es sieht also so aus als ob das Timeout schon zuschlägt, bevor das Signal das Gerät tatsächlich verlässt!

[Melanie Hermann]

GC9300:

• Test-BIOS: V9.34
• GC9300-CM-App: V2.000, SNV-Rev: 555, 134
• Oszi angeschlossen

TODO:
Prüfen, ob TRACES synchron mit Oszi-Signal auftreten. Somit kann überprüft werden, ob das BIOS die CAN-Signale, auch während einem Timeout, sofort nach Empfang von der GC9300-App nach draussen sendet.

[Melanie Hermann]

05.05.2014 12:01:12 - 12:41:33: Timeout!

Während dem Timeout konnte folgendes festgestellt werden:

• TRACES von BIOS werden ausgegeben, d.h. die Signale von der GC9300-Applikation kommen im BIOS an
• Signal wird an Oszi angezeigt, d.h. die Signale werden auch tatsächlich aus der Schnittstelle rausgesendet
• Trace-Ausgabe und Oszi-Signal beinahe Synchron, d.h. im BIOS selbst gibt es keine Verzögerungen, das Signal wird sofort nach Erhalten rausgesendet

Testaufbau:

• GC9300:
  • Original-BIOS: V1.34
  • GC9300-CM-App: V2.000, SVN-Rev: 554, 134
• Laptop CP4002-Simulation
• Oszi angeschlossen

Was wurde getan:

• Laptop: Simulation beendet und Terminal auf geöffnet
• Laptop: Signale vom GC9300 kamen am Terminal an (immer 'J')
• Laptop: Terminal beendet und Simulation wieder gestartet
• Verbindung zwischen GC9300 und Simulation sofort wieder da, GC9300 beginnt wieder mit Analysen!

TODO:

• Was war passiert? Hatte Simulation ein Problem und der Neustart hat es behoben?
• Anschliessend mit realem Messwerk testen, ob dort auch Timeouts auftreten.

[Melanie Hermann]

Fehler ist nun schon seit Tagen nicht mehr aufgetreten.
Test wird vorerst unterbrochen, damit der zweite GC9300 auch zum Testen der aktuellen
Software, mit Kommunikation über COM7, benutzt werden kann.

[Melanie Hermann]

CP4002 läuft nicht auf COM2, sondern auf COM7!