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.
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.
