#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)
Change History (14)
by , 13 years ago
| Attachment: | Email_FrauBremm.pdf added |
|---|
comment:1 by , 13 years ago
| Priority: | kurzfristig → mittelfristig |
|---|
by , 13 years ago
| Attachment: | Email_Bremm_20130710.pdf added |
|---|
by , 13 years ago
| Attachment: | Email_Bremm_20130409.pdf added |
|---|
by , 13 years ago
| Attachment: | GC9300_28KW.xlsx added |
|---|
comment:2 by , 13 years ago
| Priority: | mittelfristig → kurzfristig |
|---|
comment:3 by , 13 years ago
TODO: -> DONE:
- 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 -> OK
- Sekunden dürfen bei Alarm kommt / geht nicht abgeschnitten werden (Prüfen) -> OK
comment:4 by , 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 , 13 years ago
| Attachment: | Email_2_Bremm_20130711.pdf added |
|---|
comment:5 by , 13 years ago
| Cc: | added |
|---|
comment:6 by , 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.
comment:7 by , 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.
TODO:
- Was passiert wenn Timeout ü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!
- G485-Archiv löscht Intervall-DEI bevor Std-Archiv diesen noch verwenden kann (Für jede AG eigenen DEI verwalten? Löschen intelligenter gestalten.)
comment:8 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:9 by , 13 years ago
| Cc: | removed |
|---|
Note:
See TracTickets
for help on using tickets.
Weitere Anmerkungen von Frau Bremm bez. V.1.336-068 siehe Email vom 10.07.2013.