Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#122 closed Verbesserung (fixed)

DSfG - Archive / - Logbuch --- Frau Bremm

Reported by: Melanie Hermann Owned by: Melanie Hermann
Priority: kurzfristig Milestone:
Component: Gesamtsystem Version:
Severity: unkritischer Fehler Keywords:
Cc:

Description

Anmerkungen von Frau Bremm zu den Tests vom 09.04.2013/10.04.2013:

  • 10.04.2013 07:53:46 beginnt das Timeout > Kein Extraeintrag in der DSfG bezüglich beginnendem Timeout (Alarm)
  • 10.04.2013 11:32:16 endet das Timeout > Auch hier kein Extraeintrag in der DSfG bezüglich quittiertem Timeout (Alarm)
  • Mittelwert um 12:00:00 Uhr wird als ungestört eingetragen, obwohl das Timeout bis 11:32:16 angedauert hat
  • Status fehlt bei, als ungesört marktiertem, Mittelwerteintrag
  • Timeout im DSfG-Logbuch wird als Ersatzwert gekennzeichnet -> falsch

Attachments (5)

Email_FrauBremm.pdf (15.0 KB ) - added by Melanie Hermann 13 years ago.
Email_Bremm_20130710.pdf (35.2 KB ) - added by Melanie Hermann 13 years ago.
Email_Bremm_20130409.pdf (35.2 KB ) - added by Melanie Hermann 13 years ago.
GC9300_28KW.xlsx (18.0 KB ) - added by Melanie Hermann 13 years ago.
Email_2_Bremm_20130711.pdf (69.2 KB ) - added by Melanie Hermann 13 years ago.

Download all attachments as: .zip

Change History (14)

by Melanie Hermann, 13 years ago

Attachment: Email_FrauBremm.pdf added

comment:1 by Melanie Hermann, 13 years ago

Priority: kurzfristigmittelfristig

by Melanie Hermann, 13 years ago

Attachment: Email_Bremm_20130710.pdf added

by Melanie Hermann, 13 years ago

Attachment: Email_Bremm_20130409.pdf added

by Melanie Hermann, 13 years ago

Attachment: GC9300_28KW.xlsx added

comment:2 by Melanie Hermann, 13 years ago

Priority: mittelfristigkurzfristig

Weitere Anmerkungen von Frau Bremm bez. V.1.336-068 siehe Email vom 10.07.2013.

comment:3 by Melanie Hermann, 13 years ago

TODO:

  • Kal. kommt / geht hat keine sekundengenauen Zeitstempel in den DSfG-MW-Archiven, nur im Logbuch -> OK
  • Timeout kommt / geht wird gar nicht in den DSfG-MW-Archiven eingetragen (liegt daran, dass Alarme erst in die DSfG-MW-Archive eingetragen werden, wenn eine Analyse beendet wird. Da aber beim Timeout keine Analyse mehr beendet wird, wird dieser Alarm auch nie in die DSfG-MW-Archive eingetragen!) -> OK
  • Alarm kommt / geht ereignisorientiert?! D.h. wenn Ereignis auftritt sofort Eintrag ins DSfG-MW-Archive (genauso wie DSfG-Logbuch) und nicht auf beendete Analyse warten? -> OK
  • MW-Eintrag wird als ungestört gekennzeichnet obwohl in dieser Stunde ein Fehler anlag -> TODO
  • Sekunden dürfen bei Alarm kommt / geht nicht abgeschnitten werden (Prüfen) -> OK
Version 2, edited 13 years ago by Melanie Hermann (previous) (next) (diff)

comment:4 by Melanie Hermann, 13 years ago

DONE:

  • Kal. kommt / geht hat nun auch in den DSfG-MW-Archiven einen sekundengenauen Zeitstempel
  • Bei Kal. geht wird in der DSfG-DEI-Bitleiste auch 0x0200 gesetzt

by Melanie Hermann, 13 years ago

Attachment: Email_2_Bremm_20130711.pdf added

comment:5 by Melanie Hermann, 13 years ago

Cc: volker heinemann added

comment:6 by Melanie Hermann, 13 years ago

Änderungen:

  • err_tab.txt:
    Zuordnung der DSfG-Fehlerkategorien angepasst
  • utils.h:
    Neues enum eStream definiert
  • gcerrors.cpp, SetDSfGError():
    • Verwendung von eStream
    • Bei eALL, eREF und eKAL werden für alle Streams Einträge erzeugt
    • Bei Störungen und Rechnerfehlern wird DEI neu gesetzt
  • dsfgmana.cpp, Do_Archiv():
    • FILLEVT_NEUMESS führt nicht mehr zu zusätzlichen MW-Einträgen
    • FILLEVT_ALARM führt nun zu zusätzlichen MW-Einträgen (Aufruf von fillArchiv())
  • dsfgmrg.cpp, fillArchivGruppe():
    • Einträge machen, wenn "fillEvent & FILLEVT_HALTEWERT & FILLEVT_ALARM"
  • buildDSfGDei() prüft DO Kal. läuft und setzt entsprechend 0x0200
  • arvFill_Alarm_Ana() sorgt mit FILLEVT_ALARM_ANA dafür, dass Alarme, die die Analyse beeinflussen, in die DSfG-MW-Archive eingetragen werden
  • Bei Fehler geht werden die Bits im DEI in dem MW-Eintrag wieder gelöscht, sofern kein weiterer Fehler ansteht
  • gcerrors.cpp, FehlerInGroupInStreamDa():
    Neue Funktion, die von buildDSfGDei() verwendet wird. Somit werden die Fehlerbits streamspezifisch gesetzt.
  • Neue Matrixelemente angelegt um DEIs für Intervalle für jeden Stream zwischen zu speichern. (BitsQuat[4], BitsHour[4], BitsDay[4], BitsMonth[4])
  • dsfgmrg.cpp, fillArchivGruppe():
    • Wenn Eintrag durch Intervall entsteht wird der entsprechende DEI verwendet und danach auf Null gesetzt
  • DSFG.TAB:
    Vorher:
    19  L  BitsMeas  S  BitsDay    - -  wnayd          FRM_DSFG_HEX
    20  L  BitsMeas  S  BitsHour   - -  wnayd+dei+qei  FRM_DSFG_HEX
    25  L  BitsMeas  S  BitsMonth  - -  wnayf          FRM_DSFG_HEX
    27  L  BitsMeas  S  BitsQuat   - -  wnayh+qei      FRM_DSFG_HEX
    

Nachher:

19  -  -         S  BitsDay    - -  wnayd          FRM_DSFG_HEX
20  -  -         S  BitsHour   - -  wnayd+dei+qei  FRM_DSFG_HEX
25  -  -         S  BitsMonth  - -  wnayf          FRM_DSFG_HEX
27  -  -         S  BitsQuat   - -  wnayh+qei      FRM_DSFG_HEX
  • MW-Eintrag wird aus allen guten Analysen berechnet und DEI wird über das letzte Intervall gebildet. Anschliessend wird dieses DEI auf 0x0000 gesetzt, genauso wie beim Gerätestart. Für das Rücksetzten wird nun das Flag intern von fillArchivGruppe() bis DSfGWriteOk() durchgeschleift.
  • Falls ein MW-Eintrag entsteht bevor eine Analyse gemacht wurde, wird dieser mit DEI 0x0001 eingetragen, da die Meldung POR kommt / geht den DEI setzt.
  • BitsHour-DEI wird erst gelöscht wenn beide AGs (AG1: G485Mittelw und AG5: Mittelw/Std) diesen verwendet haben.
  • Problem: Was passiert wenn Fehler über mehrere Stunden ansteht? Bsp.: Timeout kommt 13:59:00 -> MW-Eintrag 14:00:00 mit gestörtem Intervall-DEI -> Rücksetzen des Intervall-DEI -> MW-Eintrag 15:00:00 mit ungestörtem Intervall-DEI??? Nach Rücksetzen prüfen ob immer noch Fehler ansteht, wenn ja, sofort wieder setzen.
    Lösung: dsfgmrg.cpp, fillArchivGruppe(): Nach dem Verwenden des Intervall-DEI wird buildDSfGDei() aufgerufen und somit der Intervall-DEI neu gesetzt falls immernoch ein Fehler ansteht oder momentan Kalibriert wird. Hierzu wurde utils.h eingebunden.


Last edited 13 years ago by Melanie Hermann (previous) (diff)

comment:7 by Melanie Hermann, 13 years ago

Geklärt:

  • Status von Neustart kommt / geht im DSfG-Logbuch grün. Ok? Soll nicht rot sein wie andere Fehler?
    Erklärung: Beim Schreiben des Eintrags in das Logbuch wird per gcwert::DSfGgetStatus() geprüft ob momentan noch ein Fehler anliegt. Wenn ja, was normalerweise der Fall ist, wird der Wert rot markiert (Fehler kommt). Wenn allerdings bei Gerätestart der Fehler POR kommt nachgetragen wird steht dieser Fehler ja nicht mehr an, somit wird der Eintrag grün markiert.
  • GC-Log zeigt "Alarm GC9300" und DSfG-Logbuch zeigt "Neustart GC9300 (Bios)". Das liegt daran, dass die DSfG per dsfgEvtToErrnum() herausfindet um welche Fehlernummer es sich handelt. Nun ist es so, dass Fehler 8 (POR Bios) und 9 (POR) beide die DSfG-Fehlernummer 407 erhalten haben. Da nun die Schleife bei Fehler Nr.8 als erstes vorbei kommt und dort die DSfG-Fehlernummer findet, wird zurückgegeben, dass die DSfG-Fehlernr 407 zu GC-Fehlernr 8 gehört. Obwohl in manchen Fällen die GC-Fehlernr. 9 richtig wäre. Lösung: Die Fehlernummern gedreht. Jetzt erscheint die Meldung im DSfG-Logbuch immer ohne "Bios".
Last edited 13 years ago by Melanie Hermann (previous) (diff)

comment:8 by Melanie Hermann, 13 years ago

Resolution: fixed
Status: newclosed

comment:9 by Melanie Hermann, 13 years ago

Cc: volker heinemann removed
Note: See TracTickets for help on using tickets.