Hallo Forum, ich programmiere gerade eine Applikation, bei welcher auf einem angeschlossenen Display verschiedene Meldungen angezeigt werden können. Diese Meldungen hängen von verschiedenen Faktoren und Variablen hab und stellen Alarme, Hinweise und Sonstiges dar. Bei der Implementierung stoße ich nun auf folgendes Problem: wie handhabe ich Meldungen, welche von mehr als einer Bedingung abhängen? Die Meldung soll angezeigt werden wenn mindestens eine (oder mehr) Bedingung(en) zutrifft(en) und ausgeblendet werden wenn keine Bedingung zutrifft. Angefangen habe ich mit einer Art Counter: jeder Modul meldet sich dort selbst an und wieder ab. Leider sehe ich hier das Problem für die Zukunft, dass man zur Laufzeit schnell die Übersicht verliert. Gibt es hier eine (einfache) Lösung? Programmiert wird das ganze in C / C++. Besten Dank für eure Ideen!
Merk dir doch wer die Meldung ausgelöst hat, statt wieviele Auslöser es gab. Ordne einfach einzelne Bits in deiner Variable einzelnen Auslösern zu. Dann hast du kein Problem mit Doppelmeldungen und kannst jederzeit Feststellen woher die Meldung kommt. Du musst dann nur bei der Anzeige selber zählen (wenn die Anzeigegrenze größer als 1 ist).
Wo soll die Logik sitzen, die festlegt, ob eine Meldung nötig ist? In den einzelnen Modulen? Oder in einer zentralen Stelle vor den Anzeigen, die alle Faktoren sammelt und bewertet?
Danke für eure Rückmeldungen. Dirk D. schrieb: > Merk dir doch wer die Meldung ausgelöst hat, [...] Das Problem bei dieser Idee ist, dass ich mir für jede Meldung merken muss, welches Bit für welchen Auslöser steht. Verschiedene Meldungen hängen ja von unterschiedlichen Auslösern ab, welche sich nicht notwendigerweise überschneiden. Je größer das Projekt wird (was es mal werden soll), desto mehr Arbeit hätte ich dann diese Zuordnung zu pflegen. Tom schrieb: > Wo soll die Logik sitzen, die festlegt, ob eine Meldung nötig ist? > In den einzelnen Modulen? Oder in einer zentralen Stelle vor den > Anzeigen, die alle Faktoren sammelt und bewertet? Die Logik in die einzelnen Module zu implementieren ist aus meiner Sicht keine geschickte Lösung. Momentan gibt es eine Matrix mit den einzelnen Meldungen (eine Art Datentabelle) und einen Meldungshandler, bei welchem der Counter inkrementiert oder dekrementiert wird, je nach ID.
Ich weiß nicht, ob es in dieser Sprache auch die Select-Käse-Möglichkeit gibt. Falls ja, könntest Du sagen: Falls das und das oder das passiert ist, bringe die Meldung: "Wenn Du noch einmal diese Taste drückst, sage ich es Deiner Mutter!" Falls das und das und das und das passiert ist, bringe die Meldung: "So ein Haufen Mist auf einaml darf nicht passieren!" End Falls Print "MfG Paul"
Lars Heitkamp schrieb: > Dirk D. schrieb: >> Merk dir doch wer die Meldung ausgelöst hat, [...] > > Das Problem bei dieser Idee ist, dass ich mir für jede Meldung merken > muss, welches Bit für welchen Auslöser steht. Verschiedene Meldungen > hängen ja von unterschiedlichen Auslösern ab, welche sich nicht > notwendigerweise überschneiden. Je größer das Projekt wird (was es mal > werden soll), desto mehr Arbeit hätte ich dann diese Zuordnung zu > pflegen. Ist das den wirklich nen Problem? Ich stell mir das so vor: du nimmst für jede meldung eine Variable, wenn du Speicher Sparen musst ist die eben grade so groß wie du Auslöser für die Meldungen hast. Sagen wir die Meldung ist "Du solltest Lüften" Dafür gibt es die Gründe: - CO2 Gehalt in der Luft zu hoch - Luft zu Feucht - Es stinkt - seid mehr als 24h nicht gelüftet Dafür brauchst du 4 bit, nimmst als 8. dann definierst du dir 4 Platzhalter, z.b. #define MSG_VENTILATION_REASON_CO2 1 #define MSG_VENTILATION_REASON_HUMID 2 #define MSG_VENTILATION_REASON_STINK 4 #define MSG_VENTILATION_REASON_TIME 8 wenn du deiner variable (needsVentilation) einen grund hinzufögen willst machst du das mit needsVentilation=needsVentilation | MSG_VENTILATION_REASON_HUMID den grund zurückziehen kannst du mit needsVentilation=needsVentilation & ~MSG_VENTILATION_REASON_HUMID einzelne Gründe abfragen mit doesItStink=meedsVentilation & MSG_VENTILATION_REASON_STINK abfragen ob überhaupt gelüftet werden muss einfach indem du needsVentilation auf > 0 prüfst. Die Zuordnumg musst du ja nur einmal Pflegen, und wenn du den Grund für eine Meldung nicht wissen musst brauch ja auch nur das Modul das den Grund steuert darüber bescheid wissen. du musst also nur händisch, oder mit nen bisschen Magie zur build-time 2er Potenzen eindeutig an die gründe übergeben. ... Oder stehe ich grade auf dem schlauch?
Dirk D. schrieb: > ... Oder stehe ich grade auf dem schlauch? Nö, klingt soweit sinnvoll. Auf einem Mikrocontroller mit knappem RAM würde ich auch Diagnose-Bits nehmen und die so verodern. Auf einem PC, der sowieso genug Speicher hat, kann man sich das Bitgepfriemel im Prinzip auch sparen. (wir sind hier bei PC-Programmierung oder?) Man legt einfach so viele Variablen an wie man braucht. So ungefähr kann man das auch machen (Pseudo-Code):
1 | Ursache_1_aktiv = Sensor_hat_ausgeloest(); |
2 | Ursache_2_aktiv = Letztes_Lueften_zu_lange_her(); |
3 | usw. |
4 | |
5 | Diagnosemeldung_1_aktiv_wenn = Ursache_1_aktiv || |
6 | Ursache_2_aktiv || |
7 | Ursache_3_aktiv || |
8 | Ursache_4_aktiv; |
9 | |
10 | Diagnosemeldung_2_aktiv_wenn = Ursache_5_aktiv || |
11 | Ursache_6_aktiv || |
12 | Ursache_7_aktiv; |
usw. Wenn irgendeine Ursache vorliegt, wird die Diagnosemeldung somit auf logisch TRUE gesetzt. Wenn keine Ursache vorliegt, wird sie auf logisch FALSE gesetzt. Et voilà. Man kann gerne alle Diagnosemeldungen in einer Funktion bzw. in einem Modul kapseln, welches man entsprechend benennt. Zum Beispiel diagnostic_messages.c/.h oder void set_diagnostic_messages(). Dann geht einem auch gewiss nicht die Übersicht verloren. Denn was sonst sollte hier wohl drinstecken? ;-) Wenn es wirklich arg viele Diagnosemeldunge sein sollten, kann man diese ja noch weiter unterteilen. Zum Beispiel je nach Subsystem welches betroffen ist.
:
Bearbeitet durch User
Danke für den weiteren Input an Dirk und Mark. Dirk D. schrieb: > [...] > Die Zuordnumg musst du ja nur einmal Pflegen, und wenn du den Grund für > eine Meldung nicht wissen musst brauch ja auch nur das Modul das den > Grund steuert darüber bescheid wissen. > du musst also nur händisch, oder mit nen bisschen Magie zur build-time > 2er Potenzen eindeutig an die gründe übergeben. Das kann tatsächlich funktionieren. Am Ende landet man bei einer weiteren Matrix mit "Alarmsender" auf der einen und den Alarmen selbst auf der anderen Seite. Durch verschiedene Updatemechanismen könnte man hier den Aufwand der Durchläufe auch klein halten. Vereinfacht wird die Sache dadurch, dass das Display ja nicht wissen muss wer den Alarm ausgelöst hat. Übergabe erfolgt also nur bis zur neuen Matrix. Mark B. schrieb: > Nö, klingt soweit sinnvoll. Auf einem Mikrocontroller mit knappem RAM > würde ich auch Diagnose-Bits nehmen und die so verodern. > > Auf einem PC, der sowieso genug Speicher hat, kann man sich das > Bitgepfriemel im Prinzip auch sparen. (wir sind hier bei > PC-Programmierung oder?) Man legt einfach so viele Variablen an wie man > braucht. So ungefähr kann man das auch machen (Pseudo-Code): > > [...] Das verwendete System hat sowohl einen PC als auch einen uC, die angesprochene Logik wird aber hauptsächlich auf dem uC implementiert, von daher passt die Kategorie nicht zu 100%. Das Problem mit dem Verodern der Bedingungen ist, dass man beim Hinzufügen und Entfernen von Bedingungen immer verschiedene Stellen anfassen muss, was ich eigentlich gerne vermeiden möchte. Daher ist der Plan nun die weitere Matrixlösung, muss aber dafür noch den Speicherbedarf abschätzen.
Noch ein Zusatz (da ich anscheinend die Antwort nicht mehr editieren kann?): für die Matrixvariante spricht auch die Trennung von Logikimplementierung und den Daten selbst.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.