Vorstellung: LaserSafety

[mR.Os]

Ich will jetzt nun endlich nach langer Bastelei meine neue Lasersafety vorstellen. Gebaut habe ich sie, neben den vielen kommerziellen und der von Nico, weil mir diese nicht ausgereicht haben was die Sicherheit anbelangt.
So schalten diese den Laser ja mit Zeiten im Millisekunden Bereich aus, aber da ist bei den heutigen Leistungen teilweise ja schon alles zu spät. Außerdem ist die Show dann ja auch kaputt, wenn man mal einen doofen Frame erwischt (zwar lieber Show kaputt als Auge kaputt, muss ja aber trotzdem nicht sein).

Meine Safety macht jetzt nun einige Sachen ein wenig anders als die meisten Safetys, die es bis jetzt gibt bzw. die ich kenne. So taste ich jede µs die Farb- und Scannereingangssignale ab um auch jede µs zu berechnen, ob der Laser an bleiben darf oder ausgehen muss. Es können natürlich auch Zonen eingestellt werden (momentan nur eine, aber da werden noch mehr kommen) in denen die Berechnung angewendet werden soll oder der Laser einfach geblankt wird.
Die Feedbacksignale werden jetzt zwar noch nicht mit überwacht, ist aber mit vorgesehen und muss nur noch in Software implementiert werden.

Dazu wird die Berechnung nicht in einem Mikrocontroller, wo die Software abstürzen kann, durchgeführt, sondern in einem FPGA wo die Logik „fest einprogrammiert“ ist. Die Kommunikation zum PC erfolgt über USB und es werden keine extra Treiber benötigt. Noch ist das PC Programm ein wenig schmucklos und recht umständlich zu bedienen, aber auch das wird noch werden. Erst einmal sollte es funktionieren.

Aber nun noch ein paar Bilder von der Safety und der Software:

safety_hardware.jpg

prog.PNG

Die Hardware ist zwar noch nicht ganz ausgereift, aber die nächste Platinenrevision wird dann hoffentlich alles richten. Die wichtigen Systeme funktionieren alle (wenn auch mit ein paar kleinen Hacks).

Aber nun zum allerwichtigsten, die Abschaltung. Ich habe einfach ein Rechteck gescannt und jeweils viele Eckpunkte gesetzt, so dass dort dann deutlich zu viel Leistung stehen würde. Einmal ein Bild mit deaktivierter Safety:

off.jpg

Einmal wo einfach der obere Bereich weggeblankt wurde:

blanking.jpg

Und nun zum wichtigsten, der "Energiebegrenzung":

calc.jpg

[DarkG]

Ich bestell schonmal ne version 1.0 (gehe davon aus deine vorstellung is die ver 0.5 )

MfG
DarkG

[Eike88]

Hi,

Das sieht ja sehr interessant aus.
Ich melde da auch schonmal Interesse an

Freue mich auf weitere Infos

MfG Eike

[thomasf]

Hi,

hatte HB nicht etwas ähnliches schon vor ca. 10 Jahren raus gebracht? Zumindest mit dieser Energiebegrenzung an den Ecken.

Auf jeden Fall ein cooles Projekt. Wie viel Platz wird denn auf dem Spartan 3 verbraucht? Und wie läuft das mit dem USB? Läuft da eine Micro Machine auf dem Spartan?

Thomas

[mR.Os]

Erst mal danke für die Antworten.
Auf dem Teil ist ein Spartan 6. Ich bin momentan bei 20% FlipFlops und 25% Logik, ein wenig Platz ist noch.
USB mach ich extern über einen kleinen µC, da wollte ich nicht den Aufwand betreiben das im FPGA zu implementieren. Der überwacht auch gleich noch den Spartan mit ob er sich ordentlich konfiguriert.

[gento]

HB Hatte sowas auf Analogbasis ohne CPU und ohne Einschaltverzögerung , schaut man sich die Ecken genauer an. #5

Jede CPU kann das Spiel mit Ecken abdunkeln .
Im Quadrat wirk das halt nur Cool und nicht Show zerstörend.

Fast jede 4 Euro CPU kann auch mit 10K das Feedback abtasten.

Wie man sieht im Bild #4 , wo das Quadrat oben abgeschnitten wird : Recht Träge das On/Off
Zum Spatzen abknallen benötigt man keine Kanonen.

lg Gento

[Toack]

Hi,

sieht echt interessant aus.

Auch ich melde Interesse an

Gruß Tobi

[guido]

Jau...HB hat das mit dem Ecken abdunkeln analog gemacht. Dann sind auch die kurzen Blanks weg
aber das wird bei dir sicher auch nur zum zeigen beabsichtigt sein.
Könnte man auch in der Lasersoft machen, aber wer will schon seinen Laser mit Gewalt abdunkeln
Bei Grafikshows finde ich die HotSpots aber auch nervig.

Mit den FPGAs ist schon ne Menge möglich. Aber für diese Anwendung sicher etwas mit "Kanonen auf Spatzen"
geschossen. Aber irgendein Projekt muss man ja nehmen wenn man mit so einem Teil spielen will.

"Klickeldiklick" - Programmierung oder VHDL ?

[mR.Os]

Die kurzen Blanks sind noch eine Einstellungssache (ich experimentiere da noch ein wenig) und auch der Berechnungsalgorithmus ist noch nicht komplett fertig. Ich habe da schon Ideen, nicht nur zu Entscheiden ob an oder aus, sondern auch zu dimmen. In Matlab funktioniert das auch schon ganz gut, nur die Hardware zum schalten ist in der aktuellen Revision noch zu träge dazu (Ich schalte da jetzt ja schon jede µs ...).
Was ich vielleicht noch erwähnen sollte: das Farbsignal fließt auch in die Berechnung mit ein. Wenn die Laser aus sind, dann wird auch nichts geblankt.

Ich probiere schon länger so ein Teil zu realisieren. Ich habe auch schon mehrere Controller vor dem FPGA ausprobiert, aber mit keinem kam ich auch nur in die Nähe eines Erfolges. Wenn Gento mir mitteilen kann, mit welchen Prozessor ein ähnliches Resultat zu erzielen ist (sei es nun für 4 oder 40€, ich wollte nur kein BGA Gehäuse), dann wäre ich da sehr froh. Ich habe nichts gefunden.
Mit dem FPGA kann man dann halt noch ziemlich viel machen. Mein Endziel ist noch die Überwachung der aktuellen von den Lasern abgegeben Leistung mitsamt Regelung dieser. Aber erst einmal muss das Teil so wie es ist fertig werden.

Programmiert ist der FPGA mit VHDL - wenn, dann richtig. Nur ist, muss ich zugeben, diese Sprache nicht immer ganz einfach zu beherrschen.

nochmal @Gento: Auf dem Bild mit dem Blanking ist es schief, da zum einen meine Eingangsstufe ein paar kleine Nichtlinearitäten noch hat (ist aber schon behoben, nur noch nicht auf der Platine) und weil die Abschaltung zu schnell erfolgt. Jetzt ist schon die Entscheidung zum eigentlichen Schalten um 200µs verzögert, allerdings reicht das noch nicht.

[thomasf]

Hi,

was läßt du denn da für Berechnungen machen? Ich denke ein ARM3 (oder 5) würde für diese Geschichte schon langen. Dann auch gleich mit USB Library. Die ARMs haben zudem auch DMA mit denen du direkt vom DAC in den Speicher schreiben kannst.

Das Argument mit Ausfallsicherheit und FPGA würde ich so nicht unterschreiben wollen. Programmiert vom Menschen der nunmal Fehler macht. Wo ist da der Unterschied zur CPU?

Ich will dein Projekt nicht schlecht reden. Auf jeden Fall eine gute Gelegenheit seine Kenntnisse in VHDL auzubessern. Ich könnte das so nicht auf die Schnelle. Bis auf kleine experimente an der UNI mit VHDL und div. Programmierungen habe ich nicht mehr mit VHDL gearbeitet. zudem geht man ja dazu über, auf die Dinger ganze MicroMachins zu implementieren und dann Linux drauf laufen zu lassen. VHDL, dann nur noch für die ganz Harten

Weiterhin viel Spaß mit dem Projekt! Es hat auf jeden Fall seine Berechtigung!

Thomas

[nr_lightning]

UM GOTTES WILLEN, WIE KANNST DU NUR EINE SAFETY NEBEN DER MEINEN ENTWICKELN

.. hach das waren noch Zeiten

Tolles Projekt Andreas, wirklich, bleib am Ball !


Zu der ganzen FPGA oder Microcontoller Geschichte .... mmhh ich glaube das ist wieder so ein "Glaubenskrieg" Dingens Kirchen oder !?
Ich muss gestehen ich bin jetzt nicht so Firm in der Sache das ich da "Den" Durchblick habe was welcher Chip für vor und Nachteile hat.
Aber wenn ich nicht ganz auf den Kopf gefallen bin dann wird in einer µCPU der Code auch fest in den EEPROM Gebrannt ( 101110110001001010010010 ) Hardcoded quasi. Und weil die Dinger hardcoded sind Verschleißen sie ja auch beim „Brennen“.
Was kann da mehr abstürzen als ein anderer Baustein der mit irgendwelchen Speicher Registern Arbeitet ?
Irgendein EMP oder ESD Shock zerlegt dir einfach ALLES

Klar wenn die Software Buggy ist, dann hilft der Beste Protz nichts !!! Das brauchen wir hier gar nicht diskutieren !

Immer Gut wenn jemand frischen Wind in die Sache bringt, wenn du noch Tipps brauchst ( falls ich dir überhaupt welche geben kann ) lass es mich wissen !

PS: Tipp am Rande Andreas, mach das ding so DAU sicher wie möglich und vorallem so Selbsterklärend wie möglich.
Auch die Software sollte Intuitiv sein .... Du glaubst nicht was du sonst für Fragen bekommst die für dich als Entwickler "VÖLLIG LOGISCH" sind !

Grüße Nico

[mR.Os]

Soo, viel Zeit ist vergangen in der ich weiter gemacht habe. Ich will nur einen kleinen Zwischenstand mal zeigen:
An der Hardware habe ich mittlerweile noch ein wenig was geändert: ich schalte jetzt das Lasersignal nicht nur an und aus, sondern habe am Ausgang noch einen DAC und berechne das Farbsignal komplett neu. Momentan ist es so implementiert, dass das Signal in 16 Stufen gedämpft werden kann. Auch die Gain-Einstellungen habe ich komplett in Software implementiert. Man muss also keine Trimmer irgendwo rumdrehen.
Als zusätzliche Notausquellen wird der Interlock Anschluss, die 5V vom DAC, ein Notaus und ein Schlüsselschalter überwacht. Da ich da irgendwann hier mal was gelesen habe, hab ich es auch einstellbar gemacht ob bei einem ausgelöten Notaus und dem Rückstellen dessen die Safety von alleine wieder anläuft oder ob man den Schlüsselschalter rumdrehen muss. Ein Shutter wird natürlich auch angesteuert.
Eine weitere Notausquelle ist der Vergleich zwischen dem Feedbacksignal und dem ILDA Signal. Maximale Abweichung und die Dauer wie lange diese überschritten werden muss um ausgelöst zu werden ist natürlich einstellbar.

Aber nun ein kleines Foto zur Elektronik:

IMG_0130.JPG

Auf der Platine sind noch ein paar Mod-Kabel zu sehen. Zum Teil liegt es daran, dass ich beim Teile tauschen ein paar Pads kaputt gemacht habe und dann sind auch noch zwei, drei Fehlerchen auf der Platine. Ist aber nichts weltbewegendes, die Kernkomponenten gehen. Achso, ein "Weitbereichsspannungseingang" ist nun auch drauf. Läuft von 3 bis 12V.

Aber nun zum wichtigsten, die Sicherheitsfunktion. Bei den beiden Bildern wurde jweils im oberen Bildbereich die Safety aktiviert und im unteren Bereich deaktiviert.

IMG_0117.JPG

Hier wurden auf der linken Seite die Eckpunkte vielfach wiederholt gezeichnet. Beide in etwa gleich oft (um ein oder wei Punkte könnte ich mich verzählt haben). Meiner Meinung nach sieht man einen recht großen Unterschied. Auf der rechten Seite wurde jeweils nur ein Punkt gesetzt.

IMG_0118.JPG

Bei diesem Bild habe ich einen einfachen Farbverlauf von links oben in die Mitte (hell -> dunkel) und dann weiter nach rechts unten gezeichnet (dunkel -> hell). Der Laser hat keinen Farbabgleich erfahren, deshalb ist das in der Mitte so dunkel. Man sieht es nicht zu gut, aber links oben ist der Strich dunkel als der unten in der Ecke.

Auch habe ich noch ein kleines Video gemacht, wo ich in HE Laserscan einen Kreis gezeichnet habe der immer kleiner und dann wieder größer wird. In der Mitte habe ich dann einmal die Safety deaktiviert und dann wieder an gemacht. Ich denke, man sieht wo da was passiert
Ich hoffe, der Link geht, da er gerade noch berechnet wird: https://vimeo.com/63089168

So, auf dass die Fetzen fliegen, schließlich baue ich eine Safety

[netzpfuscher]

Sieht doch schonmal nicht schlecht aus.

Mache auch viel mit µC und ein bischen mit FPGAs. Deswegen muss ich mal meinen Senf dazu geben, das was da implementiert ist macht kein µC und zwar keiner (ok ausnahme vielleicht DS Pic oder ähnliches). Da sind schon ziemlich hohe Datenraten im Spiel wenn ich ein Signal habe was mit 30khz moduliert wird, muss man schon mindestens aber auch aller mindestens mit dem zehnfachen abtasten. Das heißt man hat schon eine Datenrate von ~290 kb/s (pro Kanal bei 8 bit) aber das Reicht bei weitem nicht aus um das Signal am Ausgang wieder zum Ursprungssignal zusammenzusetzten und da wurde noch keine µs gerechnet. Zumal ich 8bit für zu wenig halte. Denn wenn das Farbsignal schon mit 8bit aus dem DA kommt dann verliert man durch ungenauigkeiten viel zu viel. Ich würde das schon so um die 10bit abtasten. Toll wäre doch auch eine Gammakorrektur/ Farbkorrektur in Hardware, dann kann die Ausgabesoftware dümmer sein und erzeugt auch weniger Rechenlast.
Ein FPGA kann auch aussteigen, ist nur unwarscheinlicher als bei einem µC, denn der FPGA basiert ja auch nur auf SRAM-Zellen die mit einem Lookup-Table konfiguriert werden. Der FPGA macht aber in der Regel CRC-Checks seiner Konfig-Daten.

Alles in allem Daumen hoch! Finde ich gut was du das baust.

[jojo]

..das was da implementiert ist macht kein µC und zwar keiner (ok ausnahme vielleicht DS Pic oder ähnliches). Da sind schon ziemlich hohe Datenraten im Spiel wenn ich ein Signal habe was mit 30khz moduliert wird, muss man schon mindestens aber auch aller mindestens mit dem zehnfachen abtasten.

Wo steht das denn?
Zunächst mal sind die "pps" einer Ausgabe keine Hertz, sondern 1/2 Hz. Also 30Kpps entsprechen einer Maximalfrequenz von 15KHz. Es braucht 2 Punkte, um einen Signalwechsel zu erzeugen. Selbst bei 100Kpps ist also bei 50KHz Schluss.
Zehnfache Abtastrate? Wenn wir eine Ausgabe mit 100Kpps fahren erhalten wir alle 10us einen neuen Ausgabewert. Sample ich also mit >2fach dann ist das mehr als genug. Theoretisch würde >100KHz Abtastrate reichen (wie gesagt: 100kpps sind NICHT 100KHz!).

Toll wäre doch auch eine Gammakorrektur/ Farbkorrektur in Hardware, dann kann die Ausgabesoftware dümmer sein und erzeugt auch weniger Rechenlast.

Ist ein netter Luxus. Dennoch stellt sich bei solchen Projekten die Frage, ob es sinnvoll ist, Funktionen in die Hardware auszulagern.
Früher war die Ausgabesoftware "dümmer", weil die Rechenpower nicht da war. Ein 50MHz-PC ging bei ein paar Berechnungen in die Knie. Firmen wie Lobo bauten eigene Systeme auf Transputer-Basis, um etwas mehr Leistung zu haben.
Das ist vorbei. Bei tausenden von Megaherzt unter der Haube sind die paar Berechnungen ein Witz.

Ein FPGA kann auch aussteigen, ist nur unwarscheinlicher als bei einem µC, denn der FPGA basiert ja auch nur auf SRAM-Zellen die mit einem Lookup-Table konfiguriert werden. Der FPGA macht aber in der Regel CRC-Checks seiner Konfig-Daten.

Das Aussteigen ist meistens an 2 Dinge gekoppelt: Störsicherheit der Schaltung und Software.
Bezüglich Störsicherheit sind FPGAs mindestens, wenn nicht sogar eher gefährdet als uCs. Die meisten FPGAa arbeiten an 1,2V oder darunter und der Störabstand der Spannungsversorgung ist daher geringer als bei einem gängigen uC.
Erfahrungsgemäß erfordern FPGAs eine sehr gute und störfeste Spannungsversorgung. Das sollte zwar auch bei uCs so sein aber FPGAs verzeihen eine Sauerei auf der Spannung weit weniger. Manche bedanken sich sogar mit Totaldefekt.

Auch muss man unterschieden, ob man es bezüglich der Software bzw. Konfiguration auf dem FPGA mit einer relativ einfachen Logik zu tun hat oder ob da eine Soft-CPU läuft. Eine CPU stürzt genauso ab wie alle anderen auch. Eine Logik theoretisch weniger, aber das hängt von der Komplexität ab und von der Mühe, die sich der Entwickler bei der Simulation gibt.
Dabei ist das Programmieren in VHDL selbst weniger das Problem. Die Arbeit ist die Simulation bzw. die Simulation unter Fehlerbedingungen. Und da ich mal annehme dass sich ein VHDL-Programmierer auch nicht mehr Mühe für die Fehlersimulation geben wird, als ein Programmierer eines Mikrokontrollers, ist eine Logik auf dem FPGA ebenso anfällig. Das Problem bei Logik in VHDL ist, dass die Schwierigkeit der Simulation bei steigendem Funktionsumfang regelrecht "explodiert". Da man meist parallel denken muss wird die Sache schnell extrem unübersichtlich. Und tritt ein Zustand auf, den man vergessen hat zu simulieren und per Logik abzufangen, knallts. Es ist eine wahnsinns Arbeit, ein System umfassend unter allen erdenklichen Bedingungen zu testen.
Deshalb denke ich nicht, dass man ein FPGA-Design pauschal als "sicherer" gegen Systemabsturz bezeichnen kann.

Nicht falsch verstehen. Ich will nun hier nicht gegen das Projekt selbst meckern.
Das Projekt selbst ist sicher lobenswert, wenn es funktioniert. Wäre sicher interessant, so etwas mal live auf einem Treffen vorgeführt zu bekommen.

Gruß

Joachim

[netzpfuscher]

@Jojo
Es wird aber nicht Synchron mit der Ausgabe abgetastet, somit braucht man eine bedeutend höhere Abtastrate, beispiel ich taste einen Sinus mit der doppelten Frequenz ab, habe ich nur zwei Stützpunkte. Damit kann man unmöglich wieder das Ausgangssignal rekonstruieren. Mit der 10fachen Frequenz kommt man da schon näher dran. Wenn man zu gering abtastet kommt es auch ganz schnell zu Alias-Effekten.

Die Farb und Gammakorrektur im Projektor selbst hätte aber zusätzlich noch den positiven Nebeneffekt das die Einstellungen dann im Projektor hinterlegt sind. Somit kann man den Projektor an eine beliebigen Steurrechner anklemmen ohne dort die Einstellungen wieder vorzunehmen.

[jojo]

@Jojo
Es wird aber nicht Synchron mit der Ausgabe abgetastet, somit braucht man eine bedeutend höhere Abtastrate, beispiel ich taste einen Sinus mit der doppelten Frequenz ab, habe ich nur zwei Stützpunkte. Damit kann man unmöglich wieder das Ausgangssignal rekonstruieren.

Bei einer maximalen Ausgabe von z.B. "30K" musst Du aber kein 30KHz Sinussignal abtasten sondern nur 30K DAC-Samples pro Sekunde.
Und dafür reichen zur hundertprozentigen Rekonstruktion genau 30KHz aus.

Gruß

Joachim

[netzpfuscher]

Könntest recht haben, wenn ich jetzt nochmal so drüber nachdenke. Allerdings stimmt das Timing dann nicht in jedem Fall, wenn das Sample grad mal ganz doof fällt, liegt das direkt vor dem nächsten DAC-Sample dardurch hat man dann zumindest eine zeitliche Verschiebung des Signals. Nagut, Kommando zurück, hast gewonnen

[ekkard]

Meine Bedenken habe ich hier: http://www.laserfreak.net/forum/viewtop ... 79#p259079 zusammen gefasst. Ich habe nicht geprüft, ob dies alles hier berücksichtigt wurde oder nicht.

[jonasst]

Find dein Projekt klasse. Mach weiter so.

Hast du irgendwelche Sicherheitseinrichtungen eingeplant die überwachen ob der FPGA noch macht was er soll?
Kenn mich mit FPGAs nicht so gut aus, gibts da so etwas ähnliches wie den Watchdog? Könnte man ja vieleich auch in die Logik mit einbauen, sowas wie ein 'hey ich arbeite noch'' Signal

[mR.Os]

Ich habe auf dem Ding ein FPGA und einen µC drauf. Beide müssen ihr okay geben, damit die Laser angehen können. Der µC überwacht, dass der FPGA sich ordentlich konfiguriert und sollte er durch irgendwas wieder in den unkonfigurierten Zustand wechseln, dann schaltet er auch die Laser wieder aus. Der Shutterausgang hängt auch an dem Signal.
Zusätzlich werden noch die Versorgungsspannungen (fast) alle überwacht und im Notfall der FPGA und der µC in Reset gebracht, was die Laser auch sofort ausgehen lässt.

Der FPGA lässt sich sonst aber ungünsitg überwachen. Allerdings sind alle Zustandsautomaten trapdoor sicher implementiert. Ist nicht zu einfach.

[jonasst]

Hört sich eigentlich ziemlich gut an.

Man sollte bei alledem nich Vergessen, dass das Safety bei einer sicheren Show ja nur im Fehlerfall zum Einsatz kommt.
Es kommt in diesem Fall also nur zu einer gefährlichen Situation wenn der Scanner versagt, das Safty versagt und die Überwachung des Safetys auch noch. Und dann muss des Stehende Strahl ja auch noch in nem Auge landen um Schaden anzurichten.
Absolute Sicherheit gibts nicht, aber ein gut funktionierendes (und eingestelltes) Safety macht es, denke ich, schon sehr unwahrscheinlich das etwas passiert.

Es muss natürlich verhindert werden das sich Fehler einschleichen die nicht bemerkt werden, sonst könnte sich die oben genannte Kette schon über die Zeit abarbeiten.

@ekkard:
Ich finde es gerade bei diesem Thema gut auch kritische Stimmen zu haben. Allerdings würde ich gerne Lesen wie du dir das ''perfekte'' Safety vorstellst.
Möglicherweise hast dus ja auch schon mal beschrieben und ich habs nicht gefunden.

[cruhbach]

Hallo Zusammen,

ich finde die Lösung absolut super und habe eigentlich nur noch eine Frage dazu: Wird man das irgendwann mal kaufen können?
Ich würde das sofort einbauen.

[mR.Os]

Ich werde demnächst auch mal wieder an der Safety weiter bauen. So viel ist in der letzten Zeit nicht geworden, da ich mit meinem Diplom beschäftigt war. Aber das ist nun seit gestern gegessen.

An sich läuft das ganze recht gut. Es fehlen nur noch ein paar (oder auch ein paar mehr) Optimierungen bei der Bedienung. Momentan kann ich es eigetlich nicht mal mir selber zumuten

[karsten]

da ich mit meinem Diplom beschäftigt war. Aber das ist nun seit gestern gegessen.

Und du glaubst, dass es nun besser wird und du nun mehr Zeit für das Projekt hast? Meine Erfahrung ist da eine andere...

[mR.Os]

Ich habe erst mal noch drei Wochen frei

[ekkard]

Man sollte bei alledem nich Vergessen, dass das Safety bei einer sicheren Show ja nur im Fehlerfall zum Einsatz kommt.

Richtig, die Safety-Schaltung ist kein Mittel des laufenden Betriebs wie z. B. ein akustisch-optischer Modulator (, der aber natürlich als Sicherheitsabschaltung eingesetzt werden kann).

Es kommt in diesem Fall also nur zu einer gefährlichen Situation wenn der Scanner versagt, das Safty versagt und die Überwachung des Safetys auch noch.

Mehrfehlerfälle abzudecken, verlangt die Norm nicht. Allerdings müssen die beschriebenen Fehler physikalisch voneinander unabhängig sein, nicht z. B. auf das Versagen einer untergeordneten Stromversorgung zurückzuführen sein. Das wäre dann der Fall, wenn die von mir genannte Versorgungseinheit sowohl den Scanner steuert, die Safety-Schaltung und den Shutter.

Und dann muss des Stehende Strahl ja auch noch in nem Auge landen um Schaden anzurichten.

Bitte in Sicherheitsfragen so nicht argumentieren!

@ekkard:
Ich finde es gerade bei diesem Thema gut auch kritische Stimmen zu haben. Allerdings würde ich gerne Lesen wie du dir das ''perfekte'' Safety vorstellst.
Möglicherweise hast dus ja auch schon mal beschrieben und ich habs nicht gefunden.

Nein in Gänze gibt es von mir diesbezüglich nichts - kann es auch nicht geben. Ich bin kein Elektroniker und werde Euch nicht in das Design hinein reden. Ihr müsst euch vergegenwärtigen, dass ihr die Sicherheit gewährleisten müsst - nicht statistisch oder wahrscheinlich, sondern sicher. Anderenfalls lasst die Bestrahlung des Publikums besser bleiben. Meine Bedenken habe ich in einem Vorbeitrag bereits genannt, weiter oben verlinkt und hier nochmals ergänzt. Wer seine Schaltung kennt, wird die Punkte "abhaken" können. Bleiben irgendwo Bedenken, muss wohl noch etwas "Gehirnschmalz" investiert werden!

[karsten]

Ihr müsst euch vergegenwärtigen, dass ihr die Sicherheit gewährleisten müsst - nicht statistisch oder wahrscheinlich, sondern sicher.

Der Satz ist nicht hundertprozentig richtig. Die 1-Fehler-Sicherheit muss für Laseranlagen gewährleistet werden. Beliebig komplexe Mehrfehlerszenarien können jedoch nie sicher beherscht werden, womit die Sicherheit doch wieder zur statistischen Größe wird.

[ekkard]

Ja, ja, wenn man verkürzend liest. Die drei aufgezählten Fehler dürfen nur nicht auf einen einzigen (gravierenden, ganz anderen) Fehler zurück zu führen sein. (Ich hatte dies vielleicht etwas zu sehr verklausuliert, sorry!) Wenn also die Überwachungen jeden Einzelfehler erfassen, ist die Sache natürlich in Ordnung.