Steinitz / Verspätete Ventilschaltung

[Melanie Hermann]

Problem:
Ventile schalten bei Wechsel auf Kal. / Ref. zu spät. Diese schalten erst nach 13 - 17 Sekunden. Sollten aber nach ca. 6 Sekunden schalten.

[Melanie Hermann]

Folgende Geräte wurden ursprünglich in Steinitz installiert:

• PGC9303: 13086009
• PGC9303: 13216003
• GC9300-Controller: 1104 (V1.340)
• GC9300-Controller: 1106 (V1.340)

Mittlerweile sind wohl folgende Geräte in Steinitz installiert:

• PGC9303: 1207604
• PGC9303: 14166008
• GC9300-Controller: 16540 (V1.610)
• GC9300-Controller: 16541 (V1.610)

[Melanie Hermann]

GC9300 > OK

[Melanie Hermann]

GC9300 > NOK

[Melanie Hermann]

Steinitz GC9300-Configuration

[Melanie Hermann]

Bisherige Ergebnisse:

• Folgendes verursacht keine Verzögerung:
  • FFSDISK. Die war sauber.
  • SDKarte. Richtiger Typ wird eingesetzt und Schreibgeschwindigkeit der SDKarte ist nicht schlechter.
  • PicoMOD. Auch nach Tausch der PicoMOD keine Veränderung.
  • Hardware. Auch nach Tausch des kompletten Controllers keine Veränderung.
  • Volle Archive. Auch nach Löschen der Archive keine Veränderung.
  • Protokolle. Auch nach Deaktivierung aller Protokolle keine Veränderung.

• Folgendes verursacht (vllt.) Verzögerung:
  • Es liegt an EVars!
  • Wenn die dritte Säule aktiviert wird, verzögert sich die Ventilschaltung um ca. 2 - 3 Sekunden! Diese Verzögerung kann bei jeder akt. Software beobachtet werden (1.612 / 2.000)!
  • Herr Gambs hat versucht das Verhalten in Butzbach zu verifizieren:
    • 9303 mit 3 aktiven Säulen: 3 Analysen = 4 Sekunden
    • 9303 mit 2 aktiven Säulen: 2 Analysen = 7 Sekunden, 3 Analysen = 5 Sekunden
    • 9303 mit 3 aktiven Säulen: 1 Analyse = 9 Sekunden, 1 Analyse = 5 Sekunden, 1 Analyse = 4 Sekunden
  • Somit haben die Tests in Butzbach das Verhalten leider nicht immer wiedergespiegelt wie hier in Beindersheim ...

[Melanie Hermann]

Hinweis: Wann schaltet GC die Ventile?

• GC startet Messung
• Wenn Messwerkstatus == RUNNING && Analysenzeit != 0 >> GC schaltet Ventile

[Melanie Hermann]

Test: Wann beginnt Messwerk seine Runtime hoch zu zählen?
Mittels ModbusTester wurden einige MB-Register aus dem Messwerk ausgelesen und geloggt. Es hat sich gezeigt, dass das Messwerk sofort 1 Sekunde nach dem Entlüften der Ventile (Klackern) und 2 Sekunden nach Injektion (LastInjectionTime) mit dem Hochzählen seiner Runtime beginnt.

Fazit:
Da Runtime im Messwerk immer 2 Sekunden nach Injektion zu Laufen beginnt, dürfte der GC9300-Controller max. 6 Sekunden nach Injektion die Ventile schalten. Denn die Funktion DoStep1() hat eine Zykluszeit von ca. 4 Sekunden.

[Melanie Hermann]

Test: MB-Kommunikation mit Wireshark mitschneiden

• Unterschiede 2 und 3 Säulen
• Antwortzeiten des Messwerks
• Wie häufig fragt Controller an

• 3 Säulen: Das MB-Register 1026 (CurrentRunningTime) wird alle 5 Sekunden (+- 100 ms bis 300 ms) abgefragt
• 2 Säulen: Das MB-Register 1026 (CurrentRunningTime) wird alle 4 Sekunden (+- 100 ms bis 300 ms) abgefragt
• Antwortzeit des Messwerks liegt immer bei ca. 100 ms Sekunden

[Melanie Hermann]

TODO:
Prüfen welche Bedingungen zu Verzögerungen der Ventilschaltung führen könnten.

Ergebnis:

• Aktivieren weiterer Säulen im Messwerk und dadurch mehr MB-Kommunikation

[Melanie Hermann]

TODO:
Genauen Programmablauf bei Ventilumschaltung nachvollziehen.

Ergebnis:
Test in Release-Modus mit TRACES und Diagnose-Log auf Debug-PicoMOD6 (2 Säulen):

Für den Test wurden neue Diagnose-Log-Einträge erstellt. Zudem wurde das Messwerk zyklisch vom ModbusTester abgefragt. Der Test hat gezeigt, dass der Controller sofort, wen er feststellt, dass die Runtime im MW != 0 ist, die Ventile schaltet. Zudem konnte nachvollzogen werden, dass der Controller aufgrund seiner Zykluszeit von ca. 4 Sekunden, meist erst etwas später merkt, dass die Runtime im MW gestartet wurde. Somit entstehen die Verzögerungen beim Schalten der Ventile.
Normalerweise sollte der Controller die Runtime sekündlich überwachen, wenn eine Analyse gestartet wurde, um dann ggf. sofort die Ventile schalten zu können.
Warum die Verzögerung in Steinitz so groß ist/war ist jedoch immer noch unklar ...

Siehe angehängte Datei Ablauf_Ventilschaltung.odg

TODO:
Prüfen welcher Teil in DoStep1() so viel Zeit benötigt...

Ergebnis:

• CP4900-Status holen (meist 2 Sek.)
• CP4900 Säulenstati holen (meist 1 Sek.)
• Am Ende der Fkt. (dann kommt Sleep(1000))
• > Insgesamt 4 Sekunden Zykluszeit für DoStep1()

TODO:
MB-Kommunikation nicht in eigenem Thread()?

Ergebnis:

• CGc
  • m_mbId
  • m_threadGc
• CMbId
  • m_modbus
• CModbusMaster
  • m_threadMbMaster

• > CMbId sollte auch in MBMaster-Thread laufen! Nur dann wäre die Kommunikation mit dem Messwerk tatsächlich in einem eigenen Thread!

TODO:
Warum dauert MB-Kommunikation so lange?

[Melanie Hermann]

Mitte Dezember soll der Controller in Steinitz getauscht werden. Eventuell gibt es dann neue Infos...

[Melanie Hermann]

Bis heute nichts mehr davon gehört...