https://www.hackerspace-ffm.de/wiki/api.php?action=feedcontributions&user=Tut&feedformat=atom
Hackerspace Ffm - Benutzerbeiträge [de]
2024-03-28T23:56:13Z
Benutzerbeiträge
MediaWiki 1.25.3
https://www.hackerspace-ffm.de/wiki/index.php?title=Reloaded:_CO%E2%82%82-Laser_2.0&diff=11578
Reloaded: CO₂-Laser 2.0
2024-03-20T19:04:44Z
<p>Tut: /* Nützliches */</p>
<hr />
<div>== Instandsetzungsmaßnahmen 2024 ==<br />
<span style="color:red;">'''LASER DEFEKT''':</span><br />
Der Laser ist derzeit defekt und kann nicht genutzt werden. <br />
<br />
=== Was ist kaputt? ===<br />
Die Laser-Leistung ist recht plötzlich extrem abgefallen und reicht allenfalls noch zum gravieren. Fehlersuche ergab folgende Erkenntnisse:<br />
* Die Leistung ist schon direkt am Ausgang der Röhre extrem schwach, man braucht deutlich länger (etwa 500ms) um ohne Fokusierung ein Loch in Krepp-Band zu schießen.<br />
* Die pinkfarbene Entladung ist in der Röhre zu sehen, auch auf der vollen Länge. Die Helligkeit dieser Entladung scheint aber deutlich geringer zu sein als üblich<br />
* Es wurde bei 99% Leistungsvorgabe ein Strom von knapp über 35mA gemessen:<br />
** Das Netzteil scheint also noch zu funktionieren<br />
** Die Sollvorgabe von 100W Laserröhren ist allerdings nur 30mA für 100%<br />
** Es ist bekannt, dass Röhren nur bei max. 80% der Nennleistung betrieben werden sollen, darüber fällt die Lebensdauer wohl extrem - statt einigen 1000h sind es dann nur noch einige 10h, bei Betrieb über 100% sogar nur im Minutenbereich.<br />
** Der Strom war daher vermutlich immer deutlich zu hoch, auch bei 80% Setting wird die Röhre in die Alterung getrieben.<br />
* Leider hat dieses Laser-Gerät keine Stromanzeige, die wäre aber sehr wichtig gewesen<br />
* Die Röhre scheint auch relativ viel Abluft (Rauch) mitgekriegt zu haben - das wird für den Auskoppelspiegel nicht gut sein.<br />
<br />
=== Was wird repariert? ===<br />
* Eine neue Röhre wurde eingebaut<br />
* Ein neues Netzteil wurde ebenfalls mit bestellt, falls das Alte ebenfalls einen Schlag weg hat<br />
* Ein Drehspulenmessinstrument für 50mA für den Laserstrom wurde mit eingebaut<br />
* Eine neue Wasserkühlung wird eingebaut<br />
* Der Bereich um den Strahlaustritt soll mit einem kleinen Überdruck Rauchgasfrei gehalten werden<br />
* Der Maximalstrom soll elektrisch limitiert werden (Schaltung etwa wie beim kleinen CO2-Laser)<br />
** Was ist der Maximalmalstrom? Die Angaben unterscheiden sich:<br />
*** 20kV / 40mA (800W)<br />
*** 26kV / 30mA (780W)<br />
** Die Brennspannung muss also mal gemessen, um den max Strom zu bestimmen.<br />
* Der Strahlengang muss neu justiert werden<br />
<br />
== '''!! ACHTUNG !!''' ==<br />
CO2-Laserschneiden – Warnhinweis:<br />
<br />
Nur folgende Kunststoffe verwenden:<br />
<br />
* Acryl (PMMA)<br />
* Polypropylen (PP)<br />
* Delrin (POM)<br />
* Mylar (PET)<br />
* Kapton (PI)<br />
<br />
Ungeeignet und gefährlich:<br />
<br />
* PVC und andere chlorhaltige Kunststoffe (Beilsteinprobe zur Überprüfung)<br />
* Polycarbonate über 1 mm Dicke (Verfärbung und Verformung)<br />
<br />
Vor dem Schneiden prüfen:<br />
<br />
* Beilsteinprobe auf Chlorverbindungen<br />
* Dicke des Materials beachten<br />
<br />
Beilsteinprobe<br />
<br />
Zuerst wird ein Kupferblech oder eine Kupferöse solange ausgeglüht, bis keine Blau- oder Grünfärbung der Flamme zu erkennen ist. Dies ist unbedingt erforderlich, da schon Spuren von Halogenen ein falsch-positives Ergebnis verursachen können. Beispielsweise kann sich aus Salzsäure und Ammoniak leicht Ammoniumchlorid bilden, das – unbemerkt niedergeschlagen auf Kupferblech oder -draht – ebenfalls eine blau-grüne Flammenfärbung hervorruft.[3]<br />
<br />
Als Nächstes wird die Probe auf das ausgeglühte – noch heiße – Kupferblech oder die Kupferöse aufgebracht und in den nicht leuchtenden Bereich einer Gasbrenner-Flamme gehalten. Wenn sich die Flamme dabei grün bis blaugrün verfärbt, so enthält die Probe mit hoher Wahrscheinlichkeit ein Halogen.<br />
<br />
https://de.wikipedia.org/wiki/Beilsteinprobe<br />
<br />
http://www.chymist.com/Polymer%20Identification.pdf<br />
<br />
== 100W-CO₂-Laser Quick and Dirty HOW_TO ==<br />
<br />
Wenn man den Laser auf dem eigenen Rechner einrichten will ... das ist aber nicht notwendig.<br />
<br />
Benötigte Software:<br />
* RD Works (getestet: V8.1.21) http://www.thunderlaser.com/laser-download<br />
* evtl. Inkscape http://www.inkscape.org/de/ mit Plugin https://github.com/jnweiger/inkscape-thunderlaser - geht, ist aber '''spiegelverkehrt'''!<br />
* Spezielles Visicut mit Thundelaser-Unterstützung: https://github.com/fablabnbg/VisiCut/releases<br />
* USB-Port über Netzwerk via Virtualhere-Client ansteuern: https://www.virtualhere.com/usb_client_software<br />
<br />
Bitte das USB-Kabel '''nicht quer durch den Raum spannen''', das ist eine Stolperfalle und ihr kommt ja auch per Netzwerk drauf.<br />
<br />
== Visicut einrichten ==<br />
Folgende Einstellung wurde mit Visicut version "visicut_1.8-310.1+20181009jw" getestet.<br />
* Origin bottom left (checkbox = off)<br />
* Write to file (checkbox = on) wenn man per USB die Datei auf den Lasercutter übergeben möchte.<br />
* Max Laser power = 80%<br />
* Bed width (mm) = 800<br />
* Bed height (mm) = 600<br />
<br />
== RD Works unter Linux installieren ==<br />
<br />
RD Works lässt sich unter Linux Mint mittels Wine installieren. Die Installationsdatei (.rar) auf dem Rechner speichern, entpacken und die RDWorksV8Setup8.01.21.exe mittels Rechtsklick "Öffnen mit... Wine-Windows-Programmstarter" installieren.<br />
Die Software lässt sich dann aus dem Startmenü (Wine-Ordner) öffnen.<br />
<br />
Verbindung zum Laser: Windows-Rechner lassen sich per USB anschließen, unter Linux noch keine Erfahrung damit.<br />
Unter Linux funktioniert die Verbindung per LAN. Dazu in der Software unter "Device -> Port Settings" ein neues Gerät anlegen "Add..." und "Web" auswählen und die IP-Adresse eingeben. '''Achtung: IP-Adresse noch nicht festgelegt.''' Der Laser muss anscheinend eine feste, manuell vergebene IP-Adresse bekommen. Bei den Tests wurde die IP 10.0.0.205 verwendet, diese kann aber jederzeit vom Router anderweitig vergeben werden. Eine feste Laser-IP muss noch eingerichtet werden. <br />
<br />
Die Verbindung zwischen Linux-Rechner und Lasersteuerung kam erst nach mehrmaligen Einstellungen und Ausprobieren zustande. Danach lief sie aber (zumindest einen Abend lang) stabil.<br />
<br />
== Bedienung RDWorks ==<br />
Es gibt ein paar "Handbuch"-PDFs zur Steuerung und zur Software.<br />
Die Software bietet einfache Grafik- und Text-Funktionen. Außerdem kann man Pfade vereinfachen und einen Daten-Check (offene Pfade?) durchführen.<br />
Es ist aber eigentlich immer zu empfehlen die Erstellung der Vorlage mit einem anderen Programm (etwa Inkscape) vorzunehmen und dann nur das Einstellen der Laserparameter mit RDWorks zu machen.<br />
<br />
== via USB .rd Dateien Lasern ==<br />
Folgende Anleitung bezieht sich auf das Folien Bedienfeld vom Lasercutter.<br />
* Laserschnitt Startposition mit Cursortaste festlegen und mit "Origin" bestätigen<br />
* USB Stick in den USB Buchse auf der rechten Seite stecken.<br />
* Auf Bedienfeld auf "Files" -> "U-Disc"<br />
* Datei auswählen und mit "copy to men" um es in den lokalen Speicher zu speichern.<br />
* Mit "ESC" eine Menüebene zurück<br />
* Laserjob auswählen und mit "RUN" Job starten.<br />
* Falls man den letzten Job nochmal ausführen möchte auf "Start" drücken<br />
<br />
== DWG zu DXF konvertieren ==<br />
* Beim DWG export älteste DWG Version auswählen (AutoCAD 2000/LT2000 Zeichung)<br />
* DWG in LibreCAD öffnen und als DXF abspeichern<br />
<br />
== Materialeinstellungen ==<br />
<br />
'''ToDo:''' Am besten man legt sich so Testkarten an. Außerdem kann man Parameter in RDWorks speichern.<br />
<br />
Bisher ausprobiert: Sperrholz 4 mm, Hartfaserplatte und Acrylglas 3 mm<br />
==== Referenz====<br />
<br />
==== Sperrholz 4mm====<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut ||80 %||20|| Auf Anhieb durch<br />
|-<br />
|}<br />
<br />
==== Acrylglas 3mm====<br />
Bei durchsichtigen Materialien am besten spiegelverkehrt gravieren!<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut||40 %||20||Auf Anhieb durch<br />
|-<br />
|}<br />
<br />
==== Hartfaserplatte 3mm====<br />
Inkscape-thunderlaser:<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Speed!!Power min!!Power max<br />
|-<br />
|Cut||10||80||100<br />
|-<br />
|Cut Shintaro||25||60||80<br />
|-<br />
|Mark||30||10||10<br />
|-<br />
|}<br />
<br />
==== Eurobox (Toom/Surplus systems, transparent) ====<br />
Bitte überprüfen ob es aus Polypropylen hergestellt wurde. Abkürzung für Polypropylen ist PP.<br />
https://de.wikipedia.org/wiki/Polypropylen<br />
<br />
cut: 15, 70, 100 - besser weniger und 2x<br />
<br />
==== Filz ====<br />
cut 100 mm/s, 20-30% power<br />
<br />
==== MDF ====<br />
<br />
==== Spiegel Acryl 3mm ====<br />
<br />
==== Wellpappe ====<br />
<br />
==== Goldkarton, beidseitg matt-gold (gibs beim Real) ====<br />
<br />
==== [https://de.wikipedia.org/wiki/Polyoxymethylen POM 4mm] ====<br />
<br />
==== Glas gravieren ====<br />
<br />
== CO₂-Laser 100W ==<br />
<br />
=== Was noch gefixt werden muss ===<br />
* Klappenschalter kann von Front-Panel-Schalter überbrückt werden (?)<br />
* Klappenschalter wirkt nicht direkt auf das Lasernetzteil<br />
* Abluftschlauch an der Seite ist evtl. ungünstig<br />
* Abluft per Nachlaufsteuerung anschliessen (!)<br />
* Klappen entscheppern/abdichten<br />
* Sicherheitsschalter evtl. auch in Front-Tür bauen<br />
* Schläuche für Wasser und Luft verlängern (andere kaufen)<br />
<br />
Laser Steuerung<br />
[[Datei:LasetSteuerungChina.jpg|200px]]<br />
<br />
=== Was schon ein bisschen gefixt wurde===<br />
* Steps/mm Einstellungen<br />
** Dazu einfach RDWorks per USB verbinden, unter File/Vendor Settings (Passwort: RD8888) gibt es für jede Achse Steps/mm. (unter dem ... Menü können auch direkt gemessene vs. geschnittene Werte eingetragen werden und die Steps werden automatisch berechnet.<br />
* Frontschlitze optisch undurchlässig machen - 17.09.18<br />
<br />
== Reverse Engineering ==<br />
* Laser horcht auf UDP-Ports 50200 und 50207 - evtl. müssen sich diese aber im gleichen 255.255.255.0-Subnetz befinden: https://github.com/jnweiger/ruida-laser/blob/master/doc/protocol.md<br />
* Weitere infos:<br />
** https://wiki.fablab-nuernberg.de/w/Nova_35<br />
** http://www.thunderlaser.com/laser-download<br />
** https://github.com/kkaempf/ruida<br />
** https://github.com/jnweiger/ruida-laser<br />
** https://github.com/jnweiger/ruida-laser/blob/master/doc/laser-nova35-rdworks.md<br />
<br />
== Nützliches ==<br />
Link für Infos zu Lasermaterial<br />
http://atxhackerspace.org/wiki/Laser_Cutter_Materials<br />
<br />
Laser Pfad justieren:<br />
https://www.youtube.com/watch?v=W5390ajG_0k<br />
<br />
Wichtige Info zur Laserpfadjustierung:<br />
* Laserdiode an Röhrenausgang stellen erleichtert die Spiegelausrichtung enorm<br />
** Laserdiode darf etwas schräg auf den ersten Spiegel scheinen, sollte ihn aber Mittig treffen<br />
* Bei den Spiegeln auf den Schlitten nicht auf Spiegelmitte justieren, sondern so, dass die Position möglichst gleich bleibt wenn der Schlitten nah ist oder weit weg ist<br />
** Hint: Justiere in die Richtung, wo der Strahl hingeht, wenn der Schlitten näher kommt:<br />
*** Strahl ist eher unten, kommt nach oben wenn der Schlitten näher kommt: Strahl weiter nach oben stellen<br />
* Verändert sich die Position auf den Spiegeln nicht mehr zwischen nah und fern, kann die Position durch verstellen der Position des Spiegels Mittig gemacht werden<br />
<br />
==Fotos==<br />
<gallery caption="Foto 05.09.2018"><br />
Datei:Neuer_CO2-Laser.jpg|Neuer 100W-CO2-Laser<br />
</gallery><br />
<br />
==Screens Installation==<br />
<gallery caption="Windows 10"><br />
Datei:2020-01-13 21 59 25-Bonjour.png<br />
Datei:2020-01-13 22 01 11-VirtualHereUI.png<br />
Datei:2020-01-13 22 02 20-VirtualHereUI.png<br />
Datei:2020-01-13 22 03 05-VirtualHereUI.png<br />
Datei:2020-01-13 22 16 33-RDWorksV8Uninstall.png<br />
</gallery><br />
<br />
==Laser down==<br />
<gallery caption="Laser down"><br />
Datei:IMG 1758.jpeg<br />
Datei:IMG 1760.jpeg<br />
Datei:IMG 1761.jpeg<br />
</gallery></div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11576
Space Zugangssysem
2024-03-17T19:12:17Z
<p>Tut: /* Zustandswechsel */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
* User-Interface:<br />
** 1-3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
** Speaker: Sound hilft auch (aber I2S Audio ist evtl knapp bei der Leitungszahl)<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
==== Zustandswechsel ====<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür während Stand-By<br />
|-<br />
! Letzte Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Ereigniss !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || egal || Detektion manuelles Zylinderbewegung || Haltestrom wegnehmen, Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Aufgeschlossen || egal || Detektion manuelles Zylinderbewegung || Haltestrom wegnehmen, Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Geöffnet || egal || Detektion manuelles Zylinderbewegung || Haltestrom wegnehmen, Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Unbekannt || egal || Detektion keine manuelle Zylinderbewegung seit 5s || Neue Schlossposition erfassen nach Tabelle || Neuen Zustang nach Tabelle anzeigen<br />
|}<br />
<br />
Neue Stati nach Detektion manuelle Zylinderbewegung:<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür nach Beendigung manueller Zylinderbewegung<br />
|-<br />
! Bereich aktuelle Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Schlossposition neu !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || geschlossen || Abgeschlossen || Anzeigen aktualisieren, zurück zu Standby || "Abgeschlossen"<br />
|-<br />
| Abgeschlossen || offen || Fehler Abgeschlossen aber offen || Signal geben, Anzeigen aktualisieren, zurück zu Standby || "Fehler: Abgeschlossen aber offen"<br />
|-<br />
| Aufgeschlossen || geschlossen || Aufgeschlossen, Tür zu || Anzeigen aktualisieren, zurück zu Standby || "Aufgeschlossen, Tür zu"<br />
|-<br />
| Aufgeschlossen || offen || Aufgeschlossen, Tür offen || Anzeigen aktualisieren, zurück zu Standby || "Aufgeschlossen, Tür offen"<br />
|-<br />
| Geöffnet || geschlossen || Geöffnet, Tür zu || Anzeigen aktualisieren, weiter zu manuell geöffnet || "Geöffnet, Tür zu"<br />
|-<br />
| Geöffnet || offen || Geöffnet, Tür offen || Anzeigen aktualisieren, weiter zu manuell geöffnet || "Geöffnet, Tür offen"<br />
|}<br />
<br />
'''Spezielle Aktion im Status manuell geöffnet:'''<br />
Der Zylinder bleibt ohne Antrieb normalerweise nicht in dieser Position, so dass die Zylinderposition auf "Aufgeschlossen" zurückfällt. Wegen dem etwas schwergängigen Antrieb kann die Position aber nun auf "Geöffnet" stehen bleiben - dass sollte verhindert werden, sofern nicht ausdrücklich der spezielle Zustand "Geöffnet" angefordert wurde (was nur per Elektronik getriggert werden kann).<br />
Die Elektronik sollte dann versuchen mit geringen Strom und für kurze Zeit in die Position "Aufgeschlossen" zu fahren.<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11575
Space Zugangssysem
2024-03-17T17:56:04Z
<p>Tut: /* Zustandswechsel */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
* User-Interface:<br />
** 1-3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
** Speaker: Sound hilft auch (aber I2S Audio ist evtl knapp bei der Leitungszahl)<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
==== Zustandswechsel ====<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür während Stand-By<br />
|-<br />
! Letzte Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Ereigniss !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || egal || Detektion manuelles Zylinderbewegung || Haltestrom wegnehmen, Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Aufgeschlossen || egal || Detektion manuelles Zylinderbewegung || Haltestrom wegnehmen, Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Geöffnet || egal || Detektion manuelles Zylinderbewegung || Haltestrom wegnehmen, Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Unbekannt || egal || Detektion keine manuelle Zylinderbewegung seit 5s || Neue Schlossposition erfassen nach Tabelle || Neuen Zustang nach Tabelle anzeigen<br />
|}<br />
<br />
Neue Stati nach Detektion manuelle Zylinderbewegung:<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür nach Beendigung manueller Zylinderbewegung<br />
|-<br />
! Bereich aktuelle Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Schlossposition neu !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || geschlossen || Abgeschlossen || Anzeigen aktualisieren, zurück zu Standby || "Abgeschlossen"<br />
|-<br />
| Abgeschlossen || offen || Fehler Abgeschlossen aber offen || Signal geben, Anzeigen aktualisieren, zurück zu Standby || "Fehler: Abgeschlossen aber offen"<br />
|-<br />
| Aufgeschlossen || geschlossen || Aufgeschlossen, Tür zu || Anzeigen aktualisieren, zurück zu Standby || "Aufgeschlossen, Tür zu"<br />
|-<br />
| Aufgeschlossen || offen || Aufgeschlossen, Tür offen || Anzeigen aktualisieren, zurück zu Standby || "Aufgeschlossen, Tür offen"<br />
|-<br />
| Geöffnet || geschlossen || Geöffnet, Tür zu || Anzeigen aktualisieren, weiter zu manuell geöffnet || "Geöffnet, Tür zu"<br />
|-<br />
| Geöffnet || offen || Geöffnet, Tür offen || Anzeigen aktualisieren, weiter zu manuell geöffnet || "Geöffnet, Tür offen"<br />
|}<br />
<br />
Spezielle Aktion im Status manuell geöffnet:<br />
Der Zylinder bleibt ohne Antrieb normalerweise nicht in dieser Position, so dass die Zylinderposition auf "Aufgeschlossen" zurückfällt. Wegen dem etwas schwergängigen Antrieb kann die Position aber nun auf "Geöffnet" stehen bleiben - dass sollte verhindert werden, sofern nicht ausdrücklich der spezielle Zustand "Geöffnet" angefordert wurde (was nur per Elektronik getriggert werden kann).<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11574
Space Zugangssysem
2024-03-17T17:42:18Z
<p>Tut: /* Zustandswechsel */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
* User-Interface:<br />
** 1-3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
** Speaker: Sound hilft auch (aber I2S Audio ist evtl knapp bei der Leitungszahl)<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
==== Zustandswechsel ====<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür während Stand-By<br />
|-<br />
! Letzte Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Ereigniss !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || egal || Detektion manuelles Zylinderbewegung || Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Aufgeschlossen || egal || Detektion manuelles Zylinderbewegung || Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Geöffnet || egal || Detektion manuelles Zylinderbewegung || Haltestrom wegnehmen, Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Unbekannt || egal || Detektion keine manuelle Zylinderbewegung seit 5s || Neue Schlossposition erfassen nach Tabelle || Neuen Zustang nach Tabelle anzeigen<br />
|}<br />
<br />
Neue Stati nach Detektion manuelle Zylinderbewegung:<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür nach Beendigung manueller Zylinderbewegung<br />
|-<br />
! Bereich aktuelle Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Schlossposition neu !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || geschlossen || Abgeschlossen || Anzeigen aktualisieren, zurück zu Standby || "Abgeschlossen"<br />
|-<br />
| Abgeschlossen || offen || Fehler Abgeschlossen aber offen || Signal geben, Anzeigen aktualisieren, zurück zu Standby || "Fehler: Abgeschlossen aber offen"<br />
|-<br />
| Aufgeschlossen || geschlossen || Aufgeschlossen, Tür zu || Anzeigen aktualisieren, zurück zu Standby || "Aufgeschlossen, Tür zu"<br />
|-<br />
| Aufgeschlossen || offen || Aufgeschlossen, Tür offen || Anzeigen aktualisieren, zurück zu Standby || "Aufgeschlossen, Tür offen"<br />
|-<br />
| Geöffnet || geschlossen || Geöffnet, Tür zu || Anzeigen aktualisieren, weiter zu manuel Geöffnet || "Geöffnet, Tür zu"<br />
|-<br />
| Geöffnet || offen || Geöffnet, Tür offen || Anzeigen aktualisieren, weiter zu manuel Geöffnet || "Geöffnet, Tür offen"<br />
|}<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11573
Space Zugangssysem
2024-03-17T17:33:46Z
<p>Tut: /* Zustandswechsel = */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
* User-Interface:<br />
** 1-3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
** Speaker: Sound hilft auch (aber I2S Audio ist evtl knapp bei der Leitungszahl)<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
==== Zustandswechsel ====<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür während Stand-By<br />
|-<br />
! Letzte Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Ereigniss !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || egal || Detektion manuelles Zylinderbewegung || Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Aufgeschlossen || egal || Detektion manuelles Zylinderbewegung || Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Geöffnet || egal || Detektion manuelles Zylinderbewegung || Haltestrom wegnehmen, Warte auf Bewegungsstop, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Unbekannt || egal || Detektion keine manuelle Zylinderbewegung seit 5s || Neue Schlossposition erfassen nach Tabelle || Neuen Zustang nach Tabelle anzeigen<br />
<br />
|}<br />
<br />
Neue Stati nach Detektion manuelle Zylinderbewegung:<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür nach Beendigung manueller Zylinderbewegung<br />
|-<br />
! Bereich aktuelle Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Schlossposition neu !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || geschlossen || Abgeschlossen || Anzeigen aktualisieren, zurück zu Standby || "Abgeschlossen"<br />
|-<br />
| Abgeschlossen || offen || Fehler Abgeschlossen aber offen || Signal geben, Anzeigen aktualisieren, zurück zu Standby || "Fehler: Abgeschlossen aber offen"<br />
|-<br />
| Aufgeschlossen || geschlossen || Aufgeschlossen, Tür zu || Anzeigen aktualisieren, zurück zu Standby || "Aufgeschlossen, Tür zu"<br />
|-<br />
| Aufgeschlossen || offen || Aufgeschlossen, Tür offen || Anzeigen aktualisieren, zurück zu Standby || "Aufgeschlossen, Tür offen"<br />
|-<br />
| Geöffnet || geschlossen || Geöffnet, Tür zu || Anzeigen aktualisieren, zurück zu Standby || "Geöffnet, Tür zu"<br />
<br />
<br />
<br />
|}<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11572
Space Zugangssysem
2024-03-17T17:16:21Z
<p>Tut: /* Details Eingangstür */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
* User-Interface:<br />
** 1-3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
** Speaker: Sound hilft auch (aber I2S Audio ist evtl knapp bei der Leitungszahl)<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
=== Zustandswechsel ====<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür<br />
|-<br />
! Letzte Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Ereigniss !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || egal || Detektion manuelles Zylinderbewegung || Neue Schlossposition erfassen, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Aufgeschlossen || egal || Detektion manuelles Zylinderbewegung || Neue Schlossposition erfassen, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Geöffnet || egal || Detektion manuelles Zylinderbewegung || Haltestrom wegnehmen, Neue Schlossposition erfassen, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
|-<br />
| Unbekannt || egal || Detektion keine manuelle Zylinderbewegung seit 5s || Neue Schlossposition erfassen, Schlossposition auf unbekannt setzen || "Manuelle Bewegung detektiert"<br />
<br />
|}<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11571
Space Zugangssysem
2024-03-17T17:07:31Z
<p>Tut: /* Details Eingangstür */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
* User-Interface:<br />
** 1-3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
** Speaker: Sound hilft auch (aber I2S Audio ist evtl knapp bei der Leitungszahl)<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
Zustandswechsel:<br />
<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür<br />
|-<br />
! Letzte Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Ereigniss !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || Tür zu || Detektion manuelles öffnen || Neue Schlossposition erfassen, Schlossposition auf unbekannt setzen || "Manueller Öffnungsvorgang detektiert"<br />
|-<br />
| Abgeschlossen || Tür zu || Detektion manuelles öffnen || Neue Schlossposition erfassen || "Manueller Öffnungsvorgang detektiert"<br />
|-<br />
|}<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11570
Space Zugangssysem
2024-03-17T17:04:15Z
<p>Tut: /* Details Eingangstür */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
* User-Interface:<br />
** 1-3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
** Speaker: Sound hilft auch (aber I2S Audio ist evtl knapp bei der Leitungszahl)<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
Zustandswechsel:<br />
<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür<br />
|-<br />
! Aktuelle Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Ereigniss !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || Tür zu || Detektion manuelles Schliessen || Neue Schlossposition erfassen || "Manueller Öffnungsvorgang detektiert"<br />
|-<br />
|}<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11569
Space Zugangssysem
2024-03-17T17:03:24Z
<p>Tut: </p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
* User-Interface:<br />
** 1-3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
** Speaker: Sound hilft auch (aber I2S Audio ist evtl knapp bei der Leitungszahl)<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
Zustandswechsel:<br />
<br />
{| class="wikitable" <br />
|+ Zustandswechsel und Fehlerzustände der Eingangstür<br />
|-<br />
! Aktuelle Schlossposition !! Aktuelle Türposition (Tür Sensor) !! Ereigniss !! Effekt !! Anzeige <br />
|-<br />
| Abgeschlossen || Tür zu || Schwarz || Detektion manuelles Schliessen || Neue Schlossposition erfassen || "Manueller Öffnungsvorgang detektiert"<br />
|-<br />
|}<br />
<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11568
Space Zugangssysem
2024-03-17T16:55:44Z
<p>Tut: </p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
* User-Interface:<br />
** 1-3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
** Speaker: Sound hilft auch (aber I2S Audio ist evtl knapp bei der Leitungszahl)<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
Zustandswechsel<br />
<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11567
Space Zugangssysem
2024-03-17T16:34:02Z
<p>Tut: /* Features */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann nur kurz offen, Falle wird für 2s zurück gezogen) <br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür offen (Falle wird offen gehalten)<br />
*** Mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
**** Neopixel-Status-Licht<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen<br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
* User-Interface:<br />
** 3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11566
Space Zugangssysem
2024-03-17T16:27:09Z
<p>Tut: /* Ziele */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann noch nicht offen, weil es keine Klinke gibt)<br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür öffnen (= Tür-Klinke betätigen)<br />
*** Entweder nur für 10s aktivieren<br />
*** Oder getriggert von aussen aktivieren (aber wie? Schalter? Bewegungssensor?)<br />
*** Oder mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen <br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
* User-Interface:<br />
** 3 Taster (zu, auf, offene Tür) <br />
** kleines OLED (für Fehlermeldungen)<br />
** Neopixel: Leuchtet in Status-Farbe<br />
* Sensoren:<br />
** Tür geschlossen (Magnetkontakt o.ä.)<br />
** Positionssensor mit AS5600 auf Stepperachse<br />
<br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11565
Space Zugangssysem
2024-03-10T20:05:17Z
<p>Tut: /* Details Eingangstür */</p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann noch nicht offen, weil es keine Klinke gibt)<br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür öffnen (= Tür-Klinke betätigen)<br />
*** Entweder nur für 10s aktivieren<br />
*** Oder getriggert von aussen aktivieren (aber wie? Schalter? Bewegungssensor?)<br />
*** Oder mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen <br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
*** 5. Software: Limitierung der Aktivierungsdauer, der maximalen Schrittzahl sowie StallGuard Enderkennung<br />
<br />
=== Details Innentüren ===<br />
* Sichere Elektronik:<br />
** Gekauftes Antriebssytem verwenden (mechanisch Kraftlimitiert)<br />
** Software: Limitierung der Aktivierungsdauer<br />
* User-Interface:<br />
** Taster mit farbiger LED in Tür:<br />
*** <br />
<br />
=== Generelles ===<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11564
Space Zugangssysem
2024-03-10T19:56:04Z
<p>Tut: </p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann noch nicht offen, weil es keine Klinke gibt)<br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür öffnen (= Tür-Klinke betätigen)<br />
*** Entweder nur für 10s aktivieren<br />
*** Oder getriggert von aussen aktivieren (aber wie? Schalter? Bewegungssensor?)<br />
*** Oder mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen <br />
<br />
=== Details Eingangstür ===<br />
* Sichere Elektronik:<br />
** Darf auf keinen Fall den manuellen Mechanismus blockieren<br />
*** 1. Maximales mechanisches Kraftlimit durch passende Auslegung des Steppermotors<br />
*** 2. Geringeres elektronisches Kraftlimit durch Limitierung der Motorströme<br />
*** 3. Zeitlimitiertes Kraftlimit durch Limitierung der Dauer der Aktivierung des Motors<br />
*** 4. Hardware-Watchdog: Stepper-Treiber Stromlos machen, wenn keine Pulse mehr vorhanden sind <br />
<br />
<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11563
Space Zugangssysem
2024-03-10T19:41:00Z
<p>Tut: </p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann noch nicht offen, weil es keine Klinke gibt)<br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür öffnen (= Tür-Klinke betätigen)<br />
*** Entweder nur für 10s aktivieren<br />
*** Oder getriggert von aussen aktivieren (aber wie? Schalter? Bewegungssensor?)<br />
*** Oder mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen <br />
<br />
=== Details Eingangstür ===<br />
<br />
<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11562
Space Zugangssysem
2024-03-10T19:39:37Z
<p>Tut: </p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
=== Features ===<br />
* Eingangstür<br />
** Zuschließen <br />
*** Per Smart-Phone<br />
*** Von innen getriggert (Knopf vorsehen)<br />
** Aufschließen (Tür ist dann noch nicht offen, weil es keine Klinke gibt)<br />
*** An sich nutzlos, weil Tür dann nicht offen ist - eben nur entriegelt<br />
*** Im Nicht-Space-Betrieb sollte es allerdings Standard sein, sonst kann jeder rein<br />
** Tür öffnen (= Tür-Klinke betätigen)<br />
*** Entweder nur für 10s aktivieren<br />
*** Oder getriggert von aussen aktivieren (aber wie? Schalter? Bewegungssensor?)<br />
*** Oder mit sehr wenig Haltestrom dauerhaft aktivieren<br />
**** Haltestrom abschalten wenn Schloss manuell gedreht, wie erkennen?<br />
*** Wie kommunizieren mit Gästen? Sie sollen einfach reingehen und nach oben kommen...<br />
<br />
* Nebentüren<br />
** Teilweise gibt es eine Klinke (Hauptraum), teilweise nicht (Werkstatt)<br />
** Werkstatt: PIR oder Taster wenn Space offen <br />
<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11561
Space Zugangssysem
2024-03-10T18:29:05Z
<p>Tut: </p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
==== Feature Wunschliste ====<br />
<br />
* Abends automatisch Abschließen (hm, warum?)<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung (sollte man vorher abstimmen, aber zumindest anonymisiert loggen...)<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11560
Space Zugangssysem
2024-03-10T18:26:57Z
<p>Tut: </p>
<hr />
<div><br />
<br />
== Ziele ==<br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang (Schrittmotorantrieb)<br />
** Tür zu Hackerspace Räume (Schlüssel-im-Zylinder Antrieb)<br />
* Normale Funktion mit Schlüssel / Panikhebel muss immer möglich sein<br />
* Haupteingangsantrieb auch von anderen Mietern/Verwaltung nutzbar <br />
<br />
===== Feature Wunschliste ===== <br />
<br />
* Abends automatisch Abschließen.<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Web User mit Keyfile <br />
* Keypad <br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
== Alt: Wird so nicht gemacht ==<br />
===== Tür Informationen ===== <br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11559
Space Zugangssysem
2024-03-04T20:36:23Z
<p>Tut: </p>
<hr />
<div>[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
===== Ziele ===== <br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang<br />
** Tür zu Hackerspace Räume<br />
* Sicher<br />
** nach längeren chat in discord, fazit gegen alles ;)<br />
<br />
===== Zugangsberechtigte für Haupteingang =====<br />
<br />
* Hausmeister / Hausverwaltung<br />
* Alle Mieter<br />
* Reinigungspersonal<br />
<br />
===== Feature Benötigt =====<br />
<br />
* Flucht aus Gebäude muss immer möglich sein<br />
* Öffnen mit vorhandenen Schlüssel <br />
<br />
===== Feature Wunschliste ===== <br />
<br />
* Abends automatisch Abschließen.<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Keypad<br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
Ein Trinamic-Treiber steuert den Stepper und fährt das Schloss gegen den mechanischen Anschlag, der per Stallguard erkannt wird und den Schrittmotor sofort stoppt.<br />
[[Datei:Teleplot_Stallguard1.png|400px|thumb|Stallguard]]<br />
<br />
Jetzt muss das noch fest verkabelt werden und mit etwas zum Autorisieren gekoppelt werden.<br />
<br />
===== Tür Informationen ===== <br />
<br />
<br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11558
Space Zugangssysem
2024-03-03T15:18:45Z
<p>Tut: </p>
<hr />
<div>[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
===== Ziele ===== <br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang<br />
** Tür zu Hackerspace Räume<br />
* Sicher<br />
** nach längeren chat in discord, fazit gegen alles ;)<br />
<br />
===== Zugangsberechtigte für Haupteingang =====<br />
<br />
* Hausmeister / Hausverwaltung<br />
* Alle Mieter<br />
* Reinigungspersonal<br />
<br />
===== Feature Benötigt =====<br />
<br />
* Flucht aus Gebäude muss immer möglich sein<br />
* Öffnen mit vorhandenen Schlüssel <br />
<br />
===== Feature Wunschliste ===== <br />
<br />
* Abends automatisch Abschließen.<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Keypad<br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerantriebMitStepper.jpg|400px|thumb|Selbstbauantrieb]]<br />
<br />
===== Tür Informationen ===== <br />
<br />
<br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Space_Zugangssysem&diff=11557
Space Zugangssysem
2024-03-03T15:16:09Z
<p>Tut: </p>
<hr />
<div>[[Datei:sigenia-flucht.png|400px|thumb|Umschaltfunktion B]]<br />
[[Datei:genius-schema.png|400px|thumb|Genius übersicht]]<br />
[[Datei:genius-pin.png|400px|thumb|Genius Pin]]<br />
<br />
===== Ziele ===== <br />
<br />
* Allen Mitgliedern Zugang zu unseren Räumen ermöglichen.<br />
** Haupteingang<br />
** Tür zu Hackerspace Räume<br />
* Sicher<br />
** nach längeren chat in discord, fazit gegen alles ;)<br />
<br />
===== Zugangsberechtigte für Haupteingang =====<br />
<br />
* Hausmeister / Hausverwaltung<br />
* Alle Mieter<br />
* Reinigungspersonal<br />
<br />
===== Feature Benötigt =====<br />
<br />
* Flucht aus Gebäude muss immer möglich sein<br />
* Öffnen mit vorhandenen Schlüssel <br />
<br />
===== Feature Wunschliste ===== <br />
<br />
* Abends automatisch Abschließen.<br />
* LED Indikator für Offen / Zu<br />
* Protokollierung<br />
* "Pffssschh" Sound beim öffnen<br />
<br />
===== Mögliche Autorisierungsmethoden =====<br />
<br />
* Keypad<br />
** https://www.youtube.com/watch?v=kxJkJ4mdTok<br />
* RFID oder NFC<br />
* Web User und Kennwort<br />
* Optional Webauthn <br />
** https://www.w3.org/TR/webauthn-2/<br />
** https://de.wikipedia.org/wiki/WebAuthn <br />
** https://webauthn.io/<br />
* Web Token auf E-Mail anfordern<br />
<br />
===== Selbst gebauter Antrieb =====<br />
Der Sigenia-Antrieb ist sündhaft teuer und war auch irgendwie nicht zu beschaffen. Wir bauen daher unseren eigenen Antrieb: Ein Schrittmotor treibt mit einem Riemen den Handknauf innen:<br />
[[Datei:TuerMitAmtrieb.jpg|400px|Selbstbauantrieb]]<br />
<br />
===== Tür Informationen ===== <br />
<br />
<br />
<br />
Aktuell verbaute Tür:<br />
<br />
Umschaltfunktion B<br />
<br />
* Öffnen der Tür gegen die Fluchtrichtung über den Drücker: erst nach der Entriegelung über den Schlüssel möglich<br />
* nach Nutzung der Fluchtfunktion und dem Zufallen der Tür: Zugang gegen die Fluchtrichtung wieder blockiert und ein Zurückflüchten nicht mehr möglich<br />
<br />
<br />
https://www.siegenia.com/de/products/door-systems/entrance-doors/emergency-exit-and-panic-door-locks/double-leaf-doors<br />
<br />
<br />
Motorik für Eingangstüren und Zutrittskontrollsysteme:<br />
<br />
https://www.siegenia.com/api/service/downloads/file/178289_de<br />
<br />
<br />
Im vorherigen Dokument wird auf dieses Produktkatalog hingewiesen für Motorik mit Panikfunktion: <br />
<br />
https://www.siegenia.com/api/service/downloads/file/261880_de<br />
<br />
<br />
Datenblatt für möglichen Antrieb (GENIUS 2.2 PANIC, Electromechanical multi-point lock):<br />
<br />
https://www.siegenia.com/api/service/downloads/file/202458_de<br />
<br />
===== GENIUS 2.2 PANIC Anschluß =====<br />
Analoger Anschluss:<br />
* Klemme 0/1: Betriebsarten-Umschaltung Tag-/Nachtbetrieb <br />
* Klemme 2: Spannungsversorgung + 24 V DC <br />
* Klemme 3: Spannungsversorgung (-) <br />
* Klemme 4: Eingang für externes Entriegelungssignal bei + 24 V DC ≥ 1 sek = Öffnungsvorgang <br />
* Klemme 7: Rückmeldefunktion für die Verschluss-Zustands-Anzeige (über Menü einstellbar)<br />
<br />
===== Wie haben andere Hackerspaces gemacht ===== <br />
<br />
https://www.hackerspace-bamberg.de/Spaceportal<br />
<br />
https://wiki.maglab.space/wiki/Zugangskontrolle<br />
<br />
https://wiki.warpzone.ms/projekte:portal</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Datei:TuerantriebMitStepper.jpg&diff=11556
Datei:TuerantriebMitStepper.jpg
2024-03-03T15:06:50Z
<p>Tut: </p>
<hr />
<div></div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Datei:Teleplot_Stallguard1.png&diff=11555
Datei:Teleplot Stallguard1.png
2024-03-03T15:04:42Z
<p>Tut: </p>
<hr />
<div></div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Reloaded:_CO%E2%82%82-Laser_2.0&diff=11554
Reloaded: CO₂-Laser 2.0
2024-03-02T19:21:50Z
<p>Tut: /* Instandsetzungsmaßnahmen 2024 */</p>
<hr />
<div>== Instandsetzungsmaßnahmen 2024 ==<br />
<span style="color:red;">'''LASER DEFEKT''':</span><br />
Der Laser ist derzeit defekt und kann nicht genutzt werden. <br />
<br />
=== Was ist kaputt? ===<br />
Die Laser-Leistung ist recht plötzlich extrem abgefallen und reicht allenfalls noch zum gravieren. Fehlersuche ergab folgende Erkenntnisse:<br />
* Die Leistung ist schon direkt am Ausgang der Röhre extrem schwach, man braucht deutlich länger (etwa 500ms) um ohne Fokusierung ein Loch in Krepp-Band zu schießen.<br />
* Die pinkfarbene Entladung ist in der Röhre zu sehen, auch auf der vollen Länge. Die Helligkeit dieser Entladung scheint aber deutlich geringer zu sein als üblich<br />
* Es wurde bei 99% Leistungsvorgabe ein Strom von knapp über 35mA gemessen:<br />
** Das Netzteil scheint also noch zu funktionieren<br />
** Die Sollvorgabe von 100W Laserröhren ist allerdings nur 30mA für 100%<br />
** Es ist bekannt, dass Röhren nur bei max. 80% der Nennleistung betrieben werden sollen, darüber fällt die Lebensdauer wohl extrem - statt einigen 1000h sind es dann nur noch einige 10h, bei Betrieb über 100% sogar nur im Minutenbereich.<br />
** Der Strom war daher vermutlich immer deutlich zu hoch, auch bei 80% Setting wird die Röhre in die Alterung getrieben.<br />
* Leider hat dieses Laser-Gerät keine Stromanzeige, die wäre aber sehr wichtig gewesen<br />
* Die Röhre scheint auch relativ viel Abluft (Rauch) mitgekriegt zu haben - das wird für den Auskoppelspiegel nicht gut sein.<br />
<br />
=== Was wird repariert? ===<br />
* Eine neue Röhre wurde eingebaut<br />
* Ein neues Netzteil wurde ebenfalls mit bestellt, falls das Alte ebenfalls einen Schlag weg hat<br />
* Ein Drehspulenmessinstrument für 50mA für den Laserstrom wurde mit eingebaut<br />
* Eine neue Wasserkühlung wird eingebaut<br />
* Der Bereich um den Strahlaustritt soll mit einem kleinen Überdruck Rauchgasfrei gehalten werden<br />
* Der Maximalstrom soll elektrisch limitiert werden (Schaltung etwa wie beim kleinen CO2-Laser)<br />
** Was ist der Maximalmalstrom? Die Angaben unterscheiden sich:<br />
*** 20kV / 40mA (800W)<br />
*** 26kV / 30mA (780W)<br />
** Die Brennspannung muss also mal gemessen, um den max Strom zu bestimmen.<br />
* Der Strahlengang muss neu justiert werden<br />
<br />
== '''!! ACHTUNG !!''' ==<br />
CO2-Laserschneiden – Warnhinweis:<br />
<br />
Nur folgende Kunststoffe verwenden:<br />
<br />
* Acryl (PMMA)<br />
* Polypropylen (PP)<br />
* Delrin (POM)<br />
* Mylar (PET)<br />
* Kapton (PI)<br />
<br />
Ungeeignet und gefährlich:<br />
<br />
* PVC und andere chlorhaltige Kunststoffe (Beilsteinprobe zur Überprüfung)<br />
* Polycarbonate über 1 mm Dicke (Verfärbung und Verformung)<br />
<br />
Vor dem Schneiden prüfen:<br />
<br />
* Beilsteinprobe auf Chlorverbindungen<br />
* Dicke des Materials beachten<br />
<br />
Beilsteinprobe<br />
<br />
Zuerst wird ein Kupferblech oder eine Kupferöse solange ausgeglüht, bis keine Blau- oder Grünfärbung der Flamme zu erkennen ist. Dies ist unbedingt erforderlich, da schon Spuren von Halogenen ein falsch-positives Ergebnis verursachen können. Beispielsweise kann sich aus Salzsäure und Ammoniak leicht Ammoniumchlorid bilden, das – unbemerkt niedergeschlagen auf Kupferblech oder -draht – ebenfalls eine blau-grüne Flammenfärbung hervorruft.[3]<br />
<br />
Als Nächstes wird die Probe auf das ausgeglühte – noch heiße – Kupferblech oder die Kupferöse aufgebracht und in den nicht leuchtenden Bereich einer Gasbrenner-Flamme gehalten. Wenn sich die Flamme dabei grün bis blaugrün verfärbt, so enthält die Probe mit hoher Wahrscheinlichkeit ein Halogen.<br />
<br />
https://de.wikipedia.org/wiki/Beilsteinprobe<br />
<br />
http://www.chymist.com/Polymer%20Identification.pdf<br />
<br />
== 100W-CO₂-Laser Quick and Dirty HOW_TO ==<br />
<br />
Wenn man den Laser auf dem eigenen Rechner einrichten will ... das ist aber nicht notwendig.<br />
<br />
Benötigte Software:<br />
* RD Works (getestet: V8.1.21) http://www.thunderlaser.com/laser-download<br />
* evtl. Inkscape http://www.inkscape.org/de/ mit Plugin https://github.com/jnweiger/inkscape-thunderlaser - geht, ist aber '''spiegelverkehrt'''!<br />
* Spezielles Visicut mit Thundelaser-Unterstützung: https://github.com/fablabnbg/VisiCut/releases<br />
* USB-Port über Netzwerk via Virtualhere-Client ansteuern: https://www.virtualhere.com/usb_client_software<br />
<br />
Bitte das USB-Kabel '''nicht quer durch den Raum spannen''', das ist eine Stolperfalle und ihr kommt ja auch per Netzwerk drauf.<br />
<br />
== Visicut einrichten ==<br />
Folgende Einstellung wurde mit Visicut version "visicut_1.8-310.1+20181009jw" getestet.<br />
* Origin bottom left (checkbox = off)<br />
* Write to file (checkbox = on) wenn man per USB die Datei auf den Lasercutter übergeben möchte.<br />
* Max Laser power = 80%<br />
* Bed width (mm) = 800<br />
* Bed height (mm) = 600<br />
<br />
== RD Works unter Linux installieren ==<br />
<br />
RD Works lässt sich unter Linux Mint mittels Wine installieren. Die Installationsdatei (.rar) auf dem Rechner speichern, entpacken und die RDWorksV8Setup8.01.21.exe mittels Rechtsklick "Öffnen mit... Wine-Windows-Programmstarter" installieren.<br />
Die Software lässt sich dann aus dem Startmenü (Wine-Ordner) öffnen.<br />
<br />
Verbindung zum Laser: Windows-Rechner lassen sich per USB anschließen, unter Linux noch keine Erfahrung damit.<br />
Unter Linux funktioniert die Verbindung per LAN. Dazu in der Software unter "Device -> Port Settings" ein neues Gerät anlegen "Add..." und "Web" auswählen und die IP-Adresse eingeben. '''Achtung: IP-Adresse noch nicht festgelegt.''' Der Laser muss anscheinend eine feste, manuell vergebene IP-Adresse bekommen. Bei den Tests wurde die IP 10.0.0.205 verwendet, diese kann aber jederzeit vom Router anderweitig vergeben werden. Eine feste Laser-IP muss noch eingerichtet werden. <br />
<br />
Die Verbindung zwischen Linux-Rechner und Lasersteuerung kam erst nach mehrmaligen Einstellungen und Ausprobieren zustande. Danach lief sie aber (zumindest einen Abend lang) stabil.<br />
<br />
== Bedienung RDWorks ==<br />
Es gibt ein paar "Handbuch"-PDFs zur Steuerung und zur Software.<br />
Die Software bietet einfache Grafik- und Text-Funktionen. Außerdem kann man Pfade vereinfachen und einen Daten-Check (offene Pfade?) durchführen.<br />
Es ist aber eigentlich immer zu empfehlen die Erstellung der Vorlage mit einem anderen Programm (etwa Inkscape) vorzunehmen und dann nur das Einstellen der Laserparameter mit RDWorks zu machen.<br />
<br />
== via USB .rd Dateien Lasern ==<br />
Folgende Anleitung bezieht sich auf das Folien Bedienfeld vom Lasercutter.<br />
* Laserschnitt Startposition mit Cursortaste festlegen und mit "Origin" bestätigen<br />
* USB Stick in den USB Buchse auf der rechten Seite stecken.<br />
* Auf Bedienfeld auf "Files" -> "U-Disc"<br />
* Datei auswählen und mit "copy to men" um es in den lokalen Speicher zu speichern.<br />
* Mit "ESC" eine Menüebene zurück<br />
* Laserjob auswählen und mit "RUN" Job starten.<br />
* Falls man den letzten Job nochmal ausführen möchte auf "Start" drücken<br />
<br />
== DWG zu DXF konvertieren ==<br />
* Beim DWG export älteste DWG Version auswählen (AutoCAD 2000/LT2000 Zeichung)<br />
* DWG in LibreCAD öffnen und als DXF abspeichern<br />
<br />
== Materialeinstellungen ==<br />
<br />
'''ToDo:''' Am besten man legt sich so Testkarten an. Außerdem kann man Parameter in RDWorks speichern.<br />
<br />
Bisher ausprobiert: Sperrholz 4 mm, Hartfaserplatte und Acrylglas 3 mm<br />
==== Referenz====<br />
<br />
==== Sperrholz 4mm====<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut ||80 %||20|| Auf Anhieb durch<br />
|-<br />
|}<br />
<br />
==== Acrylglas 3mm====<br />
Bei durchsichtigen Materialien am besten spiegelverkehrt gravieren!<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut||40 %||20||Auf Anhieb durch<br />
|-<br />
|}<br />
<br />
==== Hartfaserplatte 3mm====<br />
Inkscape-thunderlaser:<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Speed!!Power min!!Power max<br />
|-<br />
|Cut||10||80||100<br />
|-<br />
|Cut Shintaro||25||60||80<br />
|-<br />
|Mark||30||10||10<br />
|-<br />
|}<br />
<br />
==== Eurobox (Toom/Surplus systems, transparent) ====<br />
Bitte überprüfen ob es aus Polypropylen hergestellt wurde. Abkürzung für Polypropylen ist PP.<br />
https://de.wikipedia.org/wiki/Polypropylen<br />
<br />
cut: 15, 70, 100 - besser weniger und 2x<br />
<br />
==== Filz ====<br />
cut 100 mm/s, 20-30% power<br />
<br />
==== MDF ====<br />
<br />
==== Spiegel Acryl 3mm ====<br />
<br />
==== Wellpappe ====<br />
<br />
==== Goldkarton, beidseitg matt-gold (gibs beim Real) ====<br />
<br />
==== [https://de.wikipedia.org/wiki/Polyoxymethylen POM 4mm] ====<br />
<br />
==== Glas gravieren ====<br />
<br />
== CO₂-Laser 100W ==<br />
<br />
=== Was noch gefixt werden muss ===<br />
* Klappenschalter kann von Front-Panel-Schalter überbrückt werden (?)<br />
* Klappenschalter wirkt nicht direkt auf das Lasernetzteil<br />
* Abluftschlauch an der Seite ist evtl. ungünstig<br />
* Abluft per Nachlaufsteuerung anschliessen (!)<br />
* Klappen entscheppern/abdichten<br />
* Sicherheitsschalter evtl. auch in Front-Tür bauen<br />
* Schläuche für Wasser und Luft verlängern (andere kaufen)<br />
<br />
Laser Steuerung<br />
[[Datei:LasetSteuerungChina.jpg|200px]]<br />
<br />
=== Was schon ein bisschen gefixt wurde===<br />
* Steps/mm Einstellungen<br />
** Dazu einfach RDWorks per USB verbinden, unter File/Vendor Settings (Passwort: RD8888) gibt es für jede Achse Steps/mm. (unter dem ... Menü können auch direkt gemessene vs. geschnittene Werte eingetragen werden und die Steps werden automatisch berechnet.<br />
* Frontschlitze optisch undurchlässig machen - 17.09.18<br />
<br />
== Reverse Engineering ==<br />
* Laser horcht auf UDP-Ports 50200 und 50207 - evtl. müssen sich diese aber im gleichen 255.255.255.0-Subnetz befinden: https://github.com/jnweiger/ruida-laser/blob/master/doc/protocol.md<br />
* Weitere infos:<br />
** https://wiki.fablab-nuernberg.de/w/Nova_35<br />
** http://www.thunderlaser.com/laser-download<br />
** https://github.com/kkaempf/ruida<br />
** https://github.com/jnweiger/ruida-laser<br />
** https://github.com/jnweiger/ruida-laser/blob/master/doc/laser-nova35-rdworks.md<br />
<br />
== Nützliches ==<br />
Link für Infos zu Lasermaterial<br />
http://atxhackerspace.org/wiki/Laser_Cutter_Materials<br />
<br />
Laser Pfad justieren:<br />
https://www.youtube.com/watch?v=W5390ajG_0k<br />
<br />
==Fotos==<br />
<gallery caption="Foto 05.09.2018"><br />
Datei:Neuer_CO2-Laser.jpg|Neuer 100W-CO2-Laser<br />
</gallery><br />
<br />
==Screens Installation==<br />
<gallery caption="Windows 10"><br />
Datei:2020-01-13 21 59 25-Bonjour.png<br />
Datei:2020-01-13 22 01 11-VirtualHereUI.png<br />
Datei:2020-01-13 22 02 20-VirtualHereUI.png<br />
Datei:2020-01-13 22 03 05-VirtualHereUI.png<br />
Datei:2020-01-13 22 16 33-RDWorksV8Uninstall.png<br />
</gallery><br />
<br />
==Laser down==<br />
<gallery caption="Laser down"><br />
Datei:IMG 1758.jpeg<br />
Datei:IMG 1760.jpeg<br />
Datei:IMG 1761.jpeg<br />
</gallery></div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11548
WT32-ETH01 ESP32 Modul mit LAN
2024-01-21T15:33:53Z
<p>Tut: /* Wie programmiert man es? */</p>
<hr />
<div>= Besonderheiten =<br />
== LAN Port ==<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Wifi und LAN funktionieren dabei teilweise unabhängig, teilweise abhängig voneinander:<br />
<br />
* Es kann nur LAN genutzt werden und der Funk-Teil kann dann für ESP-Now oder BLE verwendet werden.<br />
* Es kann natürlich auch nur WiFi genutzt werden, LAN liegt dann einfach brach.<br />
* Es kann LAN und WiFi genutzt werden:<br />
** Normalerweise teilt sich das Modul den IP-Stack - typische Funktionen greifen dann mit dem gerade verfügbaren Interface auf das Netzwerk zu und das Modul bekommt im gleichen Netz jeweils eine unterschiedliche Adresse für WiFi und LAN. Es ist mir zumindest per Arduino nicht klar, wie z.B. ein HTTP-Server nur an ein bestimmtes Interface gebunden wird - der Stack scheint immer beide Interface zu bedienen.<br />
** Nur mit speziellen Beispielen (und dann nicht mehr mit der Arduino-Umgebung) lassen sich auch Dinge tun, wo die Interface getrennt werden - damit lassen sich NAT-Router, Access-Points usw realisieren.<br />
<br />
Bei der Prorammierung ergibt sich die Besonderheit, dass auch die Ethernet-Events (also per LAN) als WifiEvent auftauchen - also darin kann man sehen, ob z.B. der Kabel-Link aufgebaut worden ist und eine IP-Adresse bezogen wurde.<br />
<br />
== LEDs ==<br />
Es gibt folgende LEDs:<br />
* Power LED, rot, immer an wenn das Modul versorgt wird<br />
* LED Blau (LED3 im Schaltplan), an GPIO35 - dieser ist ein reiner Eingangsport, die LED kann daher nicht vom ESP32 aktiviert werden<br />
* LED Blau (LED4 im Schaltplan), an GPIO17 - diese LED kann vom ESP32 geschaltet werden (LOW-Aktiv)<br />
<br />
== Nicht nutzbare GPIOs ==<br />
* IO0: Nur zum Programmieren nutzen, teilt sich Takt-Signal mit dem LAN Chip. Pull-up zum normalen Start ist aber vorhanden.<br />
* IO2: Kann genutzt werden, aber besser offen lassen um das Modul programmieren zu können.<br />
* IO6 - IO11: nur intern für das Flash<br />
* IO12: Besser nicht nutzen, Modul startet nicht wenn auf HIGH gezogen<br />
* IO13, IO18, IO19, IO21, IO22, IO23, IO25, IO26, IO27: belegt für LAN-Chip<br />
* IO16: belegt für LAN-Chip Takt Generator<br />
<br />
== Nutzbare GPIOs ==<br />
* IO1: TxD0, Standard UART zum Programmieren und Debuggen<br />
* IO3: RxD0, Standard UART zum Programmieren und Debuggen<br />
* IO4: frei nutzbar<br />
* IO5: frei nutzbar, gibt aber PWM aus beim booten<br />
* IO14: frei nutzbar, gibt aber PWM aus beim booten<br />
* IO15: nutzbar, gibt aber PWM aus beim booten<br />
* IO17: nutzbar, blaue LED ist dran, mit TXD beschriftet (8. Pin von Links-Oben)<br />
* IO35: nutzbar nur als Eingang, blaue LED ist dran, mit RXD beschriftet (7. Pin von Links-Oben)<br />
* IO32: frei nutzbar, beschriftet mit CFG (5. Pin von Links-Oben)<br />
* IO33: frei nutzbar, beschriftet mit 485_EN (6. Pin von Links-Oben)<br />
* IO36: nutzbar nur als Eingang<br />
* IO39: nutzbar nur als Eingang<br />
<br />
<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|500px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin !! Kabel-Farbe<br />
|-<br />
| GND (2. Pin von Links-Oben) || GND || Schwarz<br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 || Rot<br />
|-<br />
| EN (1. oder 4. Pin von Links-Oben) || RST || Violett<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD || Orange<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD || Grau<br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0 || Grün<br />
|}<br />
<br />
In platformio.ini habe ich folgendes stehen um das Modul zu programmieren:<br />
<pre><br />
[env:wt32-eth01]<br />
platform = espressif32<br />
board = wt32-eth01<br />
framework = arduino<br />
monitor_speed = 115200<br />
upload_speed = 460800<br />
</pre><br />
<br />
= Stromversorgung mit 5V =<br />
Wenn es einmal programmiert ist (und man OTA aktiviert hat, was bei diesem Modul dann sowohl per Wifi als auch per LAN funktioniert), kann man es wie folgt per 5V-USB mit Strom versorgen: <br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit +5V<br />
|-<br />
! WT32-ETH01 Pin !! Stromversorgung <br />
|-<br />
| GND (11. Pin von Links-Oben) || GND <br />
|-<br />
| 5V (12. Pin von Links-Oben) || +5V <br />
|}<br />
<br />
= Programmierung =<br />
Das WT32-ETH01 nutzt den LAN8720 Chip, daher bei Ardunino am besten mit dem Beispiel "Ethernet - ETH_LAN8720" beginnen. Der öffnet die LAN Verbindung - spezieller Einstellungen für den LAN-Chip benötigt es praktischerweise nicht, es lief bei mir out-of-the-box. <br />
<br />
Wird zusätzlich WiFi benötigt, kann dieses einfach wie bei anderen ESP32-Beispielen mit hinzugefügt werden. Es gibt dann typischerweise unter Arduino-IDF die zwei Objekte '''ETH''' und '''WiFi'''. Für beide lassen sich die Interface mit den '''.begin''' Methoden starten, beim WiFi muss SSID und WiFi-Passwort übergeben, bei ETH braucht nichts übergeben zu werden.</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=CO%E2%82%82-Laser&diff=11547
CO₂-Laser
2024-01-13T14:37:58Z
<p>Tut: /* CO₂-Laser 100W */</p>
<hr />
<div>[[Datei:BetaLayoutLogo.jpg|220px|alt=Sponsor:Beta LAYOUT|link=http://www.beta-layout.com|right|Sponsor: [http://www.beta-layout.com/ Beta LAYOUT]]]<br />
<br />
== QuickQuick am Gerät ==<br />
main switch<br><br />
Laser switch <br />
<br />
Mini-PC starten<br><br />
RDWorksV8 starten<br><br />
Datei laden<br />
<br />
Material einlegen<br />
Höhe des Lasers kalibrieren mit dem orangenem Kreppband und den beiden Tasten auf der rechten Seite (Lifting-, Drop-Platform)<br />
<br />
Für einen Testlauf den Laser mit dem "Laser switch" deaktivieren<br />
<br />
start drücken<br />
<br />
== CO₂-Laser Quick and Dirty HOW_TO ==<br />
Benötigte Software:<br />
* Visicut http://hci.rwth-aachen.de/visicut<br />
* Inkscape http://www.inkscape.org/de/<br />
<br />
Vorkonfigurierte Leere Inkscape Datei:<br />
[[Datei:LaserTemplate.zip]]<br />
<br />
Visicut Settings zum importieren:<br />
[[Datei:Visicut_Settings.zip]] - '''Bitte Datei nicht entpacken - einfach zip-Datei in Visicut importieren'''<br />
<br />
Die Beispieldatei mit Inkscape öffnen und das gewünschte Objekt malen. Dabei darauf achten, immer im richtigen Layer zu <br />
arbeiten, da später über diese Layer die verschiedenen Gravier/Schneideinstellungen bestimmt werden.<br />
<br />
Probleme mit Visicut?<br />
<br />
* Keine Sonderzeichen und Umlaute in den Dateinamen der importierten Dateien nutzen (sonst gibts seltsame Socket Fehler...). Manchmal werden Einstellungen bei den Materialien nicht richtig übernommen - dann besser das Projekt speichern, Visicut neu starten.<br />
* Visicut läuft, aber der Lasercutter reagiert nicht? IP-Adresse des Lasercutters (aktuell: 10.0.0.172) unter "Optionen - Lasercutter verwalten";" LAOS" überprüfen.<br />
<br />
== Problem: OpenSCAD DXFs Lasern ==<br />
Möchte man DXF-Dateien aus OpenSCAD zum Laserschneiden benutzen müssen die Pfade vorher verbunden werden, dazu bitte wie folgt vorgehen:<br />
<br />
# Visicut-Template in Inkscape öffnen<br />
# DXF-File darin importieren<br />
# Mit dem Pfeil-Tool (F1) alle Objekte markieren (Kasten drum ziehen)<br />
# Im Menü Pfad - Kombinieren wählen (STRG + K)<br />
# Auf das Knoten-Bearbeiten-Tool (F2) klicken<br />
# Wichtig: Jetzt einmal STRG + A drücken - die Knoten werden dadurch erst richtig markiert und anders dargestellt<br />
# Auf "Gewählte Endknoten verbinden" klicken - das kann bei vielen Knoten nun etwas dauern.<br/>[[Datei:Inkscape combine nodes.PNG]]<br/> Jetzt sollten die Pfade ordentlich geschlossen sein - wenn man einen Punkt des Pfades verschiebt sollte der Pfad nun nicht mehr aufbrechen!<br />
# Optional: Im Menü Pfad - Vereinfachen (STRG + L) klicken - dann werden es gerade bei Kreisen viel weniger Punkte...<br />
<br />
Optional: Wenn gewünscht können nun wieder flächige Objekte wie folgt hergestellt werden:<br />
# Das noch kombinierte Objekt anwählen und über Menü Pfad - Zerlegen (UMSCHALT + STRG + K) wieder in einzelne (geschlossene) Pfade zerlegen. Evtl. muss man zuvor noch im Menü Gruppierung - Gruppierung aufheben wählen. Nun sollte man alle geschlossenen Pfade einzeln selektieren können.<br />
# Alle Pfade nun auswählen und über Menü Pfad - Exclusiv-Oder sinnvoll in Objekte umbauen lassen. Jetzt kann testweise eine Füllfarbe festgelegt werden - die Objekte sollten nun richtig aussehen, also auch alle Löcher richtig enthalten.<br />
<br />
=== Alternativ ===<br />
ein 2D-Objekt (oder Projection(cut=true) aus einem 3D-Objekt) rendern und als SVG exportieren.<br />
<br />
== Materialeinstellungen ==<br />
<br />
==== Referenz====<br />
<br />
[[Datei:Examplemat.PNG|thumb]]<br />
<br />
In dieser Datei wurde...<br />
<br />
...MARK mit dem Mark Settings als Vektor geschrieben<br />
<br />
...''Engrave'', sowie beide Balken darunter mit den Engrave Settings gelasert<br />
<br />
...und der vertikale, schwarze Balken in drei Stufen bearbeitet um einen Tiefeneffekt zu erhalten.<br />
<br />
[[http://www.hackerspace-ffm.de/wiki/index.php?title=Datei:LazorMaterial.svg]]<br />
<br />
==== Sperrholz 4mm====<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut 2x||20||15||[[Datei:Sprrhlzmat.png|thumb]]<br />
|-<br />
|Mark||8||100||<br />
|-<br />
|Engrave||8||100||<br />
|}<br />
<br />
<br />
Alternative zu Cut bei Problemholz (am besten um 4mm aufbocken an der vorderen Seite: 1. Power 25, Speed 15, dann 2. Power 25, Speed 7<br />
<br />
Alternative 2: Engrave P20/S100, Cut P100/23 + P100/22<br />
<br />
==== Acrylglas 3mm====<br />
Bei durchsichtigen Materialien am besten spiegelverkehrt gravieren!<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|2 mal Cut||25<br>25||6<br>8||[[Datei:Acrlglsmat.png|thumb]]<br />
|-<br />
|Mark||?||?||<br />
|-<br />
|Engrave (200dpi floyd-steinberg)||50||100||<br />
|-<br />
|Engrave (600dpi floyd-steinberg)||8||50||<br />
|}<br />
<br />
==== Hartfaserplatte 5mm====<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut||50||9||[[Datei:Hrtfsrmat.png|thumb]]<br />
|-<br />
|Mark||8||100||<br />
|-<br />
|Engrave||12||100||<br />
|}<br />
<br />
==== MDF ====<br />
3 mm<br><br />
2 mal Cut 80 power 15 speed<br />
<br />
==== Spiegel Acryl 3mm ====<br />
Cut: Schutzfolie drauf lassen. Durchsichtige Seite nach unten, dann 3x 50% Power, Speed 12. Achtung, die Spiegelfläche leitet Wärme, es brennt sehr schnell! Luft hilft.<br />
<br />
==== Wellpappe ====<br />
4mm: Cut: 2x Power 50, Speed 60.<br />
<br />
7mm: Cut: 4x Power 50, Speed 50 (Mühsam, am besten OHNE Air-Assist! Dafür aber 4x NACHEINANDER fahren, damit Dämpfe nicht fackeln. Auch die Wellpappe so einlegen, dass keine Luft durch die Wellen gezogen wird!)<br />
<br />
==== Goldkarton, beidseitg matt-gold (gibs beim Real) ====<br />
1x Power 50, Speed 25, OHNE Air-Assist, sonst wird die Kante unschön.<br />
<br />
==== [https://de.wikipedia.org/wiki/Polyoxymethylen POM 4mm] ====<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut||12||4||[[Datei:POMlasertest.jpg|thumb]]<br />
|}<br />
<br />
==== Mylarfolie 250µm ====<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut||50||32||[[Datei:BB_Schablone.jpg|thumb]]<br />
|}<br />
<br />
<br />
==== Glas gravieren ====<br />
Schneiden geht nicht, Gravieren im Rastermodus Power 70, Speed 100, bidirektional, 300dpi (mehr macht keinen Sinn). Bitmap-Vorlage wie folgt behandeln: Sehr starker, knackiger Kontrast. Ggf. nachschärfen mit der Funktion "Unscharf Maskieren", Vorlage invertieren! Schwarze Pixel werden gelasert, sehen aber auf Glas weiss aus.<br />
<br />
== CO₂-Laser 40W ==<br />
Anschalten, Daten per Netzwerk reinpumpen, Play drücken. Abluft geht fest angeschlossen nach draussen und Wasserpume kühlt fest gegen einen Radiator, um den man sich nicht kümmern braucht.<br />
<br />
Lasertyp: Es handelt sich um den China-Kracher K40-III mit LAOS-Steuerung <br />
<br />
== Instandsetzungsmaßnahmen 2023 ==<br />
<span style="color:green;">'''Softwareprobleme Visicut <-> Laos: behoben''':</span><br />
Die Übertragung per Visicut an den Laser funktionierte nicht mehr. Neue Laos-Firmware eingespielt - scheint wieder zu gehen.<br />
<br />
# Neuere Laos-Version aufspielen: https://github.com/LaosLaser/Firmware<br />
# Wenn nichts mehr hilft, Steuerung und Software wechseln:<br />
## Steuerung: https://github.com/bdring/FluidNC <br />
## Software: https://github.com/LaserWeb/LaserWeb4 oder https://lasergrbl.com/<br />
<br />
== Instandsetzungsmaßnahmen 2015==<br />
<span style="color:green;">'''Neues Abluftsystem im Raum 2.0 fertig, LASER IST BENUTZBAR''':</span><br />
Außerdem gibt es jetzt ein schönes Control-Panel - endlich ist der Elektronik-Kram auch im Kasten wo er hin gehört.<br />
<br />
== Instandsetzungsmaßnahmen 2014==<br />
<span style="color:green;">'''LASER REPARIERT, IST JETZT BENUTZBAR''':</span><br />
Der Laser ist kaputt gegangen, sowohl der Wasserdurchfluss hat versagt (Dreckspumpe, zu schwach, wir brauchen was besseres mit Durchflusssensor) und es gibt Überschläge im Flyback-Trafo - der sieht irgendwie verbrutzelt aus. Auch die Laserröhre hat Schaden genommen... Röhre, Lasernetzteil und Pumpe mussten ersetzt werden, der Laser läuft jetzt wieder, allerdings noch mit der original China-Steuerung, die noch getauscht werden soll, sobald etwas besseres gefunden wurde, das sowohl Vektoren als auch Rasterdaten gut verarbeiten kann.<br />
<br />
1. Neuer Wasserkreislauf: <br />
* Verschlauchung erneuert, der nun verwendete gewebeschlauch ist deutlich robuster und weniger knickanfällig. Die empfindlichste Stelle ist nun der Silikonschlauch direkt an der Laserröhre <span style="color:green;">'''-> DONE'''</span><br />
<br />
* neue Wasserpumpe Laing DDC-Pumpe 12V DDC-1T Plus [[Datei:WasserpumpeLaser.pdf|Bedienungsanleitung]]; Zul. Spannungsbereich 6 bis 13,2 Volt; max. Förderleistung: 10l/min <span style="color:green;">'''-> DONE'''</span><br />
<br />
* Durchflusssensor Bach DFS 1/25io [[Datei:DurchflusssensorLaser.pdf|Datenblatt]]; Messbereich: 1-25l/min 1000Impulse/l <span style="color:green;">'''-> DONE'''</span><br />
<br />
* Radiator mit Lüfter(n) bestücken - wirklich nötig? Temperatur mal messen. <span style="color:blue;">'''ToDo'''</span><br />
<br />
2. Inbetriebnahme der neuen Laserröhre/Netzteil <span style="color:green;">'''-> DONE'''</span><br />
<br />
3. Überwachungselektronik für Durchfluss Temperatur Etc. - Ein Provisorium schaltet den Laser ab, wenn nicht genug Durchfluss mehr gemessen wird. Das sollte aber noch mal schöner gemacht werden (derzeit Steckbrett mit Arduino im Laser...) <span style="color:blue;">'''ToDo'''</span><br />
<br />
4. Betriebssicherheit nach DIN60825 und BGV B2 herstellen <span style="color:red;">'''ToDo'''</span><br />
<br />
5. Punkte 7 und 8 aus 2013 <span style="color:red;">'''ToDo'''</span><br />
<br />
6. Steuerung tauschen gegen [http://redmine.laoslaser.org/projects/laos/wiki Laos] <span style="color:green;">'''-> DONE'''</span><br />
<br />
== Instandsetzungsmaßnahmen 2013==<br />
Bezüglich des Lasers steht eventuell noch aus auf eine alternative Steuerung nebst Software zu gehen. Das RZL hat ja einen ähnlichen Laser und um unseren gangbar und so nutzbar zu machen, wie deren, braucht es noch etwas Arbeit.<br />
Ich schlage folgendes vor:<br />
<br />
1. Festen Tisch/Stellplatz finden/machen. Da hatte David was vorgeschlagen, das sollten wir tun. <span style="color:green;">'''-> DONE'''</span>.<br />
<br />
2. Absaugung fit machen: Die sollte komplett im Unterdruck laufen, also eine Außenseite, die die Abgase heraus saugt -> Miefquirl muss dann verschoben werden, sollte aber klappen, Absaugung nach Draußen machen wir auch. Alternativ: Alte Absaugung reparieren. <span style="color:green;">'''-> DONE'''</span><br />
<br />
3. Kühlung an den Start bringen: Gefäß mit destilliertem Wasser und ggf. Algenkiller, Schläuche fest installiert -> Ein 5L Kanister Aqua-Dest steht schon bereit, sollte so fest installierbar sein. <span style="color:green;">'''-> DONE'''</span><br />
<br />
4. Strahlgang reinigen, da weiß Steffen sicherlich das ein oder andere zu. <span style="color:green;">'''-> DONE'''</span><br />
<br />
5. Safety Interlock ans Gehäuse bauen: Jede Klappe bekommt Mikroschalter, die den Beam abschalten, wenn irgendwas geöffnet wird -> Mikroschalter liegen bereit, wie man sie am besten anbringt müssen wir dann sehen. <span style="color:green;">'''-> DONE'''</span><br />
<br />
6. Rechner oder VM mit der Lazzor-Software als Festinstallation -> Rechner daneben hat Software installiert, Backup der Software aber nochmal machen. <span style="color:green;">'''-> DONE'''</span><br />
<br />
<span style="color:green;">'''Hurra, die wichtigsten Sachen sind gemacht, der Laser ist wieder einsatzbereit und funktioniert dank neuer Spiegelkalibrierung wieder besser als zuvor!'''</span><br />
<br />
7. Lehre für Einrichtung des Nullpunktes lasern<br />
<br />
8. Kopf mit zwei Linienlasern und Druckluft zum wegräumen von Staub und zum ausblasen der Flammen bauen -- <span style="color:green;">ein Aquarienkompressor mit zwei Abgängen befindet sich schon im Space</span><br />
<br />
9. Elektronik tauschen in etwas, was Microstepping kann und dann auch andere Firmware und Software zum Plotten an den Start bringen. -> Ist die Frage, ob das nennenswert was verbessern würde. Ja, den es gibt doch einige Probleme mit der Software und Firmware, bei manchen Motiven gehen Schritte verloren und die Geschwindigkeit fürs Cutten kann zwar eingestellt werden, hat aber leider keinen Effekt (ein bekannter Bug). Eine alternative für eine Steuerung gibt es hier http://redmine.laoslaser.org/projects/laos/wiki oder hier http://www.artaylor.co.uk/laser_conversion.html mit http://www.lasersaur.com/ . Steuerung vielleicht mit https://www.synthetos.com/project/tinyg/ ?<br />
<br />
== Ideen ==<br />
* Kupferkaschierte Platinen mit schwarzen, schnell-trocknendem Modellbaulack beschichten und diesen gezielt mit dem Laser wegbrennen um so eine Platine zu strukturieren, die anschließend Geätzt werden kann. Den Foto-Lack wegzulasern hatte in der Vergangenheit nicht geklappt, weil dieser abgeplatzt ist. Mit dem anderen Lack könnte es besser klappen.<br />
* Toolchain für den möglichst direkten Weg vom Algorithmus zum Laser-Cutter<br />
** OpenSCAD überzeugt bisher nicht da die erzeugten Export-Formate noch nachbearbeitet werden müssen.<br />
** Processing bietet die Möglichkeit, ein DXF Format zu schreiben.<br />
*** http://www.supermanoeuvre.com/blog/?p=1023<br />
*** Vorteil: Die Dateien können direkt mit VisiCut eingelesen werden.<br />
*** Nachteil: Die Skalierung ist schwierig, nur wenige Zeichenfunktionen von Processing erzeugen sinvolle Export-Daten (Linien, Kreise, aber z.B. kein Text)<br />
<br />
<br />
==Fotos==<br />
<gallery caption="Fotos 05.12.2016"><br />
Datei:Laserkeks_2016-12-05_21-16.jpg|Kekse laserverziert<br />
</gallery><br />
<br />
<gallery caption="Fotos 14.10.2015"><br />
Datei:LaserControlpanel1.JPG|Neues Control Panel<br />
Datei:LaserControlpanel2.JPG|Neues Control Panel<br />
</gallery><br />
<br />
<gallery caption="Fotos 30.01.2015"><br />
Datei:BearingBox.png|Lager Halterung als Processing Vorlage<br />
Datei:BearingBox.jpg|Lasercut der Teile für eine Lagerhalterung<br />
Datei:BearingBox_01.jpg|Lager Halterung fertig zusammen gebaut<br />
Datei:Sideplate.png|SidePlate verbindet zwei Bering boxen als Processing Vorlage<br />
Datei:ConnectedBearingBoxes.jpg|Zwei Bearing Boxen verbunden mit SeitenPlatten<br />
Datei:CamHolder.jpg|WebCamHolder aus Bearing Boxen aufgebaut<br />
<br />
</gallery><br />
<br />
<gallery caption="Fotos 06.12.2014"><br />
Datei:Xmas_lasern1.jpg|Viele Weihnachtsbasteleien aus einem Abend am Laser<br />
Datei:Merry_xmas.jpg|Dicke Pappe gelasert, mit Silberspray versehen, auf Gold-Karton<br />
Datei:Lasermaterial.jpg|Reichliche Materialauswahl im Hackerspace<br />
Datei:Vox1.jpg|Logo für einen Chor, rotes UV-aktives Plexiglas + Spiegelplexi<br />
Datei:Vox_uv.jpg|Logo für einen Chor unter Schwarzlicht<br />
Datei:Led stepup1.jpg|Lasergeschnittenes Blinkschild<br />
Datei:IMAG2082.jpg|Mit Processing erzeugtes ...<br />
Datei:IMAG2085.jpg|... Labyrinth in Pappe<br />
</gallery><br />
<br />
<gallery caption="Fotos 9.11.2014"><br />
Datei:LaserPowersupplyConnection.png|Anschluss des Lasernetzteils an Laos mit high speed Optokopplern.<br />
Datei:HighSpeedPWMMod.jpg|Modifikation aufgebaut auf kleiner Platine<br />
</gallery><br />
<br />
<gallery caption="Fotos 23.9.2014"><br />
Datei:LaserAllesMussRaus.jpg|Der große Ausverkauf - alles muss raus! Das alles kommt jetzt weg weil es unnötig geworden ist oder kaputt.<br />
Datei:Laszor2 wasser pwm adapter.jpg|Adaptore Wasser auf PWM<br />
Datei:Laszor2 tut evil master plan.jpg|Tut's evil laszor master plan<br />
Datei:Laszor2 lv psu.jpg|Low voltage PSU<br />
Datei:Laszor2 tut check.jpg|Tut check<br />
Datei:Laszor2 hv verbindung.jpg|HV Verbindung<br />
Datei:Laszor2 75prozent fertig.jpg|75% fertig<br />
Datei:Laszor2 panel.jpg|Panel + kabel<br />
Datei:Laszor2 kabel.jpg|Mehr Kabel<br />
Datei:Laszor2 hv wasser abfluss.jpg|HV und Wasser Abfluss<br />
Datei:Laszor2 hv plastidip currygeschmack.jpg|HV Anschluss in PlastiDip mit Curry Geschmack<br />
</gallery><br />
<br />
<gallery caption="Fotos 22.9.2014"><br />
Datei:LaserWaKüNeuLaserröhre.jpg|Neue Laserröhre<br />
Datei:LaserWaKüNeuSensor.jpg|Wasserkreislauf jetzt mit Durchflusssensor<br />
Datei:LaserWaKüNeuPumpe.jpg|Neue Wasserpumpe und neues Lasernetzeil<br />
Datei:NewTubeWSupply.jpg|Neue Laserröhre und neues Lasernetzteil warten auf den Einbau<br />
</gallery><br />
<br />
<gallery caption="Fotos 19.4.2014"><br />
Datei:LaserPCBDrehgeb1.jpg|Platine mit schwarzen gelaserten Lack<br />
Datei:LaserPCBDrehgeb2.jpg|Geätzt, durchlicht, Lack noch drauf<br />
Datei:LaserPCBDrehgeb3.jpg|Geätzt, Lack entfernt<br />
Datei:Drehgeb (15x30mm).png|Vorlage als Bitmap<br />
Datei:Erfolg Ätzstrukturierung.png|Genutzte Einstellungen in Lasersoftware, etwa 50% Leistung (bis der Nadeldrucker-Ton gerade wieder verschwindet)<br />
</gallery><br />
<br />
<gallery caption="Fotos 14.4.2014"><br />
Datei:LaserEi.jpg|Hühnerei gelasert<br />
Datei:Atmega329-pinout-laser.jpg|atmega328 gelasert<br />
</gallery><br />
<br />
<gallery caption="Fotos 8.4.2014"><br />
Datei:PappeGelasert.jpg|Pappe gelasert<br />
Datei:DickePappeGelasert.jpg|Dicke Pappe gelasert<br />
Datei:SchaumplastikGelasert.jpg|Schaumplastik gelasert<br />
</gallery><br />
<br />
<gallery caption="Fotos 4.1.2013"><br />
Datei:Foto4392.jpg|hackffm CO₂-Laser<br />
Datei:Foto4393.jpg|hackffm CO₂-Laser<br />
Datei:Foto4395.jpg|Abgasfilterung<br />
Datei:Foto4396.jpg|CO₂-Laser: Hobbyglas<br />
Datei:Foto4398.jpg|Polycarbonat<br />
Datei:Foto4401.jpg|Polycarbonat<br />
</gallery><br />
<br />
<gallery caption="Fotos"><br />
Datei:Foto2076.jpg|Dirk Brummer, Hartmut Seeger<br />
Datei:Foto2077.jpg|CO₂-Laser!<br />
Datei:Foto2078.jpg|40W CO₂-Laser<br />
Datei:Foto2080.jpg|Egg-Bot, Dirk Brummer, Hartmut Seeger, Jo.<br />
Datei:Foto2082.jpg|Our new 40W CO₂-Laser!<br />
Datei:Foto2083.jpg|Another perspective...<br />
</gallery></div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Reloaded:_CO%E2%82%82-Laser_2.0&diff=11546
Reloaded: CO₂-Laser 2.0
2024-01-13T14:25:27Z
<p>Tut: </p>
<hr />
<div>== Instandsetzungsmaßnahmen 2024 ==<br />
<span style="color:red;">'''LASER DEFEKT''':</span><br />
Der Laser ist derzeit defekt und kann nicht genutzt werden. <br />
<br />
=== Was ist kaputt? ===<br />
Die Laser-Leistung ist recht plötzlich extrem abgefallen und reicht allenfalls noch zum gravieren. Fehlersuche ergab folgende Erkenntnisse:<br />
* Die Leistung ist schon direkt am Ausgang der Röhre extrem schwach, man braucht deutlich länger (etwa 500ms) um ohne Fokusierung ein Loch in Krepp-Band zu schießen.<br />
* Die pinkfarbene Entladung ist in der Röhre zu sehen, auch auf der vollen Länge. Die Helligkeit dieser Entladung scheint aber deutlich geringer zu sein als üblich<br />
* Es wurde bei 99% Leistungsvorgabe ein Strom von knapp über 35mA gemessen:<br />
** Das Netzteil scheint also noch zu funktionieren<br />
** Die Sollvorgabe von 100W Laserröhren ist allerdings nur 30mA für 100%<br />
** Es ist bekannt, dass Röhren nur bei max. 80% der Nennleistung betrieben werden sollen, darüber fällt die Lebensdauer wohl extrem - statt einigen 1000h sind es dann nur noch einige 10h, bei Betrieb über 100% sogar nur im Minutenbereich.<br />
** Der Strom war daher vermutlich immer deutlich zu hoch, auch bei 80% Setting wird die Röhre in die Alterung getrieben.<br />
* Leider hat dieses Laser-Gerät keine Stromanzeige, die wäre aber sehr wichtig gewesen<br />
* Die Röhre scheint auch relativ viel Abluft (Rauch) mitgekriegt zu haben - das wird für den Auskoppelspiegel nicht gut sein.<br />
<br />
=== Was wird repariert? ===<br />
* Eine neue Röhre wurde bestellt<br />
* Ein neues Netzteil wurde ebenfalls mit bestellt, falls das Alte ebenfalls einen Schlag weg hat<br />
* Ein Drehspulenmessinstrument für 50mA für den Laserstrom soll mit eingebaut werden<br />
* Die Röhre soll auf höhenverstellbare Halter montiert werden, um den Strahlweg besser ausrichten zu können<br />
<br />
<br />
== '''!! ACHTUNG !!''' ==<br />
CO2-Laserschneiden – Warnhinweis:<br />
<br />
Nur folgende Kunststoffe verwenden:<br />
<br />
* Acryl (PMMA)<br />
* Polypropylen (PP)<br />
* Delrin (POM)<br />
* Mylar (PET)<br />
* Kapton (PI)<br />
<br />
Ungeeignet und gefährlich:<br />
<br />
* PVC und andere chlorhaltige Kunststoffe (Beilsteinprobe zur Überprüfung)<br />
* Polycarbonate über 1 mm Dicke (Verfärbung und Verformung)<br />
<br />
Vor dem Schneiden prüfen:<br />
<br />
* Beilsteinprobe auf Chlorverbindungen<br />
* Dicke des Materials beachten<br />
<br />
Beilsteinprobe<br />
<br />
Zuerst wird ein Kupferblech oder eine Kupferöse solange ausgeglüht, bis keine Blau- oder Grünfärbung der Flamme zu erkennen ist. Dies ist unbedingt erforderlich, da schon Spuren von Halogenen ein falsch-positives Ergebnis verursachen können. Beispielsweise kann sich aus Salzsäure und Ammoniak leicht Ammoniumchlorid bilden, das – unbemerkt niedergeschlagen auf Kupferblech oder -draht – ebenfalls eine blau-grüne Flammenfärbung hervorruft.[3]<br />
<br />
Als Nächstes wird die Probe auf das ausgeglühte – noch heiße – Kupferblech oder die Kupferöse aufgebracht und in den nicht leuchtenden Bereich einer Gasbrenner-Flamme gehalten. Wenn sich die Flamme dabei grün bis blaugrün verfärbt, so enthält die Probe mit hoher Wahrscheinlichkeit ein Halogen.<br />
<br />
https://de.wikipedia.org/wiki/Beilsteinprobe<br />
<br />
http://www.chymist.com/Polymer%20Identification.pdf<br />
<br />
== 100W-CO₂-Laser Quick and Dirty HOW_TO ==<br />
<br />
Wenn man den Laser auf dem eigenen Rechner einrichten will ... das ist aber nicht notwendig.<br />
<br />
Benötigte Software:<br />
* RD Works (getestet: V8.1.21) http://www.thunderlaser.com/laser-download<br />
* evtl. Inkscape http://www.inkscape.org/de/ mit Plugin https://github.com/jnweiger/inkscape-thunderlaser - geht, ist aber '''spiegelverkehrt'''!<br />
* Spezielles Visicut mit Thundelaser-Unterstützung: https://github.com/fablabnbg/VisiCut/releases<br />
* USB-Port über Netzwerk via Virtualhere-Client ansteuern: https://www.virtualhere.com/usb_client_software<br />
<br />
Bitte das USB-Kabel '''nicht quer durch den Raum spannen''', das ist eine Stolperfalle und ihr kommt ja auch per Netzwerk drauf.<br />
<br />
== Visicut einrichten ==<br />
Folgende Einstellung wurde mit Visicut version "visicut_1.8-310.1+20181009jw" getestet.<br />
* Origin bottom left (checkbox = off)<br />
* Write to file (checkbox = on) wenn man per USB die Datei auf den Lasercutter übergeben möchte.<br />
* Max Laser power = 80%<br />
* Bed width (mm) = 800<br />
* Bed height (mm) = 600<br />
<br />
== RD Works unter Linux installieren ==<br />
<br />
RD Works lässt sich unter Linux Mint mittels Wine installieren. Die Installationsdatei (.rar) auf dem Rechner speichern, entpacken und die RDWorksV8Setup8.01.21.exe mittels Rechtsklick "Öffnen mit... Wine-Windows-Programmstarter" installieren.<br />
Die Software lässt sich dann aus dem Startmenü (Wine-Ordner) öffnen.<br />
<br />
Verbindung zum Laser: Windows-Rechner lassen sich per USB anschließen, unter Linux noch keine Erfahrung damit.<br />
Unter Linux funktioniert die Verbindung per LAN. Dazu in der Software unter "Device -> Port Settings" ein neues Gerät anlegen "Add..." und "Web" auswählen und die IP-Adresse eingeben. '''Achtung: IP-Adresse noch nicht festgelegt.''' Der Laser muss anscheinend eine feste, manuell vergebene IP-Adresse bekommen. Bei den Tests wurde die IP 10.0.0.205 verwendet, diese kann aber jederzeit vom Router anderweitig vergeben werden. Eine feste Laser-IP muss noch eingerichtet werden. <br />
<br />
Die Verbindung zwischen Linux-Rechner und Lasersteuerung kam erst nach mehrmaligen Einstellungen und Ausprobieren zustande. Danach lief sie aber (zumindest einen Abend lang) stabil.<br />
<br />
== Bedienung RDWorks ==<br />
Es gibt ein paar "Handbuch"-PDFs zur Steuerung und zur Software.<br />
Die Software bietet einfache Grafik- und Text-Funktionen. Außerdem kann man Pfade vereinfachen und einen Daten-Check (offene Pfade?) durchführen.<br />
Es ist aber eigentlich immer zu empfehlen die Erstellung der Vorlage mit einem anderen Programm (etwa Inkscape) vorzunehmen und dann nur das Einstellen der Laserparameter mit RDWorks zu machen.<br />
<br />
== via USB .rd Dateien Lasern ==<br />
Folgende Anleitung bezieht sich auf das Folien Bedienfeld vom Lasercutter.<br />
* Laserschnitt Startposition mit Cursortaste festlegen und mit "Origin" bestätigen<br />
* USB Stick in den USB Buchse auf der rechten Seite stecken.<br />
* Auf Bedienfeld auf "Files" -> "U-Disc"<br />
* Datei auswählen und mit "copy to men" um es in den lokalen Speicher zu speichern.<br />
* Mit "ESC" eine Menüebene zurück<br />
* Laserjob auswählen und mit "RUN" Job starten.<br />
* Falls man den letzten Job nochmal ausführen möchte auf "Start" drücken<br />
<br />
== DWG zu DXF konvertieren ==<br />
* Beim DWG export älteste DWG Version auswählen (AutoCAD 2000/LT2000 Zeichung)<br />
* DWG in LibreCAD öffnen und als DXF abspeichern<br />
<br />
== Materialeinstellungen ==<br />
<br />
'''ToDo:''' Am besten man legt sich so Testkarten an. Außerdem kann man Parameter in RDWorks speichern.<br />
<br />
Bisher ausprobiert: Sperrholz 4 mm, Hartfaserplatte und Acrylglas 3 mm<br />
==== Referenz====<br />
<br />
==== Sperrholz 4mm====<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut ||80 %||20|| Auf Anhieb durch<br />
|-<br />
|}<br />
<br />
==== Acrylglas 3mm====<br />
Bei durchsichtigen Materialien am besten spiegelverkehrt gravieren!<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut||40 %||20||Auf Anhieb durch<br />
|-<br />
|}<br />
<br />
==== Hartfaserplatte 3mm====<br />
Inkscape-thunderlaser:<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Speed!!Power min!!Power max<br />
|-<br />
|Cut||10||80||100<br />
|-<br />
|Cut Shintaro||25||60||80<br />
|-<br />
|Mark||30||10||10<br />
|-<br />
|}<br />
<br />
==== Eurobox (Toom/Surplus systems, transparent) ====<br />
Bitte überprüfen ob es aus Polypropylen hergestellt wurde. Abkürzung für Polypropylen ist PP.<br />
https://de.wikipedia.org/wiki/Polypropylen<br />
<br />
cut: 15, 70, 100 - besser weniger und 2x<br />
<br />
==== Filz ====<br />
cut 100 mm/s, 20-30% power<br />
<br />
==== MDF ====<br />
<br />
==== Spiegel Acryl 3mm ====<br />
<br />
==== Wellpappe ====<br />
<br />
==== Goldkarton, beidseitg matt-gold (gibs beim Real) ====<br />
<br />
==== [https://de.wikipedia.org/wiki/Polyoxymethylen POM 4mm] ====<br />
<br />
==== Glas gravieren ====<br />
<br />
== CO₂-Laser 100W ==<br />
<br />
=== Was noch gefixt werden muss ===<br />
* Klappenschalter kann von Front-Panel-Schalter überbrückt werden (?)<br />
* Klappenschalter wirkt nicht direkt auf das Lasernetzteil<br />
* Abluftschlauch an der Seite ist evtl. ungünstig<br />
* Abluft per Nachlaufsteuerung anschliessen (!)<br />
* Klappen entscheppern/abdichten<br />
* Sicherheitsschalter evtl. auch in Front-Tür bauen<br />
* Schläuche für Wasser und Luft verlängern (andere kaufen)<br />
<br />
Laser Steuerung<br />
[[Datei:LasetSteuerungChina.jpg|200px]]<br />
<br />
=== Was schon ein bisschen gefixt wurde===<br />
* Steps/mm Einstellungen<br />
** Dazu einfach RDWorks per USB verbinden, unter File/Vendor Settings (Passwort: RD8888) gibt es für jede Achse Steps/mm. (unter dem ... Menü können auch direkt gemessene vs. geschnittene Werte eingetragen werden und die Steps werden automatisch berechnet.<br />
* Frontschlitze optisch undurchlässig machen - 17.09.18<br />
<br />
== Reverse Engineering ==<br />
* Laser horcht auf UDP-Ports 50200 und 50207 - evtl. müssen sich diese aber im gleichen 255.255.255.0-Subnetz befinden: https://github.com/jnweiger/ruida-laser/blob/master/doc/protocol.md<br />
* Weitere infos:<br />
** https://wiki.fablab-nuernberg.de/w/Nova_35<br />
** http://www.thunderlaser.com/laser-download<br />
** https://github.com/kkaempf/ruida<br />
** https://github.com/jnweiger/ruida-laser<br />
** https://github.com/jnweiger/ruida-laser/blob/master/doc/laser-nova35-rdworks.md<br />
<br />
== Nützliches ==<br />
Link für Infos zu Lasermaterial<br />
http://atxhackerspace.org/wiki/Laser_Cutter_Materials<br />
<br />
Laser Pfad justieren:<br />
https://www.youtube.com/watch?v=W5390ajG_0k<br />
<br />
==Fotos==<br />
<gallery caption="Foto 05.09.2018"><br />
Datei:Neuer_CO2-Laser.jpg|Neuer 100W-CO2-Laser<br />
</gallery><br />
<br />
==Screens Installation==<br />
<gallery caption="Windows 10"><br />
Datei:2020-01-13 21 59 25-Bonjour.png<br />
Datei:2020-01-13 22 01 11-VirtualHereUI.png<br />
Datei:2020-01-13 22 02 20-VirtualHereUI.png<br />
Datei:2020-01-13 22 03 05-VirtualHereUI.png<br />
Datei:2020-01-13 22 16 33-RDWorksV8Uninstall.png<br />
</gallery></div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11545
WT32-ETH01 ESP32 Modul mit LAN
2024-01-07T12:36:46Z
<p>Tut: </p>
<hr />
<div>= Besonderheiten =<br />
== LAN Port ==<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Wifi und LAN funktionieren dabei teilweise unabhängig, teilweise abhängig voneinander:<br />
<br />
* Es kann nur LAN genutzt werden und der Funk-Teil kann dann für ESP-Now oder BLE verwendet werden.<br />
* Es kann natürlich auch nur WiFi genutzt werden, LAN liegt dann einfach brach.<br />
* Es kann LAN und WiFi genutzt werden:<br />
** Normalerweise teilt sich das Modul den IP-Stack - typische Funktionen greifen dann mit dem gerade verfügbaren Interface auf das Netzwerk zu und das Modul bekommt im gleichen Netz jeweils eine unterschiedliche Adresse für WiFi und LAN. Es ist mir zumindest per Arduino nicht klar, wie z.B. ein HTTP-Server nur an ein bestimmtes Interface gebunden wird - der Stack scheint immer beide Interface zu bedienen.<br />
** Nur mit speziellen Beispielen (und dann nicht mehr mit der Arduino-Umgebung) lassen sich auch Dinge tun, wo die Interface getrennt werden - damit lassen sich NAT-Router, Access-Points usw realisieren.<br />
<br />
Bei der Prorammierung ergibt sich die Besonderheit, dass auch die Ethernet-Events (also per LAN) als WifiEvent auftauchen - also darin kann man sehen, ob z.B. der Kabel-Link aufgebaut worden ist und eine IP-Adresse bezogen wurde.<br />
<br />
== LEDs ==<br />
Es gibt folgende LEDs:<br />
* Power LED, rot, immer an wenn das Modul versorgt wird<br />
* LED Blau (LED3 im Schaltplan), an GPIO35 - dieser ist ein reiner Eingangsport, die LED kann daher nicht vom ESP32 aktiviert werden<br />
* LED Blau (LED4 im Schaltplan), an GPIO17 - diese LED kann vom ESP32 geschaltet werden (LOW-Aktiv)<br />
<br />
== Nicht nutzbare GPIOs ==<br />
* IO0: Nur zum Programmieren nutzen, teilt sich Takt-Signal mit dem LAN Chip. Pull-up zum normalen Start ist aber vorhanden.<br />
* IO2: Kann genutzt werden, aber besser offen lassen um das Modul programmieren zu können.<br />
* IO6 - IO11: nur intern für das Flash<br />
* IO12: Besser nicht nutzen, Modul startet nicht wenn auf HIGH gezogen<br />
* IO13, IO18, IO19, IO21, IO22, IO23, IO25, IO26, IO27: belegt für LAN-Chip<br />
* IO16: belegt für LAN-Chip Takt Generator<br />
<br />
== Nutzbare GPIOs ==<br />
* IO1: TxD0, Standard UART zum Programmieren und Debuggen<br />
* IO3: RxD0, Standard UART zum Programmieren und Debuggen<br />
* IO4: frei nutzbar<br />
* IO5: frei nutzbar, gibt aber PWM aus beim booten<br />
* IO14: frei nutzbar, gibt aber PWM aus beim booten<br />
* IO15: nutzbar, gibt aber PWM aus beim booten<br />
* IO17: nutzbar, blaue LED ist dran, mit TXD beschriftet (8. Pin von Links-Oben)<br />
* IO35: nutzbar nur als Eingang, blaue LED ist dran, mit RXD beschriftet (7. Pin von Links-Oben)<br />
* IO32: frei nutzbar, beschriftet mit CFG (5. Pin von Links-Oben)<br />
* IO33: frei nutzbar, beschriftet mit 485_EN (6. Pin von Links-Oben)<br />
* IO36: nutzbar nur als Eingang<br />
* IO39: nutzbar nur als Eingang<br />
<br />
<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|500px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin !! Kabel-Farbe<br />
|-<br />
| GND (2. Pin von Links-Oben) || GND || Schwarz<br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 || Rot<br />
|-<br />
| EN (4. Pin von Links-Oben) || RST || Violett<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD || Orange<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD || Grau<br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0 || Grün<br />
|}<br />
<br />
In platformio.ini habe ich folgendes stehen um das Modul zu programmieren:<br />
<pre><br />
[env:wt32-eth01]<br />
platform = espressif32<br />
board = wt32-eth01<br />
framework = arduino<br />
monitor_speed = 115200<br />
upload_speed = 460800<br />
</pre><br />
<br />
= Stromversorgung mit 5V =<br />
Wenn es einmal programmiert ist (und man OTA aktiviert hat, was bei diesem Modul dann sowohl per Wifi als auch per LAN funktioniert), kann man es wie folgt per 5V-USB mit Strom versorgen: <br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit +5V<br />
|-<br />
! WT32-ETH01 Pin !! Stromversorgung <br />
|-<br />
| GND (11. Pin von Links-Oben) || GND <br />
|-<br />
| 5V (12. Pin von Links-Oben) || +5V <br />
|}<br />
<br />
= Programmierung =<br />
Das WT32-ETH01 nutzt den LAN8720 Chip, daher bei Ardunino am besten mit dem Beispiel "Ethernet - ETH_LAN8720" beginnen. Der öffnet die LAN Verbindung - spezieller Einstellungen für den LAN-Chip benötigt es praktischerweise nicht, es lief bei mir out-of-the-box. <br />
<br />
Wird zusätzlich WiFi benötigt, kann dieses einfach wie bei anderen ESP32-Beispielen mit hinzugefügt werden. Es gibt dann typischerweise unter Arduino-IDF die zwei Objekte '''ETH''' und '''WiFi'''. Für beide lassen sich die Interface mit den '''.begin''' Methoden starten, beim WiFi muss SSID und WiFi-Passwort übergeben, bei ETH braucht nichts übergeben zu werden.</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11544
WT32-ETH01 ESP32 Modul mit LAN
2024-01-03T18:46:18Z
<p>Tut: </p>
<hr />
<div>= Besonderheiten =<br />
== LAN Port ==<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Wifi und LAN funktionieren dabei teilweise unabhängig, teilweise abhängig voneinander:<br />
<br />
* Es kann nur LAN genutzt werden und der Funk-Teil kann dann für ESP-Now oder BLE verwendet werden.<br />
* Es kann natürlich auch nur WiFi genutzt werden, LAN liegt dann einfach brach.<br />
* Es kann LAN und WiFi genutzt werden:<br />
** Normalerweise teilt sich das Modul den IP-Stack - typische Funktionen greifen dann mit dem gerade verfügbaren Interface auf das Netzwerk zu und das Modul bekommt im gleichen Netz jeweils eine unterschiedliche Adresse für WiFi und LAN. Es ist mir zumindest per Arduino nicht klar, wie z.B. ein HTTP-Server nur an ein bestimmtes Interface gebunden wird - der Stack scheint immer beide Interface zu bedienen.<br />
** Nur mit speziellen Beispielen (und dann nicht mehr mit der Arduino-Umgebung) lassen sich auch Dinge tun, wo die Interface getrennt werden - damit lassen sich NAT-Router, Access-Points usw realisieren.<br />
<br />
Bei der Prorammierung ergibt sich die Besonderheit, dass auch die Ethernet-Events (also per LAN) als WifiEvent auftauchen - also darin kann man sehen, ob z.B. der Kabel-Link aufgebaut worden ist und eine IP-Adresse bezogen wurde.<br />
<br />
== LEDs ==<br />
Es gibt folgende LEDs:<br />
* Power LED, rot, immer an wenn das Modul versorgt wird<br />
* LED Blau (LED3 im Schaltplan), an GPIO35 - dieser ist ein reiner Eingangsport, die LED kann daher nicht vom ESP32 aktiviert werden<br />
* LED Blau (LED4 im Schaltplan), an GPIO17 - diese LED kann vom ESP32 geschaltet werden (LOW-Aktiv)<br />
<br />
== Nicht nutzbare GPIOs ==<br />
* IO0: Nur zum Programmieren nutzen, teilt sich Takt-Signal mit dem LAN Chip. Pull-up zum normalen Start ist aber vorhanden.<br />
* IO2: Kann genutzt werden, aber besser offen lassen um das Modul programmieren zu können.<br />
* IO6 - IO11: nur intern für das Flash<br />
* IO12: Besser nicht nutzen, Modul startet nicht wenn auf HIGH gezogen<br />
* IO13, IO18, IO19, IO21, IO22, IO23, IO25, IO26, IO27: belegt für LAN-Chip<br />
* IO16: belegt für LAN-Chip Takt Generator<br />
<br />
== Nutzbare GPIOs ==<br />
* IO1: TxD0, Standard UART zum Programmieren und Debuggen<br />
* IO3: RxD0, Standard UART zum Programmieren und Debuggen<br />
* IO4: frei nutzbar<br />
* IO5: frei nutzbar, gibt aber PWM aus beim booten<br />
* IO14: frei nutzbar, gibt aber PWM aus beim booten<br />
* IO15: nutzbar, gibt aber PWM aus beim booten<br />
* IO17: nutzbar, blaue LED ist dran, mit TXD beschriftet (8. Pin von Links-Oben)<br />
* IO35: nutzbar nur als Eingang, blaue LED ist dran, mit RXD beschriftet (7. Pin von Links-Oben)<br />
* IO32: frei nutzbar, beschriftet mit CFG (5. Pin von Links-Oben)<br />
* IO33: frei nutzbar, beschriftet mit 485_EN (6. Pin von Links-Oben)<br />
* IO36: nutzbar nur als Eingang<br />
* IO39: nutzbar nur als Eingang<br />
<br />
<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|500px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}<br />
<br />
In platformio.ini habe ich folgendes stehen um das Modul zu programmieren:<br />
<pre><br />
[env:wt32-eth01]<br />
platform = espressif32<br />
board = wt32-eth01<br />
framework = arduino<br />
monitor_speed = 115200<br />
upload_speed = 460800<br />
</pre><br />
<br />
= Stromversorgung mit 5V =<br />
Wenn es einmal programmiert ist (und man OTA aktiviert hat, was bei diesem Modul dann sowohl per Wifi als auch per LAN funktioniert), kann man es wie folgt per 5V-USB mit Strom versorgen: <br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit +5V<br />
|-<br />
! WT32-ETH01 Pin !! Stromversorgung <br />
|-<br />
| GND (11. Pin von Links-Oben) || GND <br />
|-<br />
| 5V (12. Pin von Links-Oben) || +5V <br />
|}<br />
<br />
= Programmierung =<br />
Das WT32-ETH01 nutzt den LAN8720 Chip, daher bei Ardunino am besten mit dem Beispiel "Ethernet - ETH_LAN8720" beginnen. Der öffnet die LAN Verbindung - spezieller Einstellungen für den LAN-Chip benötigt es praktischerweise nicht, es lief bei mir out-of-the-box. <br />
<br />
Wird zusätzlich WiFi benötigt, kann dieses einfach wie bei anderen ESP32-Beispielen mit hinzugefügt werden. Es gibt dann typischerweise unter Arduino-IDF die zwei Objekte '''ETH''' und '''WiFi'''. Für beide lassen sich die Interface mit den '''.begin''' Methoden starten, beim WiFi muss SSID und WiFi-Passwort übergeben, bei ETH braucht nichts übergeben zu werden.</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11543
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T14:37:16Z
<p>Tut: /* Programmierung */</p>
<hr />
<div>= Besonderheiten =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Wifi und LAN funktionieren dabei teilweise unabhängig, teilweise abhängig voneinander:<br />
<br />
* Es kann nur LAN genutzt werden und der Funk-Teil kann dann für ESP-Now oder BLE verwendet werden.<br />
* Es kann natürlich auch nur WiFi genutzt werden, LAN liegt dann einfach brach.<br />
* Es kann LAN und WiFi genutzt werden:<br />
** Normalerweise teilt sich das Modul den IP-Stack - typische Funktionen greifen dann mit dem gerade verfügbaren Interface auf das Netzwerk zu und das Modul bekommt im gleichen Netz jeweils eine unterschiedliche Adresse für WiFi und LAN. Es ist mir zumindest per Arduino nicht klar, wie z.B. ein HTTP-Server nur an ein bestimmtes Interface gebunden wird - der Stack scheint immer beide Interface zu bedienen.<br />
** Nur mit speziellen Beispielen (und dann nicht mehr mit der Arduino-Umgebung) lassen sich auch Dinge tun, wo die Interface getrennt werden - damit lassen sich NAT-Router, Access-Points usw realisieren.<br />
<br />
Bei der Prorammierung ergibt sich die Besonderheit, dass auch die Ethernet-Events (also per LAN) als WifiEvent auftauchen - also darin kann man sehen, ob z.B. der Kabel-Link aufgebaut worden ist und eine IP-Adresse bezogen wurde.<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|500px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}<br />
<br />
In platformio.ini habe ich folgendes stehen um das Modul zu programmieren:<br />
<pre><br />
[env:wt32-eth01]<br />
platform = espressif32<br />
board = wt32-eth01<br />
framework = arduino<br />
monitor_speed = 115200<br />
upload_speed = 460800<br />
</pre><br />
<br />
= Stromversorgung mit 5V =<br />
Wenn es einmal programmiert ist (und man OTA aktiviert hat, was bei diesem Modul dann sowohl per Wifi als auch per LAN funktioniert), kann man es wie folgt per 5V-USB mit Strom versorgen: <br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit +5V<br />
|-<br />
! WT32-ETH01 Pin !! Stromversorgung <br />
|-<br />
| GND (11. Pin von Links-Oben) || GND <br />
|-<br />
| 5V (12. Pin von Links-Oben) || +5V <br />
|}<br />
<br />
= Programmierung =<br />
Das WT32-ETH01 nutzt den LAN8720 Chip, daher bei Ardunino am besten mit dem Beispiel "Ethernet - ETH_LAN8720" beginnen. Der öffnet die LAN Verbindung - spezieller Einstellungen für den LAN-Chip benötigt es praktischerweise nicht, es lief bei mir out-of-the-box. <br />
<br />
Wird zusätzlich WiFi benötigt, kann dieses einfach wie bei anderen ESP32-Beispielen mit hinzugefügt werden. Es gibt dann typischerweise unter Arduino-IDF die zwei Objekte '''ETH''' und '''WiFi'''. Für beide lassen sich die Interface mit den '''.begin''' Methoden starten, beim WiFi muss SSID und WiFi-Passwort übergeben, bei ETH braucht nichts übergeben zu werden.</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11542
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T14:35:20Z
<p>Tut: </p>
<hr />
<div>= Besonderheiten =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Wifi und LAN funktionieren dabei teilweise unabhängig, teilweise abhängig voneinander:<br />
<br />
* Es kann nur LAN genutzt werden und der Funk-Teil kann dann für ESP-Now oder BLE verwendet werden.<br />
* Es kann natürlich auch nur WiFi genutzt werden, LAN liegt dann einfach brach.<br />
* Es kann LAN und WiFi genutzt werden:<br />
** Normalerweise teilt sich das Modul den IP-Stack - typische Funktionen greifen dann mit dem gerade verfügbaren Interface auf das Netzwerk zu und das Modul bekommt im gleichen Netz jeweils eine unterschiedliche Adresse für WiFi und LAN. Es ist mir zumindest per Arduino nicht klar, wie z.B. ein HTTP-Server nur an ein bestimmtes Interface gebunden wird - der Stack scheint immer beide Interface zu bedienen.<br />
** Nur mit speziellen Beispielen (und dann nicht mehr mit der Arduino-Umgebung) lassen sich auch Dinge tun, wo die Interface getrennt werden - damit lassen sich NAT-Router, Access-Points usw realisieren.<br />
<br />
Bei der Prorammierung ergibt sich die Besonderheit, dass auch die Ethernet-Events (also per LAN) als WifiEvent auftauchen - also darin kann man sehen, ob z.B. der Kabel-Link aufgebaut worden ist und eine IP-Adresse bezogen wurde.<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|500px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}<br />
<br />
In platformio.ini habe ich folgendes stehen um das Modul zu programmieren:<br />
<pre><br />
[env:wt32-eth01]<br />
platform = espressif32<br />
board = wt32-eth01<br />
framework = arduino<br />
monitor_speed = 115200<br />
upload_speed = 460800<br />
</pre><br />
<br />
= Stromversorgung mit 5V =<br />
Wenn es einmal programmiert ist (und man OTA aktiviert hat, was bei diesem Modul dann sowohl per Wifi als auch per LAN funktioniert), kann man es wie folgt per 5V-USB mit Strom versorgen: <br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit +5V<br />
|-<br />
! WT32-ETH01 Pin !! Stromversorgung <br />
|-<br />
| GND (11. Pin von Links-Oben) || GND <br />
|-<br />
| 5V (12. Pin von Links-Oben) || +5V <br />
|}<br />
<br />
= Programmierung =<br />
Das WT32-ETH01 nutzt den LAN8720 Chip, daher bei Ardunino am besten mit dem Beispiel "Ethernet - ETH_LAN8720" beginnen. Der öffnet die LAN Verbindung - spezieller Einstellungen für den LAN-Chip benötigt es praktischerweise nicht, es lief bei mir out-of-the-box. <br />
<br />
Wird zusätzlich WiFi benötigt, kann dieses einfach wie bei anderen ESP32-Beispielen mit hinzugefügt werden. Es gibt dann typischerweise unter Arduino-IDF die zwei Objekte '''ETH''' und '''WiFi'''.</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11541
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T14:29:15Z
<p>Tut: </p>
<hr />
<div>= Besonderheiten =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Wifi und LAN funktionieren dabei teilweise unabhängig, teilweise abhängig voneinander:<br />
<br />
* Es kann nur LAN genutzt werden und der Funk-Teil kann dann für ESP-Now oder BLE verwendet werden.<br />
* Es kann natürlich auch nur WiFi genutzt werden, LAN liegt dann einfach brach.<br />
* Es kann LAN und WiFi genutzt werden:<br />
** Normalerweise teilt sich das Modul den IP-Stack - typische Funktionen greifen dann mit dem gerade verfügbaren Interface auf das Netzwerk zu und das Modul bekommt im gleichen Netz jeweils eine unterschiedliche Adresse für WiFi und LAN. Es ist mir zumindest per Arduino nicht klar, wie z.B. ein HTTP-Server nur an ein bestimmtes Interface gebunden wird - der Stack scheint immer beide Interface zu bedienen.<br />
** Nur mit speziellen Beispielen (und dann nicht mehr mit der Arduino-Umgebung) lassen sich auch Dinge tun, wo die Interface getrennt werden - damit lassen sich NAT-Router, Access-Points usw realisieren.<br />
<br />
Bei der Prorammierung ergibt sich die Besonderheit, dass auch die Ethernet-Events (also per LAN) als WifiEvent auftauchen - also darin kann man sehen, ob z.B. der Kabel-Link aufgebaut worden ist und eine IP-Adresse bezogen wurde.<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|500px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}<br />
<br />
In platformio.ini habe ich folgendes stehen um das Modul zu programmieren:<br />
<pre><br />
[env:wt32-eth01]<br />
platform = espressif32<br />
board = wt32-eth01<br />
framework = arduino<br />
monitor_speed = 115200<br />
upload_speed = 460800<br />
</pre><br />
<br />
= Stromversorgung mit 5V =<br />
Wenn es einmal programmiert ist (und man OTA aktiviert hat, was bei diesem Modul dann sowohl per Wifi als auch per LAN funktioniert), kann man es wie folgt per 5V-USB mit Strom versorgen: <br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit +5V<br />
|-<br />
! WT32-ETH01 Pin !! Stromversorgung <br />
|-<br />
| GND (11. Pin von Links-Oben) || GND <br />
|-<br />
| 5V (12. Pin von Links-Oben) || +5V <br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11540
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T14:08:55Z
<p>Tut: </p>
<hr />
<div>= Worum geht es? =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Der LAN-Anschluss<br />
<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|500px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}<br />
<br />
In platformio.ini habe ich folgendes stehen um das Modul zu programmieren:<br />
<pre><br />
[env:wt32-eth01]<br />
platform = espressif32<br />
board = wt32-eth01<br />
framework = arduino<br />
monitor_speed = 115200<br />
upload_speed = 460800<br />
</pre><br />
<br />
= Stromversorgung mit 5V =<br />
Wenn es einmal programmiert ist (und man OTA aktiviert hat, was bei diesem Modul dann sowohl per Wifi als auch per LAN funktioniert), kann man es wie folgt per 5V-USB mit Strom versorgen: <br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit +5V<br />
|-<br />
! WT32-ETH01 Pin !! Stromversorgung <br />
|-<br />
| GND (11. Pin von Links-Oben) || GND <br />
|-<br />
| 5V (12. Pin von Links-Oben) || +5V <br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11539
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T14:05:29Z
<p>Tut: </p>
<hr />
<div>= Worum geht es? =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Der LAN-Anschluss<br />
<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|500px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}<br />
<br />
In platformio.ini habe ich folgendes stehen um das Modul zu programmieren:<br />
<pre><br />
[env:wt32-eth01]<br />
platform = espressif32<br />
board = wt32-eth01<br />
framework = arduino<br />
monitor_speed = 115200<br />
upload_speed = 460800<br />
</pre></div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11538
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T14:02:35Z
<p>Tut: </p>
<hr />
<div>= Worum geht es? =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Der LAN-Anschluss<br />
<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|500px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11537
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T14:01:56Z
<p>Tut: </p>
<hr />
<div>= Worum geht es? =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Der LAN-Anschluss<br />
<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg|width=400px]]<br />
<br />
{| class="wikitable" <br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11536
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T14:00:53Z
<p>Tut: </p>
<hr />
<div>= Worum geht es? =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Der LAN-Anschluss<br />
<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
[[Datei:WT32 ETH01 with ESP Prog.jpg ]]<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11535
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T14:00:00Z
<p>Tut: </p>
<hr />
<div>= Worum geht es? =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Der LAN-Anschluss<br />
<br />
<br />
= Wie programmiert man es? =<br />
Am einfachsten geht es mit einem ESP Prog Adapter, den man günstig an vielen Stellen kaufen kann, der eigentlich zur Programmierung für ESP-01 Module mit ESP8266 ist, der aber auch hier prima funktioniert.<br />
<br />
Leider hat das WT32-ETH01 Modul einige Pinne mehrfach mit gleichem Namen, aber unterschiedlicher Funktion (RXD, TXD, EN-Pinne) und es ist nicht ganz klar, welche Pinne dann was genau machen. Daher habe ich die Pin-Positionen mit aufgeführt. Das Modul muss wie folgt verbunden werden:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|+ Verbindung WT32-ETH01 mit ESP Prog<br />
|-<br />
! WT32-ETH01 Pin !! ESP Prog Pin <br />
|-<br />
| GND (2. Pin von Links-Oben) || GND <br />
|-<br />
| 3V3 (3. Pin von Links-Oben) || 3V3 <br />
|-<br />
| EN (4. Pin von Links-Oben) || RST<br />
|-<br />
| TXD (1. Pin von Rechts-Oben) || TXD<br />
|-<br />
| RXD (2. Pin von Rechts-Oben) || RXD <br />
|-<br />
| IO0 (3. Pin von Rechts-Oben) || IO0<br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Datei:WT32_ETH01_with_ESP_Prog.jpg&diff=11534
Datei:WT32 ETH01 with ESP Prog.jpg
2024-01-02T13:43:47Z
<p>Tut: </p>
<hr />
<div></div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=WT32-ETH01_ESP32_Modul_mit_LAN&diff=11533
WT32-ETH01 ESP32 Modul mit LAN
2024-01-02T13:43:17Z
<p>Tut: Die Seite wurde neu angelegt: „= Worum geht es? = Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Der LAN-Anschluss“</p>
<hr />
<div>= Worum geht es? =<br />
Das WT32-ETH01 ist ein Modul mit einem ESP32 und einem kabelgebundenen LAN Anschluss. Der LAN-Anschluss</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Projekte&diff=11532
Projekte
2024-01-02T13:38:56Z
<p>Tut: /* Info Sammlung */</p>
<hr />
<div>== Info Sammlung ==<br />
* [[WT32-ETH01 ESP32 Modul mit LAN]] <br />
* [[VNC Server Protokoll verstehen]]<br />
* [[Fern Bild Sprechanlage Einrichten]]<br />
* [[Face Shield]]<br />
* [[OpenCV mit Python]]<br />
* [[Python Grundlagen|Grundlagen zur Benutzung von Python]]<br />
* [[ESP32_with_OLED|ESP32 Module mit integriertem OLED Display]]<br />
* [[Heltec Wifi LoRa 32]]<br />
* [[DataTransferWebRaspberryArduino]]<br />
* [[RaspberryGPIOSerial]]<br />
* [[Kameramodule fuer uC]]<br />
* [[Bluetooth-Modul HC-05]]<br />
* [[Arduino / C Programmierung Grundlagen]]<br />
* [[COVID-19 Nukleotidsequenz anschauen]]<br />
<br />
== Geplante Gemeinschaftsprojekte ==<br />
<br />
* [[DIY NFC-/PWA-Schachspiel (interaktive Holzfiguren mit NFC-Chips und WebApp)]]<br />
* [[Space Zugangssysem]]<br />
* [[NachtderMuseen2020|Alien Space Escape auf der Nacht der Museen]]<br />
* Lötstation<br />
* 5 Achsenfräse<br />
* Käsehobel Upgrade<br />
* Drehbank<br />
* 100W Lasercutter Überarbeitung<br />
* 10 Jahre Hackerspace<br />
<br />
== Laufende Projekte ==<br />
<br />
<gallery mode="packed"><br />
Image:Voidnet Viator img.jpg|link=Reloaded: Voidnet Viator Cyberdeck |[[Voidnet Viator Cyberdeck]]<br />
Image:BLEbc.jpg|link=Reloaded: Bluetooth LE bicycle computer |[[Bluetooth LE bicycle computer]]<br />
Image:elektronisches_saiteninstrument.jpg|link=Reloaded: Elektronisches Saiteninstrument 1.0|[[Elektronisches Saiteninstrument 1.0]]<br />
Image:neuer_CO2-Laser.jpg|link=Reloaded: CO₂-Laser 2.0|[[Reloaded: CO₂-Laser 2.0]]<br />
Image:Diningroomlight_on_table.jpg|link=DesignerEsszimmerLampe|[[DesignerEsszimmerLampe|Designer Esszimmer Lampe]]<br />
Image:HoloDingsYoutube.jpg|link=HoloDings|[[HoloDings|Holo Dings]]<br />
Image:20180624-fpvauto-fpvauto-stdconfig.jpg|link=FPV-Auto|[[FPV-Auto]]<br />
Image:LoRaGoPort aufRPi.jpg|link=LoRaWAN|[[LoRaWAN]]<br />
Image:AVRProgrammer.jpg|link=AVRProgrammer|[[AVRProgrammer]]<br />
Image:EXCISS-isback.jpg|link=EXCISS|[[EXCISS|EXCISS - Experimental Chondrule Formation at the ISS]]<br />
Image:uni_frankfurt_2018.jpg|link=Elektronische_Bassflöte|[[Elektronische_Bassflöte|Elektronische kleine Bassflöte Version 2.0]]<br />
Image:Wiessenthaner ESB 01.jpg|link=Elektronische_Bassflöte|[[Elektronische_Bassflöte|Elektronische kleine Bassflöte Version 1.5]]<br />
Image:LineCamPrinter.jpg|link=LineCamPrinter|[[LineCamPrinter]]<br />
Image:Ominibot.jpg|link=OmnibotWebcontrol|[[OmnibotWebcontrol]]<br />
Image: Steering_kartesian.PNG|link=Space Robot Experimental aka SpaceREx|[[Space Robot Experimental aka SpaceREx]]<br />
Image:Elektronische Bassquerfloete 1.jpg|link=Elektronische_große_Bassflöte_Version_1.0|[[Elektronische_große_Bassflöte_Version_1.0|Elektronische große Bassflöte Version 1.0]]<br />
Image:Kleine Bassfloete.jpg|link=Elektronische_kleine_Bassflöte_Version_1.0|[[Elektronische_kleine_Bassflöte_Version_1.0|Elektronische kleine Bassflöte Version 1.0]]<br />
Image:20170114_161830.jpg|link=Spider UFO|[[Spider UFO|Ufo von SpaceInLasers_3.0]]<br />
Image:AutoUpload_2016_11_08_22_00_57.jpg|link=ReaktiveRadioLight|[[ReaktiveRadioLight|Reaktivlicht auf NRF24L01+ Basis]]<br />
Image:DIY CNC Fräser 2016-10-25 19-42.jpg|link=OpenBuilds Fräse|[[OpenBuilds Fräse]]<br />
Image:Trash.Cache.Logo.png|link=Trash.Cache|[[Trash.Cache]]<br />
Image:Actioncam_case_1.jpg|link=CubicPlates|[[CubicPlates]]<br />
Image:SpaceShuttel_base2.jpg|link=Space_Shuttle|[[Space_Shuttle]]<br />
Image:ntc_clock_progress_1.jpg|link=Clockwork NTP|[[Clockwork NTP]]<br />
Image:Arucomover.jpg|link=Arucomover|[[Arucomover]]<br />
</gallery><br />
<br />
== Projekte im Planungsstadium ==<br />
* [[Stickmaschine]] - Crowdfunding im Mai 2016 zur Anschaffung eines ''CrowdStitchers''<br />
* [[Raum 2.0 - PHASE 2]]<br />
* [[SNES-4-Space]] (Super Nintendo Entertainment System)<br />
* [[hackffmhome|Startseite des Hackerspaces]]<br />
* [[ATmega-Assembler-Lehrgang]]<br />
* [[Geocache]]<br />
* [[IR_Reaktivlicht]]<br />
* [[Ultimaker - ALU]]<br />
* [[Einrichtung]]<br />
* [[Orscheler Seifenkistenrennen]]<br />
* [[PCB Ätzresist tschüss Laser Apparat]]<br />
<br />
== Work in Progress Projekte ==<br />
* [[dingDing MK-I]]<br />
<br />
== Abgeschlossene Projekte ==<br />
* [[MembraneBreathCtrl|Midi Breath-Controller with 4 CC joystick and optical metronome]]<br />
* [[Schlüsselring]]<br />
* [[Mini Sustain Pedal for APC Key25]]<br />
* [[SAMLAIR Airbrush Chamber]]<br />
* [[Flaschenlampe]]<br />
* [[ESP8266 Internet Button]]<br />
* [[CloudBox]]<br />
* [[SpaceInLasers_3.0]] auf der [[Make Rhein-Main 2017]]<br />
** [[Spider UFO]]<br />
*** [[UFO]]<br />
* [[SpaceInLasers|SpaceInLasers 2.0]]<br />
* [[BrickUsingMultipleModules]]<br />
* [[Barcode Scanner Hack]]<br />
* [[Wackelbildprotokollator]]<br />
* [[Do It Yourself Slider für Zeitraffer und Videoaufnahmen|Do It Yourself Slider]]<br />
* [[Rundbunt_Mini_WIFI|Rundbunt Mini WIFI]]<br />
* [[Mikroturbine]]<br />
* [[HackffmActivitySensors_MQTT]]<br />
* [[BrettBoard|BrettBoard - Modulares Transport System (work in progress)]]<br />
* [[Ultraschall Luftpumpe]]<br />
* [[Raspberry PI Zero + nano USB WiFi Adapter mod ]]<br />
* [[Gobo-Projektor]]<br />
* [[ESP8266 mit Arduino programmieren]]<br />
* [[SMD Tools]]<br />
* [[HackFFM-Duino_Chime]]<br />
* [[Raum 2.0 - PHASE 1]]<br />
* [[Workshop BB-One]]<br />
* [[Arduino 1.0.6 auf Raspberry Pi installieren]]<br />
* [[Arduino Bootloader Programmer]]<br />
* [[raspicam|USB-Webcam am Raspberry]]<br />
* [[Raspberry Pi enable ttyS0]]<br />
* [[Spulentraeger]]<br />
* [[LED step-up converter with ATtiny85]]<br />
* [[RPG Effect Templates]]<br />
* [[PLA Flieger]]<br />
* [[Rundbuntplasma|Plasmalampe mit LPD8806 und Raspberry]]<br />
* [[Rundbunt Mini]]<br />
* [[Community 3d-Drucker]]<br />
* [[Mehr_Dampf_Maus]]<br />
* [[Mumomi_Electronic| mumomi RepRap Electronic]]<br />
* [[Isolated_versatile_FTDI|Isolated versatile FTDI]]<br />
* [[CO₂-Laser]]<br />
* [[Jet Antrieb im Maßstab 1:87|Jet-Antrieb für einen Modelltruck im Maßstab 1:87]]<br />
* [[Arduino_IDE_like_serial_monitor_in_the_Raspberry_Pi_shell|Arduino IDE like serial monitor in the Raspberry Pi shell]]<br />
* [[Raspi_EDLC_UPS|Simple Uninterruptible Power Supply (UPS) for Raspberry Pi using Supercapacitors (EDLC)]] <br />
* [[Processing250kBaud|Trick to use non-standard baud rates like 250kB under Linux with Processing]]<br />
* [[DIY-Autoloader]]<br />
* [[Hackffm³RepRap|hackffm³RepRap]]<br />
* [[HanseBot|HanseBot I]]<br />
* [[Podcast]]<br />
* [[SimpleSDAudio|Arduino Library zur Audiowiedergabe mit SD-Karten]]<br />
* [[Hackffm on Air|hackffm on Air]]<br />
* [[HackffmActivitySensors]]<br />
* [[LedBrett]]<br />
* [[Merlin Extruder|Merlin Extruder]]<br />
* [[Buntich]]<br />
* [[Git Benutzen]]<br />
* [[DIY Mikroskop| DIY Mikroskop]]<br />
* [[WMFRA45|Webmontag 45]]<br />
* [[Mendel_Upgrade|Ikea Mendel Upgrade]]<br />
* [[Hackerspace Ffm Stempel und T-Shirts]]<br />
* [[Drawbot@MfK]]<br />
* [[@MfK]]<br />
* [[3D Drucker für Wöhlerschule]] (3 Wochen)<br />
* [[3D-Drucker mit AUGE.de]] (7 Monate)<br />
* [[3D-Drucker für MfK]] (2 Monate)<br />
* [[Raumsuche|Raum 1.0]] (12 Monate)<br />
* [[Hackerspace Flyer]] (7 Wochen)<br />
* [[Wikimediawettbewerb]]<br />
* [[Bristlebots]] (MfK, TEDxYouth)<br />
<br />
== Eingestellte Projekte ==<br />
* [[HACKFFM-Server]]<br />
* [[Community 3d-Drucker 2.0]]<br />
* [[RGB-Pipe]]<br />
* [[Fail Button]]<br />
* [[Ultraschall GPS]]<br />
* [[Neuland Taskforce]]<br />
* [[Airsoft_Pellet_Bitmaps_(build_blog)|Airsoft Pellet Bitmaps (build blog)]]<br />
<br />
[[Kategorie:Projekte|!]]</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Hauptseite&diff=11531
Hauptseite
2024-01-02T13:36:54Z
<p>Tut: </p>
<hr />
<div><!--<span style="color: red;">Bitte beachtet unsere derzeitigen '''[[Corona_Regelungen]]'''</span>--><br />
<br />
Der Hackerspace FFM e.V. befindet sich in Oberursel in Räumen einer ehemaligen Transformatorenfabrik. Der Name des Vereins stammt aus Zeiten, wo der Verein noch in Frankfurt-Rödelheim ansässig war ([[Raum 1.0]]). Wir haben in Oberursel eine preiswerte neue Bleibe gefunden, die uns mehr als 4x soviel Raum bietet wie der Raum in Rödelheim. Damit gibt es auch genug Platz für neue Maschinen - besucht uns einfach an einen der für Besucher offenen Tagen ([[Open_Monday_*|Montags]] und [[Hackffm³RepRap|Mittwochs]] Abends ab 19.00), um unsere neuen Räumlichkeiten zu besichtigen!<br />
<br />
[[Datei:Raum2.0_Lage1c.png|600px|Lage]]<br><br />
[http://www.openstreetmap.org/copyright © OpenStreetMap-Mitwirkende]<br />
<br />
[[Datei:WegEingang1.jpg|x300px|Zum Eingang]]<br />
[[Datei:WegEingang2.jpg|x300px|Zum Eingang]]<br />
<br />
<br />
; Anschrift<br />
:'''Hackerspace Ffm e.V.'''<br />
:Ludwig-Erhard-Str. 32 <br />
:61440 Oberursel<br />
<br />
<br />
; Verein <br />
: [[Termine]]<br />
: [[Satzung]]<br />
: [[Beitragsordnung]]<br />
: [[Protokolle]]<br />
: [[Impressum]]<br />
: [[Hackerspace_Ffm:Datenschutz|Datenschutz]]<br />
<br />
<br />
<!--; IRC, wird nicht gepflegt zur Zeit...<br />
: '''Server''': irc.freenode.net<br /><br />
: '''Port''': 6667<br /><br />
: '''Channel''': #hackerspace-ffm<br /><br />
: '''Hotlink''': irc://irc.freenode.net:6667/hackerspace-ffm<br /><br />
<br />//--><br />
; E-Mail<br />
:[[Datei:Email.gif]]<br />
<br />
<br />
; Web / Einstiegsseite<br />
:[https://www.hackerspace-ffm.de www.hackerspace-ffm.de]<br />
:[http://www.hackffm.de www.hackffm.de]<br />
<br />
<br />
; Twitter<br />
: [https://twitter.com/hackffm @hackffm]<br />
: Hashtag: #hackffm<br /><br />
<br />
<br />
; Telefon / Anrufbeantworter<br /><br />
: 069 1755 41 48<br />
:''(Die Nachricht wird aufgezeichnet und in einen e-Mail-Verteiler weitergeleitet.)''<br />
: 06171 892 9955 <br />
:''(Telefon im Labor, ungewiss ob jemand drangeht...)''<br />
<br />
<br />
; Stempel<br />
:Für Besucher mit / for visitors with [[Hackerspace_Ffm_Stempel_und_T-Shirts#Ein_Stempel_f.C3.BCr_den_Hackerspace|Hackerspace Pass]]<br />
:[[Datei:Hackerspace FFM Stamp reviewed.png|100px|none]]<br />
<br />
<br />
[[Kategorie:Location]]</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=Reloaded:_CO%E2%82%82-Laser_2.0&diff=11530
Reloaded: CO₂-Laser 2.0
2023-12-22T16:34:46Z
<p>Tut: /* Materialeinstellungen */</p>
<hr />
<div>== '''!! ACHTUNG !!''' ==<br />
CO2-Laserschneiden – Warnhinweis:<br />
<br />
Nur folgende Kunststoffe verwenden:<br />
<br />
* Acryl (PMMA)<br />
* Polypropylen (PP)<br />
* Delrin (POM)<br />
* Mylar (PET)<br />
* Kapton (PI)<br />
<br />
Ungeeignet und gefährlich:<br />
<br />
* PVC und andere chlorhaltige Kunststoffe (Beilsteinprobe zur Überprüfung)<br />
* Polycarbonate über 1 mm Dicke (Verfärbung und Verformung)<br />
<br />
Vor dem Schneiden prüfen:<br />
<br />
* Beilsteinprobe auf Chlorverbindungen<br />
* Dicke des Materials beachten<br />
<br />
Beilsteinprobe<br />
<br />
Zuerst wird ein Kupferblech oder eine Kupferöse solange ausgeglüht, bis keine Blau- oder Grünfärbung der Flamme zu erkennen ist. Dies ist unbedingt erforderlich, da schon Spuren von Halogenen ein falsch-positives Ergebnis verursachen können. Beispielsweise kann sich aus Salzsäure und Ammoniak leicht Ammoniumchlorid bilden, das – unbemerkt niedergeschlagen auf Kupferblech oder -draht – ebenfalls eine blau-grüne Flammenfärbung hervorruft.[3]<br />
<br />
Als Nächstes wird die Probe auf das ausgeglühte – noch heiße – Kupferblech oder die Kupferöse aufgebracht und in den nicht leuchtenden Bereich einer Gasbrenner-Flamme gehalten. Wenn sich die Flamme dabei grün bis blaugrün verfärbt, so enthält die Probe mit hoher Wahrscheinlichkeit ein Halogen.<br />
<br />
https://de.wikipedia.org/wiki/Beilsteinprobe<br />
<br />
http://www.chymist.com/Polymer%20Identification.pdf<br />
<br />
== 100W-CO₂-Laser Quick and Dirty HOW_TO ==<br />
<br />
Wenn man den Laser auf dem eigenen Rechner einrichten will ... das ist aber nicht notwendig.<br />
<br />
Benötigte Software:<br />
* RD Works (getestet: V8.1.21) http://www.thunderlaser.com/laser-download<br />
* evtl. Inkscape http://www.inkscape.org/de/ mit Plugin https://github.com/jnweiger/inkscape-thunderlaser - geht, ist aber '''spiegelverkehrt'''!<br />
* Spezielles Visicut mit Thundelaser-Unterstützung: https://github.com/fablabnbg/VisiCut/releases<br />
* USB-Port über Netzwerk via Virtualhere-Client ansteuern: https://www.virtualhere.com/usb_client_software<br />
<br />
Bitte das USB-Kabel '''nicht quer durch den Raum spannen''', das ist eine Stolperfalle und ihr kommt ja auch per Netzwerk drauf.<br />
<br />
== Visicut einrichten ==<br />
Folgende Einstellung wurde mit Visicut version "visicut_1.8-310.1+20181009jw" getestet.<br />
* Origin bottom left (checkbox = off)<br />
* Write to file (checkbox = on) wenn man per USB die Datei auf den Lasercutter übergeben möchte.<br />
* Max Laser power = 80%<br />
* Bed width (mm) = 800<br />
* Bed height (mm) = 600<br />
<br />
== RD Works unter Linux installieren ==<br />
<br />
RD Works lässt sich unter Linux Mint mittels Wine installieren. Die Installationsdatei (.rar) auf dem Rechner speichern, entpacken und die RDWorksV8Setup8.01.21.exe mittels Rechtsklick "Öffnen mit... Wine-Windows-Programmstarter" installieren.<br />
Die Software lässt sich dann aus dem Startmenü (Wine-Ordner) öffnen.<br />
<br />
Verbindung zum Laser: Windows-Rechner lassen sich per USB anschließen, unter Linux noch keine Erfahrung damit.<br />
Unter Linux funktioniert die Verbindung per LAN. Dazu in der Software unter "Device -> Port Settings" ein neues Gerät anlegen "Add..." und "Web" auswählen und die IP-Adresse eingeben. '''Achtung: IP-Adresse noch nicht festgelegt.''' Der Laser muss anscheinend eine feste, manuell vergebene IP-Adresse bekommen. Bei den Tests wurde die IP 10.0.0.205 verwendet, diese kann aber jederzeit vom Router anderweitig vergeben werden. Eine feste Laser-IP muss noch eingerichtet werden. <br />
<br />
Die Verbindung zwischen Linux-Rechner und Lasersteuerung kam erst nach mehrmaligen Einstellungen und Ausprobieren zustande. Danach lief sie aber (zumindest einen Abend lang) stabil.<br />
<br />
== Bedienung RDWorks ==<br />
Es gibt ein paar "Handbuch"-PDFs zur Steuerung und zur Software.<br />
Die Software bietet einfache Grafik- und Text-Funktionen. Außerdem kann man Pfade vereinfachen und einen Daten-Check (offene Pfade?) durchführen.<br />
Es ist aber eigentlich immer zu empfehlen die Erstellung der Vorlage mit einem anderen Programm (etwa Inkscape) vorzunehmen und dann nur das Einstellen der Laserparameter mit RDWorks zu machen.<br />
<br />
== via USB .rd Dateien Lasern ==<br />
Folgende Anleitung bezieht sich auf das Folien Bedienfeld vom Lasercutter.<br />
* Laserschnitt Startposition mit Cursortaste festlegen und mit "Origin" bestätigen<br />
* USB Stick in den USB Buchse auf der rechten Seite stecken.<br />
* Auf Bedienfeld auf "Files" -> "U-Disc"<br />
* Datei auswählen und mit "copy to men" um es in den lokalen Speicher zu speichern.<br />
* Mit "ESC" eine Menüebene zurück<br />
* Laserjob auswählen und mit "RUN" Job starten.<br />
* Falls man den letzten Job nochmal ausführen möchte auf "Start" drücken<br />
<br />
== DWG zu DXF konvertieren ==<br />
* Beim DWG export älteste DWG Version auswählen (AutoCAD 2000/LT2000 Zeichung)<br />
* DWG in LibreCAD öffnen und als DXF abspeichern<br />
<br />
== Materialeinstellungen ==<br />
<br />
'''ToDo:''' Am besten man legt sich so Testkarten an. Außerdem kann man Parameter in RDWorks speichern.<br />
<br />
Bisher ausprobiert: Sperrholz 4 mm, Hartfaserplatte und Acrylglas 3 mm<br />
==== Referenz====<br />
<br />
==== Sperrholz 4mm====<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut ||80 %||20|| Auf Anhieb durch<br />
|-<br />
|}<br />
<br />
==== Acrylglas 3mm====<br />
Bei durchsichtigen Materialien am besten spiegelverkehrt gravieren!<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Power!!Speed!!Bild<br />
|-<br />
|Cut||40 %||20||Auf Anhieb durch<br />
|-<br />
|}<br />
<br />
==== Hartfaserplatte 3mm====<br />
Inkscape-thunderlaser:<br />
{|class="wikitable" style="text-align: left; color: #333; padding:12px; vertical-align:top; "<br />
!Schnitt!!Speed!!Power min!!Power max<br />
|-<br />
|Cut||10||80||100<br />
|-<br />
|Cut Shintaro||25||60||80<br />
|-<br />
|Mark||30||10||10<br />
|-<br />
|}<br />
<br />
==== Eurobox (Toom/Surplus systems, transparent) ====<br />
Bitte überprüfen ob es aus Polypropylen hergestellt wurde. Abkürzung für Polypropylen ist PP.<br />
https://de.wikipedia.org/wiki/Polypropylen<br />
<br />
cut: 15, 70, 100 - besser weniger und 2x<br />
<br />
==== Filz ====<br />
cut 100 mm/s, 20-30% power<br />
<br />
==== MDF ====<br />
<br />
==== Spiegel Acryl 3mm ====<br />
<br />
==== Wellpappe ====<br />
<br />
==== Goldkarton, beidseitg matt-gold (gibs beim Real) ====<br />
<br />
==== [https://de.wikipedia.org/wiki/Polyoxymethylen POM 4mm] ====<br />
<br />
==== Glas gravieren ====<br />
<br />
== CO₂-Laser 100W ==<br />
<br />
=== Was noch gefixt werden muss ===<br />
* Klappenschalter kann von Front-Panel-Schalter überbrückt werden (?)<br />
* Klappenschalter wirkt nicht direkt auf das Lasernetzteil<br />
* Abluftschlauch an der Seite ist evtl. ungünstig<br />
* Abluft per Nachlaufsteuerung anschliessen (!)<br />
* Klappen entscheppern/abdichten<br />
* Sicherheitsschalter evtl. auch in Front-Tür bauen<br />
* Schläuche für Wasser und Luft verlängern (andere kaufen)<br />
<br />
Laser Steuerung<br />
[[Datei:LasetSteuerungChina.jpg|200px]]<br />
<br />
=== Was schon ein bisschen gefixt wurde===<br />
* Steps/mm Einstellungen<br />
** Dazu einfach RDWorks per USB verbinden, unter File/Vendor Settings (Passwort: RD8888) gibt es für jede Achse Steps/mm. (unter dem ... Menü können auch direkt gemessene vs. geschnittene Werte eingetragen werden und die Steps werden automatisch berechnet.<br />
* Frontschlitze optisch undurchlässig machen - 17.09.18<br />
<br />
== Reverse Engineering ==<br />
* Laser horcht auf UDP-Ports 50200 und 50207 - evtl. müssen sich diese aber im gleichen 255.255.255.0-Subnetz befinden: https://github.com/jnweiger/ruida-laser/blob/master/doc/protocol.md<br />
* Weitere infos:<br />
** https://wiki.fablab-nuernberg.de/w/Nova_35<br />
** http://www.thunderlaser.com/laser-download<br />
** https://github.com/kkaempf/ruida<br />
** https://github.com/jnweiger/ruida-laser<br />
** https://github.com/jnweiger/ruida-laser/blob/master/doc/laser-nova35-rdworks.md<br />
<br />
== Nützliches ==<br />
Link für Infos zu Lasermaterial<br />
http://atxhackerspace.org/wiki/Laser_Cutter_Materials<br />
<br />
Laser Pfad justieren:<br />
https://www.youtube.com/watch?v=W5390ajG_0k<br />
<br />
==Fotos==<br />
<gallery caption="Foto 05.09.2018"><br />
Datei:Neuer_CO2-Laser.jpg|Neuer 100W-CO2-Laser<br />
</gallery><br />
<br />
==Screens Installation==<br />
<gallery caption="Windows 10"><br />
Datei:2020-01-13 21 59 25-Bonjour.png<br />
Datei:2020-01-13 22 01 11-VirtualHereUI.png<br />
Datei:2020-01-13 22 02 20-VirtualHereUI.png<br />
Datei:2020-01-13 22 03 05-VirtualHereUI.png<br />
Datei:2020-01-13 22 16 33-RDWorksV8Uninstall.png<br />
</gallery></div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=VNC_Server_Protokoll_verstehen&diff=11525
VNC Server Protokoll verstehen
2023-11-20T01:27:51Z
<p>Tut: </p>
<hr />
<div>== Hintergrund ==<br />
Das VNC Protokoll eignet sich gut, um es auch bei Microcontrollern mit Netzwerkzugang wie z.B. den ESP32 / ESP8266 zu nutzen. Damit lassen sich Bildschirminhalte von Displays in Echtzeit übertragen, was bei der Entwicklung von Nutzen sein kann. Sogar "Headless" Anwendungen sind denkbar, also grafische Anwendungen auf dem ESP laufen lassen, der selbst kein Display hat, wo die Steuerung dann ausschließlich über VNC erfolgt.<br />
<br />
[https://github.com/hackffm/ESP32_VNCServer Arduino/PlattformIO Beispiel auf Github]<br />
<br />
== Protokoll ==<br />
Das Protokoll ist in der [https://datatracker.ietf.org/doc/html/rfc6143 RFC6143] beschrieben. Die Komplexität würde ich als mittelschwer beschreiben: Also nicht ganz so einfach wie ein HTTP-Request, aber auch super komplex. Ich habe erfolgreich einen VNC Server auf TCP-Basis programmiert, mit dem der Inhalt eines kleinen Displays übertragen und manipulitert werden kann.<br />
<br />
Während in der RFC die Details des Protokolls gut beschrieben sind, gibt es einige Dinge, die noch etwas anders beschrieben werden können.<br />
<br />
=== Zwei Haupzustände der VNC Verbindung ===<br />
Eine VNC Verbindung kann im wesentlichen in zwei Hauptzustände unterteilt werden:<br />
<br />
# Verbindungsaufbau<br />
# Fernsteuerung<br />
<br />
=== Verbindungsaufbau ===<br />
Während des Verbindungsaufbaus funktioniert das Prokoll im strengen Halbduplex (Handshake): Es folgt einer strikten Struktur und es gibt immer genau eine Anfrage und genau eine Antwort darauf. Die Nachrichten sind hier genau vorgegeben und haben daher typischerweise kein separates Header-Byte, was die Art der Nachricht vorgibt.<br />
<br />
Für eine Verbindung ohne Passwort-Authentifikation sieht das wie folgt aus und kann recht simpel "hart" kodiert werden:<br />
# Client baut TCP Verbindung zum Server aus, Server nimmt diese an.<br />
# Server sendet "RFB 003.008\n" - das ist die derzeit typische Protokollversion.<br />
# Client antwortet ebenfalls mit "RFB 003.008\n" - und bestätigt damit, das er diese Protkollversion akzeptiert.<br />
# Server sendet 0x01 0x01 - Er sagt damit, dass er nur den Security Handshake "None" unterstützt, also gar keine Authentifikation. Natürlich könnte man hier auch komplexere Handshakes erlauben, der Einfachheit halber soll das aber hier genügen.<br />
# Client antwortet mit 0x01 - Er sagt damit, dass er den Security Handshake "None" akzeptiert. <br />
# Server sendet 0x00 0x00 0x00 0x00 - Er sagt damit, dass der Security Handshake erfolgreich war und er die Verbindung akzeptiert.<br />
# Client sendet nun genau ein Byte, entweder 0x00 oder 0x01. Bei einer 0x00 wünscht er eine exlusive Verbindung zum Server - der Server sollte also bestehende Verbindungen trennen. Bei einer 0x01 braucht es nicht exlusiv zu sein. Ob 0x00 oder 0x01 ist für einfache Anwendungen unwichtig, ggf lässt der Simple-Server ja eh nur eine Verbindung zu.<br />
# Server sendet nun die sog. ServerInit Message: Diese enthält die Auflösung und das Farbformat des Framebuffers sowie den Namen der Verbindung. Dieses PIXEL_FORMAT ist allerdings nur eine Art maximale Empfehlung für den Client, denn dieser kann das PIXEL_FORMAT jederzeit ändern, was zumindest bei RealVNC auch häufig passiert. Statt das z.B. die Farbpixel mit 24Bit übertragen werden (typischerweise dann als 32 Bit Werte), kann der Client z.B. ein 8 Bit Farbformat anfragen, um schneller ein erstes Bild zu erhalten. Wichtig ist hier daher, dass auch bei einfachsten Implementierungen des Servers trotzdem verschiedene PIXEL_FORMAT Nachrichten richtig ausgewertet werden müssen. <br />
# Übergang in den Fernsteuerungsmodus: siehe nächstes Kapitel. Typischerweise kommen hier gleich mehrere Pakete hintereinander vom Client, ohne dass der Server irgendwas sendet. Bei RealVNC wurden die folgenden 3 Pakete beobachtet:<br />
## SetEncodings<br />
## SetPixelFormat<br />
## FramebufferUpdateRequest<br />
<br />
=== Fernsteuerung ===<br />
<br />
Am Ende davon geht das Protokoll in den Fernsteuerungsmodus über - hier ist die Situation anders: Es gibt nun kein festes Handshake mehr, stattdessen werden verschiedene Nachrichtentypen unabhängig voneinander übertragen. So kann z.B. der Client in freier Folge Nachrichten senden, wenn er Bildschirmupdates haben möchte oder wenn er Tastatur- oder Mausereignisse hat. Der Server sendet im wesentlichen Nachrichten vom Typ FramebufferUpdate und updatet damit die Bildschirmdarstellung auf dem Client.<br />
<br />
Im Fernsteuerungsmodus sind die Nachrichten über das erste Byte, das Type-Byte kodiert. Es gibt allerdings keine direkte Info, wie lang ein Paket ist. Damit der Server die Nachrichten auseinander nehmen kann, muss er auch für die einfachste Implementierung zumindest die folgenden Nachrichtentypen soweit parsen können, dass er die Längen richtig einliest:<br />
<br />
==== Client-Server Nachrichten ====<br />
{| class="wikitable" <br />
|-<br />
! Nummer<br />
! Name<br />
! Länge<br />
|-<br />
| 0<br />
| SetPixelFormat <br />
| 19 Byte<br />
|-<br />
| 2<br />
| SetEncodings <br />
| variable Länge<br />
|-<br />
| 3<br />
| FramebufferUpdateRequest <br />
| 10 Byte<br />
|-<br />
| 4<br />
| KeyEvent <br />
| 8 Byte<br />
|-<br />
| 5<br />
| PointerEvent<br />
| 6 Byte<br />
|-<br />
| 6<br />
| ClientCutEvent <br />
| variable Länge<br />
|}<br />
<br />
==== Server-Client Nachrichten ====<br />
Für den Server ist die Sache einfacher, es gibt zwar 4 verschiedene Nachrichten (FramebufferUpdate, SetColorMapEntries (nur bei Paletten Farbformat), Bell und ServerCutText), aber eigentlich macht '''FramebufferUpdate''' die ganze Arbeit.<br />
<br />
Die FramebufferUpdate-Nachricht kann verschiedene rechteckige Bereiche mit neuen Bilddaten auffrischen und dazu verschiene Codierungen nutzen. Die Kodierungen werden über SetEncodings abgeglichen, aber für die Einfachstimplementierung geht immer die RAW-Kodierung, die einfach die Rohdaten ohne Kompression allerdings im jeweils aktuellen PIXEL_FORMAT überträgt.<br />
<br />
=== PIXEL_FORMAT ===<br />
Wie schon oben erwähnt kann der Client jederzeit über eine SetPixelFormat-Nachricht das aktuelle PIXEL_FORMAT verändern - und zumindest RealVNC macht davon auch Gebrauch. Daher muss auch eine Einfachimplementation hier adequat reagieren. <br />
<br />
==== Bits-per-Pixel ====<br />
Die Zahl in diesem Byte bestimmt, wie viele Bytes pro Pixel übertragen werden. Lauf RFC sind hier genau die folgenden drei Werte erlaubt:<br />
# 8 (true-color-flag beachten)<br />
# 16 (big-endian-flag beachten)<br />
# 32 (big-endian-flag beachten)<br />
<br />
Obwohl eine Farbtiefe von 24 Bit nicht unüblich ist, werden hierzu immer 32 Bit (= 4 Byte) übertragen. Eine 3 Byte Übertragung ist nicht vorgesehen.<br />
<br />
==== Depth ====<br />
In diesem Byte wird die echte Farbtiefe übertragen. Allerdings scheint das den Client nicht soviel zu interessieren...<br />
<br />
==== Big-Endian-Flag ====<br />
Ist Bits-per-Pixel größer als 8 bestimmt das Flag die Reihenfolge mit der die Bytes übertragen werden. Da der Client hier freie Wahl hat, muss auch der Einfach-Server hier beide Varianten unterstützen.<br />
<br />
==== True-Color-Flag ====<br />
Wenn dieses Flag gesetzt ist, wird nicht mit Farbpaletten gearbeitet sondern mit MAX und SHIFT-Werten für die Farben. Ich habe zumindest nicht beobachet, dass der Client dieses Bit anders setzt als bei der initialen Aushandlung vom Server vorgegeben. Für die einfache Implementation setze ich daher dieses Bit in der Server-Nachricht und benötige dann keine Farbpaletten-Nachrichten mehr.<br />
<br />
==== Max und Shift Werte ====<br />
Im True-Color-Modus werden diese Werte vom Client für alle drei Farbkomponenten übergeben und bestimmen, wie die Farbe übertragen wird. Für 24 Bit Farbtiefe werden je 8 Bits pro Farbe genommen. In der Einstellung "LOW" bei RealVNC wurde die Farbtiefe auf 2 Bit pro Farbe vom Client reduziert. Die PIXEL_FORMAT Nachricht wurde in diesen Fällen wie folgt bestückt:<br />
{| class="wikitable" <br />
|-<br />
! Type<br />
! Description<br />
! Je 8 Bit pro Farbe<br />
! Je 2 Bit pro Farbe<br />
|-<br />
| U8<br />
| bits-per-pixel <br />
| 32<br />
| 8<br />
|-<br />
| U8<br />
| depth<br />
| 24 <br />
| 6<br />
|-<br />
| U8<br />
| big-endian-flag <br />
| 0<br />
| 0<br />
|-<br />
| U8<br />
| true-color-flag<br />
| 1 <br />
| 1<br />
|-<br />
| U16<br />
| red-max<br />
| 255<br />
| 3<br />
|-<br />
| U16<br />
| green-max<br />
| 255<br />
| 3<br />
|-<br />
| U16<br />
| blue-max<br />
| 255<br />
| 3<br />
|-<br />
| U8<br />
| red-shift<br />
| 16<br />
| 4<br />
|-<br />
| U8<br />
| green-shift<br />
| 8<br />
| 2<br />
|-<br />
| U8<br />
| blue-shift<br />
| 0<br />
| 0<br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=VNC_Server_Protokoll_verstehen&diff=11524
VNC Server Protokoll verstehen
2023-11-19T18:58:39Z
<p>Tut: </p>
<hr />
<div>== Hintergrund ==<br />
Das VNC Protokoll eignet sich gut, um es auch bei Microcontrollern mit Netzwerkzugang wie z.B. den ESP32 / ESP8266 zu nutzen. Damit lassen sich Bildschirminhalte von Displays in Echtzeit übertragen, was bei der Entwicklung von Nutzen sein kann. Sogar "Headless" Anwendungen sind denkbar, also grafische Anwendungen auf dem ESP laufen lassen, der selbst kein Display hat, wo die Steuerung dann ausschließlich über VNC erfolgt.<br />
<br />
== Protokoll ==<br />
Das Protokoll ist in der [https://datatracker.ietf.org/doc/html/rfc6143 RFC6143] beschrieben. Die Komplexität würde ich als mittelschwer beschreiben: Also nicht ganz so einfach wie ein HTTP-Request, aber auch super komplex. Ich habe erfolgreich einen VNC Server auf TCP-Basis programmiert, mit dem der Inhalt eines kleinen Displays übertragen und manipulitert werden kann.<br />
<br />
Während in der RFC die Details des Protokolls gut beschrieben sind, gibt es einige Dinge, die noch etwas anders beschrieben werden können.<br />
<br />
=== Zwei Haupzustände der VNC Verbindung ===<br />
Eine VNC Verbindung kann im wesentlichen in zwei Hauptzustände unterteilt werden:<br />
<br />
# Verbindungsaufbau<br />
# Fernsteuerung<br />
<br />
=== Verbindungsaufbau ===<br />
Während des Verbindungsaufbaus funktioniert das Prokoll im strengen Halbduplex (Handshake): Es folgt einer strikten Struktur und es gibt immer genau eine Anfrage und genau eine Antwort darauf. Die Nachrichten sind hier genau vorgegeben und haben daher typischerweise kein separates Header-Byte, was die Art der Nachricht vorgibt.<br />
<br />
Für eine Verbindung ohne Passwort-Authentifikation sieht das wie folgt aus und kann recht simpel "hart" kodiert werden:<br />
# Client baut TCP Verbindung zum Server aus, Server nimmt diese an.<br />
# Server sendet "RFB 003.008\n" - das ist die derzeit typische Protokollversion.<br />
# Client antwortet ebenfalls mit "RFB 003.008\n" - und bestätigt damit, das er diese Protkollversion akzeptiert.<br />
# Server sendet 0x01 0x01 - Er sagt damit, dass er nur den Security Handshake "None" unterstützt, also gar keine Authentifikation. Natürlich könnte man hier auch komplexere Handshakes erlauben, der Einfachheit halber soll das aber hier genügen.<br />
# Client antwortet mit 0x01 - Er sagt damit, dass er den Security Handshake "None" akzeptiert. <br />
# Server sendet 0x00 0x00 0x00 0x00 - Er sagt damit, dass der Security Handshake erfolgreich war und er die Verbindung akzeptiert.<br />
# Client sendet nun genau ein Byte, entweder 0x00 oder 0x01. Bei einer 0x00 wünscht er eine exlusive Verbindung zum Server - der Server sollte also bestehende Verbindungen trennen. Bei einer 0x01 braucht es nicht exlusiv zu sein. Ob 0x00 oder 0x01 ist für einfache Anwendungen unwichtig, ggf lässt der Simple-Server ja eh nur eine Verbindung zu.<br />
# Server sendet nun die sog. ServerInit Message: Diese enthält die Auflösung und das Farbformat des Framebuffers sowie den Namen der Verbindung. Dieses PIXEL_FORMAT ist allerdings nur eine Art maximale Empfehlung für den Client, denn dieser kann das PIXEL_FORMAT jederzeit ändern, was zumindest bei RealVNC auch häufig passiert. Statt das z.B. die Farbpixel mit 24Bit übertragen werden (typischerweise dann als 32 Bit Werte), kann der Client z.B. ein 8 Bit Farbformat anfragen, um schneller ein erstes Bild zu erhalten. Wichtig ist hier daher, dass auch bei einfachsten Implementierungen des Servers trotzdem verschiedene PIXEL_FORMAT Nachrichten richtig ausgewertet werden müssen. <br />
# Übergang in den Fernsteuerungsmodus: siehe nächstes Kapitel. Typischerweise kommen hier gleich mehrere Pakete hintereinander vom Client, ohne dass der Server irgendwas sendet. Bei RealVNC wurden die folgenden 3 Pakete beobachtet:<br />
## SetEncodings<br />
## SetPixelFormat<br />
## FramebufferUpdateRequest<br />
<br />
=== Fernsteuerung ===<br />
<br />
Am Ende davon geht das Protokoll in den Fernsteuerungsmodus über - hier ist die Situation anders: Es gibt nun kein festes Handshake mehr, stattdessen werden verschiedene Nachrichtentypen unabhängig voneinander übertragen. So kann z.B. der Client in freier Folge Nachrichten senden, wenn er Bildschirmupdates haben möchte oder wenn er Tastatur- oder Mausereignisse hat. Der Server sendet im wesentlichen Nachrichten vom Typ FramebufferUpdate und updatet damit die Bildschirmdarstellung auf dem Client.<br />
<br />
Im Fernsteuerungsmodus sind die Nachrichten über das erste Byte, das Type-Byte kodiert. Es gibt allerdings keine direkte Info, wie lang ein Paket ist. Damit der Server die Nachrichten auseinander nehmen kann, muss er auch für die einfachste Implementierung zumindest die folgenden Nachrichtentypen soweit parsen können, dass er die Längen richtig einliest:<br />
<br />
==== Client-Server Nachrichten ====<br />
{| class="wikitable" <br />
|-<br />
! Nummer<br />
! Name<br />
! Länge<br />
|-<br />
| 0<br />
| SetPixelFormat <br />
| 19 Byte<br />
|-<br />
| 2<br />
| SetEncodings <br />
| variable Länge<br />
|-<br />
| 3<br />
| FramebufferUpdateRequest <br />
| 10 Byte<br />
|-<br />
| 4<br />
| KeyEvent <br />
| 8 Byte<br />
|-<br />
| 5<br />
| PointerEvent<br />
| 6 Byte<br />
|-<br />
| 6<br />
| ClientCutEvent <br />
| variable Länge<br />
|}<br />
<br />
==== Server-Client Nachrichten ====<br />
Für den Server ist die Sache einfacher, es gibt zwar 4 verschiedene Nachrichten (FramebufferUpdate, SetColorMapEntries (nur bei Paletten Farbformat), Bell und ServerCutText), aber eigentlich macht '''FramebufferUpdate''' die ganze Arbeit.<br />
<br />
Die FramebufferUpdate-Nachricht kann verschiedene rechteckige Bereiche mit neuen Bilddaten auffrischen und dazu verschiene Codierungen nutzen. Die Kodierungen werden über SetEncodings abgeglichen, aber für die Einfachstimplementierung geht immer die RAW-Kodierung, die einfach die Rohdaten ohne Kompression allerdings im jeweils aktuellen PIXEL_FORMAT überträgt.<br />
<br />
=== PIXEL_FORMAT ===<br />
Wie schon oben erwähnt kann der Client jederzeit über eine SetPixelFormat-Nachricht das aktuelle PIXEL_FORMAT verändern - und zumindest RealVNC macht davon auch Gebrauch. Daher muss auch eine Einfachimplementation hier adequat reagieren. <br />
<br />
==== Bits-per-Pixel ====<br />
Die Zahl in diesem Byte bestimmt, wie viele Bytes pro Pixel übertragen werden. Lauf RFC sind hier genau die folgenden drei Werte erlaubt:<br />
# 8 (true-color-flag beachten)<br />
# 16 (big-endian-flag beachten)<br />
# 32 (big-endian-flag beachten)<br />
<br />
Obwohl eine Farbtiefe von 24 Bit nicht unüblich ist, werden hierzu immer 32 Bit (= 4 Byte) übertragen. Eine 3 Byte Übertragung ist nicht vorgesehen.<br />
<br />
==== Depth ====<br />
In diesem Byte wird die echte Farbtiefe übertragen. Allerdings scheint das den Client nicht soviel zu interessieren...<br />
<br />
==== Big-Endian-Flag ====<br />
Ist Bits-per-Pixel größer als 8 bestimmt das Flag die Reihenfolge mit der die Bytes übertragen werden. Da der Client hier freie Wahl hat, muss auch der Einfach-Server hier beide Varianten unterstützen.<br />
<br />
==== True-Color-Flag ====<br />
Wenn dieses Flag gesetzt ist, wird nicht mit Farbpaletten gearbeitet sondern mit MAX und SHIFT-Werten für die Farben. Ich habe zumindest nicht beobachet, dass der Client dieses Bit anders setzt als bei der initialen Aushandlung vom Server vorgegeben. Für die einfache Implementation setze ich daher dieses Bit in der Server-Nachricht und benötige dann keine Farbpaletten-Nachrichten mehr.<br />
<br />
==== Max und Shift Werte ====<br />
Im True-Color-Modus werden diese Werte vom Client für alle drei Farbkomponenten übergeben und bestimmen, wie die Farbe übertragen wird. Für 24 Bit Farbtiefe werden je 8 Bits pro Farbe genommen. In der Einstellung "LOW" bei RealVNC wurde die Farbtiefe auf 2 Bit pro Farbe vom Client reduziert. Die PIXEL_FORMAT Nachricht wurde in diesen Fällen wie folgt bestückt:<br />
{| class="wikitable" <br />
|-<br />
! Type<br />
! Description<br />
! Je 8 Bit pro Farbe<br />
! Je 2 Bit pro Farbe<br />
|-<br />
| U8<br />
| bits-per-pixel <br />
| 32<br />
| 8<br />
|-<br />
| U8<br />
| depth<br />
| 24 <br />
| 6<br />
|-<br />
| U8<br />
| big-endian-flag <br />
| 0<br />
| 0<br />
|-<br />
| U8<br />
| true-color-flag<br />
| 1 <br />
| 1<br />
|-<br />
| U16<br />
| red-max<br />
| 255<br />
| 3<br />
|-<br />
| U16<br />
| green-max<br />
| 255<br />
| 3<br />
|-<br />
| U16<br />
| blue-max<br />
| 255<br />
| 3<br />
|-<br />
| U8<br />
| red-shift<br />
| 16<br />
| 4<br />
|-<br />
| U8<br />
| green-shift<br />
| 8<br />
| 2<br />
|-<br />
| U8<br />
| blue-shift<br />
| 0<br />
| 0<br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=VNC_Server_Protokoll_verstehen&diff=11523
VNC Server Protokoll verstehen
2023-11-19T18:19:59Z
<p>Tut: </p>
<hr />
<div>== Hintergrund ==<br />
Das VNC Protokoll eignet sich gut, um es auch bei Microcontrollern mit Netzwerkzugang wie z.B. den ESP32 / ESP8266 zu nutzen. Damit lassen sich Bildschirminhalte von Displays in Echtzeit übertragen, was bei der Entwicklung von Nutzen sein kann. Sogar "Headless" Anwendungen sind denkbar, also grafische Anwendungen auf dem ESP laufen lassen, der selbst kein Display hat, wo die Steuerung dann ausschließlich über VNC erfolgt.<br />
<br />
== Protokoll ==<br />
Das Protokoll ist in der [https://datatracker.ietf.org/doc/html/rfc6143 RFC6143] beschrieben. Die Komplexität würde ich als mittelschwer beschreiben: Also nicht ganz so einfach wie ein HTTP-Request, aber auch super komplex. Ich habe erfolgreich einen VNC Server auf TCP-Basis programmiert, mit dem der Inhalt eines kleinen Displays übertragen und manipulitert werden kann.<br />
<br />
Während in der RFC die Details des Protokolls gut beschrieben sind, gibt es einige Dinge, die noch etwas anders beschrieben werden können.<br />
<br />
=== Zwei Haupzustände der VNC Verbindung ===<br />
Eine VNC Verbindung kann im wesentlichen in zwei Hauptzustände unterteilt werden:<br />
<br />
# Verbindungsaufbau<br />
# Fernsteuerung<br />
<br />
=== Verbindungsaufbau ===<br />
Während des Verbindungsaufbaus funktioniert das Prokoll im strengen Halbduplex (Handshake): Es folgt einer strikten Struktur und es gibt immer genau eine Anfrage und genau eine Antwort darauf. Die Nachrichten sind hier genau vorgegeben und haben daher typischerweise kein separates Header-Byte, was die Art der Nachricht vorgibt.<br />
<br />
Für eine Verbindung ohne Passwort-Authentifikation sieht das wie folgt aus und kann recht simpel "hart" kodiert werden:<br />
# Client baut TCP Verbindung zum Server aus, Server nimmt diese an.<br />
# Server sendet "RFB 003.008\n" - das ist die derzeit typische Protokollversion.<br />
# Client antwortet ebenfalls mit "RFB 003.008\n" - und bestätigt damit, das er diese Protkollversion akzeptiert.<br />
# Server sendet 0x01 0x01 - Er sagt damit, dass er nur den Security Handshake "None" unterstützt, also gar keine Authentifikation. Natürlich könnte man hier auch komplexere Handshakes erlauben, der Einfachheit halber soll das aber hier genügen.<br />
# Client antwortet mit 0x01 - Er sagt damit, dass er den Security Handshake "None" akzeptiert. <br />
# Server sendet 0x00 0x00 0x00 0x00 - Er sagt damit, dass der Security Handshake erfolgreich war und er die Verbindung akzeptiert.<br />
# Client sendet nun genau ein Byte, entweder 0x00 oder 0x01. Bei einer 0x00 wünscht er eine exlusive Verbindung zum Server - der Server sollte also bestehende Verbindungen trennen. Bei einer 0x01 braucht es nicht exlusiv zu sein. Ob 0x00 oder 0x01 ist für einfache Anwendungen unwichtig, ggf lässt der Simple-Server ja eh nur eine Verbindung zu.<br />
# Server sendet nun die sog. ServerInit Message: Diese enthält die Auflösung und das Farbformat des Framebuffers sowie den Namen der Verbindung. Dieses PIXEL_FORMAT ist allerdings nur eine Art maximale Empfehlung für den Client, denn dieser kann das PIXEL_FORMAT jederzeit ändern, was zumindest bei RealVNC auch häufig passiert. Statt das z.B. die Farbpixel mit 24Bit übertragen werden (typischerweise dann als 32 Bit Werte), kann der Client z.B. ein 8 Bit Farbformat anfragen, um schneller ein erstes Bild zu erhalten. Wichtig ist hier daher, dass auch bei einfachsten Implementierungen des Servers trotzdem verschiedene PIXEL_FORMAT Nachrichten richtig ausgewertet werden müssen. <br />
# Übergang in den Fernsteuerungsmodus: siehe nächstes Kapitel. Typischerweise kommen hier gleich mehrere Pakete hintereinander vom Client, ohne dass der Server irgendwas sendet. Bei RealVNC wurden die folgenden 3 Pakete beobachtet:<br />
## SetEncodings<br />
## SetPixelFormat<br />
## FramebufferUpdateRequest<br />
<br />
=== Fernsteuerung ===<br />
<br />
Am Ende davon geht das Protokoll in den Fernsteuerungsmodus über - hier ist die Situation anders: Es gibt nun kein festes Handshake mehr, stattdessen werden verschiedene Nachrichtentypen unabhängig voneinander übertragen. So kann z.B. der Client in freier Folge Nachrichten senden, wenn er Bildschirmupdates haben möchte oder wenn er Tastatur- oder Mausereignisse hat. Der Server sendet im wesentlichen Nachrichten vom Typ FramebufferUpdate und updatet damit die Bildschirmdarstellung auf dem Client.<br />
<br />
Im Fernsteuerungsmodus sind die Nachrichten über das erste Byte, das Type-Byte kodiert. Es gibt allerdings keine direkte Info, wie lang ein Paket ist. Damit der Server die Nachrichten auseinander nehmen kann, muss er auch für die einfachste Implementierung zumindest die folgenden Nachrichtentypen soweit parsen können, dass er die Längen richtig einliest:<br />
<br />
==== Client-Server Nachrichten ====<br />
{| class="wikitable" <br />
|-<br />
! Nummer<br />
! Name<br />
! Länge<br />
|-<br />
| 0<br />
| SetPixelFormat <br />
| 19 Byte<br />
|-<br />
| 2<br />
| SetEncodings <br />
| variable Länge<br />
|-<br />
| 3<br />
| FramebufferUpdateRequest <br />
| 10 Byte<br />
|-<br />
| 4<br />
| KeyEvent <br />
| 8 Byte<br />
|-<br />
| 5<br />
| PointerEvent<br />
| 6 Byte<br />
|-<br />
| 6<br />
| ClientCutEvent <br />
| variable Länge<br />
|}<br />
<br />
==== Server-Client Nachrichten ====<br />
Für den Server ist die Sache einfacher, es gibt zwar 4 verschiedene Nachrichten (FramebufferUpdate, SetColorMapEntries (nur bei Paletten Farbformat), Bell und ServerCutText), aber eigentlich macht '''FramebufferUpdate''' die ganze Arbeit.<br />
<br />
Die FramebufferUpdate-Nachricht kann verschiedene rechteckige Bereiche mit neuen Bilddaten auffrischen und dazu verschiene Codierungen nutzen. Die Kodierungen werden über SetEncodings abgeglichen, aber für die Einfachstimplementierung geht immer die RAW-Kodierung, die einfach die Rohdaten ohne Kompression allerdings im jeweils aktuellen PIXEL_FORMAT überträgt.<br />
<br />
=== PIXEL_FORMAT ===</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=VNC_Server_Protokoll_verstehen&diff=11522
VNC Server Protokoll verstehen
2023-11-19T18:11:25Z
<p>Tut: </p>
<hr />
<div>== Hintergrund ==<br />
Das VNC Protokoll eignet sich gut, um es auch bei Microcontrollern mit Netzwerkzugang wie z.B. den ESP32 / ESP8266 zu nutzen. Damit lassen sich Bildschirminhalte von Displays in Echtzeit übertragen, was bei der Entwicklung von Nutzen sein kann. Sogar "Headless" Anwendungen sind denkbar, also grafische Anwendungen auf dem ESP laufen lassen, der selbst kein Display hat, wo die Steuerung dann ausschließlich über VNC erfolgt.<br />
<br />
== Protokoll ==<br />
Das Protokoll ist in der [https://datatracker.ietf.org/doc/html/rfc6143 RFC6143] beschrieben. Die Komplexität würde ich als mittelschwer beschreiben: Also nicht ganz so einfach wie ein HTTP-Request, aber auch super komplex. Ich habe erfolgreich einen VNC Server auf TCP-Basis programmiert, mit dem der Inhalt eines kleinen Displays übertragen und manipulitert werden kann.<br />
<br />
Während in der RFC die Details des Protokolls gut beschrieben sind, gibt es einige Dinge, die noch etwas anders beschrieben werden können.<br />
<br />
=== Zwei Haupzustände der VNC Verbindung ===<br />
Eine VNC Verbindung kann im wesentlichen in zwei Hauptzustände unterteilt werden:<br />
<br />
# Verbindungsaufbau<br />
# Fernsteuerung<br />
<br />
=== Verbindungsaufbau ===<br />
Während des Verbindungsaufbaus funktioniert das Prokoll im strengen Halbduplex (Handshake): Es folgt einer strikten Struktur und es gibt immer genau eine Anfrage und genau eine Antwort darauf. Die Nachrichten sind hier genau vorgegeben und haben daher typischerweise kein separates Header-Byte, was die Art der Nachricht vorgibt.<br />
<br />
Für eine Verbindung ohne Passwort-Authentifikation sieht das wie folgt aus und kann recht simpel "hart" kodiert werden:<br />
# Client baut TCP Verbindung zum Server aus, Server nimmt diese an.<br />
# Server sendet "RFB 003.008\n" - das ist die derzeit typische Protokollversion.<br />
# Client antwortet ebenfalls mit "RFB 003.008\n" - und bestätigt damit, das er diese Protkollversion akzeptiert.<br />
# Server sendet 0x01 0x01 - Er sagt damit, dass er nur den Security Handshake "None" unterstützt, also gar keine Authentifikation. Natürlich könnte man hier auch komplexere Handshakes erlauben, der Einfachheit halber soll das aber hier genügen.<br />
# Client antwortet mit 0x01 - Er sagt damit, dass er den Security Handshake "None" akzeptiert. <br />
# Server sendet 0x00 0x00 0x00 0x00 - Er sagt damit, dass der Security Handshake erfolgreich war und er die Verbindung akzeptiert.<br />
# Client sendet nun genau ein Byte, entweder 0x00 oder 0x01. Bei einer 0x00 wünscht er eine exlusive Verbindung zum Server - der Server sollte also bestehende Verbindungen trennen. Bei einer 0x01 braucht es nicht exlusiv zu sein. Ob 0x00 oder 0x01 ist für einfache Anwendungen unwichtig, ggf lässt der Simple-Server ja eh nur eine Verbindung zu.<br />
# Server sendet nun die sog. ServerInit Message: Diese enthält die Auflösung und das Farbformat des Framebuffers sowie den Namen der Verbindung. Dieses PIXEL_FORMAT ist allerdings nur eine Art maximale Empfehlung für den Client, denn dieser kann das PIXEL_FORMAT jederzeit ändern, was zumindest bei RealVNC auch häufig passiert. Statt das z.B. die Farbpixel mit 24Bit übertragen werden (typischerweise dann als 32 Bit Werte), kann der Client z.B. ein 8 Bit Farbformat anfragen, um schneller ein erstes Bild zu erhalten. Wichtig ist hier daher, dass auch bei einfachsten Implementierungen des Servers trotzdem verschiedene PIXEL_FORMAT Nachrichten richtig ausgewertet werden müssen. <br />
# Übergang in den Fernsteuerungsmodus: siehe nächstes Kapitel. Typischerweise kommen hier gleich mehrere Pakete hintereinander vom Client, ohne dass der Server irgendwas sendet. Bei RealVNC wurden die folgenden 3 Pakete beobachtet:<br />
## SetEncodings<br />
## SetPixelFormat<br />
## FramebufferUpdateRequest<br />
<br />
=== Fernsteuerung ===<br />
<br />
Am Ende davon geht das Protokoll in den Fernsteuerungsmodus über - hier ist die Situation anders: Es gibt nun kein festes Handshake mehr, stattdessen werden verschiedene Nachrichtentypen unabhängig voneinander übertragen. So kann z.B. der Client in freier Folge Nachrichten senden, wenn er Bildschirmupdates haben möchte oder wenn er Tastatur- oder Mausereignisse hat. Der Server sendet im wesentlichen Nachrichten vom Typ FramebufferUpdate und updatet damit die Bildschirmdarstellung auf dem Client.<br />
<br />
Im Fernsteuerungsmodus sind die Nachrichten über das erste Byte, das Type-Byte kodiert. Es gibt allerdings keine direkte Info, wie lang ein Paket ist. Damit der Server die Nachrichten auseinander nehmen kann, muss er auch für die einfachste Implementierung zumindest die folgenden Nachrichtentypen soweit parsen können, dass er die Längen richtig einliest:<br />
<br />
==== Client-Server Nachrichten ====<br />
{| class="wikitable" <br />
|-<br />
! Nummer<br />
! Name<br />
! Länge<br />
|-<br />
| 0<br />
| SetPixelFormat <br />
| 19 Byte<br />
|-<br />
| 2<br />
| SetEncodings <br />
| variable Länge<br />
|-<br />
| 3<br />
| FramebufferUpdateRequest <br />
| 10 Byte<br />
|-<br />
| 4<br />
| KeyEvent <br />
| 8 Byte<br />
|-<br />
| 5<br />
| PointerEvent<br />
| 6 Byte<br />
|-<br />
| 6<br />
| ClientCutEvent <br />
| variable Länge<br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=VNC_Server_Protokoll_verstehen&diff=11521
VNC Server Protokoll verstehen
2023-11-19T18:10:09Z
<p>Tut: </p>
<hr />
<div>== Hintergrund ==<br />
Das VNC Protokoll eignet sich gut, um es auch bei Microcontrollern mit Netzwerkzugang wie z.B. den ESP32 / ESP8266 zu nutzen. Damit lassen sich Bildschirminhalte von Displays in Echtzeit übertragen, was bei der Entwicklung von Nutzen sein kann. Sogar "Headless" Anwendungen sind denkbar, also grafische Anwendungen auf dem ESP laufen lassen, der selbst kein Display hat, wo die Steuerung dann ausschließlich über VNC erfolgt.<br />
<br />
== Protokoll ==<br />
Das Protokoll ist in der [https://datatracker.ietf.org/doc/html/rfc6143 RFC6143] beschrieben. Die Komplexität würde ich als mittelschwer beschreiben: Also nicht ganz so einfach wie ein HTTP-Request, aber auch super komplex. Ich habe erfolgreich einen VNC Server auf TCP-Basis programmiert, mit dem der Inhalt eines kleinen Displays übertragen und manipulitert werden kann.<br />
<br />
Während in der RFC die Details des Protokolls gut beschrieben sind, gibt es einige Dinge, die noch etwas anders beschrieben werden können.<br />
<br />
=== Zwei Haupzustände der VNC Verbindung ===<br />
Eine VNC Verbindung kann im wesentlichen in zwei Hauptzustände unterteilt werden:<br />
<br />
# Verbindungsaufbau<br />
# Fernsteuerung<br />
<br />
=== Verbindungsaufbau ===<br />
Während des Verbindungsaufbaus funktioniert das Prokoll im strengen Halbduplex (Handshake): Es folgt einer strikten Struktur und es gibt immer genau eine Anfrage und genau eine Antwort darauf. Die Nachrichten sind hier genau vorgegeben und haben daher typischerweise kein separates Header-Byte, was die Art der Nachricht vorgibt.<br />
<br />
Für eine Verbindung ohne Passwort-Authentifikation sieht das wie folgt aus und kann recht simpel "hart" kodiert werden:<br />
# Client baut TCP Verbindung zum Server aus, Server nimmt diese an.<br />
# Server sendet "RFB 003.008\n" - das ist die derzeit typische Protokollversion.<br />
# Client antwortet ebenfalls mit "RFB 003.008\n" - und bestätigt damit, das er diese Protkollversion akzeptiert.<br />
# Server sendet 0x01 0x01 - Er sagt damit, dass er nur den Security Handshake "None" unterstützt, also gar keine Authentifikation. Natürlich könnte man hier auch komplexere Handshakes erlauben, der Einfachheit halber soll das aber hier genügen.<br />
# Client antwortet mit 0x01 - Er sagt damit, dass er den Security Handshake "None" akzeptiert. <br />
# Server sendet 0x00 0x00 0x00 0x00 - Er sagt damit, dass der Security Handshake erfolgreich war und er die Verbindung akzeptiert.<br />
# Client sendet nun genau ein Byte, entweder 0x00 oder 0x01. Bei einer 0x00 wünscht er eine exlusive Verbindung zum Server - der Server sollte also bestehende Verbindungen trennen. Bei einer 0x01 braucht es nicht exlusiv zu sein. Ob 0x00 oder 0x01 ist für einfache Anwendungen unwichtig, ggf lässt der Simple-Server ja eh nur eine Verbindung zu.<br />
# Server sendet nun die sog. ServerInit Message: Diese enthält die Auflösung und das Farbformat des Framebuffers sowie den Namen der Verbindung. Dieses PIXEL_FORMAT ist allerdings nur eine Art maximale Empfehlung für den Client, denn dieser kann das PIXEL_FORMAT jederzeit ändern, was zumindest bei RealVNC auch häufig passiert. Statt das z.B. die Farbpixel mit 24Bit übertragen werden (typischerweise dann als 32 Bit Werte), kann der Client z.B. ein 8 Bit Farbformat anfragen, um schneller ein erstes Bild zu erhalten. Wichtig ist hier daher, dass auch bei einfachsten Implementierungen des Servers trotzdem verschiedene PIXEL_FORMAT Nachrichten richtig ausgewertet werden müssen. <br />
# Übergang in den Fernsteuerungsmodus: siehe nächstes Kapitel. Typischerweise kommen hier gleich mehrere Pakete hintereinander vom Client, ohne dass der Server irgendwas sendet. Bei RealVNC wurden die folgenden 3 Pakete beobachtet:<br />
## SetEncodings<br />
## SetPixelFormat<br />
## FramebufferUpdateRequest<br />
<br />
=== Fernsteuerung ===<br />
<br />
Am Ende davon geht das Protokoll in den Fernsteuerungsmodus über - hier ist die Situation anders: Es gibt nun kein festes Handshake mehr, stattdessen werden verschiedene Nachrichtentypen unabhängig voneinander übertragen. So kann z.B. der Client in freier Folge Nachrichten senden, wenn er Bildschirmupdates haben möchte oder wenn er Tastatur- oder Mausereignisse hat. Der Server sendet im wesentlichen Nachrichten vom Typ FramebufferUpdate und updatet damit die Bildschirmdarstellung auf dem Client.<br />
<br />
Im Fernsteuerungsmodus sind die Nachrichten über das erste Byte, das Type-Byte kodiert. Es gibt allerdings keine direkte Info, wie lang ein Paket ist. Damit der Server die Nachrichten auseinander nehmen kann, muss er auch für die einfachste Implementierung zumindest die folgenden Nachrichtentypen soweit parsen können, dass er die Längen richtig einliest:<br />
<br />
{| class="wikitable" <br />
|-<br />
! Nummer<br />
! Name<br />
! Länge<br />
|-<br />
| 0<br />
| SetPixelFormat <br />
| 19 Byte<br />
|-<br />
| 2<br />
| SetEncodings <br />
| variable Länge<br />
|-<br />
| 3<br />
| FramebufferUpdateRequest <br />
| 10 Byte<br />
|-<br />
| 4<br />
| KeyEvent <br />
| 8 Byte<br />
|-<br />
| 5<br />
| PointerEvent<br />
| 6 Byte<br />
|-<br />
| 6<br />
| ClientCutEvent <br />
| variable Länge<br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=VNC_Server_Protokoll_verstehen&diff=11520
VNC Server Protokoll verstehen
2023-11-19T18:08:36Z
<p>Tut: </p>
<hr />
<div>== Hintergrund ==<br />
Das VNC Protokoll eignet sich gut, um es auch bei Microcontrollern mit Netzwerkzugang wie z.B. den ESP32 / ESP8266 zu nutzen. Damit lassen sich Bildschirminhalte von Displays in Echtzeit übertragen, was bei der Entwicklung von Nutzen sein kann. Sogar "Headless" Anwendungen sind denkbar, also grafische Anwendungen auf dem ESP laufen lassen, der selbst kein Display hat, wo die Steuerung dann ausschließlich über VNC erfolgt.<br />
<br />
== Protokoll ==<br />
Das Protokoll ist in der [https://datatracker.ietf.org/doc/html/rfc6143 RFC6143] beschrieben. Die Komplexität würde ich als mittelschwer beschreiben: Also nicht ganz so einfach wie ein HTTP-Request, aber auch super komplex. Ich habe erfolgreich einen VNC Server auf TCP-Basis programmiert, mit dem der Inhalt eines kleinen Displays übertragen und manipulitert werden kann.<br />
<br />
Während in der RFC die Details des Protokolls gut beschrieben sind, gibt es einige Dinge, die noch etwas anders beschrieben werden können.<br />
<br />
=== Zwei Haupzustände der VNC Verbindung ===<br />
Eine VNC Verbindung kann im wesentlichen in zwei Hauptzustände unterteilt werden:<br />
<br />
# Verbindungsaufbau<br />
# Fernsteuerung<br />
<br />
=== Verbindungsaufbau ===<br />
Während des Verbindungsaufbaus funktioniert das Prokoll im strengen Halbduplex (Handshake): Es folgt einer strikten Struktur und es gibt immer genau eine Anfrage und genau eine Antwort darauf. Die Nachrichten sind hier genau vorgegeben und haben daher typischerweise kein separates Header-Byte, was die Art der Nachricht vorgibt.<br />
<br />
Für eine Verbindung ohne Passwort-Authentifikation sieht das wie folgt aus und kann recht simpel "hart" kodiert werden:<br />
# Client baut TCP Verbindung zum Server aus, Server nimmt diese an.<br />
# Server sendet "RFB 003.008\n" - das ist die derzeit typische Protokollversion.<br />
# Client antwortet ebenfalls mit "RFB 003.008\n" - und bestätigt damit, das er diese Protkollversion akzeptiert.<br />
# Server sendet 0x01 0x01 - Er sagt damit, dass er nur den Security Handshake "None" unterstützt, also gar keine Authentifikation. Natürlich könnte man hier auch komplexere Handshakes erlauben, der Einfachheit halber soll das aber hier genügen.<br />
# Client antwortet mit 0x01 - Er sagt damit, dass er den Security Handshake "None" akzeptiert. <br />
# Server sendet 0x00 0x00 0x00 0x00 - Er sagt damit, dass der Security Handshake erfolgreich war und er die Verbindung akzeptiert.<br />
# Client sendet nun genau ein Byte, entweder 0x00 oder 0x01. Bei einer 0x00 wünscht er eine exlusive Verbindung zum Server - der Server sollte also bestehende Verbindungen trennen. Bei einer 0x01 braucht es nicht exlusiv zu sein. Ob 0x00 oder 0x01 ist für einfache Anwendungen unwichtig, ggf lässt der Simple-Server ja eh nur eine Verbindung zu.<br />
# Server sendet nun die sog. ServerInit Message: Diese enthält die Auflösung und das Farbformat des Framebuffers sowie den Namen der Verbindung. Dieses PIXEL_FORMAT ist allerdings nur eine Art maximale Empfehlung für den Client, denn dieser kann das PIXEL_FORMAT jederzeit ändern, was zumindest bei RealVNC auch häufig passiert. Statt das z.B. die Farbpixel mit 24Bit übertragen werden (typischerweise dann als 32 Bit Werte), kann der Client z.B. ein 8 Bit Farbformat anfragen, um schneller ein erstes Bild zu erhalten. Wichtig ist hier daher, dass auch bei einfachsten Implementierungen des Servers trotzdem verschiedene PIXEL_FORMAT Nachrichten richtig ausgewertet werden müssen. <br />
# Übergang in den Fernsteuerungsmodus: siehe nächstes Kapitel. Typischerweise kommen hier gleich mehrere Pakete hintereinander vom Client, ohne dass der Server irgendwas sendet. Bei RealVNC wurden die folgenden 3 Pakete beobachtet:<br />
## SetEncodings<br />
## SetPixelFormat<br />
## FramebufferUpdateRequest<br />
<br />
=== Fernsteuerung ===<br />
<br />
Am Ende davon geht das Protokoll in den Fernsteuerungsmodus über - hier ist die Situation anders: Es gibt nun kein festes Handshake mehr, stattdessen werden verschiedene Nachrichtentypen unabhängig voneinander übertragen. So kann z.B. der Client in freier Folge Nachrichten senden, wenn er Bildschirmupdates haben möchte oder wenn er Tastatur- oder Mausereignisse hat. Der Server sendet im wesentlichen Nachrichten vom Typ FramebufferUpdate und updatet damit die Bildschirmdarstellung auf dem Client.<br />
<br />
Im Fernsteuerungsmodus sind die Nachrichten über das erste Byte, das Type-Byte kodiert. Es gibt allerdings keine direkte Info, wie lang ein Paket ist. Damit der Server die Nachrichten auseinander nehmen kann, muss er auch für die einfachste Implementierung zumindest die folgenden Nachrichtentypen soweit parsen können, dass er die Längen richtig einliest:<br />
<br />
{| class="wikitable" <br />
|-<br />
! Nummer<br />
! Name<br />
|-<br />
| 0<br />
| SetPixelFormat (19 Byte Länge)<br />
|-<br />
| 2<br />
| SetEncodings (variable Länge)<br />
|-<br />
| 3<br />
| FramebufferUpdateRequest (10 Byte Länge)<br />
|-<br />
| 4<br />
| KeyEvent (8 Byte Länge)<br />
|-<br />
| 5<br />
| PointerEvent (6 Byte Länge)<br />
|-<br />
| 6<br />
| ClientCutEvent (variable Länge)<br />
|}</div>
Tut
https://www.hackerspace-ffm.de/wiki/index.php?title=VNC_Server_Protokoll_verstehen&diff=11519
VNC Server Protokoll verstehen
2023-11-19T17:46:27Z
<p>Tut: </p>
<hr />
<div>== Hintergrund ==<br />
Das VNC Protokoll eignet sich gut, um es auch bei Microcontrollern mit Netzwerkzugang wie z.B. den ESP32 / ESP8266 zu nutzen. Damit lassen sich Bildschirminhalte von Displays in Echtzeit übertragen, was bei der Entwicklung von Nutzen sein kann. Sogar "Headless" Anwendungen sind denkbar, also grafische Anwendungen auf dem ESP laufen lassen, der selbst kein Display hat, wo die Steuerung dann ausschließlich über VNC erfolgt.<br />
<br />
== Protokoll ==<br />
Das Protokoll ist in der [https://datatracker.ietf.org/doc/html/rfc6143 RFC6143] beschrieben. Die Komplexität würde ich als mittelschwer beschreiben: Also nicht ganz so einfach wie ein HTTP-Request, aber auch super komplex. Ich habe erfolgreich einen VNC Server auf TCP-Basis programmiert, mit dem der Inhalt eines kleinen Displays übertragen und manipulitert werden kann.<br />
<br />
Während in der RFC die Details des Protokolls gut beschrieben sind, gibt es einige Dinge, die noch etwas anders beschrieben werden können.<br />
<br />
=== Zwei Haupzustände der VNC Verbindung ===<br />
Eine VNC Verbindung kann im wesentlichen in zwei Hauptzustände unterteilt werden:<br />
<br />
# Verbindungsaufbau<br />
# Fernsteuerung<br />
<br />
=== Verbindungsaufbau ===<br />
Während des Verbindungsaufbaus funktioniert das Prokoll im strengen Halbduplex (Handshake): Es folgt einer strikten Struktur und es gibt immer genau eine Anfrage und genau eine Antwort darauf. Die Nachrichten sind hier genau vorgegeben und haben daher typischerweise kein separates Header-Byte, was die Art der Nachricht vorgibt.<br />
<br />
Für eine Verbindung ohne Passwort-Authentifikation sieht das wie folgt aus und kann recht simpel "hart" kodiert werden:<br />
# Client baut TCP Verbindung zum Server aus, Server nimmt diese an.<br />
# Server sendet "RFB 003.008\n" - das ist die derzeit typische Protokollversion.<br />
# Client antwortet ebenfalls mit "RFB 003.008\n" - und bestätigt damit, das er diese Protkollversion akzeptiert.<br />
# Server sendet 0x01 0x01 - Er sagt damit, dass er nur den Security Handshake "None" unterstützt, also gar keine Authentifikation. Natürlich könnte man hier auch komplexere Handshakes erlauben, der Einfachheit halber soll das aber hier genügen.<br />
# Client antwortet mit 0x01 - Er sagt damit, dass er den Security Handshake "None" akzeptiert. <br />
# Server sendet 0x00 0x00 0x00 0x00 - Er sagt damit, dass der Security Handshake erfolgreich war und er die Verbindung akzeptiert.<br />
# Client sendet nun genau ein Byte, entweder 0x00 oder 0x01. Bei einer 0x00 wünscht er eine exlusive Verbindung zum Server - der Server sollte also bestehende Verbindungen trennen. Bei einer 0x01 braucht es nicht exlusiv zu sein. Ob 0x00 oder 0x01 ist für einfache Anwendungen unwichtig, ggf lässt der Simple-Server ja eh nur eine Verbindung zu.<br />
# Server sendet nun die sog. ServerInit Message: Diese enthält die Auflösung und das Farbformat des Framebuffers sowie den Namen der Verbindung. Dieses PIXEL_FORMAT ist allerdings nur eine Art maximale Empfehlung für den Client, denn dieser kann das PIXEL_FORMAT jederzeit ändern, was zumindest bei RealVNC auch häufig passiert. Statt das z.B. die Farbpixel mit 24Bit übertragen werden (typischerweise dann als 32 Bit Werte), kann der Client z.B. ein 8 Bit Farbformat anfragen, um schneller ein erstes Bild zu erhalten. Wichtig ist hier daher, dass auch bei einfachsten Implementierungen des Servers trotzdem verschiedene PIXEL_FORMAT Nachrichten richtig ausgewertet werden müssen. <br />
# Übergang in den Fernsteuerungsmodus: siehe nächstes Kapitel. Typischerweise kommen hier gleich mehrere Pakete hintereinander vom Client, ohne dass der Server irgendwas sendet. Bei RealVNC wurden die folgenden 3 Pakete beobachtet:<br />
## SetEncodings<br />
## SetPixelFormat<br />
## FramebufferUpdateRequest<br />
<br />
=== Fernsteuerung ===<br />
<br />
Am Ende davon geht das Protokoll in den Fernsteuerungsmodus über - hier ist die Situation anders:</div>
Tut