CP4002 auf Win-Com (COM7)

[Melanie Hermann]

Falls sich Timeout mit Test-Bios nicht reproduzieren lässt ist es vllt besser das CP4002-Protokoll auf einer Windows-Schnittstelle laufen zu lassen.

TODO:

• Parallel zu den Tests mit dem Test-Bios CP4002-Protokoll auf einer Win-COM einbauen und ebenfalls testen.

[Melanie Hermann]

Als mögliche Win-Com wird Com7 gewählt, da diese als default auf RS232 eingestellt ist und hier bisher nur das Modbus-Protokoll zur Verfügung steht.

[Melanie Hermann]

Da das Messwerk jetzt auf COM7 (Win-Com) und nicht mehr auf COM2 (CAN-Com) angeschlossen wird, musste auch das EZChrom-Protokoll angepasst werden.

• Vorher: Mic (Win-Com) <-> Cp (CAN-Com)
• Jetzt: Mic (Win-Com) <-> Cp (Win-Com)

[Melanie Hermann]

Änderungen:

• mtx_tab.txt:
  • Modus EZChrom für COM7 eingebaut.
  • Modus EZChrom für COM2 entfernt.
• gcvars.cpp:
  • chk_ComBaudrate_6(): Neue Funktion. Fix 9600 Baud.
  • chk_ComBits_6(): Neue Funktion. Fix 8N1.
  • chk_ComMode_6(): Neue Funktion. Fix CP4002-Protokoll.
  • chk_ComBaudrate_1(): Auskommentiert.
  • chk_ComBits_1(): Auskommentiert.
  • chk_ComMode_1(): Auskommentiert.
• InOut.cpp:
  • SetComModeAndParameter(): ComMode_1_CP4002 auskommentiert und ComMode_6_CP4002 eingebaut.
  • SerSetBiosParameter(): ComMode_1_CP4002 auskommentiert.
  • WriteCanQueue(): ComMode_1_CP4002 auskommentiert.
  • ReadCanQueue(): ComMode_1_CP4002 auskommentiert.
• GcApp.cpp:
  • SetFixValuesForCM(): Fixe Werte für CP4002-Protokoll auf COM7 setzen
  • InitInstance(): Falls normale GC9300-Applikation und CP4002-Prot auf COM7, wird Modus = AUS auf COM7 gesetzt. Und ModbusSlave wird ebenfalls nur bei normaler GC9300-Applikation gestartet.
• CAN.cpp:
  • ThreadFunc(): CAN_ID_COM2_RXD tut nichts mehr
• CP4002Prot.cpp:
  • Komplett verändert! Keine Kommunikation per CAN-Com (COM2) mehr, sondern per Win-Com (COM7). Bedeutet keine Timeoutüberwachung per Events, sondern per MyTimer.

[Melanie Hermann]

Kommunikation mit Messwerk und auch EZChrom scheinen, nach den ersten Tests, gut zu funktionieren.

TODO:

• Dauertest
• Testen aller möglichen Szenarien (SS/MS, EZChrom, Timeout, ...)

[Melanie Hermann]

Kommunikation läuft ganz gut.
Aber ab und zu werden nicht alle Daten einer Analyse empfangen und dann wird die komplette Analyse verworfen. Meist fehlen um die 10 Bytes.
Deshalb wurde das Timeout, ab dem 2ten Byte, von 2 auf 3 Sekunden erhöht.
Jetzt muss geprüft werden ob jetzt immer alle Bytes der Analysen empfangen werden.

[Melanie Hermann]

Mehr als 100 Analysen wurden fehlerfrei übertragen. Aber dann kam doch ein Timeout.

[Melanie Hermann]

Rücksetzen des Timers, der das Timeout überwacht, wurde intern etwas abgeändert.
Denn vorher konnte es vorkommen, dass nach dem Rücksetzen die Timeoutzeit nicht wie gewollt 3, sondern nur 2 Sekunden beträgt. Jetzt sollte die Timeoutzeit garantiert immer 3 Sekunden sein.

Änderungen:

• MyTimer.cpp:
  • StartTimer(): Setzt nicht mehr direkt m_expiryCounter und m_aktSecs, sondern die Flags m_resetExpCounter und m_resetAktSecs
  • ResetExpCounter(): Setzt nicht mehr direkt m_expiryCounter, sondern das Flag m_resetExpCounter
  • ResetTimer(): Setzt nicht mehr direkt m_expiryCounter und m_aktSecs, sondern die Flags m_resetExpCounter und m_resetAktSecs
  • ResetTimerWithNewMaxSecs(): Setzt nicht mehr direkt m_expiryCounter und m_aktSecs, sondern die Flags m_resetExpCounter und m_resetAktSecs
  • ThreadFunc(): Hier werden die tatsächlichen Variablen, m_expiryCounter und m_aktSecs, zurückgesetzt.

TODO: Testen, ob noch Timeouts auftreten.

[Melanie Hermann]

Trotz einer Timeoutzeit von 4 Sekunden gab es weiterhin noch vereinzelt Timeouts.
Es liegt also wohl nicht (nur) an der Timeoutzeit.
Allerdings lief gleichzeitig auf dem GC-Rechner die GC9300-Mathe-Test-Applikation im Debugger.

[Melanie Hermann]

Gemerkt, dass es ja die Struktur COMMTIMEOUTS zum Handhaben der Timeouts bei Com-Schnittstellen gibt.

Änderungen:

• m_recvTimer wieder komplett aus CCP4002Prot entfernt
• COMMTIMEOUTS in CP4002Prot eingebaut
• Timeout, ab dem 2ten Byte, wieder auf 2 Sekunden zurückgestellt
• CCP4002Prot::Trans() und CCP4002Prot::Recv() geändert

[Melanie Hermann]

TODO:

• Testen mit Messwerk

[Melanie Hermann]

Änderungen:

• CCP4002Prot::Recv(): Sleep(200) eingebaut wenn CP_START
• CP_ANADATA_TIMEOUT_2 von 2000 auf 3000 ms erhöht

TODO:

• Testen mit Messwerk

[Melanie Hermann]

Wenn das Messwerk neugestartet wird, schlägt die Datenübertragung bei den ersten beiden Analysen immer fehl. Danach läuft alles ohne Probleme.

TODO:

• Herausfinden warum die ersten beiden Analysen Probleme machen.
• Problem beheben

[Melanie Hermann]

Änderungen:

• Änderungen vom 09.05.2014 rückgängig gemacht.
  • Sleep(200) aus CCP4002Prot::Recv() entfernt
  • CP_ANADATA_TIMEOUT_2 von 3000 auf 2000 ms wieder gesenkt

Beobachtung:

• 10% Abweichung bei Säulentemperaturen erlaubt:
  • Analysenstart sofort, wenn MesswerkStatus OK > NOK
  • Analysenstart 1 Min warten, nach MesswerkStatus OK > NOK
  • Analysenstart 2 Min warten, nach MesswerkStatus OK > OK

• 1% Abweichung bei Säulentemperaturen erlaubt:
  • Analysenstart sofort, wenn MesswerkStatus OK > NOK
  • Analysenstart 1 Min warten, nach MesswerkStatus OK > OK
  • Analysenstart 2 Min warten, nach MesswerkStatus OK > OK

Das Messwerk scheint also nicht sofort bereit zu sein, obwohl es laut Temperaturen und Drücken bereit sein müsste.

Info:
Bei Gambs nachgefragt. Es ist nicht bekannt, dass es nach dem Neustart eines Messwerks solche Probleme gibt. Sobald sich das Messwerk mit OK meldet, beginnt der GC9000 mit Analysen und diese sind von Anfang an korrekt.
Zudem ist dieses Problem mit der Timeoutüberwachung per Timer oder bei der Kommunikation per CAN-Schnittstelle auch nie aufgetreten.

[Melanie Hermann]

Timeoutdefines für Messwerkkommunikation überarbeitet:

• 'J' = 5 Sekunden
• 'N' = 2 Sekunden
• 'C' = 5 Sekunden
• 'H' = 5 Sekunden
• 'D' = 5 Sekunden
• 'START' = Sampletime * SampletimeFaktor + 35 Sekunden (hier: 110 Sekunden)
• Timeout zwischen Zeichen = 2 Sekunden

[Melanie Hermann]

Siehe auch Ticket #47.