Echt jetzt? Wenn man so etwas einbaut, tritt ein solcher Fehler doch niemals ein?
Ich weiss jetzt nicht, Dagobert, an welcher Stelle wir anscheinend aneinander vorbei geredet haben.
Oder bist Du abergläubisch und meinst, sobald man eine solche "Falle" eingebaut hat, kommt niemand mehr in die Verlegenheit, entsprechende Fehler (unbewusst/ungewollt) einzubauen?
Diese Falle hat wahrscheinlich tatsächlich dazu geführt, dass fortan disziplinierter programmiert wurde. So gesehen kann ich Deine Bedenken
durchaus nachvollziehen.
Wir haben damals zu mehreren an unseren Projekten gearbeitet. Arbeitsteilung zwischen den ProjektVerantwortlichen und den "Zulieferern" für diverse "SpezialGebiete" (z.B. Werkzeug-/Werkstück-/Paletten-Wechsel/-Verwaltung).
Das unabsichtliche Zerschiessen der Immer-Eins- und Immer-Null-Merker hätte jedem der Beteiligten passieren können und es hätte ihn vermutlich (zu) wenig berührt, solange sein eigener Bereich dadurch nicht gestört worden wäre.
Die Auswirkungen des Zerschiessens wirken sich nunmal "global" aus und die Suche nach der wirklichen Ursache kann durchaus mühsam werden.
Durch die RadikalMassnahme wurde man aber unmissverständlich und meistens auch sehr "zeitnah" auf einen fälligen HandlungsBedarf hingewiesen!
Und das schon in der Entwicklungs- oder spätestens in der InbetriebnahmePhase.
Es soll auch vorgekommen sein, dass erst vor Ort an längst laufenden Maschinen Änderungen/Erweiterungen an der PLC-Software durchgeführt wurden
von wohlmeinenden, aber letztlich nicht wirklich informierten Leuten. So hatten wir im TBE zumindest im Fehlerfall eine Chance, von solchen Eingriffen überhaupt zu erfahren, ggfs durch Beschwerden über das letzte, vermeintlich unsinnige Netzwerk des OB 1.
PS:
Wie weit will man das eigentlich spinnen?
Gar nicht!
Damals gab es keine Konstanten TRUE und FALSE und die Notwendigkeit von Immer-Null- und Immer-Eins-Merkern war deshalb gegeben.
Ihre Verwendung liess sich zwar einschränken und beherrschen ... und dennoch war man nicht allein für ihr unversehrtes Überleben zuständig/verantwortlich.
Frühzeitiges Erkennen eines ProgrammierFehltritts war allemal hilfreich, die Ursache (und den Verursacher) einzukreisen.
Die Prüfung erforderte lediglich zwei zusätzliche Befehle, die in jedem Zyklus durchlaufen werden mussten und einen dritten zusätzlichen Befehl, der nur im Fehlerfall den Stopp auslöste.
So wenig Aufwand für so durchschlagenden Erfolg hat man nicht oft!
PPS:
Nein, ich habe mich nicht verzählt.
Der BEB wurde nicht zusätzlich, sondern anstelle des BE durchlaufen und der BE wurde auch im Fehlerfall nicht mehr durchlaufen.
