Hallo zusammen, ich habe eine Maschine, da kann der Weitertransport des Werkstückes aus verschiedenen Gründen blockiert sein, weil z.B. das Ziel belegt ist oder der Greifer gerade etwas anderes tut, oder weil ein Signal fehlt, oder, oder, oder. Damit man nicht blöd vor der Maschine steht und sich wundert soll nun der Grund auf einem Display als Text angezeigt werden, warum es nicht weiter geht. Es soll nur der wichtigste Grund angezeigt werden. Das bekommt man ja gut über Prioritäten der Gründe hin. Aber nun ist es so, dass die einzelnen Gründe sich mehrmals die Sekunde ändern. Dann würde eine einfache Auswertung nach Priorität ständig wechseln, und man könnte gar nichts auf dem Display lesen. Wie stell ich das am besten an, dass die Anzeige immer den wichtigsten Grund anzeigt, aber trotzdem nicht ständig wechselt?
Hmm, und was ist, wenn zwischen den Aktualisierungen kurz z.B. ein wichtigerer Grund auftrat? Der geht dann unter, sollte aber angezeigt werden. Es könnte ja sein, dass dieser wichtige Grund immer nur genau zwischen den Aktualisierungen auftritt.
Denis schrieb: > Nur alle x Sekunden das Display aktualisieren... Und wenn man schon dabei ist auch die Prioritäten nur alle x Sekunden auswerten. Warum ständig rechnen wenn die Ergebnisse nicht benutzt werden? >> Es soll nur der wichtigste Grund angezeigt werden. Warum eigentlich? Das ist nur wichtig wenn der wichtigste Grund ein Fehler ist und ein Bediener der aufs Display schaut den beheben kann. Für alle anderen, die sowieso nur rumstehen und warten müssen, reicht es irgend einen Grund anzuzeigen. Da geht es nur um Psychologie. Ich würde den ersten auftretenden Grund anzeigen solange er, mit entsprechender Filterung, besteht und mich nicht um Prioritäten kümmern.
Programmierer schrieb: > Hmm, und was ist, wenn zwischen den Aktualisierungen kurz z.B. ein > wichtigerer Grund auftrat? Die Auswertung der Gründe machst Du in einer höheren Rate. Langsam ist nur die Anzeige.
Hannes J. schrieb: > Warum eigentlich? Es gibt sehr unterschiedliche Gründe. Manche Gründe erkennt man sofort, da wäre keine Anzeige notwendig, z.B. Ziel belegt. Andere Gründe sind sehr subtil und nicht auf Anhieb ersichtlich. Und da tritt dann das Problem auf, dass die Leute vor der Maschine anfangen mit den Füßen zu scharren und wild an der Maschine rumzufummeln. > Da geht es nur um Psychologie. So ist es. Darum soll da das "Totschlag-Argument" stehen, warum es nicht weiter geht. Wenn die Leute das wissen, sind sie ruhig. Vor allem wenn sie wissen, es ist etwas das sie nicht beeinflussen können. Unwichtigere Gründe könnten sie beeinflussen. D.h. wenn einfach irgendein Grund darstehen würde, und der Grund wäre beeinflussbar, würden die Leute anfangen dran rumzufummeln, nur um danach festzustellen, das es doch nicht weiter geht, weil es noch einen anderen Grund gibt, gegen den sie nichts machen können.
Was wäre denn, wenn man die Beschreibungen der Fehlercodes permanent sammelt, nach Priorität sortiert, Duplikate entfernt und dann die ganze Liste auf einem Display darstellt - mit dem wichtigsten Grund an erster Stelle. vielleicht sind niedriger priorisierten Fehler ja ebenfalls für die Fehlerbehebung interessant.
An dieser Stelle soll explizit keine Liste dargestellt werden. Es geht auch gerade nicht um Fehler. Es ist hier völlig normal, das hier ein Teil der Maschine nicht weiter macht, weil dieser Teil erst auf ein paar Bedingungen wartet. Einige der Bedingungen sieht man sofort, z.b. das belegte Ziel. Andere Bedingungen sieht man nicht und sind eher subtil. Man könnte sich vorstellen, dass z.B. eine Heizung noch nicht warm genug ist. Und die Leute "wundern" sich dann, warum es nicht weiter geht. Darum soll der "wichtigste" Grund, z.B. "Wartet auf Zieltemperatur" angezeigt werden. In der Zwischenzeit ist es nämlich oft so, dass z.B. das Ziel frei wird. Das würde aber am Warten nichts ändern. Die verschiedenen Gründe kann man gut sortieren. Z.B. ist "Heizung aus" wichtiger als "Wartet auf Zieltemperatur" und das ist wichtiger wie "Greifer belegt" usw. Jetzt ist es halt so, dass die konkreten Gründe sich wirklich in einer Sekunde mehrfach ändern können, warum es nicht weitergeht. Es also in der Realität nicht so träge wie eine Heizung, die schon mal ihre Zeit benötigt, bis sie warm ist.
Kontrollampen beschriftet. Das ist viel einfacher als immer nen Text zu lesen.
Den "wichtigsten" Grund einfach speichern und mindestens x Sekunden anzeigen. Wenn in der Zwischenzeit etwas wichtigeres passiert das drüber schreiben. Wenn es weitergeht Anzeige löschen. Wenn die x Sekunden um sind einfach den dann "wichtigsten" Grund holen und anzeigen (also das Spiel von vorne). Ist zwar ziemlich pfuschig, aber wenn es nur um die Psychologie geht ¯\_(ツ)_/¯
Programmierer schrieb: > Jetzt ist es halt so, dass die konkreten Gründe sich wirklich in einer > Sekunde mehrfach ändern können, warum es nicht weitergeht. Tolle Maschine! ;-) Aber kein Bediener muss das mehrfach pro Sekunde mitgeteilt bekommen. Da reicht eine Update alle 1-x Sekunden. Sonst flimmert es nur noch und man wird irre.
Max D. schrieb: > Wenn in der Zwischenzeit etwas wichtigeres passiert das drüber > schreiben. Würde ich nicht machen, das wird zu chaotisch. Wenn man eine Mindestanzeigezeit von 1-x Sekunden wählt, sollte das besser funktionieren, auch wenn dazwischen eine höher priorisierte Meldung eintrifft. Also schnell sortieren, aber nur langsam anzeigen. Damit filtert man auch gleich die kurzen Meldungen, die mehr irritieren als helfen. Und sich die Frage stellen, ob diese Anzeige in der Form sinnvoll ist. Solange die Anlage läuft und nur normal wartet, würde ich als Status "RUN" ausgeben, auch wenn ein Teil ab und an still steht. Nur wenn ECHT was klemmt und Timeouts zuschlagen, sollte man eine Warnung oder gar Fehlermeldung ausgeben. Damit vermeidet man einen Informationsüberfluß.
Max D. schrieb: > Ist zwar ziemlich pfuschig, aber Nein, so ist es genau richtig: wichtige Gründe überschreiben sofort, ansonsten mindestens 2 Sekunden, je nach Display und Lesbarkeit auch länger. Wenn man nicht sofort überschreibt, entsteht der Eindruck, der wichtige Fehler sei erst danach aufgetreten, obwohl er praktisch gleichzeitig kam (eine Loop später wegen ...) Und wenn es mehr als etwa 7 Prioritäten gibt, ggf auch nur bei relevanter Erhöhung, sonst springt es 10 Minuten lang jede halbe Sekunde.
A. S. schrieb: > Wenn man nicht sofort überschreibt, entsteht der Eindruck, der wichtige > Fehler sei erst danach aufgetreten, obwohl er praktisch gleichzeitig kam > (eine Loop später wegen ...) Ja und? Diese Anzeige ist doch sowieso nur für ADHS-Geschädigte, die nicht mal ein paar Sekunden scheinbaren Maschinenstillstand ertragen können.
Programmierer schrieb: > Wie stell ich das am besten an, dass die Anzeige immer den wichtigsten > Grund anzeigt, aber trotzdem nicht ständig wechselt? Die Regeln ändern. Wenn die Anzeige immer den wichtigsten Grund anzeigen soll und der sich ständig ändert, muss sie sich ständig ändern. Um die Anzeige ruhig zu halten, könntest du einem Fehlerstatus, unabhängig von der tatsächlichen Dauer, immer eine bestimmte Mindestlebensdauer zuordnen, erst wenn die Lebensdauer abgelaufen ist, bekommt ein niedrigerer Fehlerstatus eine Chance auf Anzeige. Und/oder ein Fehlerstatus kommt erst in die Bewertung für die Anzeige, wenn er eine gewisse Zeit stabil ansteht.
Programmierer schrieb: > Damit man nicht blöd vor der Maschine steht und sich wundert soll nun > der Grund auf einem Display als Text angezeigt werden, Schön. Einfach 10 Leuchtdioden untereinander, jede leuchtet wenn ein Grund anzuhalten aufritt, und dahinter mit festem Text beschriften damit man weiss eas die LED anzeigt. Einfache Gründe in gelb, Fehler in rot, und wenn alles lauft leuchtet eine grüne. Ein Textdisplay das nur 1 Grund anzeigen kann ist eben die falsche Lösung.
Programmierer schrieb: > Damit man nicht blöd vor der Maschine steht und sich wundert soll nun > der Grund auf einem Display als Text angezeigt werden, warum es nicht > weiter geht. Also sind überhaupt nur Ereignisse relevant, die lange genug (also z.B. 10-15s) anhalten werden, daß sich Beobachter zu wundern beginnen. Programmierer schrieb: > Aber nun ist es so, dass die einzelnen Gründe sich mehrmals die Sekunde > ändern. Warum? Stellen sich mehrmals pro Sekunde jeweils noch wichtigere Fortschritts-Hindernisse ein? Über einen Zeitraum der lange genug ist, daß die Zuschauer sich zu wundern beginnen? Wieviele unterschiedliche Prioritätsstufen glaubst Du zu benötigen? Oder handelt es sich um eine sequentielle Abfolge von Mikro-Hindernissen, die sich regelmäßig zu einer relevanten Verzögerung aufsummiert? Dann einfach unter einem Sammelbegriff zusammenfassen; ggf. mit Fortschrittsbalken. ;) Programmierer schrieb: > Hmm, und was ist, wenn zwischen den Aktualisierungen kurz z.B. ein > wichtigerer Grund auftrat? Der geht dann unter, sollte aber angezeigt > werden. Es könnte ja sein, dass dieser wichtige Grund immer nur genau > zwischen den Aktualisierungen auftritt. Gründe die immer nur zwischen Display-Aktualisierungen auftreten - die also nie länger als ein paar Sekunden dauern - fallen schon per Punkt 1 als für die Anzeige relevant aus. In einem Log-File für den Wartungstechniker - das diese ja Anzeige ausdrücklich nicht darstellen soll - kann man sie natürlich trotzdem vermerken; sollte es auch dafür keinen Grund geben, dann hat da jemand bei der Vergabe der Prioritäten gewaltigen Mist gebaut. Programmierer schrieb: > Es gibt sehr unterschiedliche Gründe. Manche Gründe erkennt man sofort, > da wäre keine Anzeige notwendig, z.B. Ziel belegt. Wenn keine Anzeige nötig ist, dann zeige erst gar nichts an. Programmierer schrieb: > Und da tritt dann das Problem auf, dass die Leute vor der Maschine > anfangen mit den Füßen zu scharren und wild an der Maschine rumzufummeln. Sollte das passieren könnte man z.B. folgende Meldung anzeigen: »»» So kann ich nicht arbeiten. Hören sie sofort auf mich zu befummeln! ««« 😂😂😂 Programmierer schrieb: > Andere Bedingungen sieht man nicht und sind eher subtil. Man könnte sich > vorstellen, dass z.B. eine Heizung noch nicht warm genug ist. Und die > Leute "wundern" sich dann, warum es nicht weiter geht. > > Darum soll der "wichtigste" Grund, z.B. "Wartet auf Zieltemperatur" > angezeigt werden. Am Besten dazu auch ständig die aktuell Temperatur anzeigen, sei als Zahl oder auch nur als Thermometer-Balken. - Aber Achtung: diese Meldung darf z.B. nur dann hoch priorisiert werden, wenn die erwartbar länger dauern wird, während es kaum sinnvoll ist, wenn sie bei jedem Sekunden-kurzen Nachheizen aufpoppt; läßt sich gerade beim Aufheizen ja leicht abschätzen. Programmierer schrieb: > Darum soll da das "Totschlag-Argument" stehen, warum es nicht > weiter geht. Wenn die Leute das wissen, sind sie ruhig. Vor allem wenn > sie wissen, es ist etwas das sie nicht beeinflussen können. Wenns nur darum geht, das Publikum ruhig zu stellen bzw. bei Laune zu halten, dann mach doch genau das. Melde z.B. »»» Systemkritischer Reorganisationsprozess wird durchgeführt - gleich gehts weiter! ««« Und wenn eine längere Stockung zu erwarten ist, dann bespaße doch die Zuseher, spiel ein paar Animationen ab, zeige die neuesten XKDC Comics an,… Wenn die Leute nichts gegen die Verzögerung unternehmen können sollen, dann lenk sie ab, sodaß sie gar nicht erst auf blöde Ideen kommen. 😂😂😂
Programmierer schrieb: > ich habe eine Maschine, da kann der Weitertransport des Werkstückes aus > verschiedenen Gründen blockiert sein, weil z.B. das Ziel belegt ist oder > der Greifer gerade etwas anderes tut, oder weil ein Signal fehlt, oder, > oder, oder. Was ist das für eine komische Maschine? Ist es etwa ein vollautomatischer Eiswagen auf Malle??? Der alles kann und nebenbei auch mal ein Hörnchen Eis ausgibt?? Und wenn er eben alles macht, neben Eis-Ausgeben, dann müssen die Leute bei Laune gehalten werden. Ist es das??? Sorry, habe gerade einen Traum gehabt :-) Gruß Rainer
Programmierer schrieb: > Wie stell ich das am besten an, dass die Anzeige immer den wichtigsten > Grund anzeigt, aber trotzdem nicht ständig wechselt? Beim Hersteller bemängeln oder nen Fluxkondensator einbauen... Oder, Du programmierst "Die Maschine" um. Zugang zum Source-Code, Programmierkenntnisse? Wenn JA, was soll dann diese dumme Frage Herr "Programmierer"?!
Ich würde verschiedene Kausalitätsketten definieren die jeweils zu einem Stop führen können. Jeder Fehler wird dann einer dieser Kausalitätsketten zugeordnet und dann wird nur der ursächliche Grund aus der jeweiligen Kette angezeigt. Fiktives Beispiel: Steht weil Ziel belegt> Ziel belegt weil Greifer belegt> Greifer belegt weil Ofen nicht bereit> Ofen nicht bereit weil zu kalt Viele Fehler, alle aus einer Kausalitätskette. Angezeigt wird nur nur der Fehler der dem Anfang der Kette am nächsten ist. Im Beispiel "Ofen zu kalt" Das kann natürlich komplex werden denn auch Verzweigungen sind denkbar.
Sebastian S. schrieb: > Ich würde verschiedene Kausalitätsketten [...] Ja, über solche Kausalitätsketten stolpere ich auch immer wieder. Hat Du dazu Literatur-Tips oder evtl. sogar Beispiel-Code? Also, wie sammelt man die Ursachen in der Software zusammen und wie geben die einzelnen Module/Abstraktionsebene die Gründe weiter? Oder gibt es einen großen "Kausalitäts-Master", der jeden einzelnen Grund kennt, und den kompletten Zusammenhang der einzelnen Gründe kennt? Das hätten den Vorteil, das die Kausalitätskette bzw. der Kausalitätsgraph nicht nach der Architektur der Module implizit erstellt wird, sondern explizit und unabhängig von der Modul-Architektur. Allerdings fühlt sich das für mich nach doppelter Arbeit an.
Packe alle Stop-Gründe, die zum Stop führen können, auf eine Anzeigenseite. Alle sind per default grau. Nach Prio geordnet. Sobald einer TRUE wird, mache ihn rot. Damit springt nichts mehr hin und her. Selbst wenn der Stop-Grund erlischt, ist das graue Feld weiterhin lesbar. Auf den ersten Blick siehst du auch: Ok es ist irgendetwas rot. Falls mehr Grüne als Platz auf der Anzeige: Beschränke das eben gesagt auf die letzten 5 Stop-Gründe. Lasse diese dann langsam ausfaden und nach hinten wandern.
mIstA schrieb: > Also sind überhaupt nur Ereignisse relevant, die lange genug (also z.B. > 10-15s) anhalten werden, daß sich Beobachter zu wundern beginnen. Eigentlich ja. Eine "kurze" Verzögerung (10-15s) interessiert eigentlich überhaupt nicht. Es ist wirklich so, wenn es "zu lange" dauert, die Leute unruhig werden. > Stellen sich mehrmals pro Sekunde jeweils noch wichtigere > Fortschritts-Hindernisse ein? Über einen Zeitraum der lange genug ist, > daß die Zuschauer sich zu wundern beginnen? Vielen Dank für die Frage bzw. den Hinweis. Bis jetzt habe ich nur den Ansatz per Priorität das Problem zu lösen verfolgt. Aber man könnte tatsächlich auch nach der voraussichtlichen Dauer entscheiden, was angezeigt wird. Wobei, das ist ja nichts weiter als eine Priorität. Aber vermutlich eine "gute Wahl" für die Priorität.
Programmierer schrieb: > Hat Du dazu Literatur-Tips oder evtl. sogar Beispiel-Code? Nein, das war lediglich eine spontane Idee zu einem Problem über das ich bisher noch nie gestolpert bin. Kann natürlich sein, dass das ne Sackgasse ist. Mein erster Gedanke bei deinem Eingangspost war aber: Priorität scheint ungeeignet, denn Fehlerereignisse können zu Folgefehlern führen. Anhand einer erdachten Priorisierung lässt sich aber nicht erkennen, ob ein Fehler (auch wenn er hochpriorisiert ist) Folge eines anderen Fehlers ist und sich in Luft auflöst wenn der ursächliche Fehler behoben ist, oder ob er Folge eines externen Ereignisses ist. Wenn in der Kausalitätskette vor dem "frühesten" Fehler kein Fehler mehr vorliegt, ist er entweder unvorhergesehn oder extern. In beiden Fällen aber der Punkt an dem man zuerst analysieren sollte.
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.