https://wiki.raumzeitlabor.de/api.php?action=feedcontributions&user=Bfritz0815&feedformat=atomRaumZeitLabor Wiki - Benutzerbeiträge [de]2024-03-28T15:30:18ZBenutzerbeiträgeMediaWiki 1.40.2https://wiki.raumzeitlabor.de/index.php?title=Kategorie:KleinProzessorZ%C3%BCchter&diff=16707Kategorie:KleinProzessorZüchter2023-12-12T22:37:58Z<p>Bfritz0815: </p>
<hr />
<div>Die KleinProzessorZüchter sind die Mikrocontroller Fans im RaumZeitLabor. Siehe [[KleinProzessorZüchter]].<br />
<br />
Auf dieser Seite sind alle Wikiseiten gelistet, die etwas mit den KPZ zu tun haben.<br />
<br />
[[Kategorie:Arbeitsgruppe]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Kategorie:K%C3%BCche&diff=16706Kategorie:Küche2023-12-12T22:37:10Z<p>Bfritz0815: </p>
<hr />
<div>[[Kategorie:RaumZeitLabor]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Kategorie:Ger%C3%A4t&diff=16705Kategorie:Gerät2023-12-12T22:36:31Z<p>Bfritz0815: </p>
<hr />
<div>Den Besuchern des RaumZeitLabor stehen zahllose Geräte und Maschinen zur Verfügung. Zu diesen gibt es hier Dokumentation.<br />
<br />
[[Kategorie:Hardware]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Diskussion:Pinpad/Frontendv2&diff=16704Diskussion:Pinpad/Frontendv22023-12-12T22:35:01Z<p>Bfritz0815: Die Seite wurde neu angelegt: „historische relevanz? --~~~~“</p>
<hr />
<div>historische relevanz? --[[Benutzer:Bfritz0815|Bfritz0815]] ([[Benutzer Diskussion:Bfritz0815|Diskussion]]) 22:35, 12. Dez. 2023 (UTC)</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Pinpad/Frontendv2&diff=16703Pinpad/Frontendv22023-12-12T22:34:44Z<p>Bfritz0815: </p>
<hr />
<div>[[Datei:Pinpad_Frontend_v2_01.jpg|200px|thumb|right|Prototyp]]<br />
<br />
Auf dieser Seite wird das neue Frontend dokumentiert. Da die alte Platine in Betrieb ist können wir dort nicht ohne größeren Aufwand zu treiben alte Probleme beheben (beispielsweise funktionieren die Blink- und Pieps-Funktionen zwar prinzipiell, aber nicht so wie wir das gerne hätten). Unter anderem aus diesem Grund bauen wir ein neues Frontend.<br />
<br />
= Fuses =<br />
sudo avrdude -c usbasp -p atmega644p -P usb -U lfuse:w:0xdf:m -U hfuse:w:0xd9:m<br />
'''Unbedingt''' diese Fuses verwenden, sonst sind z.B. JTAG oder Clock Output aktiv, was dazu führt, dass manche Sachen nicht richtig funktionieren (wir belegen nahezu alle Ports des ATmegas).<br />
<br />
= LCD =<br />
DaFo hat uns freundlicherweise ein JHD 162A-LCD bereitgestellt, welches 16x2 Zeichen darstellen kann. Das LCD kann man im 4-Bit-Modus betreiben, sodass man effektiv 3 Pins (Enable, Read/Write, Register Select) und 4 Datenpins braucht.<br />
<br />
Wichtig:<br />
* Contrast (VEE, Pin 3) auf GND ziehen für maximalen Kontrast, sonst sieht man nichts. Den idealen Kontrast hat man zwischen 0.24V und 0.36V auf VEE.<br />
* Fuse-Settings beachten, sonst stehen die Pins ggf. nicht zur Verfügung<br />
* Zur Ansteuerung verwenden wir derzeit die lcd.{c,h} von http://www.jump.to/fleury<br />
<br />
= LEDs =<br />
Als LEDs verwenden wir zur Anzeige des Raumstatus und zur Eingabebestätigung/-verweigerung zweifarbige LEDs (rot/grün). Diese haben eine gemeinsame Kathode und zwei Pins, die jeweils Rot bzw. Grün aktivieren. Die entsprechenden Widerstände sind 140 Ohm für Grün und 150 Ohm für Rot. Das Beinchen auf der abgeflachten Seite ist für Rot.<br />
<br />
= Übertragung =<br />
Diesmal möchten wir statt TTL-Pegel-UART lieber RS485 verwenden, was bei zwei Teilnehmern sehr einfach sein sollte.<br />
<br />
Wichtig:<br />
* Darauf achten den Bus ordentlich zu terminieren (Widerstände zwischen A/B/VCC/GND, wie beim Hausbus).<br />
<br />
= TODO-Liste =<br />
<br />
* Türkontakt für Erkennung von Abgeschlossen einbauen (AlexanderB)<br />
* Hometec0x und RasPi in das Gehäuse einbauen<br />
<br />
[[Kategorie:Archäologie]]<br />
[[Kategorie:Wiki_Cleanup/ToDo]]<br />
[[Kategorie:Infrastruktur/obsolet]]<br />
[[Kategorie:Gerät]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Pinpad/Controller&diff=16702Pinpad/Controller2023-12-12T22:34:10Z<p>Bfritz0815: </p>
<hr />
<div>Diese Seite beschreibt den neuen Pinpad-Controller, basierend auf einem Raspberry Pi und einer eigenen Platine von AlexanderB. Dieser Controller kommt bisher nur im Getränkelager zum Einsatz, soll aber auch im eigentlichen Raum eingesetzt werden.<br />
<br />
= Partitionstabelle der SD-Card =<br />
<br />
Disk /dev/sdb: 4011 MB, 4011851776 bytes<br />
4 heads, 32 sectors/track, 61216 cylinders, total 7835648 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x000ee283<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2048 155647 76800 c W95 FAT32 (LBA)<br />
/dev/sdb2 155648 974847 409600 83 Linux<br />
/dev/sdb3 974848 1794047 409600 83 Linux<br />
/dev/sdb4 1794048 1998847 102400 c W95 FAT32 (LBA)<br />
<br />
Die erste Partition ist für den Bootloader + Kernel.<br />
<br />
Die zweite Partition ist das Root-Dateisystem.<br />
<br />
Die dritte Partition ist reserviert für remote-upgrades des Root-Dateisystems, derzeit aber ungenutzt.<br />
<br />
Die vierte Partition ist für persistente Daten (Benutzer-PINs).<br />
<br />
[[Kategorie:Archäologie]]<br />
[[Kategorie:Wiki_Cleanup/ToDo]]<br />
[[Kategorie:Infrastruktur/obsolet]]<br />
[[Kategorie:Gerät]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Diskussion:Pinpad/Controller&diff=16701Diskussion:Pinpad/Controller2023-12-12T22:33:23Z<p>Bfritz0815: Die Seite wurde neu angelegt: „Das is vom alten Pinpad, right? Also historisch --~~~~“</p>
<hr />
<div>Das is vom alten Pinpad, right? Also historisch --[[Benutzer:Bfritz0815|Bfritz0815]] ([[Benutzer Diskussion:Bfritz0815|Diskussion]]) 22:33, 12. Dez. 2023 (UTC)</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Snuggies&diff=16700Snuggies2023-12-12T22:32:48Z<p>Bfritz0815: </p>
<hr />
<div> Name Farbe Anzahl<br />
---------------------------------------------------------------------------------------<br />
Alexander Brock blau/rot 1<br />
Hannes blau oder grün 1<br />
PhyberApex blau/rot 2<br />
Sandra (Kumpel von TheTinyToon) rot oder grün 1<br />
Zwetschgo blau oder rot oder grün 1<br />
ThinkJD blau rot oder grün 2<br />
<br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Diskussion:Snuggies&diff=16699Diskussion:Snuggies2023-12-12T22:32:30Z<p>Bfritz0815: Die Seite wurde neu angelegt: „Sieht nach alter Einkaufsliste aus. Kann weg, oder? --~~~~“</p>
<hr />
<div>Sieht nach alter Einkaufsliste aus. Kann weg, oder? --[[Benutzer:Bfritz0815|Bfritz0815]] ([[Benutzer Diskussion:Bfritz0815|Diskussion]]) 22:32, 12. Dez. 2023 (UTC)</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Rarity/Wartungslogbuch&diff=16698Rarity/Wartungslogbuch2023-12-12T22:32:01Z<p>Bfritz0815: </p>
<hr />
<div>{| class="wikitable td-top"<br />
!Datum<br />
!Laborant<br />
!Wartung<br />
|-<br />
|20.08.2016<br />
|[[Benutzer:Alexander Brock|Alexander Brock]]<br />
|Umlaufgreifer-Schrauben angezogen, Maschine komplett geölt.<br />
|-<br />
|31.01.2015<br />
|[[Benutzer:Alexander Brock|Alexander Brock]]<br />
|Nadeln 9,13 ausgetauscht<br />
|-<br />
|28.01.2015<br />
|[[Benutzer:Alexander Brock|Alexander Brock]]<br />
|Nadeln 15,14,12,11,3 ausgetauscht<br />
|-<br />
|18.01.2015<br />
|[[Benutzer:Alexander Brock|Alexander Brock]]<br />
|Komplettölung, Fadenreste und Fussel entfernt, Nadeln 9 und 6 ersetzt, Rahmenhalterung umgebaut so dass die Rahmen jetzt waagrecht eingespannt werden.<br />
|-<br />
|24.11.2014<br />
|[[Benutzer:Alexander Brock|Alexander Brock]]<br />
|Fadenreste und Fussel entfernt, Komplettölung<br />
|-<br />
|31.08.2014<br />
|[[Benutzer:Alexander Brock|Alexander Brock]]<br />
|Mehr PTFE eingebaut. Fotos: <gallery><br />
Datei:Rarity-PTFE 1.jpg<br />
Datei:Rarity-PTFE 2.jpg<br />
Datei:Rarity-PTFE 3.jpg<br />
Datei:Rarity-PTFE 4.jpg<br />
Datei:Rarity-PTFE 5.jpg<br />
</gallery><br />
|-<br />
|27.08.2014<br />
|[[Benutzer:Alexander Brock|Alexander Brock]]<br />
|PTFE-Scheibe eingebaut, Fadenreste und Fussel entfernt, Komplettölung<br />
|-<br />
|16.08.2014<br />
|[[Benutzer:Alexander Brock|Alexander Brock]]<br />
|Komplettölung<br />
|-<br />
|14.08.2014<br />
|[[Benutzer:Alexander Brock|Alexander Brock]]<br />
|X-Achsen-Abdeckung zurechtgebogen<br />
|}<br />
<br />
[[Kategorie:Fablab]]<br />
[[Kategorie:Textiles]]<br />
[[Kategorie:Gerät]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Rarity/Hackwert&diff=16697Rarity/Hackwert2023-12-12T22:30:53Z<p>Bfritz0815: </p>
<hr />
<div>== Mechanische Verbesserungen ==<br />
<br />
=== Höhe der Rahmen ===<br />
<br />
Problem: Die Rahmen drücken die Textilien auf die Stichplatte, das führt zu Verzug.<br />
<br />
Lösungsansatz 1: Weiße Plastik-Laser-Teile sorgen dafür, dass die Rahmen 2mm höher liegen.<br />
<br />
Problem: Die Höhe des Rahmens über der Stichplatte ist abhängig von der Y-Position des Rahmens.<br />
<br />
Lösungsansatz 2: Die weißen Plastikteile durch keilförmige Aluminiumteile ersetzen.<br />
<br />
* Bei ganz nach vorne gefahrenem normalen Rechteckrahmen sind es mit den weißen Plastikteilen 4.44mm.<br />
* Bei fast ganz nach hinten gefahrenem Rahmen (300mm) etwa -1.78mm.<br />
* Differenz: 6.22mm.<br />
* Winkel: 1.18776°<br />
* Länge des benötigten Keils: 135mm (incl. absichtlichem Übermaß)<br />
* Höhendifferenz des benötigten Keils: 2.8mm.<br />
<br />
Messungen mit dem ganz großen Rahmen:<br />
* Bei fast ganz nach hinten gefahrenem Rahmen: -6.09mm<br />
* Bei ganz nach vorne gefahrenem Rahmen (355.8mm): 3.81mm<br />
* Differenz: 9.9mm<br />
* Winkel: 1.5938°<br />
* Höhendifferenz des benötigten Keils: 3.8mm.<br />
<br />
<br />
<br />
<br />
== Anbindung an die Cloud[tm] ==<br />
<br />
=== Steckerbeschriftung ===<br />
<br />
* LED = Fehler-LED an der Vorderseite der Maschine<br />
* H = Hauptspindel-Lichtschranke<br />
* G = Garnverbrauchszähler <br />
* N = Nadelwahl-Spindeltrimmer<br />
<br />
=== Spannungen am Spindeltrimmer für die Nadelwahl:===<br />
<br />
Aufsteigend gemessen:<br />
<br />
<pre><br />
Minimum: 0.230<br />
1 0.282<br />
2 0.435<br />
3 0.608<br />
4 0.781<br />
5 0.946<br />
6 1.109<br />
7 1.274<br />
8 1.438<br />
9 1.602<br />
10 1.765<br />
11 1.921<br />
12 2.085<br />
13 2.258<br />
14 2.421<br />
15 2.586<br />
Maximum: 2.664<br />
</pre><br />
<br />
Absteigend gemessen:<br />
<br />
<pre><br />
15 2.610<br />
14 2.424<br />
12 2.087<br />
11 1.922<br />
10 1.768<br />
9 1.604<br />
8 1.440<br />
7 1.275<br />
6 1.112<br />
5 0.948<br />
4 0.784<br />
3 0.611<br />
2 0.438<br />
1 0.282<br />
Minimum: 0.229<br />
</pre><br />
<br />
[[Kategorie:Fablab]]<br />
[[Kategorie:Textiles]]<br />
[[Kategorie:Gerät]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Rarity/Garnwahl&diff=16696Rarity/Garnwahl2023-12-12T22:30:35Z<p>Bfritz0815: </p>
<hr />
<div>Beim Sticken vorgegebener Motive habe ich regelmäßig das Problem, aus den 334<br />
verschiedenen Garnfarben diejenigen auszusuchen, die den Motiv-Farben am<br />
ähnlichsten sind.<br />
<br />
Deshalb habe ich ein kleines Programm geschrieben,<br />
das mir die Garnwahl erleichtert,<br />
[https://github.com/abrock/color-matcher den Code findet ihr auf Github].<br />
<br />
Die Idee ist einfach: Beim Start des Programms wird eine Datei eingelesen,<br />
die in jeder Zeile zuerst eine Farbnummer enthält, gefolgt von einem<br />
Leerzeichen und der zugehörigen Farbe in hexadezimaler RGB-Darstellung,<br />
z.B. so:<br />
<br />
501 b4b9a5<br />
502 efc810<br />
505 0c082d<br />
508 f9e6ca<br />
520 fdf3da<br />
<br />
Dann kann der Benutzer hexadezimale RGB-Farbwerte eingeben und bekommt 1-2<br />
Farb-Nummern vorgeschlagen, die der gesuchten Farbe ähnlich sind.<br />
Als Ähnlichkeitsmaße werden unabhängig voneinander der euklidsche Abstand im<br />
[https://de.wikipedia.org/wiki/Lab-Farbraum Lab-Farbraum] und der euklidsche<br />
Abstand im [https://de.wikipedia.org/wiki/DIN99-Farbraum DIN99-Farbraum]<br />
verwendet.<br />
<br />
Für die Konvertierung von RGB nach Lab werden<br />
[http://opencv.org/ OpenCV]-Routinen benutzt, unter Debian müsst ihr daher<br />
vor dem kompilieren das Paket *libopencv-dev* installieren, wenn ihr andere<br />
Betriebssysteme benutzt heißt das Paket ggf. anders.<br />
Den Code inklusive der Beispiel-Tabelle mit den Sulky-Garnnummern könnt ihr<br />
folgendermaßen klonen:<br />
<br />
git clone https://github.com/abrock/color-matcher.git<br />
<br />
Der Befehl *make* erzeugt die Programmdatei *color-matcher*, das Programm wird<br />
dann folgendermaßen aufgerufen und benutzt:<br />
<br />
alexander@toothless:~/rzl/color-matcher$ ./color-matcher sulky.data <br />
Tests passed, read 334 values from file sulky.data<br />
73a6f6<br />
Input was interpreted as (115, 166, 246)<br />
best LAB match: 1534 (rgb: 347dcb), difference: 16.3557 (large)<br />
best DIN match: 1249 (rgb: 62aadc), difference: 9.12243 (large)<br />
<br />
Die letzten beiden Zeilen zeigen die ähnlichste Farbe bezüglich des<br />
Lab-Ähnlichkeitsmaßes (1524) und bezüglich des DIN99-Ähnlichkeitsmaßes (1249)<br />
an, dazu die jeweiligen RGB-Werte und den gemessenen Abstand.<br />
Zu dem DIN99-Ähnlichkeitsmaß habe ich keine Angabe gefunden, ab wann der Abstand<br />
als "groß" o.ä. gilt, daher sind diese Angaben mit Vorsicht zu genießen.<br />
<br />
Den RGB-Wert, der hier in der dritten Zeile eingegeben wird bekommt man<br />
in Inkscape z.B. indem man die Funktion "Pick colours from image (F7)"<br />
auswählt und den Mauszeiger über die gewünschte Farbe bewegt.<br />
Der Farbcode wird dann unten angezeigt, siehe Bild 1.<br />
In [http://www.gimp.org/ GIMP] bekommt man eine ähnliche Funktion über<br />
"Tools->Color Picker (O)", da muss man dann auf die gewünschte Farbe klicken.<br />
Eine einfache Alternative zu den genannten Bildverarbeitungsprogrammen<br />
ist [http://gcolor2.sourceforge.net/ gcolor2], dessen einzige Aufgabe die<br />
Auswahl von Farben ist.<br />
<br />
Die Software ist nicht auf die Auswahl von Garnen beschränkt, mit geeigneten<br />
Tabellen könnte man auch Plotterfolien zuordnen o.ä.<br />
<br />
[[Kategorie:Fablab]]<br />
[[Kategorie:Textiles]]<br />
[[Kategorie:Gerät]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=PRON-Protokoll&diff=16695PRON-Protokoll2023-12-12T22:27:56Z<p>Bfritz0815: </p>
<hr />
<div> <nowiki>================================================================================<br />
RZL1337 PRON-Wall Protocol Juli 2011<br />
================================================================================<br />
<br />
1 Introduction<br />
--------------<br />
<br />
This PRON-Wall Protocol (PWP) is defined to make available a datagram mode of<br />
communicating with a series of dot matrix light panels working together to form <br />
a display. This protocol assumes that the ethernet protocol [1] is used as the<br />
underlying protocol.<br />
<br />
This protocol provides a procedure for application programs to send messages <br />
to light panels with a minimum of protocol mechanism. The protocol is <br />
transaction oriented.<br />
<br />
1.1 Terminology<br />
---------------<br />
<br />
panel<br />
A device connected to the network, with a unique MAC address.<br />
<br />
subpanel<br />
A logical unit for displaying pictures. All Subpanels belong to a panel.<br />
<br />
display<br />
The set of panels logically connected to the same Ethernet segment.<br />
<br />
client<br />
The system that sends requests to the display (user equipment).<br />
<br />
1.2 Hardware setup<br />
------------------<br />
<br />
A display has one ethernet interface (RJ45), power supply and two cinch sockets<br />
to daisy chain the common interrupt line. Displays are addressed by their MAC<br />
address (or via broadcast).<br />
<br />
2 Communication<br />
---------------<br />
<br />
The following types of frames and packets are used for communication purposes.<br />
The communication is structured into two parts: the first part deals with the<br />
configuration of the panel devices and client software, the second part is used<br />
for the actual image frame transmission and processing. All communication is<br />
based on the Ethernet protocol.<br />
<br />
2.1 Ethernet Frame<br />
------------------<br />
<br />
0 8 16 24 63 <br />
+-----+-----+-----+-----+-----+-----+-----+-----+<br />
| T | V | S | R |<br />
+-----+-----+-----+-----+-----+-----+-----+-----+<br />
| Payload ...<br />
+-----+-----+-----+-----...<br />
<br />
T ... Packet type<br />
V ... Version of the protocol (should be 23 for the first version)<br />
S ... Subpanel ID<br />
R ... Reserved<br />
<br />
Ethertype: 0x2342<br />
<br />
2.2 Packet Types<br />
----------------<br />
<br />
The first bit of the packet type defines whether is a request or reply.<br />
<br />
0xxxxxxx ... request message<br />
1xxxxxxx ... reply message<br />
<br />
There are <br />
<br />
0x00 ... Scan Request<br />
0x80 ... Scan Reply<br />
0x01 ... Echo Request<br />
0x81 ... Echo Reply<br />
0x02 ... Set Master Request<br />
0x82 ... Set Master Reply<br />
0x03 ... Frame<br />
0x83 ... Frame Acknowledgement<br />
<br />
2.2.1 Scan Request Payload<br />
--------------------------<br />
<br />
0 n<br />
+---+---+---+---+<br />
| R |<br />
+---+---+---+---+<br />
<br />
R ... Reserved<br />
<br />
<br />
2.2.2 Scan Reply Payload<br />
------------------------<br />
<br />
0 1 15 16 23 24 31 32 39<br />
+-+-----+-------+-------+-------+-------+<br />
|T| BUFSZ | COLR | COLG | COLB |<br />
+-+-----+-------+-------+-------+-------+<br />
| REF | NSUBP | SUBPR | X1 |<br />
+-------+-------+-------+-------+-------+<br />
| Y1 | ...<br />
+-------+...<br />
<br />
T ... Type of display (1 = RGB / 0 = Monochromatic) <br />
BUFSZ ... Buffer size in frames of the panel<br />
COLR ... Color of panel (Red value)<br />
COLG ... Color of panel (Green value)<br />
COLB ... Color of panel (Blue value)<br />
REF ... Refresh rate of the panel (Hz)<br />
NSUBP ... Number of subpanels in this panel<br />
SUBPR ... Subpanels per row<br />
X(1-N) ... Panel Width in pixels<br />
Y(1-N) ... Panel Height in pixels<br />
<br />
There are as many X,Y pairs as indicated in NSUBP. If NSUBP%SUBPR != 0, the last<br />
row of subpanels consists of less subpanels than the other rows. "Color of<br />
panel" could be used for identification in the client UI.<br />
<br />
2.2.3 Echo Request Payload<br />
--------------------------<br />
<br />
0 8 16 24 32<br />
+---+---+---+---+---+---+---+---+<br />
| R | ID |<br />
+---+---+---+---+---+---+---+---+<br />
<br />
R ... Reserved<br />
ID ... ID of the Echo Request. Should be returned by the other endpoint.<br />
<br />
<br />
2.2.4 Echo Reply Payload<br />
------------------------<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| R | ID |<br />
+---+---+---+---+---+---+---+---+<br />
<br />
R ... Reserved<br />
ID ... ID of the Echo Request as sent by the client.<br />
<br />
2.2.5 Set Master Request Payload<br />
--------------------------------<br />
<br />
+---+---+---+---+---+---+---+---+---+---+<br />
| R | MAC ADDRESS OF MASTER |<br />
+---+---+---+---+---+---+---+---+---+---+<br />
<br />
2.2.6 Set Master Reply Payload<br />
------------------------------<br />
<br />
+---+---+---+---+<br />
| R | I |<br />
+---+---+---+---+<br />
<br />
R ... Reserved<br />
I ... Feedback. 1 if the selected Panel is now the Master. 0 if not.<br />
<br />
3 Master Autodiscovery<br />
----------------------<br />
<br />
Upon bootup, a device waits at least one interrupt interval plus an additional<br />
random backoff timer. If, during that time, no interrupt was recognized on the<br />
input line, the device sets up an interrupt by itself and thus serves as the<br />
master. Also, it informs the connected client about this decision so that<br />
unlikely, but possible collisions (several masters) can be detected and<br />
resolved by the client.<br />
<br />
4 Image Frames<br />
--------------<br />
<br />
Each frame contains a single image with brightness levels. This image can either<br />
be a greyscale image or one of the three base colors (R,G,B).<br />
<br />
The protocol also supports 3D displays. The two most significant bits are <br />
designated for those frames. The most significant bit marks frames that are part<br />
of a 3D picture, the second one designates a frame for the left eye when it is<br />
not set and for the right eye when set.<br />
<br />
4.1 Image Frame<br />
---------------<br />
<br />
0 8 16 24 32<br />
+---+---+---+---+---+<br />
| C | TIME | SEQ |<br />
+---+---+---+---+---+<br />
| PIXELS ... <br />
----------...<br />
<br />
C ... type of frame (see 4.2)<br />
TIME ... duration in milliseconds frame will be displayed<br />
SEQ ... will be used for retransmissions<br />
PIXEL ... each pixel is represented by a single byte, containing the<br />
brightness level of this pixel<br />
<br />
4.2 Image Frame Types<br />
---------------------<br />
<br />
PWP supports monochromatic/greyscale, 3D and RGB frames. 3D can be achieved<br />
using the shutter technique with an infrared LED serving as the synchronization<br />
clock generator.<br />
<br />
00xxxxxx ... normal frame<br />
1xxxxxxx ... 3D frame<br />
10xxxxxx ... 3D frame for left eye<br />
11xxxxxx ... 3D frame for right eye<br />
xxxxxx00 ... greyscale frame<br />
xxxxxx01 ... red frame<br />
xxxxxx10 ... blue frame<br />
xxxxxx11 ... green frame<br />
<br />
4.3 Sequence number<br />
-------------------<br />
<br />
A sequence number designates the current full picture.</code><br />
<br />
[[Kategorie:Sonstiges_Projekt]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Plenum/2023-05-07&diff=16694Plenum/2023-05-072023-12-12T22:27:20Z<p>Bfritz0815: </p>
<hr />
<div>== Realitätsabgleich ==<br />
<br />
* Status-Updates, die fehlen:<br />
** Druckplotter?<br />
** BenutzerDB?<br />
** Ameise?<br />
<br />
* JBC Entlötstation muss zurückgeschickt werden<br />
** Returenlabel von welectron ist erstellbar<br />
** Verpackungsmaterial wurde schon entsorgt<br />
** Wir versuchen am Dienstag abend was zusammenzuwerfen und sie zu verschicken<br />
<br />
* Werkstatt-Pläne<br />
** Strom nur über PIN (statt Motorschloss)<br />
** Betriebsvereinbarung wäre vorzubereiten (evtl. Hilfe von Christian)<br />
** Verbandskasten sauber machen und prominent aufhängen<br />
<br />
* Der Onkyo in der Küche hat einen neuen Chromecast spendiert bekommen.<br />
** funktioniert und macht Spass<br />
** Fernbedienung ist am Snackregal über dem Barcodescanner<br />
<br />
* Libella hat eine neue, große Festplatte bekommen <br />
** wird aber nicht erkannt. Wäre cool, wenn jemand danach schauen kann<br />
<br />
* Türschloss<br />
** Wir müssten das Schloss einschicken und vermutlich Wochen darauf warten, dass es debuggt wird<br />
** Statt dessen wollen wir unsere Steuerung umprogrammieren, damit eine Eingabe einer bekannten PIN, wenn der Raum schon offen ist, NICHT den Raum abschliesst.<br />
<br />
* Agenda-Aktion Mannheim wartet auf unseren Input<br />
** Anmeldeseite muss noch umgebaut werden<br />
<br />
== Ideen ==<br />
<br />
* Hauptraum ("hinten" bzw. "rechts")<br />
** Idee eine zweite Regalreihe zu ziehen, parallel zu der jetzigen, von der Säule ab bis zum Fenster<br />
** Plenum beschließt, lieber erstmal das bestehende Regal im Hauptraum auszumisten<br />
** Bitte labelt Privatkram deutlich bis zum nächsten Plenum. Am 02.07. wird hart aussortiert. Team dafür sind Brudi, Marco, helix und pitchbent<br />
<br />
== Anschaffungen ==<br />
<br />
* Gab keine Anträge im WIki und auf der ML<br />
<br />
== nächstes Plenum ==<br />
<br />
* da der 28.5. Pfingsten ist und wir da ein Event haben, wird auch dieses verschoben auf das WE danach, also auf den 04.06.<br />
<br />
[[Kategorie:Plenum]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=NOC_Team/RAID-Setup&diff=16693NOC Team/RAID-Setup2023-12-12T22:26:54Z<p>Bfritz0815: </p>
<hr />
<div>== Volume Mapper ==<br />
=== ZFS ===<br />
==== Pro ====<br />
* Kann Snapshots (as in Performant, auch mehrere pro Device, erspaart uns cp cashdesk cashdesk-pre-experimentelle-änderung15)<br />
* Checksums<br />
* Option: zfs send für Backups<br />
<br />
==== Contra ====<br />
* Nicht im Tree<br />
* Verbraucht „Experimental-Punkte“<br />
<br />
=== LVM ===<br />
==== Pro ====<br />
* Simpel<br />
* Abgehangen<br />
<br />
==== Contra ====<br />
* Snapshots sind echt nicht geil<br />
<br />
=== ext4 und Ordner mit Images ===<br />
==== zu Evaluieren ====<br />
* Was geht da mit Snapshots? Stichwort qcow2-Files<br />
<br />
==== Contra ====<br />
* Fühlt sich falsch an<br />
<br />
== RAID ==<br />
=== ZFS ===<br />
==== Pro ====<br />
* Bei Bedarf: Performance-Verbesserung via SSD mit Write intent Log und L2ARC<br />
<br />
==== Contra ====<br />
* müssten HBA besorgen<br />
<br />
=== dm-raid / mdadm ===<br />
==== Pro ====<br />
* Simpel<br />
* Abgehangen<br />
<br />
=== Hardware-RAID-Controller ===<br />
==== Pro ====<br />
* Performance<br />
<br />
==== Contra ====<br />
* schlechte Doku<br />
* wenn der ausfällt sind die Daten pfutsch<br />
<br />
[[Kategorie:Infrastruktur]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=NOC_Team/To-Dos&diff=16692NOC Team/To-Dos2023-12-12T22:26:39Z<p>Bfritz0815: </p>
<hr />
<div>== Tagebuch ==<br />
<br />
Wichtiger Punkt: Dokumentation, was bisher getan wurde. Was ergab sich aus der Freifunk-Diskussion heute, was aus Verm.+Pfalzkom+Politik, was machen wir mit dem Cisco-Stack hinsichtlich des Tschisko-Fuckups mit Self-Signed Certificates (ist zwar scheisse, macht aber jeder(tm), auch wir?) '''''vor''''' Januar 2020? Was habe ich vergessen?<br />
<br />
Cisco siehe auch [https://www.cisco.com/c/en/us/support/docs/field-notices/704/fn70489.html FN 70489].<br />
<br />
• <small><strong>[[User:0xb4dc0d3d|<span style="color: #0072ce;">&nbsp;0xb4dc0d3d&nbsp;</span>]]</strong>[[Benutzer Diskussion:0xb4dc0d3d| <sup style="font-weight: bold; color: #ef2b2d;">wtf?</sup>]]</small> • 21:35, 27. Dez. 2019 (CET)<br />
<br />
Und noch ein wichtiger Punkt: Entscheid Serverhardware, Anbringung des Kostenpunkts im Plenum Anfang Januar.<br />
<br />
# Tagebuch erstellt, [https://git.raumzeitlabor.org/NOC/tagebuch git]<br />
# Server-Hardware-Raussuchen festgehalten, [https://git.raumzeitlabor.org/NOC/server-hardware git], in Progress<br />
<br />
• <small><strong>[[User:0xb4dc0d3d|<span style="color: #0072ce;">&nbsp;0xb4dc0d3d&nbsp;</span>]]</strong>[[Benutzer Diskussion:0xb4dc0d3d| <sup style="font-weight: bold; color: #ef2b2d;">wtf?</sup>]]</small> • 22:58, 29. Dez. 2019 (CET)<br />
<br />
== Netzwerk ==<br />
<br />
=== DNS rzl.so ===<br />
Alle internen Dienste enden auf .rzl, was keine Domain ist, die uns gehört. Möglichkeit: Belassen mit ungültigem FQDN oder mergen in rzl.so unter Berücksichtigung der Security-Through-Obscurity-Prinzipien.<br />
<br />
→ Split-DNS? --> Verschoben auf [[Diskussion:NOC_Team/To-Dos|Diskussionsseite]], dafür ist sie da.<br />
<br />
=== SSL-Zertifikate ===<br />
Für nur intern verfügbare Dienste wäre auch ein SSL-Zertifikat sinnvoll.<br />
<br />
Letsencrypt *.rzl.so würde die internen Dienste dann nicht nach [https://crt.sh crt.sh] | [https://www.entrust.com/ct-search/?domain=raumzeitlabor.de&includeExpired=true&exactMatch=false entrust.com/ct-search] leaken, daher würde ich das vorschlagen.<br />
<br />
Für extern verfügbare Dienste kann man dann ja je FQDN ein normales Cert holen. Eventuell auf [https://letsencrypt.org/docs/rate-limits/ Rate Limits] aufpassen.<br />
<br />
--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)<br />
<br />
: Aufbauend darauf (Obacht: Rate Limits are a real thing): Automatisierung der Zertifikate. LE-Zerts halten nur 3 Monate, da ist Rumgammeln keine Option mehr. Und die Faustregel heißt: ist es rein interner Kram? Wirklich? Wenn nein --> Non-Wildcard und SAN. Wildcard-Zerts sind obsolete Tech, machen wir nur zur Obfuscation. Doku essentiell, SAN-Zusammenfassung und -Stepping!<br />
<br />
: Zur Disk. im NOC-Meeting. Bei weiteren Diskussionspunkten diese Zeile löschen und bitte die Diskussionsseite dieses Artikels nutzen. • <small><strong>[[User:0xb4dc0d3d|<span style="color: #0072ce;">&nbsp;0xb4dc0d3d&nbsp;</span>]]</strong>[[Benutzer Diskussion:0xb4dc0d3d| <sup style="font-weight: bold; color: #ef2b2d;">wtf?</sup>]]</small> • 20:38, 27. Dez. 2019 (CET)<br />
<br />
=== Inventur Internetleitung ===<br />
<br />
Welche Leitungen haben wir, welche Möglichkeiten zum Upgrade gibt es?<br />
<br />
Aktuelle Leitung: <br />
: Telekom-Hybrid 50Mbit<br />
: 16 Mbit DSL<br />
: Rest geht über im Router verbaute SIM-Karte (nur mit Telekom-Router kompatibel)<br />
<br />
Geimeinsame Klärung mit der Spedition erstrebenswert.<br />
<br />
=== Holzwerkstatt ===<br />
<br />
Wurde geklärt: es muss definitiv ein Patchpanel für die neue Werkstatt angeschafft werden, z.B.: [https://www.amazon.de/deleyCON-Patchpanel-Verteilerfeld-Port-Servermontage/dp/B01N5OB4B2/ref%3Dsr_1_4?__mk_de_DE=ÅMÅŽÕÑ&crid=3VYNP23DYV9L9&keywords=patchpanel%2Bcat%2B6%2B24%2Bport&qid=1577560089&sprefix=patchpanel%2Bcat%2B6%2B%2Caps%2C161&sr=8-4 Amazon-Link, deleyCON Patchpanel]<br />
<br />
Außerdem noch ein Switch, da der momentane Ersatz ein Relikt aus den 90ern ist. Beispiel: [https://www.omg.de/mikrotik/routerboard/mikrotik-routerboard-crs328-24p-4s-rm/a-14454/ Mikrotik Routerboard CRS328 (24-Port) auf omg]. Oder jemand repariert den Ubiquity der seit Monaten in der Werkstatt liegt.<br />
<br />
(alles unsigniert von [[Benutzer:Lordeis|Lordeis]])<br />
<br />
=== Freifunk + IPv6 ===<br />
<br />
Zukunft ab 01.01.2020? Kübler Glasfaser? Fürs Erste, wenn möglich, über das /56 Netz, das am Telekom Router anliegt. - [[Benutzer:Lordeis|Lordeis]]<br />
<br />
Update vom 27.12.19:<br />
<br />
Laut [[Benutzer:cheatha|@cheatha]] wird gerade die Freifunk-Infrastruktur umgezogen, was uns ein wenig Zeit ins neue Jahr gewähren sollte.<br /><br />
[[Benutzer:Lordeis|Lordeis]] ([[Benutzer Diskussion:Lordeis|Diskussion]]) 18:00, 29. Dez. 2019 (CET)<br />
<br />
=== Switches ===<br />
Inventur aller Switche und Firmware-Stände prüfen <br />
<br />
==== Cisco-Stack E-Werkstatt ====<br />
Update von Cisco verfügbar: '''1.4.11.02'''<br />
<br />
Diskussion, ob Update durchgeführt werden soll (unsignierter Beitrag von [[Benutzer:Lordeis|Lordeis]])<br />
<br />
'''Wichtig:'''<br />
<br />
'''Prüfen, ob die Switche von dem Cisco-Zertifikats-Fuckup betroffen sind.'''<br />
<br />
=== Benutzer-DB ===<br />
<br />
TLS-Renewal. Details nach Fertigstellung.<br />
<br />
=== Router ===<br />
==== Ubiquity ====<br />
# Auseinandersortieren der Netzwerkverbindungen.<br />
# Reverse Engineering und Dokumentieren der Konfiguration.<br />
# IPv6 Konfiguration.<br />
<br />
==== Speedport (Telekom) ====<br />
# Reverse Engineering und Dokumentieren der Konfiguration.<br />
# IPv6 Konfiguration.<br />
<br />
Kommentar Ranlvor: Sollte ziemlich Standard sein, nur eventuell ein paar Regeln drin, die versuchen sollen Telefonie-Traffic auf DSL zu zwingen (weil das weniger schlecht tut als via LTE).<br />
<br />
=== WIFI Access Points ===<br />
==== Ubiquity ====<br />
# Reverse-Engineering und Dokumentieren der Konfiguration.<br />
# Auseinandersortieren der SSIDs:<br />
## Prüfen, ob alle SSIDs nötig sind. <br />
## Diskutieren, ob Band-Steering sinvoll Wäre.<br />
## Prüfen, ob Layer-3-Roaming sinnig ist.<br />
# Prüfung, ob ein zusätzlicher Unify-AP für die Werkstatt sinn macht.<br />
# Auslagern des RZL-IOT-WLAN auf anderen AP.<br />
<br />
==== IOT-Accesspoint ====<br />
# Extra-AP verwenden da Performance Probleme.<br />
# Ich habe noch einen Lancom rumliegen, den ich spenden würde - [[Benutzer:Lordeis|Lordeis]]<br />
<br />
=== Verkabelung ===<br />
<br />
# Die zwei Tische an der E/Ä-Ecke sind vorbildlich verkabelt, wenn man sie als autonome Hackrepublik innerhalb des RZL betrachtet. --> Uplink-Kabel setzen.<br />
## Update: Hab' mal Kabel geordert, Kanäle haben wir noch da. Könnte auch beim Umbau 2020 hilfreich sein. • <small><strong>[[User:0xb4dc0d3d|<span style="color: #0072ce;">&nbsp;0xb4dc0d3d&nbsp;</span>]]</strong>[[Benutzer Diskussion:0xb4dc0d3d| <sup style="font-weight: bold; color: #ef2b2d;">wtf?</sup>]]</small> • 18:34, 28. Dez. 2019 (CET)<br />
<br />
=== WLAN ===<br />
# Kanäle auswürfeln und konfigurieren<br />
<br />
== Hypervisor ==<br />
<br />
=== RAM ===<br />
<br />
Welche Möglichkeiten zum Update gibt es? Kurzfristiger Punkt, da der RAM erschöpft ist. Auf jeden Fall mögliches Upgrade wären zusätzliche 4 GiB für 30-40 Euronen; wenn wir in den Server reingeschaut haben, wissen wir aber, ob noch mehr als die dann 16GiB gehen.<br />
<br />
Aktuelles To-Do: Dokumentation Hardwaremöglichkeiten - [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]<br />
<br />
Update: Macht das noch Sinn? Siehe Punkt Server-Hardware weiter unten in diesem Kapitel. • <small><strong>[[User:0xb4dc0d3d|<span style="color: #0072ce;">&nbsp;0xb4dc0d3d&nbsp;</span>]]</strong>[[Benutzer Diskussion:0xb4dc0d3d| <sup style="font-weight: bold; color: #ef2b2d;">wtf?</sup>]]</small> • 22:10, 27. Dez. 2019 (CET)<br />
<br />
=== Rechtekonzept ===<br />
<br />
User sollten ihre VMs durchstarten können. Geht Hand in Hand mit dem Gedanken, nicht mehr überall als root zu springen und alles als root zu tun, stattdessen Nutzung sudo und mittelfristig ggf. Anbindung an [[UserDB|UserDB]].<br />
<br />
Person mit Hut: [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]<br />
<br />
=== Hypervisor-Software ===<br />
<br />
# HV bleibt KVM. Helix erwähnte heute Cockpit, das scheint also auch ohne das ganze oVirt-Debakel zu gehen, und wäre dann prima. Geht als Frontend dann mit dem Rechtekonzept Hand in Hand. Alternative: Proxmox als Aufsatz, nicht(!!!) als Basis.<br />
<br />
# OS sollte CentOS sein: der Hypervisor hat dumm zu sein (CA-Verwaltung, Automatisierung etc. darf da nicht laufen), also genügt CentOS, und wir gewinnen den Benefit SELinux. (Alternative wäre Arch, aber Rolling Release in bedingt gewarteter aber produktiver Umgebung? Meh. Willstenich.)<br />
<br />
Gesamtes Kapitel zur Diskussion, habe ich ad hoc so niedergeschrieben • <small><strong>[[User:0xb4dc0d3d|<span style="color: #0072ce;">&nbsp;0xb4dc0d3d&nbsp;</span>]]</strong>[[Benutzer Diskussion:0xb4dc0d3d| <sup style="font-weight: bold; color: #ef2b2d;">wtf?</sup>]]</small> • 21:13, 27. Dez. 2019 (CET)<br />
<br />
=== VM-Inventur ===<br />
<br />
Prüfen, was noch aktiv ist, und nach einer geordneten(!) Inventarisierung Mitglieder bei Bedarf anschreiben. Im Zweifelsfall Downtime und einen Zeitraum X auf Reaktion warten.<br />
<br />
=== VM-Struktur ===<br />
<br />
Ordnung schaffen: Sind Dinge(tm) produktiv, sollten diese auf dedizierte VMs, gutes Beispiel hier: [[cashdesk.rzl]] (leider auch gutes Beispiel für undokumentierte VM).<br />
<br />
Kommentar Ranlvor: cashdesk ist ein schlechtes Beispiel, da das eigentlich mal eine MemberVM war und neben cashdesk auch den Infoscreen hosted.<br />
<br />
=== Serverhardware ===<br />
<br />
Zukunft: Redundanz? Idee: KVM over 2 Nodes mit GlusterFS.<br />
<br />
# Ob wir 2 Nodes brauchen oder 1 reicht, sollten wir in NOC-Meeting und Plenum diskutieren.<br />
# Basis: Nunja, 32 oder 64GiB RAM, mind. 64 GiB Platte und schauen wo die 3-4 TiB VM-Store hinkommen. Also Basisrahmen, zur Diskussion und Anpassung hier. • <small><strong>[[User:0xb4dc0d3d|<span style="color: #084;">&nbsp;0xb4dc0d3d&nbsp;</span>]]</strong>[[Benutzer Diskussion:0xb4dc0d3d| <sup style="font-weight: bold; color: #c50;">wtf?</sup>]]</small> • 18:31, 27. Dez. 2019 (CET)<br />
<br />
Erneuerung unumgänglich, RAM-Erweiterung ist nur Lebenserhaltungsmaßnahme bei einer designierten Leiche.<br />
<br />
Optionen:<br />
# Eigenkonfiguration auf Basis eines Supermicro-Boards und einer AMD-Epyc-CPU. Konfiguration hier: [https://git.raumzeitlabor.org/NOC/server-hardware/ Hardware Konfiguration] [[Benutzer:Lordeis|Lordeis]] ([[Benutzer Diskussion:Lordeis|Diskussion]]) 18:10, 29. Dez. 2019 (CET) --> Preis: 1848,39€<br />
# [https://www.thomas-krenn.com/de/produkte/einsatzzweck/software-defined-storage/storage-spaces-direct/s2d-micro-cluster/s2d-micro-cluster-advanced.html Thomas-Krenn-Storage-Cluster]: 240GB SSD OS, 3TB Nested Mirror, SuperMicro, 32GiB DDR4 ECC, max. 185W/Server, 13.100 Euro für zwei Server<br />
# [[Benutzer:Kite|Kite]] kann eventuell einen PowerEdge R510 startklarmachen. Er gibt noch bescheid, Basis-Specsheet [https://www.dell.com/downloads/global/products/pedge/R510_Spec_Sheet.pdf hier].<br />
<br />
Übersicht --> [[NOC Team/To-Dos/Serverhardware Q1 2020]]<br />
<br />
=== Installationsstandards ===<br />
<br />
Keine Nummer für den HV alleine, aber hier passt's am Ehesten rein: es gibt VMs ohne Swap, und alle VMs haben nur ein root-FS. Das lässt sich genauso simpel automatisieren und strukturieren wie das was wir schon haben. Resultat siehe meine User-VM. Z.B. den apt-cacher in eine root-Partition zu kloppen und generell nur eine root-Partition vorzuhalten, ist grober Unfug, oder Windows 95, oder wie auch immer man das nennen möchte.<br />
<br />
Wir sollten einen Standard hinsichtlich Partitionen, Basissoftware etc. verabschieden. Aufbauend auf dem trivial gehaltenen Status Quo. • <small><strong>[[User:0xb4dc0d3d|<span style="color: #0072ce;">&nbsp;0xb4dc0d3d&nbsp;</span>]]</strong>[[Benutzer Diskussion:0xb4dc0d3d| <sup style="font-weight: bold; color: #ef2b2d;">wtf?</sup>]]</small> • 18:20, 29. Dez. 2019 (CET)<br />
<br />
=== DNS ===<br />
<br />
Konzept:<br />
# IP, DNS und Reverse DNS für den angedachten Hostnamen asap registrieren, die MACs dürften sich auch nicht ändern<br />
# CNAME-Record für den neuen Host (volt?), name: cybervisor.rzl[.so]<br />
<br />
== Services ==<br />
<br />
=== Mailserver ===<br />
<br />
==== Spamfilter ====<br />
<br />
Überarbeitung und Erweiterung. Wir bekommen keine Viagramails, aber einiges an Werbung. ''Erst'' Spamfilter, ''dann'' Unterpunkt Blocklisten ;-)<br />
<br />
==== Mailman ====<br />
lists.raumzeitlabor.de benutzt Mailman v2.1.18 vom 6.5.2014.<br />
<br />
Eine [https://docs.mailman3.org/en/latest/migration.html Migration von 2.1 auf 3.x] ist möglich.<br />
<br />
--[[Benutzer:Helix|Helix]] ([[Benutzer Diskussion:Helix|Diskussion]]) 14:07, 28. Dez. 2019 (CET)<br />
<br />
=== Gitlab ===<br />
<br />
# Root-Passwort unbekannt, Version zu alt und damit insecure.<br />
# AutoDevops und CI-Runner sind aktiviert ohne Instanz, nerven also bei jedem neuen Projekt wieder. Das anzuschalten ohne es zu konfigurieren ist nicht gerade clever. Sollte man beseitigen oder nachfragen warum das überhaupt angedacht wurde.<br />
<br />
=== Raumtelefonie ===<br />
<br />
Es geht! Allerdings haben wir eine irritierende Anzahl diverser Töne auf den Telefonen. Nun bietet es sich an, jedem Telefon einen individuellen Ton zu verpassen, der die Raumharmonie dennoch erhält. Hierzu haben die Götter dem Menschen das Werkzeug des Kanons dargereicht, daher bieten sich folgende Klassiker eines anerkannten Künstlers an:<br />
<br />
* Der Klassiker, sechsstimmig: [https://de.wikipedia.org/wiki/Leck_mich_im_Arsch KV 231 (382c)] von Wolfgang Amadeus Mozart<br />
* Eine andere Variante, dreistimmig: [https://de.wikipedia.org/wiki/Leck_mir_den_Arsch_fein_recht_schön_sauber KV 233 (382d)] von W.A. Mozart<br />
<br />
• <small><strong>[[User:0xb4dc0d3d|<span style="color: #0072ce;">&nbsp;0xb4dc0d3d&nbsp;</span>]]</strong>[[Benutzer Diskussion:0xb4dc0d3d| <sup style="font-weight: bold; color: #ef2b2d;">wtf?</sup>]]</small> • 19:51, 3. Mär. 2020 (CET)<br />
<br />
[[Kategorie:Infrastruktur]]<br />
[[Kategorie:Arbeitsgruppe]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Diskussion:PartKeepr/Featurew%C3%BCnsche&diff=16691Diskussion:PartKeepr/Featurewünsche2023-12-12T22:24:45Z<p>Bfritz0815: Die Seite wurde neu angelegt: „Die Seite könnte als historische Seite relevant sein. Ist sie es auch als Informationsquelle? --~~~~“</p>
<hr />
<div>Die Seite könnte als historische Seite relevant sein. Ist sie es auch als Informationsquelle? --[[Benutzer:Bfritz0815|Bfritz0815]] ([[Benutzer Diskussion:Bfritz0815|Diskussion]]) 22:24, 12. Dez. 2023 (UTC)</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=PartKeepr/Featurew%C3%BCnsche&diff=16690PartKeepr/Featurewünsche2023-12-12T22:20:56Z<p>Bfritz0815: </p>
<hr />
<div>featurewünsche:<br />
<br />
== Features ==<br />
<br />
* Bauteile '''erledigt'''<br />
* Kategorien '''erledigt'''<br />
* Footprints '''erledigt''', jedoch noch ohne Footprint DXFs<br />
* Datenblätter<br />
* Herstellerlogos<br />
* Lieferanten<br />
* Lagerbestand + Lager / Lagerort / Lager-"größe" + Lagerwert + Reservierung<br />
* User- und Rechteverwaltung (Gruppen?)<br />
* Bestellisten pro User für Sammelbestellungen<br />
* Logging (Einlage, Entnahme, ...)<br />
* Kassensoftwareanbindung<br />
* Lagerort übergreifende suche<br />
* Umlagern<br />
* Inventur<br />
* Statistik<br />
* Teile ohne Preis <br />
* Freier Lagerort<br />
* Mehrere Lagerorte pro Teil<br />
* Mutterlager -> damit ist gemeint, daß Bauteile aus einem anderen, größeren Lager kommen. Beispielsweise haben wir 3000 Dioden, von denen 20 in Lager XY gelagert werden, und der Rest in Lager ZZ. Ist XY leer, kann umgebucht werden.<br />
* Private Lager (damit man auch seine eigenen, nicht-public Bauteile verwalten kann)<br />
<br />
=== Bauteile ===<br />
<br />
Je Bauteil (Artikel) sollen die folgenden Eigenschaften abgelegt werden:<br />
<br />
* Kategorie<br />
* Bauteilwert (Ohm, Chip-Typ, ...) und zwar mehrdimensional. z.b. spannungsregler 7805 vIn (min 7V max 50V) vOut min 4.5V max 5.0V).<br />
* Bauform (Gehäuseform) und Footprint(s) <br />
* Datenblätter (Datei *und* URL)<br />
* interner Verkaufspreis<br />
* Status (neu/refurbished)<br />
* ROHS<br />
* Quelle<br />
* Moisture Sensitivity Level<br />
* Preishistorie zwecks: letztem Einkaufspreis und gemitteltem Preis<br />
* vorhandene Stückzahl<br />
* Mindeststückzahl<br />
* Bestellnumer / Lieferant(en)<br />
* Lagerort<br />
* Kommentar<br />
* Ähnliche Bauteile (querlinks)<br />
* Hersteller<br />
* Matchcode ?<br />
* Bezeichnung<br />
* Artikelzustand (neu/gebraucht)<br />
<br />
* Footprint Viewer unter http://www.mentor.com/products/pcb-system-design/library-tools/lp-wizard/lp-viewer-download<br />
<br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Rarity/Einkaufsliste&diff=16689Rarity/Einkaufsliste2023-12-12T22:20:28Z<p>Bfritz0815: </p>
<hr />
<div>Hier wird protokolliert, welches Zubehör fehlt (hoffentlich keins), welches Verbrauchsmaterial zur Neige geht und von welchem Verbrauchsmaterial wir schon auf Vorrat nachgekauft haben weil das alte fast leer war.<br />
<br />
Aktuelle Einkaufsliste:<br />
<br />
* 1x Stiffy 1995 15,59€<br />
<br />
Aktuelle Summe: 15,59€<br />
<br />
<br />
[[Kategorie:Textiles]]<br />
[[Kategorie:Wiki_Cleanup/ToDo]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Staging/Homepage_Relaunch&diff=16688Staging/Homepage Relaunch2023-12-12T22:18:25Z<p>Bfritz0815: </p>
<hr />
<div>{{ProjektInfoBox<br />
|name = Homepage Relaunch™ v3<br />
|status = staging<br />
|image = Super-hp.gif<br />
|description = Eine Überarbeitung unserer Homepage<br />
|author = Else<br />
|username = <br />
|version = 0.1337<br />
|update = <br />
|platform = <br />
|license = <br />
|download = [https://github.com/raumzeitlabor/rzl-homepage Github] / [https://new.raumzeitlabor.de Preview]<br />
}}<br />
<br />
Bei Interesse mitzuhelfen, melde dich bei [[Benutzer:Else|Else]]. Vorschläge bitte [[Diskussion:Staging/Homepage Relaunch|hier]].<br />
<br />
== Ausgangssituation ==<br />
<br />
Momentan nutzen wir ein Wordpress, dessen ältere Inhalte tiefpunkt damals von Drupal konvertiert hatte. Die Wordpress-Version ist nicht die neuste, weil wir Debian Pakete nutzen und die automatischen Updates abgeschaltet haben. Manuelles Updaten der Plugins ist jedoch zeitaufwendig, und niemand machts.<br />
<br />
Inhaltlich nutzen wir das Wordpress eigentlich nur für die Blogbeiträge, Kommentare und den Kalender. Zusätzlich gibts noch ein paar statische Webseiten. Wordpress ist eigentlich ziemlich nervig.<br />
<br />
== Vorschlag ==<br />
<br />
Wir migrieren erneut, und diesmal nutzen wir einen Static Blog Generator, der aus Textdateien entsprechende HTML Seiten generiert. Das hat den Vorteil, dass wir keinerlei dynamische Skripts für die Seite benötigen. Für die Kommentare nutzen wir ein selbstgehostetes Kommentarsystem ähnlich [http://disqus.com disqus] (z.B. [http://posativ.org/isso/ isso]). Für den Kalender hingegen laden wir die Events über Javascript aus statischen JSON Dateien, die entsprechend geändert werden.<br />
<br />
Die gesamte Homepage verwalten wir in einem git Repository. Wenn jemand einen Blogbeitrag schreiben möchte, muss er nichts anderes tun als das Repository zu klonen, eine entsprechende Datei anzulegen, und diese zu commiten und zu pushen. Über einen Webhook wird die Webseite dann neu generiert. Das ist alles eigentlich nix neues, und es gibt da schon entsprechende Workflows für.<br />
<br />
=== Kalender ===<br />
<br />
Der Kalender ist nichts anderes als eine statische Webseite mit entsprechendem Javascript. Jeder Monat des Jahres bekommt eine eigene JSON Datei, z.B. 2014-07.json. Zusätzlich gibt es noch jahresunabhängige Dateien für jeden Monat, z.B. 1337-07.json. Dann kann man entweder vor jeden Commit diese Dateien "kompilieren", sodass am Ende eine Datei rausfällt, oder man lässt es einfach so und macht für den Monat zwei (auf den Monat dieses Jahres sowie dem generischen Monat). Das Javascript auf der statischen Kalenderseite lädt die die jeweilige(n) Datei(en) für die jeweilige Monatansicht.<br />
<br />
Eine andere Möglichkeit wäre ein CalDAV mit entsprechendem Backup.<br />
<br />
=== Design ===<br />
<br />
Irgendwas simples, was ein bißchen seriöser als das jetzige aussieht. Am besten Mobile first (und responsive web).<br />
<br />
[[File:rzl-entwurf.png|400px]]<br />
<br />
== Aufgaben ==<br />
<br />
''tbd''<br />
<br />
[[Kategorie:Staging]]<br />
[[Kategorie:Archäologie]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Kategorie:Staging&diff=16687Kategorie:Staging2023-12-12T22:17:30Z<p>Bfritz0815: </p>
<hr />
<div>Hier werden Projektvorschläge dokumentiert.<br />
<br />
''Wenn jemand weiß, wie hier eine Kategorie draus gemacht werden kann, bitte machen. --[[Benutzer:Else|Else]] ([[Benutzer Diskussion:Else|Diskussion]]) 20:44, 2. Jul. 2014 (CEST)''<br />
Done --[[Benutzer:Bfritz0815|Bfritz0815]] ([[Benutzer Diskussion:Bfritz0815|Diskussion]]) 22:17, 12. Dez. 2023 (UTC)<br />
<br />
== Übersicht ==<br />
<br />
* [[Staging/Homepage Relaunch]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Kategorie:Staging&diff=16686Kategorie:Staging2023-12-12T22:17:04Z<p>Bfritz0815: </p>
<hr />
<div>Hier werden Projektvorschläge dokumentiert.<br />
<br />
''Wenn jemand weiß, wie hier eine Kategorie draus gemacht werden kann, bitte machen. --[[Benutzer:Else|Else]] ([[Benutzer Diskussion:Else|Diskussion]]) 20:44, 2. Jul. 2014 (CEST)''<br />
Done --~~<br />
<br />
== Übersicht ==<br />
<br />
* [[Staging/Homepage Relaunch]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Kategorie:Staging&diff=16685Kategorie:Staging2023-12-12T22:16:42Z<p>Bfritz0815: Die Seite wurde neu angelegt: „Hier werden Projektvorschläge dokumentiert. ''Wenn jemand weiß, wie hier eine Kategorie draus gemacht werden kann, bitte machen. --Else (Diskussion) 20:44, 2. Jul. 2014 (CEST)'' == Übersicht == * Staging/Homepage Relaunch“</p>
<hr />
<div>Hier werden Projektvorschläge dokumentiert.<br />
<br />
''Wenn jemand weiß, wie hier eine Kategorie draus gemacht werden kann, bitte machen. --[[Benutzer:Else|Else]] ([[Benutzer Diskussion:Else|Diskussion]]) 20:44, 2. Jul. 2014 (CEST)''<br />
<br />
== Übersicht ==<br />
<br />
* [[Staging/Homepage Relaunch]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Staging&diff=16684Staging2023-12-12T22:16:35Z<p>Bfritz0815: </p>
<hr />
<div>Hier werden Projektvorschläge dokumentiert.<br />
<br />
''Wenn jemand weiß, wie hier eine Kategorie draus gemacht werden kann, bitte machen. --[[Benutzer:Else|Else]] ([[Benutzer Diskussion:Else|Diskussion]]) 20:44, 2. Jul. 2014 (CEST)''<br />
<br />
== Übersicht ==<br />
<br />
* [[Staging/Homepage Relaunch]]<br />
<br />
[[Kategorie:Staging]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=MegaMoodlamp&diff=16683MegaMoodlamp2023-12-12T22:15:31Z<p>Bfritz0815: </p>
<hr />
<div>Schlachtplan: Moodlamp-Board bauen, das $vieles kann. Das ganze variabel halten.<br />
<br />
Was man will:<br />
* Möglichst kleines Board, also SMD<br />
* Steuerbar via I²C, wenn jemand Ethernet/Seriell/RFM12/whatever haben mag, kann er es einfach über I²C anbinden<br />
* CPU: ATtiny26L ? Kann nur 2 HW-PWM-Channels, aber da die CPU nur wenig machen muß (I²C->PWM, geht auch in SW), könnte das gehen.<br />
* Treiber-IC will mann, sofern es welche mit 1A per Channel gibt<br />
<br />
[[Kategorie:Elektronik]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Mate_(Server)/Technische_Doku&diff=16682Mate (Server)/Technische Doku2023-12-12T22:14:12Z<p>Bfritz0815: </p>
<hr />
<div>== Neue Debian-VM ohne GUI, nur mittels shell installieren (serielle console) ==<br />
<br />
Vor der Installation neues, leeres Image anlegen (Images liegen unter '''/srv/vm'''):<br />
<br />
<pre><br />
export VMNAME=foobar<br />
export VMSIZE=20G<br />
export VMMEM=256<br />
export VMOSTYPE=linux<br />
export VMOSVARIANT=debianwheezy<br />
export VMINSTALLER=http://ftp.de.debian.org/debian/dists/wheezy/main/installer-amd64/<br />
</pre><br />
<br />
<pre><br />
fallocate -l $VMSIZE /srv/vm/$VMNAME.img<br />
</pre><br />
<br />
Dann Netzinstallation starten:<br />
<br />
<pre><br />
virt-install --connect qemu:///system --name=$VMNAME --ram=$VMMEM --vcpus=1 \<br />
--disk path=/srv/vm/$VMNAME.img,format=raw,cache=writeback,bus=virtio --os-type $VMOSTYPE \<br />
--os-variant $VMOSVARIANT --network=bridge=br0,model=virtio --nographics \<br />
--location $VMINSTALLER \<br />
--extra-args="console=tty0 console=ttyS0,115200n8" -v<br />
</pre><br />
<br />
== Besondere Einstellungen auf dem Hypervisor ==<br />
<br />
Die Default-Linux-Einstellungen (bzw die von Debian) sind etwas ungünstig für Performance. Folgendes sollte geändert werden:<br />
<br />
* '''Default-Scheduler von cfq auf deadline''' (Kernel-Parameter elevator=deadline <ref name="KER-PAR-01">[http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt#796 Dokumentation zum Kernel-Parameter elevator] </ref> in '''/etc/default/grub''' setzen, danach '''update-grub2''' ausführen)<br />
* '''Hugepages''' erlauben (in '''/etc/rc.local''') <ref name=KVM-TUN-01">[http://sheepdog.taobao.org/people/zituan/kvm_tuning.html#sec-1-2 KVM Memory Tuning]</ref>:<br />
** '''echo 1 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag'''<br />
** '''echo always > /sys/kernel/mm/transparent_hugepage/enabled'''<br />
** '''echo never > /sys/kernel/mm/transparent_hugepage/defrag'''<br />
* Prüfen, ob das Modul '''vhost_net''' geladen ist<br />
<br />
== Besondere Einstellungen auf den virtuellen Maschinen ==<br />
<br />
=== In der Config für die VM ===<br />
* Das '''Platten-Image''' muß '''raw''' und '''pre-allokiert''' sein. qcow2 und dynamische Allokierung ist wirklich langsam.<br />
* Der Modus des Festplatten-Controllers muß '''virtio''' sein (Achtung: Die Platten in den VMs sind dann '''vda, vdb etc''' anstatt '''sda, sdb etc''')<br />
* Das '''Plattenimage''' muß den '''Cache-Modus''' auf '''writeback''' gesetzt haben ('''<driver name='qemu' type='raw' cache='writeback'/>''')<br />
* Der Typ des '''Netzwerkinterfaces''' muß '''virtio''' sein ('''<model type='virtio'/>''')<br />
<br />
=== In der VM selbst ===<br />
* '''Default-Scheduler von cfq auf noop''' (Kernel-Parameter elevator=noop <ref name="KER-PAR-01">[http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt#796 Dokumentation zum Kernel-Parameter elevator] </ref> in '''/etc/default/grub''' setzen, danach '''update-grub2''' ausführen)<br />
* '''Tickless Kernel aktivieren''' (Kernel-Parameter nohz=on <ref name="KER-PAR-02">[http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt#1855 Dokumentation zum Kernel-Parameter nohz] </ref> in '''/etc/default/grub''' setzen, danach '''update-grub2''' ausführen)<br />
* Prüfen, ob die Module '''virtio-blk''' und '''virtio-net''' geladen sind<br />
* Serielle Konsole in '''/etc/inittab''' aktivieren: '''T0:23:respawn:/sbin/getty -L ttyS0 115200 vt102'''<br />
* Serielle Konsole zusätzlich zur normalen Konsole aktivieren (in '''/etc/default/grub'''), wenn man schon dabei ist, kann man auch grub serial beibringen: <pre>GRUB_TERMINAL=serial&#10;GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"</pre> sowie <pre>console=ttyS0,115200n8 console=tty0</pre><br />
<br />
Für die faulen Hunde, wie ich einer bin, hier nochmal der komplette GRUB_CMDLINE-Kram:<br />
<br />
<pre><br />
GRUB_CMDLINE_LINUX_DEFAULT="elevator=noop nohz=on transparent_hugepage=always console=ttyS0,115200n8 console=tty0"<br />
</pre><br />
<br />
<blink>'''DON'T FORGET THE MAGIC update-grub2'''</blink><br />
<br />
== Puppet ==<br />
Um eine VM unter die Kontrolle von Puppet zu bekommen, ist folgendes zu erledigen:<br />
* '''mate.rzl''':/etc/puppet/manifests/nodes.pp: die Node eintragen<br />
* '''<neuevm>.rzl''':<br />
** Puppet installieren<br />
** Deamon Autostart in /etc/default/puppet aktivieren<br />
** puppet agent --test ausführen<br />
* '''mate.rzl''': <pre>#Liste der neuen Zertifikate:&#10;puppet cert list&#10;&#10;#Zertifikat signieren:&#10;puppet cert sign <neuevm.rzl></pre><br />
* '''<neuevm.rzl>''': Nochmal puppet agent --test ausführen<br />
<br />
Wenn alles geklappt hat, so wird puppet zumindest mal alle fehlenden Pakete nachinstallieren.<br />
<br />
== Zabbix ==<br />
<br />
Um eine VM zu monitoren:<br />
<br />
* Ändere in der Datei '''/etc/zabbix/zabbix_agentd.conf''' den Parameter "Server" auf "172.22.36.251" und den Parameter "Hostname" auf den hostnamen inkl. .rzl-Domain<br />
* Füge den Server in Zabbix hinzu (Configuration->Hosts->Create), linke die Templates Template_Linux sowie Template_Puppet_Agent<br />
<br />
== Bacula backups ==<br />
<br />
* Config-Änderungen auf mate:<br />
** in /etc/bacula/clients die jeweilige Config umkopieren und die Namen sowie das Director-Passwort ändern<br />
** die leeren files in /etc/bacula/clients/includes sowie excludes erzeugen<br />
** in /etc/bacula/bacula-dir.conf das neue config file includen<br />
** bacula neustarten<br />
** Das file /etc/puppet/templates/bacula-fd_conf.erb in die VM kopieren und die Variablen ersetzen<br />
<br />
* In der VM:<br />
** /etc/init.d/bacula-fd restart<br />
** prüfen, ob bacula-fd auf 0.0.0.0:9102 lauscht (bei Fehlern lauscht er nur auf localhost)<br />
<br />
Schließlich über bconsole, danach run den entsprechende Job auswählen und testweise laufen lassen.<br />
<br />
== Bacula restores ==<br />
<br />
'''Achtung: Die Anleitung ist nicht optimal. Idealerweise bootet man ein Recovery Image, damit man keine neue VM aufsetzen muß, sondern diese direkt Recovern kann.'''<br />
<br />
Um eine komplette VM wiederherzustellen ohne vorhandenes Disk-Image:<br />
<br />
* Alte VM-Konfiguration sichern! (wegen allen Einstellungen/MAC-Adresse etc)<br />
* Neue, blanke VM mittels virt-install installieren<br />
* Bacula-fd installieren<br />
* Folgende Config in /etc/bacula/bacula-fd.conf legen:<br />
<br />
<pre><br />
Director {<br />
Name = cookiemonster.rzl<br />
Password = "Passwort aus der Client-config auf cookiemonster"<br />
}<br />
<br />
FileDaemon {<br />
Name = <lokaler host, z.b. infra.rzl><br />
FDport = 9102<br />
WorkingDirectory = /var/lib/bacula<br />
Pid Directory = /var/run/bacula<br />
Maximum Concurrent Jobs = 20<br />
}<br />
<br />
Messages {<br />
Name = Standard<br />
director = cookiemonster.rzl = all, !skipped, !restored<br />
}<br />
</pre><br />
* Bacula-fd auf dem Client neu starten<br />
* Restore mittels folgendem Snippet starten: <pre>restore where=/ client=<name, z.b. infra.rzl> replace=always all</pre> Danach die Option "5" drücken und entsprechenden Client auswählen. Beim folgenden Prompt einfach "done" eintippen und den Job starten<br />
* grub2-config neu generieren, da sich die UUIDs geändert haben. update-grub2 unter Debian<br />
* grub-install /dev/vda ausführen<br />
* in /etc/fstab die neuen UUIDs eintragen<br />
* VM runterfahren<br />
* Alte VM-config umkopieren<br />
* VM starten<br />
<br />
== TODO ==<br />
* Automatisches Discovery von VMs in Zabbix?<br />
<br />
== Einzelnachweise ==<br />
<references /><br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]<br />
[[Kategorie:Archäologie]]<br />
[[Kategorie:Infrastruktur]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Mate_(Server)/infra.rzl/Apache2&diff=16681Mate (Server)/infra.rzl/Apache22023-12-12T22:13:49Z<p>Bfritz0815: </p>
<hr />
<div>== Software ==<br />
* [https://github.com/raumzeitlabor/rzl-benutzerdb/tree/master/apache-authenticator|/ mod_perl Authentication Modul]<br />
** authentifiziert BenutzerDB user via Basic-Auth an zB. [[PartKeepr]]<br />
<br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]<br />
[[Kategorie:Infrastruktur]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Lichtsteuerung/Nebenraum&diff=16680Lichtsteuerung/Nebenraum2023-12-12T22:13:10Z<p>Bfritz0815: </p>
<hr />
<div>[[Image:Lichtsteuerung Nebenraum.jpg|600px]]<br />
<br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]<br />
[[Kategorie:Infrastruktur]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Lichtsteuerung/Konzept&diff=16679Lichtsteuerung/Konzept2023-12-12T22:12:45Z<p>Bfritz0815: </p>
<hr />
<div>== Einführung ==<br />
<br />
Die Lichtsteuerung verwendet [[wikipedia:DMX512|DMX]], um die Schaltzustände zu übertragen. Dies ermöglicht es, auch andere Peripherie wie z.b. [[wikipedia:Stage_lighting_instrument#PAR_lights|PAR-Spots]] anzusteuern. DMX sendet kontinuierlich die Werte für alle 512 Kanäle.<br />
<br />
== Schaltzustände ==<br />
<br />
In regulären DMX-Setups gibt es nur einen [[Lichtsteuerung/Controller]], der alle angeschlossenen Geräte steuert. Im Falle der Lichtsteuerung gibt es da aber ein Problem: Was ist, wenn jemand einen Lichtschalter betätigt? Wie bekommt der Controller den Schaltzustand mit?<br />
<br />
Wir verwenden [[wikipedia:RDM_(lighting)|RDM]], um dieses Problem zu umgehen. Mittels RDM können Daten von RDM-fähigen Geräten abgerufen werden.<br />
<br />
Wird ein Schaltzustand von der Lichtsteuerung verändert, z.b. durch einen Taster, so wird dieser Kanal zukünftig von der Lichtsteuerung ignoriert.<br />
<br />
Der Controller frägt den Schaltzustand aktiv mittels DEFAULT_SLOT_VALUE ab, um den aktuellen Wert des Kanals zu erhalten. Die Slotnummern sind 0-31, analog zu den Ausgängen der Lichtsteuerung.<br />
<br />
Erst wenn der empfangene Wert über DMX mit dem internen Wert der Lichtsteuerung übereinstimmt, wird der Kanal nicht mehr ignoriert.<br />
<br />
Hierdurch ist sichergestellt, daß die Lichtsteuerung autark funktioniert, auch wenn der Controller defekt ist.<br />
<br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]<br />
[[Kategorie:Infrastruktur]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Lichtsteuerung/Lichtkreise&diff=16678Lichtsteuerung/Lichtkreise2023-12-12T22:12:34Z<p>Bfritz0815: </p>
<hr />
<div>[[Image:Lichtkreisplan Hauptraum.svg|thumb|300px|Lichtkreisplan Hauptraum]]<br />
* Im Hauptraum gibt es 23 Lichtkreise.<br />
** Ein Lichtkreis an der Decke bezeichnet eine 2-flammige Lampe (derzeit nur ein Leuchtmittel eingesetzt), ansonsten 1-flammig.<br />
** Jede Deckenlampe lässt sich laut dem Lichtkreisplan schalten. Die Deckenleuchten (Lichtkreise 1-16) sind derzeit auf 3 Sektionen (Tafel, Beamer, Lager) zusammengeschlossen.<br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]<br />
[[Kategorie:Infrastruktur]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Lichtsteuerung/Relais&diff=16677Lichtsteuerung/Relais2023-12-12T22:12:22Z<p>Bfritz0815: </p>
<hr />
<div>Die Lichtsteuerung verwendet Omron G2R-1-SNDI 24V <small>([http://www.omron.com/ecb/products/pdf/en-g2r.pdf PDF])</small> Relais. Diese haben eine Freilaufdiode und LED eingebaut und können im Fehlerfalle von Hand bedient werden. Als Sockel kommen Omron P2RF-05-E <small>([http://www.ia.omron.com/data_pdf/data_sheet/p2rf-__-s_dsheet_gwj132-e2-02-x.pdf PDF]) zum Einsatz.<br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]<br />
[[Kategorie:Infrastruktur]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Lichtsteuerung/Client&diff=16676Lichtsteuerung/Client2023-12-12T22:11:36Z<p>Bfritz0815: </p>
<hr />
<div>= Einführung =<br />
<br />
Der Lichtsteuerungsclient sorgt dafür, Schaltwünsche von Benutzern in Lichtzustände umzusetzen. Technisch: DMX- oder Benutzerinput zu Relaisoutput.<br />
<br />
= Features =<br />
[[Image:Lichtsteuerung board top.png|thumb|right|Clientplatine Oberseite]]<br />
[[Image:Lichtsteuerung board bottom.png|thumb|right|Clientplatine Unterseite]]<br />
* DMX/RDM Ein- und Ausgang<br />
* Batteriegestützte Realtime Clock<br />
* 1024KB I²C EEPROM<br />
* 32 Ausgänge<br />
* 16 Eingänge<br />
* RS232<br />
<br />
= Kaskadierung =<br />
<br />
Entgegen des ursprünglichen Plans besitzt der aktuelle Lichtsteuerungsclient nur noch einen Ein/Ausgang, der im Halbduplexmodus genutzt wird. Kaskadierung wird über RS485-Hubs gelöst.<br />
<br />
= Relais schalten und Verkabeln =<br />
<br />
Am Relais liegt +24V an und wird nach GND durch den Relaistreiber durchgeschalten. Der maximale Strom pro Port beträgt 500mA.<br />
<br />
Die Versorgungsspannung der Relais sollte von den Klemmen X1 und X2 abgegriffen werden, da diese jeweils mit einer 200mA Polyfuse gesichert sind. Somit ist gewährleistet, daß der Relaistreiber nicht beschädigt wird.<br />
<br />
Reichen 500mA nicht aus, so darf man laut ULN2803-Datenblatt mehrere Ausgänge parallel schalten, dies wurde aber bisher nicht getestet.<br />
<br />
Die Ausgänge besitzen keine Freilaufdioden. Der Relaistreiber besitzt Dioden, allerdings sollte man Relais verwenden, die eine Freilaufdiode eingebaut haben.<br />
<br />
= Schaltzustände =<br />
<br />
Schaltzustände können über DMX mittels [http://en.wikipedia.org/wiki/RDM_(lighting) RDM] erfragt werden. Inwiefern das Probleme mit existierendem DMX-Equipment gibt, ist bisher unklar; laut Wikipedia soll dies aber keine Probleme verursachen.<br />
<br />
= EEPROM Memory Map (Atmega64, 2K) =<br />
<br />
{| class="wikitable"<br />
|-----<br />
!Adresse!!Länge (Bytes)!!Inhalt<br />
|-<br />
|0x0000||1||Signatur 1 von DMXSerial2<br />
|-<br />
|0x0001||1||Signatur 2 von DMXSerial2<br />
|-<br />
|0x0002||2||DMX-Startaddresse<br />
|-<br />
|0x0004||32||Gerätebezeichnung<br />
|-<br />
|0x0024||6||Geräte-UID<br />
|-<br />
|0x002A||2006||Reserviert für bitlash-Funktionen<br />
|}<br />
<br />
= EEPROM Memory Map (I2C, 1MB) =<br />
<br />
{| class="wikitable"<br />
|-----<br />
!Adresse!!Länge (Bytes)!!Inhalt<br />
|-<br />
|0x00000||1024||Namen der Ausgänge (32x32 Zeichen)<br />
|-<br />
|0x00400||512||Namen der Eingänge (16x32 Zeichen)<br />
|-<br />
|0x00600||16||Modus der Eingänge<br />
|-<br />
|0x00610||32||Private-Flag für die Ausgänge<br />
|-<br />
|0xF000||4096||Backup des Arduino-EEPROMS<br />
<br />
|}<br />
<br />
= Firmware =<br />
<br />
Die Firmware ist generisch gehalten, sodaß die selbe Firmware für Haupt- und Nebenraum eingesetzt werden kann. Die Konfigurationsdaten werden im EEPROM vorgehalten.<br />
<br />
Auf der Lichtsteuerung kommt deshalb [http://bitlash.net/ bitlash] zum Einsatz, welches rudimentäres Scripting ermöglicht. Folgende Funktionen stehen zur Verfügung und können zum Beispiel über die serielle Schnittstelle oder vom PI aus ausgeführt werden:<br />
<br />
== setDeviceName ==<br />
<br />
<pre><br />
setDeviceName("description");<br />
</pre><br />
<br />
Setzt den Namen der Lichtsteuerung. Maximal 32 Zeichen ASCII. Wird im EEPROM abgespeichert. Kann über RDM gesetzt und abgefragt werden (DEVICE_LABEL). Beispiel:<br />
<br />
<pre><br />
setDeviceName("Lichtsteuerung Hauptraum");<br />
</pre><br />
<br />
== getDeviceName ==<br />
<br />
<pre><br />
getDeviceName();<br />
</pre><br />
<br />
Liefert den Namen der Lichtsteuerung. Beispiel:<br />
<br />
<pre><br />
print getDeviceName();<br />
> Lichtsteuerung Hauptraum<br />
</pre><br />
<br />
== getDMXStartAddress ==<br />
<br />
<pre><br />
getDMXStartAddress();<br />
</pre><br />
<br />
Liefert die konfigurierte DMX Startaddresse zurück. Kann über RDM gesetzt und abgefragt werden (DMX_START_ADDRESS). Beispiel:<br />
<br />
<pre><br />
print getDMXStartAddress();<br />
> 32<br />
</pre><br />
<br />
== setDMXStartAddress ==<br />
<br />
Obsolet; DMX-Startaddresse wird nur über RDM gesetzt.<br />
<br />
== getRDMUID ==<br />
<br />
<pre><br />
getRDMUID();<br />
</pre><br />
<br />
Liefert die RDM UID zurück. Beispiel:<br />
<br />
<pre><br />
print getRDMUID();<br />
&gt; 1f13:abde1000<br />
</pre><br />
<br />
== setOutputName ==<br />
<br />
<pre><br />
setOutputName(number, "Description");<br />
</pre><br />
<br />
Gibt dem Ausgang mit <code>number</code> eine Beschreibung, maximal 32 Zeichen, nur ASCII. Wird im EEPROM abgespeichert. Die Beschreibung kann über RDM abgefragt werden. Beispiel:<br />
<br />
<pre><br />
setOutputName(1, "Lichtkreis 1 (Lager)");<br />
</pre><br />
<br />
== getOutputName ==<br />
<br />
<pre><br />
getOutputName(number);<br />
</pre><br />
<br />
Liefert den Namen eines Ausgangs zurück. Beispiel:<br />
<br />
<pre><br />
print getOutputName(1);<br />
> Lichtkreis 1 (Lager)<br />
</pre><br />
<br />
== setOutputState ==<br />
<pre><br />
setOutputState(number, state);<br />
</pre><br />
<br />
Setzt den Ausgang <code>number</code> auf den Zustand 0 (aus) oder 1 (an). Beispiel:<br />
<br />
<pre><br />
setOutputState(10, 1);<br />
</pre><br />
<br />
== getOutputState ==<br />
<pre><br />
getOutputState(number);<br />
</pre><br />
<br />
Gibt den Zustand des Ausgangs <code>number</code> zurück.<br />
<br />
Beispiel:<br />
<br />
<pre><br />
print getOutputState(10);<br />
> 1<br />
</pre><br />
<br />
== toggleOutputState ==<br />
<pre><br />
toggleOutputState(number);<br />
</pre><br />
<br />
Toggelt den Zustand des Ausgangs <code>number</code>.<br />
<br />
Beispiel:<br />
<pre><br />
toggleOutputState(1);<br />
print getOutputState(1);<br />
> 1<br />
toggleOutputState(1);<br />
print getOutputState(1);<br />
> 0<br />
</pre><br />
== setInputName ==<br />
<br />
<pre><br />
setInputName(number, "Description");<br />
</pre><br />
<br />
Gibt dem Eingang mit <code>number</code> eine Beschreibung, maximal 32 Zeichen, nur ASCII. Wird im EEPROM abgespeichert. Beispiel:<br />
<br />
<pre><br />
setInputName(1, "Lichtschalter Tuer Lager");<br />
</pre><br />
<br />
<br />
== setPrivateFlag ==<br />
<br />
<pre><br />
setPrivateFlag(port,private)<br />
</pre><br />
<br />
Setzt das "private" flag für einen Ausgang. "private" bedeutet, daß der Port nicht für den Endbenutzer sichtbar sein soll - dies ist für Ports nützlich, die eine Sonderfunktion haben, z.b. ein Warnsignal, welches vor einem Shutdown des Nebenraumes warnt.<br />
<br />
Beispiel:<br />
<br />
<pre><br />
setPrivateFlag(1,1);<br />
</pre><br />
<br />
Dies setzt den Ausgang 1 auf "private".<br />
== getInputName ==<br />
<br />
<pre><br />
getInputName(number);<br />
</pre><br />
<br />
Gibt den Namen des Eingangs zurück. Beispiel:<br />
<br />
<pre><br />
print getInputName(1);<br />
> Lichtschalter Tuer Lager<br />
</pre><br />
<br />
== setInputMode ==<br />
<br />
<pre><br />
setInputMode(number, mode);<br />
</pre><br />
<br />
Setzt den Modus des Eingangs. Wird im EEPROM abgespeichert. Folgende Modis sind definiert:<br />
<br />
<pre><br />
MODE_TOGGLE: Wechselschalter<br />
MODE_MOMENTARY: Taster<br />
</pre><br />
<br />
Beispiel:<br />
<pre><br />
setInputMode(1, "MODE_MOMENTARY");<br />
</pre><br />
<br />
== getInputMode ==<br />
<br />
<pre><br />
getInputMode(number);<br />
</pre><br />
<br />
Liefert den Modus des Eingangs.<br />
<br />
Beispiel:<br />
<br />
<pre><br />
print getInputMode(1);<br />
> MODE_MOMENTARY<br />
</pre><br />
<br />
== listOutputs ==<br />
<br />
<pre><br />
listOutputs();<br />
</pre><br />
<br />
Gibt alle Ausgänge inklusive der Namen auf dem Terminal zurück. Beispiel:<br />
<br />
<pre><br />
listOutputs();<br />
> #1: Lichtkreis 1 (Lager)<br />
> #2: Lichtkreis 2 (Lager)<br />
> #3: Lichtkreis 3 (Lager)<br />
> ...<br />
> #32: Nicht belegt<br />
</pre><br />
<br />
== listInputs ==<br />
<br />
<pre><br />
listInputs();<br />
</pre><br />
<br />
Gibt alle Ausgänge inklusive der Namen und des Modus auf dem Terminal zurück. Beispiel:<br />
<br />
<pre><br />
listInputs();<br />
> #1: Lichtschalter Tuer (Lager) [MODE_TOGGLE]<br />
> #2: Lichtschalter Tuer (Beamer) [MODE_TOGGLE]<br />
> #3: Lichtschalter Tuer (Tafel) [MODE_TOGGLE]<br />
> #4: Lichtschalter Tuer (Kueche) [MODE_TOGGLE]<br />
> ...<br />
> #16: Nicht belegt [MODE_TOGGLE]<br />
</pre><br />
<br />
== anyOutputOn ==<br />
<br />
<pre><br />
anyOutputOn (number[,number,...]);<br />
</pre><br />
<br />
Gibt zurück, ob ein Eingang in der Range eingeschalten ist. Beispiel:<br />
<br />
<pre><br />
anyOutputOn(1,2,3,4,5,6);<br />
> 0<br />
</pre><br />
<br />
== onInputOn, onInputOff==<br />
<br />
<pre><br />
function onInputNOff {}<br />
function onInputNOn {}<br />
function onInputN {}<br />
</pre><br />
<br />
onInputN wird aufgerufen, wenn sich der logische Zustand des Eingangs ändert. Bei einem Taster ist dies analog zu einem kurzen Tasterdruck. N wird dabei durch den entsprechenden Eingang ersetzt.<br />
<br />
onInputNOff wird aufgerufen, wenn sich der logische Zustand des Eingangs auf 0 ändert.<br />
onInputNOn wird aufgerufen, wenn sich der logische Zustand des Eingangs auf 1 ändert.<br />
<br />
Beispiel: Prüft, ob einer der Lichtkreise der Tafel an ist. Wenn ja, schalte alle Lichtkreise der Tafel aus. Wenn nein, schalte alle Lichtkreise der Tafel an.<br />
<br />
<pre><br />
function onInput1 { z=anyOutputOn(5,6,7,11,12,13); setOutputState(5, !z); setOutputState(6, !z);<br />
setOutputState(7, !z); setOutputState(11, !z); setOutputState(12, !z); setOutputState(13, !z);}<br />
</pre><br />
<br />
Kurzform:<br />
<br />
<pre><br />
function onInput1 { z=aoo(5,6,7,11,12,13); sos(5, !z); sos(6, !z);sos(7, !z); sos(11, !z); sos(12, !z); sos(13, !z);}<br />
</pre><br />
<br />
= Tests des Prototypboards =<br />
<br />
{{TaskListStart}}<br />
{{TaskListItem<br />
| title = Relais-Ausgänge<br />
| description = <br />
| status = done<br />
| last_changed = <br />
}}<br />
{{TaskListItem<br />
| title = DS1307 RTC<br />
| description = <br />
| status = done<br />
| last_changed = <br />
}}<br />
{{TaskListItem<br />
| title = 24FC1024 I²C EEPROM<br />
| description = <br />
| status = done<br />
| last_changed = <br />
}}<br />
{{TaskListItem<br />
| title = Eingänge<br />
| description = <br />
| status = done<br />
| last_changed = <br />
}}<br />
{{TaskListItem<br />
| title = DMX IN<br />
| description = <br />
| status = done<br />
| last_changed = <br />
}}<br />
{{TaskListItem<br />
| title = DMX OUT<br />
| description = <br />
| status = done<br />
| last_changed = <br />
}}<br />
{{TaskListEnd}}<br />
<br />
[[Kategorie:Infrastruktur]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Lichtsteuerung/Beleuchtungsst%C3%A4rken&diff=16675Lichtsteuerung/Beleuchtungsstärken2023-12-12T22:07:44Z<p>Bfritz0815: </p>
<hr />
<div>Beleuchtungsstärken, gemessen im Juni '15:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Ort !! Lux<br />
|-<br />
| Tafel || 315<br />
|-<br />
| Ä-Ecke || 300<br />
|-<br />
| E-Ecke Arbeitsplatz || 850<br />
|-<br />
| Workshopraum || 330<br />
|-<br />
| Werkstatt || 510<br />
|-<br />
| Fablab || 110<br />
|}<br />
<br />
<br />
[[Kategorie:Archäologie]]<br />
[[Kategorie:Wiki_Cleanup/ToDo]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Lichtsteuerung/Alt&diff=16674Lichtsteuerung/Alt2023-12-12T22:05:16Z<p>Bfritz0815: </p>
<hr />
<div><br />
== Warum? ==<br />
<br />
* Es gibt im Moment nur 2 Zustände pro Bereich: An und aus (oder auch: 350W oder 0W). Oftmals ist im Lagerbereich z.b. nur eine Leuchtstoffröhre nötig.<br />
* Der Helligkeitsunterschied zwischen Deckenbeleuchtung und den Stehlampen ist zu groß - ein Mittelding fehlt<br />
* Ist der Nebenraum fertig, so muß man jeden Raum überprüfen, ob dort noch Licht brennt. Dies kann mit der Lichtsteuerung (MasterPowerOff) gelöst werden.<br />
* Unfallvermeidung (stell dir vor, du sitzt im Olymp, und es wird dunkel. Du mußt erst den Olymp verlassen, um das Licht anzuschalten -> Treppe runterfallen = aua. Mit der Lichtsteuerung könnte das übers LAN gehen).<br />
<br />
[[Image:Lichtkreisplan Hauptraum.svg|thumb|300px|Lichtkreisplan Hauptraum]]<br />
== Dinge aka Facts ==<br />
* Im Hauptraum gibt es 23 Lichtkreise.<br />
** Ein Lichtkreis an der Decke bezeichnet eine 2-flammige Lampe (derzeit nur ein Leuchtmittel eingesetzt), ansonsten 1-flammig.<br />
** Jede Deckenlampe lässt sich laut dem Lichtkreisplan schalten. Die Deckenleuchten (Lichtkreise 1-16) sind derzeit auf 3 Sektionen (Tafel, Beamer, Lager) zusammengeschlossen.<br />
** Mehr Granularität -> bessere Anpassung an den jeweiligen Bedarf -> niedrigerer Stromverbrauch.<br />
* Im Nebenraum gibt es 3 Lichtkreise, einen pro Raum<br />
* Eine Deckenröhre benötigt 58 Watt. Das bedeutet 348 Watt für die Tafel- und Beamerwandsektion und 232 Watt für das Lager. In der Küche sind 2x36 Watt-Leuchten verbaut, in der E-Ecke/Ä-Ecke sind es wieder 58 Watt.<br />
* Nebenraum bisher unbekannt.<br />
* Alle Lichter sollen im Haupt+Nebenraum ausgeschalten werden können, wenn der letzte geht.<br />
* Es soll dunkel/mittel/hell pro Bereich möglich sein, in dem in einer Sektion eben nur 1/3, 2/3 oder 3/3 der Lampen geschalten wird<br />
* Die Verkabelung der Lampen wurde bereits beim Einbau darauf ausgelegt<br />
* Auf dem Konferenztisch werden etwa 430 Lux erreicht, was schon ziemlich gut ist (wenn eine Sektion voll geschalten ist).<br />
<br />
== Implementierung ==<br />
<br />
* Alles, was gemacht wird, muß dokumentiert werden!<br />
* Die Lichtkreise werden über Relais gesteuert (siehe unten).<br />
* Die vorhandenen Schalter werden (teilweise) über Koppelrelais an den µC als Eingang geschalten<br />
* Der µC schaltet anhand der Schalterstellungen (Wechselschalter), ein Lichttableau oder über externe Steuersignale (z.B. Hausbus) die Relais<br />
* Der µC soll vom DMX-Bus abgekoppelt werden können, um notfalls manuell Problemen aus dem Weg zu gehen (Spielkinder, böse Hackerangriffe, rumspinnende DMX-Apps etc).<br />
* Es sind ggf. minimale Schaltzeiten zu beachten<br />
* Der µC soll speichern, wie lange jeder Lichtkreis aktiv war. Somit kann man die Einsparung berechnen und Statistiken sind eh super.<br />
[[Image:Lichtsteuerung Overview.svg]]<br />
<br />
== Kosten ==<br />
<br />
Eine Lichtsteuerung für Haupt- und Nebenraum sollte für unter 500€ machbar sein.<br />
<br />
* Pro Lichtkreis Reichelt FIN 95.95.3 (2,65€ pro Stück) plus Reichelt 40.51.9 12V (1,75€ pro Stück) -oder-<br />
* Pro Lichtkreis G2R-1-SNI 12V DC (3,50€ pro Stück laut Liste, evtl billiger) plus P2RF-05-E (2,20€ pro Stück laut Liste, evtl billiger). Diese haben manuelle Steuerung und Aktiv-LED.<br />
* Gehäuse Hensel KV 9440, ca. 130€<br />
* Netzteil für 24V, Hutschine, ca. 20€<br />
* DC-DC-Wandler von 24V auf 5V für das ControllerBoard, ca. 5 Euro<br />
* Einen µC, ein bisschen Holz für das Lichttableau, ein paar LEDs und Relaistreiber (z.B. ULN 2803A, UDN2981 )<br />
<br />
<br />
{| class="wikitable"<br />
|-----<br />
! Pos || Bezeichnung || Anmerkungen || Stück || E-Preis || G-Preis<br />
|-<br />
| 1 || G2R-1-SNDI 24V DC || Relais || 23 (Hauptraum) + 6 (Nebenraum) = 29 || 6,09€ || 176,69€<br />
|-<br />
| 2 || P2RF-05-E || Relaissockel || 29 || 3,10€ || 90 €<br />
|-<br />
| 3 || 4-reihiger Aufputzverteiler || Gehäuse || 3 || 60€ || 180 €<br />
|-<br />
| 4 || Netzteil 24V || für Hutschine || 2 || 20€ || 40€<br />
|-<br />
| 5 || DC-DC-Wandler 24V -> 5V || || 2 || 5€ || 10€<br />
|-<br />
| 6 || Koppelrelais || für Lichtschalter || 12 || 5,5€ || 66€<br />
|-<br />
| 7 || Bauelemente || ICs, Platinenmaterial, Schieberegister, Relaistreiber || 1 || 40€ || 40€<br />
|-<br />
!colspan=5 |Gesamt|| 602,69€<br />
|}<br />
<br />
== Controllerboard ==<br />
<br />
* Atmel-Irgendwas auf Platine mit Relaistreibern und Verbindung zum Lichttableau (DaFo schlägt DMX vor wegen Leitungslänge und co).<br />
* 11x 74AHC595 Schieberegister (serial in, parallel out) steuern die 10x ULN 2803A Treiber an.<br />
* Gehäuse http://www.phoenixcontact.com/global/pcb-connection/224_35923.htm entweder OT U11 oder OT U22, geeignet für Doppelstockklemmen<br />
<br />
== Ausgangsstufe ==<br />
<br />
* mit 30 Ports<br />
* LED-Status pro Port<br />
* Hutschinengehäuse<br />
* Enthält Schieberegister und Relaistreiber, Kaskadierbar<br />
* Eingänge: +5V, +12V, GND, Data In, Shift, Latch, Clear<br />
* Ausgänge: 30x Relaisausgänge (eigentlich Eingänge, da gegen GND geschalten wird), Data Out<br />
<br />
Kleines Diagramm: https://docs.google.com/drawings/d/10NOeBbUY8iZKpfekg_nUPKMvijKwDq1PlwwYthOxCoY/edit<br />
<br />
<br />
Kosten pro Ausgangsstufe 30 Port (ca-Preis):<br />
<br />
* Gehäuse BOPLA CN 100AK (6,85€)<br />
* Schieberegister und Relaistreiber: ca. 2 €<br />
* LED Quadratisch 5mm für Statusanzeige: 3€ (Reichelt V 532)<br />
* Klemmen (passend für Bopla-Gehäuse, RM5): 6x AKL 320-05 und 2x AKL 320-04 (die eigentlichen Klemmen hat Felicitus noch massenhaft vorrätig)<br />
* Platine ca. 2 €<br />
<br />
Kosten pro Ausgangsstufe: ca. 20€<br />
<br />
== USB-to-DMX ==<br />
<br />
* Günstiger Selbstbau unter http://orikson.piranho.de/pa/uDMX/ inkl Galvanischer Trennung<br />
<br />
= Aktuelle Version =<br />
<br />
== Features ==<br />
* 32 Relais-Ausgänge (gesinkt). 500mA maximum pro 8 Kanäle (die von uns eingesetzten Relais ziehen 21.6mA bei 24V)<br />
* 16 isolierte Digitaleingänge für Lichtschalter o.ä. über Koppelrelais - 24V<br />
* RTC mit Batteriepuffer<br />
* I²C-Schnittstelle<br />
* DMX-Eingang mit Startaddressenkonfiguration via DIP-Switch<br />
* 128kB EEPROM für Ein- und Ausschalterfassung<br />
<br />
=== Bauteile ===<br />
<br />
Herz der Lichtsteuerung ist ein Atmega 64-16 TQ mit 64k Flash, 53 I/O Pins, 2k EEPROM und 4kB RAM. Der Controller ist bewusst überdimensioniert, um für zukünftige Erweiterungen genügend Spielraum zu haben.<br />
<br />
Über den DMX-Eingang sowie die Digitaleingänge wird der Schaltzustand der Ausgänge definiert. Da DMX permanent Daten schickt, würden die Digitaleingänge überschrieben werden, von daher gilt folgende Logik:<br />
<br />
* Ein Logikwechsel durch den Eingang bewirkt das togglen der betreffenden Ausgänge<br />
* Nur ein Logikwechsel auf dem DMX-Input setzt den entsprechende Ausgang. Wird derselbe Zustand erneut empfangen, so wird nichts geändert!<br />
<br />
Ein Atmega8 kümmert sich um das fortlaufende Senden von DMX-Daten, um weitere Lichtsteuerungen oder DMX-Endgeräte ansteuern zu können. Dieser ist über I²C an den Atmega64 angeschlossen.<br />
<br />
===== EEPROM-Konfiguration =====<br />
<br />
Die folgenden Konfigurationsdaten werden auf dem EEPROM des Atmega 64 abgelegt:<br />
<br />
* welcher Digitaleingang welche Ausgänge beeinflusst<br />
* ob die Eingänge tastend oder schaltend sind<br />
<br />
Die Konfigurationsdaten sollen über den RS232-Port verändert werden können.<br />
<br />
== Siehe auch ==<br />
<br />
[https://github.com/raumzeitlabor/lichtsteuerung Github]<br />
<br />
[[Kategorie:Archäologie]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Diskussion:Everdrive64&diff=16673Diskussion:Everdrive642023-12-12T22:02:25Z<p>Bfritz0815: Die Seite wurde neu angelegt: „* Gibts das noch? * Isses in der Retro Lounge aufgestellt? * Gibts davon ein Photo? * Gibts dazu neuere Infos (vielleicht die dort verfügbaren games)? --~~~~“</p>
<hr />
<div>* Gibts das noch?<br />
* Isses in der Retro Lounge aufgestellt?<br />
* Gibts davon ein Photo?<br />
* Gibts dazu neuere Infos (vielleicht die dort verfügbaren games)?<br />
--[[Benutzer:Bfritz0815|Bfritz0815]] ([[Benutzer Diskussion:Bfritz0815|Diskussion]]) 22:02, 12. Dez. 2023 (UTC)</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Everdrive64&diff=16672Everdrive642023-12-12T22:01:06Z<p>Bfritz0815: </p>
<hr />
<div>Wir haben für das RZL einen Everdrive64 bestellt:<br />
http://www.gp2x.de/shop/product_info.php/cPath/48/products_id/180<br />
''Note: We don't support ILLEGAL COPIES - don't do that as well!<br />
Only use these modules to play legal BACKUP copies of games you own or for homebrew games!''<br />
<br />
* thinkJD: 10 € (bezahlt)<br />
* silsha: 20 € (bezahlt)<br />
* else: 20 € (bezahlt)<br />
* mxf: 20 € (bezahlt)<br />
* sECuRE: 20 € (bezahlt)<br />
* muzy: 5 € (bezahlt)<br />
* pennylane: 25 € (bezahlt)<br />
<br />
= Status =<br />
<br />
Das Modul ist angekommen und funktioniert, wird am 2012-05-11 ins RZL gebracht. Eine 8 GB-SD-Karte von sECuRE ist eingesteckt.<br />
<br />
= Bedienung =<br />
<br />
Am Anfang wählt man via Richtungskreuz (links) das Spiel aus und lädt mit Start. Sofern statt der Spielauswahl eine Fehlermeldung kommt, die besagt, dass er das OS nicht finden kann, einfach nochmal neu starten. Manchmal scheint er die SD-Karte nicht richtig zu erkennen.<br />
<br />
= Save Games =<br />
<br />
Bisher unklar, wie das funktioniert. Mit L/R kann man vor dem Spielstart beeinflussen, wie das save game-handling läuft. Aber bei "force sram" hat das Spiel hinterher den State verloren und auf der SD-Karte finde ich keine neuen Dateien.<br />
<br />
[[Kategorie:RetroLounge]]<br />
[[Kategorie:Gerät]]<br />
[[Kategorie:Hardware]]<br />
[[Kategorie:Wiki_Cleanup/ToDo]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Diskussion:Reichelt/2012-05-07&diff=16671Diskussion:Reichelt/2012-05-072023-12-12T21:59:18Z<p>Bfritz0815: Die Seite wurde neu angelegt: „Brauchen wir ne alte Einkaufsliste noch? --~~~~“</p>
<hr />
<div>Brauchen wir ne alte Einkaufsliste noch? --[[Benutzer:Bfritz0815|Bfritz0815]] ([[Benutzer Diskussion:Bfritz0815|Diskussion]]) 21:59, 12. Dez. 2023 (UTC)</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Reichelt/2012-05-07&diff=16670Reichelt/2012-05-072023-12-12T21:58:55Z<p>Bfritz0815: </p>
<hr />
<div>Bitte den Warenkorb exportieren, damit man das später einfach importieren kann.<br />
<br />
== sECuRE benötigt ==<br />
<br />
<pre><br />
HIROSE CAT6 BL;10<br />
AVK 119Q-25;1<br />
LOGILINK UA0095;1<br />
PATCH-DW6 5 BL;1<br />
LED 5 RG-3;2<br />
LED 5MM 5V GN;1<br />
</pre><br />
<br />
== cradle benötigt ==<br />
<pre><br />
FUNK 470N;2<br />
</pre><br />
<br />
== pennylane benötigt ==<br />
<br />
<pre><br />
AK 673-A;2<br />
AK 93352;1<br />
WIHA 302-HK6;1<br />
COMPUTER WZ KIT;1<br />
</pre><br />
<br />
== Felicitus benötigt ==<br />
<br />
<pre><br />
MM SL 12SK;4<br />
MM FL 12G;4<br />
LF 412 CP;6<br />
SIL 5-4 1,0K;1<br />
</pre><br />
<br />
== Else benötigt ==<br />
<br />
<pre><br />
LED 1206-420 RT;1<br />
X7R-G1206 22N;10<br />
X7R-G1206 100N;10<br />
CR 2032;2<br />
</pre><br />
<br />
== mdb benötigt ==<br />
<br />
<pre><br />
KAB HA 08-10;1<br />
PATCH-C6 2 BL;1<br />
</pre><br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Intel_Leibniz_Challenge&diff=16669Intel Leibniz Challenge2023-12-12T21:58:11Z<p>Bfritz0815: </p>
<hr />
<div>*Mail von [[Benutzer:Rami|rami]] vom 04.02.2012:<br />
<blockquote><br />
In zwei Tagen geht die Intel Leibniz Challenge 2012 los, ein Wettbewerb zu Informatik und Elektrozeug für alle Schüler in der 9.-13. Klasse. Teilnehmen kann man nur als Team aus 3-5 Schülern. Ich wäre interessiert, es zumindest mal zu versuchen und die Aufgaben anzuschauen, ob sich das lohnt. Ich hab aber kein Team. Du hast Lust? Super, meld dich bei mir!<br><br><br />
Mehr Infos gibts auf der leider recht unübersichtlichen Website: http://www.intel-leibniz-challenge.de/<br />
</blockquote><br />
<br />
*Status 05.02.2012: In Kooperation mit DasLabor'lern haben wir eine Gruppe gestartet, vielleicht wirds ja was!<br />
<br />
== Teilnehmer ==<br />
* [[Benutzer:Rami|rami]]<br />
* Robin ([[Benutzer:dj2mc|dj2mc]])<br />
* [[Benutzer:blafoo|blafoo]] (Das Labor)<br />
<br />
== Details ==<br />
Gruppe: „Das Labor“ im ILC-System :)<br />
<br />
[[Kategorie:Veranstaltung]]<br />
[[Kategorie:Archäologie]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Diskussion:20161102_-_RFC-Docker&diff=16668Diskussion:20161102 - RFC-Docker2023-12-12T21:57:16Z<p>Bfritz0815: Die Seite wurde neu angelegt: „is this page even still needed for anything? --~~~~“</p>
<hr />
<div>is this page even still needed for anything? --[[Benutzer:Bfritz0815|Bfritz0815]] ([[Benutzer Diskussion:Bfritz0815|Diskussion]]) 21:57, 12. Dez. 2023 (UTC)</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=20161102_-_RFC-Docker&diff=1666720161102 - RFC-Docker2023-12-12T21:56:56Z<p>Bfritz0815: </p>
<hr />
<div>Die Diskussion im NOC-Team hat wohl gezeigt: Docker ist doof fürs NOC, wir machen Ansible. Gut und Schön aber: "Mal eben nen Service hochziehen" (Infoscreen usw.) der keinen relevanten State braucht - bzw. seinen state auf einen zentralen, vom NOC verwalteten, DB-Host bzw. Object-Storage speichert ist einfach mit docker wesentlich einfacher für eine Organisation wie einen Hackerspace wo vielleicht nicht jeder Root auf den Servern ist und wir ja offensichtlich nicht für jeden Member ne vm machen können (Meine Anfrage für ne VM ist seit Januar pending)<br />
<br />
Also folgender Vorschlag:<br />
# Das NOC betreibt eine VM als dockerhost (beispielsweise RancherOS oder CoreOS) (Hostnahme "rzlocker")<br />
# Es gibt ein zentrales github-Repo von dem der rzlocker seine dockerfiles pulled, baut und deployed.<br />
# Dort liegt ein Template-File das verwendet werden muss<br />
# $member forkt das Repo baut aus dem Template sein Dockerfile zusammen, mach einen PR.<br />
# PR wird nach review gemerged --> goto 2.<br />
<br />
** Q: Aber dann haben wir immer noch alte Baseimages ohne security-fixes!!!<br />
** A: Wir legen im Template fest, dass nur official-base-images mit release-tag verwendet werden dürfen. Die werden jeweils kurzfristig vom distibution-team selbst geupdated (s. https://hub.docker.com/explore/). durch das Flag `--pull` zieht sich der docker-prozess beim bauen des containers jeweils ein akutelles base-image. Jetzt noch ein systemd-service, der um 03:00 alle kontainer neu baut - fertig.<br />
<br />
** Q: Und nach sechs Monaten haben wir 1000 docker-container laufen von denen niemand weiß was sie tun...<br />
** A: Durch unser github-repo sieht jeder, jederzeit was läuft. Unser PR-Template enthält ferner Dinge wie "was tut es und warum" und "welche Ports braucht es und warum"<br />
<br />
** Q: Jetzt weiß zwar jeder was läuft und warum und die base ist atkuell aber trotzdem wird da ein Zoo wachsen.<br />
** A: Wir könnten einfach(tm) ein Verfallsdatum für die Container definieren. À la: Service läuft einmal täglich und checkt: Letzte Änderung am dockerfile ist älter als $monate? --> Nachricht an Maintainer: "Mach was damit oder ich schmeiß das Ding in $tagen weg!!"<br />
<br />
[[Kategorie:Wiki_Cleanup/ToDo]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Ubuntu_Developer_Week&diff=16666Ubuntu Developer Week2023-12-12T21:55:13Z<p>Bfritz0815: </p>
<hr />
<div>Die [https://wiki.ubuntu.com/UbuntuDeveloperWeek Ubuntu Developer Week] ist eine dreitägige Veranstaltung der Firma Canonical, die hinter der Linux-Distribution [http://www.ubuntu.com Ubuntu] steckt. Die UDW findet regelmäßig statt und wird im IRC mit gestreamten Vorträgen abgehalten.<br />
<br />
== Teilnehmen ==<br />
<br />
Der Chatchannel ist [http://webchat.freenode.net/?channels=ubuntu-classroom%2Cubuntu-classroom-chat #ubuntu-classroom/Freenode]. Einen einfachen Einstieg gibt es mit dem Programm [https://wiki.ubuntu.com/Lernid Lernid], mit dem man z.B. auch die Folien in RealTime anschauen kann.<br />
<br />
== Sessions ==<br />
<br />
Die verfügbaren Sessions finden sich auf [https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions dieser Seite] mit einer Kurzinfo. Das Who-Attends-Who findet sich hier (Bitte beachten: Die angegebenen Zeiten sind UTC!):<br />
<br />
{| class="wikitable"<br />
!Datum<br />
!Uhrzeit (UTC)<br />
!Titel<br />
!Raumzeitlaboranten<br />
|-<br />
|31.01.<br />
|20:00<br />
|Automated Testing and Jenkins (Continuous Integration)<br />
|[[Benutzer:eeemsi|eeemsi]], [[Benutzer:TheTinyToon|TheTinyToon]]<br />
|-<br />
|01.02.<br />
|17:00<br />
|Charming Juju (Cloud-Verwaltung a la Ubuntu)<br />
|[[Benutzer:eeemsi|eeemsi]], [[Benutzer:TheTinyToon|TheTinyToon]]<br />
|-<br />
|01.02.<br />
|19:00<br />
|Ubuntu Distributed Development (Weltweite Entwicklung coordinieren)<br />
|[[Benutzer:eeemsi|eeemsi]], [[Benutzer:TheTinyToon|TheTinyToon]]<br />
|-<br />
|02.02.<br />
|18:30<br />
|Pair Programming and Code Review in the Cloud<br />
|[[Benutzer:eeemsi|eeemsi]], [[Benutzer:TheTinyToon|TheTinyToon]]<br />
|-<br />
|}<br />
<br />
[[Kategorie:Veranstaltung]]<br />
[[Kategorie:Archäologie]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=KrachBummLabor&diff=16665KrachBummLabor2023-12-12T21:53:50Z<p>Bfritz0815: </p>
<hr />
<div>{{ProjektInfoBox<br />
|name = KrachBummLabor (Mk II)<br />
|status = in storage<br />
|image = <br />
|description = Digitale und Analoge Klangerzeugung<br />
|author = [[Benutzer:slowpoke|slowpoke]], [[Benutzer:lutoma|lutoma]], [[Benutzer:Yocky|yocky]], jede*r Interessierte<br />
|maintainer = [[Benutzer:slowpoke|slowpoke]], [[Benutzer:lutoma|lutoma]], [[Benutzer:Yocky|yocky]]<br />
|user =<br />
|owner =<br />
|location = Auf dem Olymp, in der Ecke über der Küche<br />
|version = <br />
|update = <br />
|platform = <br />
|hostname =<br />
|license = <br />
|download = <br />
|bausatz =<br />
|preis =<br />
}}<br />
<br />
Das '''KrachBummLabor (Mk II)''' bietet Interessierten die Möglichkeit, sich mit digitaler und analoger Klangerzeugung zu beschäftigen. Zu diesem Zweck sind dort diverse Gerätschaften und Instrumente verbaut bzw verfügbar.<br />
Aktuell (2020) befindet sich der [[Olymp]] im Umbau, das KrachBummLabor wird danach wieder in Betrieb genommen.<br />
<br />
== History ==<br />
<br />
Das erste KrachBummLabor (welches wir jetzt als ''Mk I'' bezeichnen) wurde seinerzeit von [[Benutzer:Felicitus|Felicitus]] und [[Benutzer:Tiefpunkt|Tiefpunkt]] aufgebaut. Die alte Wikiseite ist als [[KrachBummLabor/Mk I]] erhalten.<br />
<br />
== Equipment ==<br />
<br />
Dem KrachBummLabor stehen diverse Instrumente, Geräte, und Verbindungselemente zur Verfügung:<br />
<br />
* [[#Mischpult|analoges 16-Kanal Mischpult]] (Yamaha MG 166C-USB)<br />
* analoger Modularsynth, made by [[Benutzer:Felicitus|Felicitus]]<br />
* kleines MIDI-Keyboard<br />
* ein Atari 1040 STFM mit Bildschirm, Festplatte und Software (s.u.) zum Aufnehmen, Abspielen, Sequencen und Bearbeiten von MIDI<br />
* eine E-Gitarre (Dauerleihgabe von [https://twitter.com/junaimnetz @junaimnetz])<br />
* ein Epiphone Thunderbird E-Bass plus 20W Verstärker mit Effekten (gehört [[Benutzer:slowpoke|slowpoke]], bitte nur nach Einweisung verwenden)<br />
* diverse Kabel<br />
<br />
Desweiteren existiert im RaumZeitLabor weiteres Equipment, dass für das KrachBummLabor interessant ist, aber nicht fest dort verbaut ist. Das meiste davon ist in der [[Elektroecke|E-Ecke]] zu finden:<br />
<br />
* diverse digitale und analoge [[Elektroecke/Geräte#Messtechnik|Oszilloskope]]<br />
* ein 2-Kanal arbiträrer [[Frequenzgenerator|Funktionsgenerator]]<br />
<br />
== Benutzung ==<br />
<br />
Das KrachBummLabor kann und darf grundsätzlich von jeder befähigten und interessierten Person benutzt werden, es gibt dabei nur ein paar wenige Dinge zu beachten. Am besten lässt du dir aber eine kurze Einweisung geben, dazu fragst du einfach eine der Personen, die oben in der ProjektInfoBox als Author*innen gelistet sind. Alternativ kannst du natürlich auch im IRC-Channel oder auf der Mailingliste fragen, ob dir irgendwer mal ins KrachBummLabor einweist.<br />
<br />
Ansonsten sind deiner Fantasie natürlich nur technische Grenzen gesetzt. Achte aber bitte auf folgende Dinge:<br />
<br />
=== Einschalten ===<br />
<br />
Derzeit hängt das KrachBummLabor noch an mehreren Steckdosen, die eingeschaltet werden müssen. Das wird sich in naher Zukunft noch ändern. Derzeit muss die Steckdosenleiste rechts neben dem Mischpult sowie die, die unter dem Tisch montiert ist, angeschaltet werden. Achte dabei darauf, dass die Aktivbox rechts auf dem Tisch ausgeschaltet bzw komplett runtergedreht ist. Der Modularsynth wird mit dem grossen roten Sicherheitsschalter an der linken Seite angeschaltet.<br />
<br />
=== Handhabung ===<br />
<br />
* Bitte iss nicht in der Nähe des KrachBummLabors, besonders nichts krümmeliges. <br />
* Sei vorsichtig mit Getränken, und stell keine Tassen oder Trinkflaschen - schon gar keine offenen - auf den Tisch, den Synth, oder sonstwohin.<br />
* Behandle das Equipment sorgsam. Einiges davon ist teuer und/oder unersetzbar.<br />
* Geh anderen Menschen im Raum nicht auf die Nerven. Benutze wenn nötig Kopfhörer, das Mischpult hat einen entsprechenden Ausgang rechts unten.<br />
<br />
=== Modularsynth ===<br />
<br />
Der Modularsynth kann mit den Kabeln in der Kiste und am Regal nach Lust und Laune gepatcht werden. Kaputt machen kannst du rein technisch eigentlich nichts, sei aber trotzdem vorsichtig damit. Bitte bau wieder ab, was du aufgebaut hast, damit die nächste Person nicht erst ab- bzw umpatchen muss, um den Synth zu verwenden.<br />
<br />
=== Mischpult ===<br />
<br />
Das 16-Kanal Mischpult mag auf den ersten Blick etwas kompliziert sein, ist aber prinzipiell recht einfach zu bedienen. Wenn du nicht weisst, wie das geht, lass es dir am besten von einer der Person, die oben in der ProjektInfoBox gelistet sind, erklären.<br />
<br />
Es handelt sich um ein Yamaha MG 166C-USB, das eine Dauerleihgabe von lutoma ist. Manual: http://shuswaptheatre.com/wp-content/uploads/Yamaha-MG166c-Mixer-Owners-Manual.pdf<br />
<br />
=== Atari ST<sup>FM</sup> ===<br />
<br />
Dieses hochmoderne™ Gerät aus den 80ern war der erste Heimcomputer mit eingebautem MIDI, und gilt bis heute als einer der besten MIDI-Sequencer, die existieren. Da das [[Team R.E.T.R.O.]] zufälligerweise™ eine metrische Scheissetonne davon rumstehen hat, haben wir einen davon samt Originalfestplatte mit sagenhaften 30MB Speicher im KrachBummLabor verbaut. Unter anderem läuft auf diesem eine authentische Kopie von Steinberg Cubase (Version 3.10), mit dem MIDI-Sequenzen aufgenommen, abgespielt, und bearbeitet werden können. Weitere Software und Hardwaremods werden folgen.<br />
<br />
=== Instrumente ===<br />
<br />
Wie oben gelistet steht dem KrachBummLabor neben dem Modularsynth derzeit eine E-Gitarre und ein E-Bass plus Verstärker zur Verfügung. Letztere sind bitte nur nach Rücksprache mit [[Benutzer:slowpoke|slowpoke]] zu verwenden. Räumt sie nach Benutzung bitte wieder so weg, wie ihr sie vorgefunden habt.<br />
<br />
=== Ausschalten ===<br />
<br />
Prinzipiell wie das Einschalten, nur rückwärts. Achte bitte darauf, die Aktivbox runterzudrehen und auszuschalten, bevor du den Strom abstellst.<br />
<br />
== Weitere Pläne ==<br />
<br />
=== ASM-2 Board ===<br />
<br />
Es existiert ein Synth-Board von Elby, dass noch fertig bestückt und mit einem Patchpanel versehen werden muss. Dieses soll in ein Eurorack eingebaut werden, damit es später in ein 19"-Rack montiert werden kann (s.u.). Auf dem Board befinden sich unter anderem zwei VCOs, ein Rauschgenerator, zwei VCAs, zwei ADSRs, sowie zwei VCFs und ein LFO.<br />
<br />
=== Mobiles KrachBummLabor ===<br />
<br />
Für die etwas fernere Zukunft soll eine fahrbare 19"-Rackbox (so um die 20U) organisiert werden, in die mehrere Euroracks mit Synthmodulen, ein 19"-Rackmischpult, Schubladen für Kabel, und weiteres Zubehör eingebaut werden sollen. So kann das KrachBummLabor auch mit auf Veranstaltungen (zB die GPN oder den Congress) mitgenommen werden, um dort <strike>Leuten auf den Keks zu gehen</strike> Musik zu machen.<br />
<br />
[[Kategorie:Krachbummlabor]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=KrachBummLabor/Mk_I&diff=16664KrachBummLabor/Mk I2023-12-12T21:52:31Z<p>Bfritz0815: </p>
<hr />
<div>{{ProjektInfoBox<br />
|name = KrachBummLabor<br />
|status = obsolete<br />
|image = <br />
|description = <br />
|author = [[Benutzer:Felicitus|Felicitus]], [[Benutzer:Tiefpunkt|tiefpunkt]] und weitere (bitte tragt euch ein)<br />
|username = <br />
|version = <br />
|update = <br />
|platform = <br />
|license = <br />
|download = <br />
}}<br />
<br />
Das KrachBummLabor war ein kleines Musikstudio innerhalb vom RaumZeitLabor.<br />
<br />
Bisher ist folgendes an Hardware vorhanden (Bedienhinweise sind hinter den Links hinterlegt):<br />
<br />
== Einschaltprozedur ==<br />
<br />
Einfach die Steckdosenleiste, die von unten unter den rechten Tisch geschraubt ist, anschalten. Das war's auch schon.<br />
<br />
== Lautstärke regeln ==<br />
<br />
Nutze dafür den "Studio"-Regler auf der rechten Seite des Pultes. Bitte '''nicht''' die Lautstärke an den Lautsprechern selbst ändern.<br />
<br />
== Audio-Equipment ==<br />
* [[Podcast-Labor/Tascam M-2600|Tascam M-2600]] 32-Kanal Mischpult<br />
* ESI nEar 05 Monitorlautsprecher<br />
* Sennheiser e822 S<br />
* Sony MDR-V700 DJ-Kopfhörer (leider am zerfallen, nach 7 Jahren Einsatz aber auch kein Wunder)<br />
* [[Podcast-Labor/Behringer Ultrapatch|Behringer Ultrapatch Pro PX 2000]] 48-Kanal Patchbay<br />
* [[Podcast-Labor/Behringer Composer Pro|Behringer Composer Pro MDX200]] 2-Kanal Expander/Compressor/Limiter<br />
* [[Podcast-Labor/Behringer Virtualizer Pro|Behringer Virtualizer Pro DSP2024P]] Multieffektgerät<br />
<br />
== MIDI-Equipment ==<br />
* M-Audio KeyStation 61es<br />
* [[KrachBummLabor/Roland RS-70 Synthesizer|Roland RS-70 Synthesizer]]<br />
<br />
== Sonstiges ==<br />
* Genug Audio-Kabel, um 3-5 Mann an die Decke zu fesseln (passiert dann, wenn jemand mit Getränken in der Nähe des Equipments hantiert, siehe unten)<br />
<br />
== Regeln und Handhabung ==<br />
<br />
Teilweise ist Audio-Hardware etwas empfindlich. Wenn ihr euch nicht sicher seid, was bei bestimmten Aktionen passieren kann (z.b. bei Aktivierung der +48V Phantomspeisung), fragt einfach. Bestimmte Informationen zu einelznen Geräten findet Ihr auf der Geräte-Seite.<br />
<br />
Da verschiedene Leute die Hardware nutzen, solltet ihr euch die Reglerpositionen des Pultes notieren, falls ihr nicht an einem Abend fertig werdet. Im Handbuch gibt es dazu die Grafik eines Channel-Strips, da müsste man mal das ganze als Kopiervorlage umbasteln, damit man da einfach die Einstellungen markieren kann.<br />
<br />
'''Regeln zur Benutzung der Hardware:'''<br />
<br />
* Keine Getränke in der Nähe (sprich: <1m) des Equipments<br />
* Keine Getränke in der Nähe (sprich: <1m) des Equipments<br />
* Keine Speisen in der Nähe (sprich: <1m) des Equipments<br />
* Geht so pfleglich um, als ob die Geräte euch gehören würden. Ggf. noch etwas pfleglicher.<br />
* Achtet darauf, daß keine Flüssigkeiten, Krümel, Speisen und anderes auf die Geräte gelangen. Gerade beim Mischpult ist es sehr ärgerlich, wenn ein Krümel in den Faderweg gerät, denn so ein Fader auszutauschen ist ganz schön viel Arbeit und Ersatzteile sind teuer.<br />
<br />
== Zukunft ==<br />
<br />
* In naher Zukunft bringe ich noch einen Rechner mit, der dann mit 4 M-Audio Delta 1010LT-Karten bestückt wird (ist die preisgünstigste Lösung, um einen Rechner mit 32 Analogen I/Os auszustatten - pro Karte ca. 110-130 Eur NEU). Wenn jemand eine andere Lösung kennt oder sogar eine 24-Kanal Recordingkarte (z.b. MoTU o.ä.) hat, immer her damit!<br />
* Mehr Effektgeräte wären toll. Ich persönlich plane, nach den I/O-Karten ein Boss VF-1 und ein Lexicon MPX-500 zu organisieren.<br />
* Wer wissen möchte, was man mit dem Equipment so alles anstellen kann, für den kann ich gerne einen Workshop anbieten.<br />
* In ferner Zukunft wäre natürlich ein Raum-im-Raum mit akustischer Optimierung nützlich, weil unser Raum schon ganz schön hallt. Das hängt aber stark davon ab, wie sehr das Equipment auch genutzt wird.<br />
<br />
== Defekte ==<br />
<br />
Derzeit keine bekannt.<br />
<br />
== Unterseiten ==<br />
<splist /><br />
<br />
[[Kategorie:Krachbummlabor]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=KrachBummLabor/Mk_I/Behringer_Ultrapatch&diff=16663KrachBummLabor/Mk I/Behringer Ultrapatch2023-12-12T21:52:05Z<p>Bfritz0815: </p>
<hr />
<div>Die Patchbay ist die zentrale Stelle für '''benutzerdefinierte Audio-Routings'''.<br />
<br />
Im Regelfall funktioniert das ganze Audio-Setup "wie erwartet". Möchte jemand jedoch ein eigenes mitgebrachtes Effektgerät oder eine Gitarre mitbringen und einbinden, so muß er dank der Patchbay nicht hinter dem Pult herumturnen und diese einstöpseln, sondern kann das ganz bequem über die Patchbay machen.<br />
<br />
Übrigens: '''wer die Patchbay rückseitig umkonfiguriert, den erwartet die gleiche Strafe, wie als wenn er mit Getränken am Pult hantiert: Fesselung mittels Audio-Kabel an der Decke *hrhr*'''<br />
<br />
Die Ports der Patchbay werden mit einer Zahl und einem Buchstaben adressiert, z.b. ist der Eingang des Tascam-Pultes "16" auf B16 zu finden (B=untere Reihe, 16 wie beschriftet).<br />
<br />
'''Wichtig: Leider ist der Tascam-Sendkanal falsch beschriftet. Er liegt auf 8, nicht auf 1.'''<br />
<br />
=== Standardbelegung ===<br />
<br />
Die Patchbay ist vorderseitig beschriftet und bei allen Kanälen außer 23 und 24 auf halbnormalisiert gestellt. Sprich: Auf dem oberen Port liegt jeweils das Eingangssignal an (und kann dort ohne Unterbrechung abgenommen werden) und auf dem unteren Port liegt jeweils der Ausgang.<br />
<br />
== Tascam-Eingänge ==<br />
<br />
Die Klinken-Eingänge des Tascam-Pultes findet man auf B1-B16. Ist die Patchbay nicht belegt, so erhalten B1-B16 das Audio-Signal von A1-A16 (Eingänge des PC-Audio-Interfaces und des MOTU-Interfaces).<br />
<br />
Die Kanäle 31 und 32 sind direkt mit dem MOTU-Interface verbunden!<br />
<br />
== PC-Ausgänge ==<br />
<br />
Der PC hat eine M-Audio Delta 416 Karte mit 8 analogen Ausgängen und 2 analogen Eingängen. Die 8 Ausgänge sind auf A1-A8 zu finden.<br />
<br />
== Send/Return ==<br />
<br />
Der Mono-Send befindet sich auf A17, der Stereo-Return auf B19-20.<br />
<br />
== Virtualizer ==<br />
<br />
Der Virtualizer-Eingang befindet sich auf B17-18, der Virtualizer-Ausgang auf A19-20.<br />
<br />
== Master-Insert ==<br />
<br />
Der Master-Insert Ausgang befindet sich auf A23-24, der Master-Return auf B21-22.<br />
<br />
== Composer ==<br />
<br />
Der Composer-Eingang befindet sich auf B23-24, der Composer-Ausgang auf A21-22.<br />
<br />
=== Wie schliesse ich ... an? ===<br />
<br />
== Eigene E-Gitarre ==<br />
<br />
Deine E-Gitarre kannst du über jeden Port zwischen B-1 und B-16 anschliessen. Einfach Klinkenkabel in deine Gitarre, das andere Ende in einen Tascam-Input-Port, fertig! Natürlich kannst du auch ein Effektgerät zwischenschalten, da der pure Sound der E-Gitarre eher langweilig ist. Später kannst du auch das Signal deiner Gitarre über einen Software-Verzerrer geben, aber derzeit ist das leider noch nicht möglich.<br />
<br />
== Eigener Synthesizer ==<br />
<br />
Die Vorgehensweise ist ähnlich wie bei der E-Gitarre, aber je nachdem, ob dein Synthie Mono oder Stereoausgänge hat, mußt du natürlich mehr als einen Kanal verwenden.<br />
<br />
== Eigenes Effektgerät ==<br />
Derzeit nur möglich, wenn man auf den Virtualizer verzichtet. Stecke ein Klinkenkabel in A17 und verbinde es mit dem Eingang deines Effektgerätes. Stecke 2 Klinkenkabel in B19 und B20 und verbinde diese mit dem L/R-Ausgang deines Effektgerätes. Fertig! Der Auxweg für dein eigenes Effektgerät ist übrigens AUX8 (und nicht Aux1, wie beschriftet)!<br />
<br />
[[Kategorie:Hardware]]<br />
[[Kategorie:Gerät]]<br />
[[Kategorie:Krachbummlabor]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Kategorie:Krachbummlabor&diff=16662Kategorie:Krachbummlabor2023-12-12T21:51:27Z<p>Bfritz0815: Leere Seite erstellt</p>
<hr />
<div></div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=KrachBummLabor/Mk_I/Tascam_M-2600&diff=16661KrachBummLabor/Mk I/Tascam M-26002023-12-12T21:51:10Z<p>Bfritz0815: </p>
<hr />
<div>Das Tascam M-2600 ist ein Studio-Recording-Pult mit 32 Kanälen (Mic/Line), 32 Tape-Sends und 32-Tape-Returns. <br />
<br />
== Schnellstart ==<br />
<br />
'''Einschalten''': Alle Kanalfader runterziehen, Mischpult anschalten (großer Kasten unter dem Tisch), erst DANN die Monitorboxen anschalten (Kippschalter auf der Rückseite der Boxen).<br />
<br />
== Eingänge ==<br />
<br />
* 17-24: MoTU Analog Outs 1-8<br />
* 29-30: XLR Inputs 1&2<br />
* 31-32: MoTU Main Outs<br />
<br />
Weitere Eingänge werden belegt, sobald der Musikproduktionsrechner inkl. der benötigten Soundkarten vorhanden ist. Auch denkbar wäre eine Patchbay, damit man nicht immer hinter dem Pult herumkriechen muß, wenn jemand seine Gitarre aufnehmen möchte.<br />
<br />
== Wie geht ...? ==<br />
Diese Sektion gibt einige Hinweise für die "Eigenheiten" von diesem Pult und Recording-Pulten im allgemeinen.<br />
<br />
=== ...das mit den Stereo-Kanälen? ===<br />
<br />
Es gibt nur ganz wenige Pulte, deren Kanalzüge komplett in Stereo ausgelegt sind. Denn die meisten Signale, die im normalen Studioalltag bearbeitet werden, sind Mono (z.b. Sprache, E-Gitarre usw). Jeder Kanalzug kann im Stereopanorama mittels des PAN-Knopfes (der unterste Knopf bei jedem Kanal) platziert werden. C ist Center, L/R sollte klar sein. Weiterhin kann jeder Kanal einen Stereo-Effekt mittels den Aux-Wegen bekommen. Da wir aber noch keine Effektgeräte haben, hat sich das erst einmal erledigt :)<br />
<br />
=== ...denn doch, wenn ich jetzt aber doch einen Stereo-Input habe? ===<br />
<br />
Ganz einfach. Du benötigst dafür 2 freie Kanäle, den einen legst du mittels Panning auf L und den anderen auf R. Es ist zwar etwas umständlich, weil man zum abmischen immer 2 Fader bewegen muß, funktioniert aber. Ein Beispiel für eine solche Lösung findest du im Regelfall auf den Kanälen 31 und 32, da dies die regulären Stereo-Outs des MoTU-Interfaces darstellen.<br />
<br />
=== ...das mit den Subgruppen? ===<br />
<br />
Damit man sich die Finger nicht wundmischt, wenn man z.b. ein ganzes Schlagzeug abgemischt hat und jetzt noch eine Gitarre dazumischen möchte, gibt es die Subgruppen. Diese sind dafür da, um beliebige Kanäle als einen quasi virtuellen Kanal zu nutzen (Routing). Hat man z.b. die Kanäle 1-8 für das Schlagzeug benutzt, so kann man diese 8 Kanäle auf die Subgruppe 1/2 routen und mit nur einem Fader die Kanäle 1-8 abmischen. Natürlich muß man das Routing für den Master entfernen. Natürlich kann man mit Subgruppen noch mehr anstellen, aber die Neugier sollte mit der Kurzinfo hier befriedigt sein ;)<br />
<br />
== Wichtig!!! ==<br />
<br />
Bitte lasst die Finger von der Phantomspeisung weg. Solltet ihr wirklich die Phantomspeisung benötigen, gibts auf der Rückseite kleine Schalter, mit denen die Phantomspeisung für je 8 Kanäle eingeschaltet werden kann. Hier hilft die Anleitung auch weiter.<br />
<br />
== Fehlersuche ==<br />
<br />
* Sicherstellen, daß die Routing-Taster "L-R" bei den zu hörenden Kanälen gedrückt sind<br />
* Sicherstellen, daß in der Sektion "Control Room" der Taster "Stereo" gedrückt ist und der "Level"-Regler mindestens 1/4 aufgedreht ist<br />
* Sicherstellen, daß der Taster "Line" (ganz oben bei jedem Kanalzug) gedrückt ist<br />
* Sicherstellen, daß SOLO nicht aktiv ist (sprich: SOLO-Lampe in der Sektion "Control Room" ist AUS)<br />
* Sicherstellen, daß die zu hörenden Kanäle nicht gemutet sind<br />
<br />
[[Kategorie:Hardware]]<br />
[[Kategorie:Gerät]]<br />
[[Kategorie:Krachbummlabor]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=KrachBummLabor/Mk_I/Roland_RS-70_Synthesizer&diff=16660KrachBummLabor/Mk I/Roland RS-70 Synthesizer2023-12-12T21:49:49Z<p>Bfritz0815: </p>
<hr />
<div>== Informationen ==<br />
* Alle Infos etc. unter http://www.rolandmusik.de/produkte/RS-70/index.php<br />
* Handbuch befindet sich im Case (unter einem der Tische)<br />
<br />
== Defekte ==<br />
* Floppy-Drive funktioniert nicht, wird eine Diskette eingelegt, landet der RS-70 in einer Reboot-Schleife<br />
* USB-Interface geht anscheinend auch nicht<br />
<br />
[[Kategorie:Gerät]]<br />
[[Kategorie:Krachbummlabor]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=KrachBummLabor/Mk_I/Behringer_Composer_Pro&diff=16659KrachBummLabor/Mk I/Behringer Composer Pro2023-12-12T21:49:25Z<p>Bfritz0815: </p>
<hr />
<div>Der Behringer Composer Pro ist ein 2-kanaliger Kompressor, der per Default auf dem Master Insert des Pultes liegt.<br />
<br />
== Wichtige Infos ==<br />
<br />
Der Composer braucht nicht in Betrieb zu sein, um ein Audiosignal durchzulassen - ist er aus, sorgt ein Relais dafür, daß alles, was in den Composer reingeht, unverändert wieder rauskommt. Sprich: Composer aus - trotzdem Signal auf dem Master! Daher nicht wundern!<br />
<br />
[[Kategorie:Gerät]]<br />
[[Kategorie:Krachbummlabor]]</div>Bfritz0815https://wiki.raumzeitlabor.de/index.php?title=Shapeoko_2/tinyg_settings&diff=16658Shapeoko 2/tinyg settings2023-12-12T21:46:02Z<p>Bfritz0815: </p>
<hr />
<div>= TinyG Config Dump =<br />
<br />
== Date: 2016-11-08 ==<br />
<br />
<pre><br />
<br />
$$<br />
[fb] firmware build 440.20<br />
[fv] firmware version 0.97<br />
[hp] hardware platform 0.00<br />
[hv] hardware version 8.00<br />
[id] TinyG ID 3X3566-JL2<br />
[ja] junction acceleration 2000000 mm<br />
[ct] chordal tolerance 0.0100 mm<br />
[sl] soft limit enable 0<br />
[st] switch type 1 [0=NO,1=NC]<br />
[mt] motor idle timeout 2.00 Sec<br />
[ej] enable json mode 0 [0=text,1=JSON]<br />
[jv] json verbosity 4 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]<br />
[js] json serialize style 1 [0=relaxed,1=strict]<br />
[tv] text verbosity 1 [0=silent,1=verbose]<br />
[qv] queue report verbosity 1 [0=off,1=single,2=triple]<br />
[sv] status report verbosity 1 [0=off,1=filtered,2=verbose]<br />
[si] status interval 250 ms<br />
[ec] expand LF to CRLF on TX 0 [0=off,1=on]<br />
[ee] enable echo 1 [0=off,1=on]<br />
[ex] enable flow control 0 [0=off,1=XON/XOFF, 2=RTS/CTS]<br />
[baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]<br />
[net] network mode 0 [0=master]<br />
[gpl] default gcode plane 0 [0=G17,1=G18,2=G19]<br />
[gun] default gcode units mode 1 [0=G20,1=G21]<br />
[gco] default gcode coord system 1 [1-6 (G54-G59)]<br />
[gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]<br />
[gdi] default gcode distance mode 0 [0=G90,1=G91]<br />
[1ma] m1 map to axis 0 [0=X,1=Y,2=Z...]<br />
[1sa] m1 step angle 1.800 deg<br />
[1tr] m1 travel per revolution 40.0000 mm<br />
[1mi] m1 microsteps 8 [1,2,4,8]<br />
[1po] m1 polarity 0 [0=normal,1=reverse]<br />
[1pm] m1 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]<br />
[2ma] m2 map to axis 1 [0=X,1=Y,2=Z...]<br />
[2sa] m2 step angle 1.800 deg<br />
[2tr] m2 travel per revolution 40.0000 mm<br />
[2mi] m2 microsteps 8 [1,2,4,8]<br />
[2po] m2 polarity 0 [0=normal,1=reverse]<br />
[2pm] m2 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]<br />
[3ma] m3 map to axis 2 [0=X,1=Y,2=Z...]<br />
[3sa] m3 step angle 1.800 deg<br />
[3tr] m3 travel per revolution 2.1170 mm<br />
[3mi] m3 microsteps 8 [1,2,4,8]<br />
[3po] m3 polarity 0 [0=normal,1=reverse]<br />
[3pm] m3 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving]<br />
[4ma] m4 map to axis 3 [0=X,1=Y,2=Z...]<br />
[4sa] m4 step angle 1.800 deg<br />
[4tr] m4 travel per revolution 2.1166 mm<br />
[4mi] m4 microsteps 8 [1,2,4,8]<br />
[4po] m4 polarity 0 [0=normal,1=reverse]<br />
[4pm] m4 power management 0 [0=disabled,1=always on,2=in cycle,3=when moving]<br />
[xam] x axis mode 1 [standard]<br />
[xvm] x velocity maximum 4000 mm/min<br />
[xfr] x feedrate maximum 8000 mm/min<br />
[xtn] x travel minimum 0.000 mm<br />
[xtm] x travel maximum 260.000 mm<br />
[xjm] x jerk maximum 2000 mm/min^3 * 1 million<br />
[xjh] x jerk homing 2000 mm/min^3 * 1 million<br />
[xjd] x junction deviation 0.0100 mm (larger is faster)<br />
[xsn] x switch min 3 [0=off,1=homing,2=limit,3=limit+homing]<br />
[xsx] x switch max 2 [0=off,1=homing,2=limit,3=limit+homing]<br />
[xsv] x search velocity 1000 mm/min<br />
[xlv] x latch velocity 50 mm/min<br />
[xlb] x latch backoff 20.000 mm<br />
[xzb] x zero backoff 2.000 mm<br />
[yam] y axis mode 1 [standard]<br />
[yvm] y velocity maximum 4000 mm/min<br />
[yfr] y feedrate maximum 8000 mm/min<br />
[ytn] y travel minimum 0.000 mm<br />
[ytm] y travel maximum 275.000 mm<br />
[yjm] y jerk maximum 2000 mm/min^3 * 1 million<br />
[yjh] y jerk homing 2000 mm/min^3 * 1 million<br />
[yjd] y junction deviation 0.0100 mm (larger is faster)<br />
[ysn] y switch min 3 [0=off,1=homing,2=limit,3=limit+homing]<br />
[ysx] y switch max 2 [0=off,1=homing,2=limit,3=limit+homing]<br />
[ysv] y search velocity 1000 mm/min<br />
[ylv] y latch velocity 50 mm/min<br />
[ylb] y latch backoff 20.000 mm<br />
[yzb] y zero backoff 2.000 mm<br />
[zam] z axis mode 1 [standard]<br />
[zvm] z velocity maximum 800 mm/min<br />
[zfr] z feedrate maximum 800 mm/min<br />
[ztn] z travel minimum -70.000 mm<br />
[ztm] z travel maximum 0.000 mm<br />
[zjm] z jerk maximum 50 mm/min^3 * 1 million<br />
[zjh] z jerk homing 1000 mm/min^3 * 1 million<br />
[zjd] z junction deviation 0.0100 mm (larger is faster)<br />
[zsn] z switch min 0 [0=off,1=homing,2=limit,3=limit+homing]<br />
[zsx] z switch max 1 [0=off,1=homing,2=limit,3=limit+homing]<br />
[zsv] z search velocity 1000 mm/min<br />
[zlv] z latch velocity 50 mm/min<br />
[zlb] z latch backoff 20.000 mm<br />
[zzb] z zero backoff 2.000 mm<br />
[aam] a axis mode 3 [radius]<br />
[avm] a velocity maximum 25920 deg/min<br />
[afr] a feedrate maximum 12960 deg/min<br />
[atn] a travel minimum -1.000 deg<br />
[atm] a travel maximum -1.000 deg<br />
[ajm] a jerk maximum 324000 deg/min^3 * 1 million<br />
[ajh] a jerk homing 324000 deg/min^3 * 1 million<br />
[ajd] a junction deviation 0.1000 deg (larger is faster)<br />
[ara] a radius value 5.3050 deg<br />
[asn] a switch min 1 [0=off,1=homing,2=limit,3=limit+homing]<br />
[asx] a switch max 0 [0=off,1=homing,2=limit,3=limit+homing]<br />
[asv] a search velocity 2000 deg/min<br />
[alv] a latch velocity 2000 deg/min<br />
[alb] a latch backoff 5.000 deg<br />
[azb] a zero backoff 2.000 deg<br />
[bam] b axis mode 0 [disabled]<br />
[bvm] b velocity maximum 3600 deg/min<br />
[bfr] b feedrate maximum 3600 deg/min<br />
[btn] b travel minimum -1.000 deg<br />
[btm] b travel maximum -1.000 deg<br />
[bjm] b jerk maximum 20 deg/min^3 * 1 million<br />
[bjd] b junction deviation 0.0100 deg (larger is faster)<br />
[bra] b radius value 1.0000 deg<br />
[cam] c axis mode 0 [disabled]<br />
[cvm] c velocity maximum 3600 deg/min<br />
[cfr] c feedrate maximum 3600 deg/min<br />
[ctn] c travel minimum -1.000 deg<br />
[ctm] c travel maximum -1.000 deg<br />
[cjm] c jerk maximum 20 deg/min^3 * 1 million<br />
[cjd] c junction deviation 0.0100 deg (larger is faster)<br />
[cra] c radius value 1.0000 deg<br />
[p1frq] pwm frequency 2500 Hz<br />
[p1csl] pwm cw speed lo 5500 RPM<br />
[p1csh] pwm cw speed hi 12000 RPM<br />
[p1cpl] pwm cw phase lo 0.080 [0..1]<br />
[p1cph] pwm cw phase hi 0.900 [0..1]<br />
[p1wsl] pwm ccw speed lo 1000 RPM<br />
[p1wsh] pwm ccw speed hi 2000 RPM<br />
[p1wpl] pwm ccw phase lo 0.125 [0..1]<br />
[p1wph] pwm ccw phase hi 0.200 [0..1]<br />
[p1pof] pwm phase off 0.000 [0..1]<br />
[g54x] g54 x offset 0.000 mm<br />
[g54y] g54 y offset 0.000 mm<br />
[g54z] g54 z offset 0.000 mm<br />
[g54a] g54 a offset 0.000 deg<br />
[g54b] g54 b offset 0.000 deg<br />
[g54c] g54 c offset 0.000 deg<br />
[g55x] g55 x offset 0.000 mm<br />
[g55y] g55 y offset 0.000 mm<br />
[g55z] g55 z offset 0.000 mm<br />
[g55a] g55 a offset 0.000 deg<br />
[g55b] g55 b offset 0.000 deg<br />
[g55c] g55 c offset 0.000 deg<br />
[g56x] g56 x offset 0.000 mm<br />
[g56y] g56 y offset 0.000 mm<br />
[g56z] g56 z offset 0.000 mm<br />
[g56a] g56 a offset 0.000 deg<br />
[g56b] g56 b offset 0.000 deg<br />
[g56c] g56 c offset 0.000 deg<br />
[g57x] g57 x offset 0.000 mm<br />
[g57y] g57 y offset 0.000 mm<br />
[g57z] g57 z offset 0.000 mm<br />
[g57a] g57 a offset 0.000 deg<br />
[g57b] g57 b offset 0.000 deg<br />
[g57c] g57 c offset 0.000 deg<br />
[g58x] g58 x offset 0.000 mm<br />
[g58y] g58 y offset 0.000 mm<br />
[g58z] g58 z offset 0.000 mm<br />
[g58a] g58 a offset 0.000 deg<br />
[g58b] g58 b offset 0.000 deg<br />
[g58c] g58 c offset 0.000 deg<br />
[g59x] g59 x offset 0.000 mm<br />
[g59y] g59 y offset 0.000 mm<br />
[g59z] g59 z offset 0.000 mm<br />
[g59a] g59 a offset 0.000 deg<br />
[g59b] g59 b offset 0.000 deg<br />
[g59c] g59 c offset 0.000 deg<br />
[g92x] g92 x offset 0.000 mm<br />
[g92y] g92 y offset 0.000 mm<br />
[g92z] g92 z offset 0.000 mm<br />
[g92a] g92 a offset 0.000 deg<br />
[g92b] g92 b offset 0.000 deg<br />
[g92c] g92 c offset 0.000 deg<br />
[g28x] g28 x position 0.000 mm<br />
[g28y] g28 y position 0.000 mm<br />
[g28z] g28 z position 0.000 mm<br />
[g28a] g28 a position 0.000 deg<br />
[g28b] g28 b position 0.000 deg<br />
[g28c] g28 c position 0.000 deg<br />
[g30x] g30 x position 0.000 mm<br />
[g30y] g30 y position 0.000 mm<br />
[g30z] g30 z position 0.000 mm<br />
[g30a] g30 a position 0.000 deg<br />
[g30b] g30 b position 0.000 deg<br />
[g30c] g30 c position 0.000 deg<br />
tinyg [mm] ok> <br />
<br />
</pre><br />
<br />
[[Kategorie:Fräse]]</div>Bfritz0815