HolzBauTech RobotikZentrale Begleitseite
Dokumentation & LLM-NutzungEinzelnachweis · Teamstand · Quellen
Zentrale Begleitseite · gilt für alle Projekte

Technische Arbeit nachvollziehbar dokumentieren

Ihr führt zwei unterschiedliche Dokumente: Jede Person belegt den eigenen Beitrag nach jeder Doppelstunde. Das Team entwickelt parallel eine technische Gesamtdokumentation und lädt deren aktuellen Stand nur an den ausgewiesenen Meilensteinen hoch.

Die GrundregelDokumentiert knapp, konkret und mit Belegen. Die Dokumentation begleitet die Arbeit – sie ersetzt weder Programmierung noch Erprobung.
Dokumentation · Überblick

Zwei Dokumente erfüllen zwei verschiedene Aufgaben

Der individuelle Nachweis macht den persönlichen Beitrag sichtbar. Die technische Teamdokumentation zeigt Planung, Programmierung, Simulation, Realtest und Verbesserungen des gemeinsamen Produkts.

Individuelleigene Arbeit und eigenes Lernen
Im Teamtechnische Gesamtentwicklung
GeprüftQuellen, LLM und Simulation
Profilbild der fiktiven Person Selin ArslanKI
Von: Selin Arslan · QualitätssicherungBetreff: Technische Entscheidungen und persönliche Beiträge belegen

Hallo Robotik-Team,

bei einer automatisierten Anlage reicht es nicht, dass sie am Ende irgendwie funktioniert. Wir müssen nachvollziehen können, wie Punkte, Bewegungen, Signale und Sicherheitsmaßnahmen entstanden sind und welche Tests durchgeführt wurden.

Deshalb führt jede Person einen kurzen individuellen Nachweis. Zusätzlich pflegt das Team eine gemeinsame technische Dokumentation. Verwendet aussagekräftige Belege, aber vermeidet unnötige Textmengen.

Viele Grüße
Selin Arslan
Qualitätssicherung

ArbeitenProgrammieren, testen, recherchieren
Belegeneigene Ergebnisse sichern
IndividuellPDF nach der Doppelstunde abgeben
Teamstandfortlaufend ergänzen
Meilensteinaktuellen Teamstand hochladen
Nicht doppelt schreiben
Ein technischer Inhalt wird ausführlich in der Teamdokumentation erklärt. Im individuellen Dokument verweist ihr darauf und beschreibt euren eigenen Anteil daran.
Individueller Nachweis

Nach jeder Doppelstunde den eigenen Beitrag knapp festhalten

Das Dokument wird fortlaufend ergänzt und als PDF mit demselben Dateinamen abgegeben. Entscheidend ist nicht die Textmenge, sondern die konkrete eigene Leistung.

DateinameTeam_Nachname_Robotik.pdf
Rhythmusnach jeder Doppelstunde
Umfangkurz, konkret, belegt
BausteinWas gehört hinein?
ArbeitszielWas sollte in dieser Doppelstunde erreicht werden?
Eigener BeitragWelche Aufgabe hast du tatsächlich selbst bearbeitet?
Ergebnis / NachweisWelche Erkenntnis, Datei, Tabelle, Codeänderung oder Simulation belegt das Ergebnis?
Quellen / LLMWelche Hilfe wurde genutzt und wie wurde der Inhalt geprüft?
Nächster SchrittWas ist fachlich als Nächstes zu bearbeiten?
Kopiervorlage für einen neuen Eintrag
Datum / Unterrichtseinheit:
Arbeitsziel:
Mein eigener Beitrag:
Ergebnis oder Nachweis:
Quellen und LLM-Nutzung:
Nächster Schritt:
Zu allgemein

„Wir haben am Programm gearbeitet und einige Fehler behoben.“

Nachvollziehbar

„Ich habe die Greifposition des Distanzstücks neu eingemessen und den movel-Abschnitt getestet. In der Simulation kollidierte der Greifer zunächst mit dem Wagenrand. Nach Erhöhung der Sicherheitsfahrhöhe um … lief der Einzelzyklus fehlerfrei.“

Programmierung, Dokumentation, Recherche und Erprobung werden nicht dauerhaft einzelnen Personen zugeordnet. Notiert den Bereich, den ihr in der jeweiligen Einheit tatsächlich bearbeitet habt. Im Fachgespräch müsst ihr auch gemeinsame Entscheidungen erklären können.

Beleg statt Behauptung
Ein Screenshot, eine markierte Codeänderung, eine Messung oder eine kurze Testtabelle ist häufig aussagekräftiger als ein langer Fließtext.
Technische Teamdokumentation

Ein gemeinsames technisches Dokument über alle drei Projekte führen

Das Team ergänzt den Gesamtstand während der Arbeit. Hochgeladen wird er nur an den auf den Projektseiten markierten Meilensteinen.

DateinameTeam_Robotik_Gesamtdokumentation.pdf
Verantwortunggemeinsam, Aufgaben wechselnd
Standfortlaufend aktualisieren

Kapitel je Projekt

  1. Auftrag und gewählte Stufe
  2. Anlagen- und Ablaufplanung
  3. Punkte, I/O und Variablen
  4. begründete Programmstruktur
  5. Simulation und Testfälle
  6. Sicherheitsfreigabe und Realtest
  7. Abnahme und Verbesserungen

Gemeinsamer Anhang

  • vollständige Punktlisten
  • I/O-Zuordnungen
  • Quellenverzeichnis
  • ausgewählte Codeausschnitte
  • Test- und Abnahmeprotokolle
  • Versionsstände der SRS-Projekte
Kein Codefriedhof
Nehmt nur die Codeausschnitte auf, die eine wichtige Entscheidung oder Funktion zeigen. Erläutert jeweils Zweck, Ein- und Ausgänge sowie getestetes Verhalten.
ProjektBesonders wichtige Inhalte
Projekt 1 · FügestationKontur, Punkt- und Bewegungsplanung, movec-Zwischenpunkte, Simulation der Bahn
Projekt 2 · MontagesetsGreiferzustände, BasicIO, Aufnahme-/Ablagepunkte, while-Wechselphase und for-Serie
Projekt 3 · MaterialflussWert-/Gültigkeitspaare, wait, Entscheidungsbaum, Unterprogramme, Rücksetzungen und Testmatrix
TX90-ZusatzauftragSignalvertrag, Förderbandpositionen, TX90-Orientierungen, senkrechte Vorrichtung und Zykluszeitoptimierung
Meilensteine und Abgaben

Die Teamdokumentation nur an echten Prüfpunkten hochladen

Die Projektseiten nennen verbindlich, wann ein Upload erforderlich ist. Dazwischen arbeitet das Team im selben Dokument weiter.

Projekt 13 Meilensteine
Projekt 23 Meilensteine
Projekt 34 Meilensteine

M1 · Bahnplanung

Punktliste, Kontur, Bewegungswahl und Sicherheitsfahrhöhe.

M2 · Simulation

Codeausschnitte, Bahnzeichnung und fehlerfreie Simulation.

M3 · Abnahme

Finale Dokumentation, Abnahmeprotokoll und SRS-Dateien.

M1 · Planung

Ablaufplan, Punktliste, I/O- und Zustandstabelle.

M2 · Simulation

Schleifennachweis, Greiferablauf und vollständige Simulation.

M3 · Abnahme

Finale Dokumentation, Protokoll und SRS-Dateien.

M1 · Materialfluss/I/O

Stationsskizze, I/O-Tabelle, Zustandsfolge und Punkte.

M2 · Signallogik

Handshakes, bool-Werte, if-Testfälle und Ausgänge.

M3 · Simulation

Gesamtprogramm, Testmatrix und Fachgesprächsnachweis.

M4 · Abnahme

Finale Dokumentation, Protokoll und SRS-Dateien.

Für den Zusatzauftrag gelten die vier auf der TX90-Seite ausgewiesenen Meilensteine: Schnittstelle/Ablauf, RS40/Förderband, TX90-Simulation sowie Integration/Abnahme. Verwendet dieselbe technische Teamdokumentation und ergänzt ein eigenes Kapitel.

Geeignete Nachweise

Belege auswählen, die eine technische Aussage wirklich stützen

Ein Nachweis ist dann nützlich, wenn Außenstehende die Entscheidung oder das Testergebnis nachvollziehen können.

gezieltnur relevante Ausschnitte
beschriftetwas ist zu erkennen?
eingeordnetwarum ist es wichtig?
Skizze oder Ablaufplanzeigt räumliche Anordnung, Reihenfolge oder Zustände.
Punkt- oder I/O-Tabellemacht Werte und Zuordnungen prüfbar.
Codeausschnittbelegt eine konkrete Funktion, nicht das ganze Programm.
Simulationsbildzeigt eine relevante Lage oder Bahn mit Beschriftung.
Testmatrixstellt Soll und Ist für mehrere Fälle gegenüber.
Fehlerprotokollzeigt Fehlerbild, Ursache, Änderung und Ergebnis.
Beispiel für eine aussagekräftige Bildunterschrift

„Simulation der Bahn B–C: Der Zwischenpunkt liegt auf dem vorgesehenen Kreisbogen. Die Werkzeugorientierung bleibt mit rx = -180 konstant; Shoulder wurde auf die in der Zelle erreichbare Konfiguration eingestellt.“

Nicht ausreichend
„Screenshot aus der Simulation“ erklärt weder die geprüfte Funktion noch das Ergebnis.
Quellen und LLM-Nutzung

Hilfen transparent nutzen und fachlich überprüfen

Die integrierte Stäubli-Hilfe und die installierte Softwareversion sind für Syntax und roboterspezifische Funktionen maßgeblich. LLM-Vorschläge müssen geprüft und gegebenenfalls korrigiert werden.

Quelle nennenHilfe, Handbuch oder LLM
PrüfenSoftwarehilfe, Simulation, Test
Entscheidenübernehmen, ändern, verwerfen
Vorlage für Quellen- und LLM-Nachweis
Werkzeug / Quelle:
Fragestellung:
Vorschlag oder relevante Aussage:
Fachliche Prüfung mit:
Ergebnis der Prüfung:
Übernommen / verändert / verworfen:
Ohne LLM
Wenn kein LLM genutzt wurde, schreibt ihr eindeutig: „Keine KI genutzt.“ Andere Quellen werden trotzdem genannt.
Vorschlag betrifft …Geeignete Prüfung
VAL3-Syntaxintegrierte Stäubli-Hilfe und Übersetzen/Starten in der installierten Version
Punkt oder Bewegung3D-Ansicht, Simulation, Kollisionsprüfung und langsamer Realtest nach Freigabe
I/O-LogikZustandstabelle, I/O-Monitor und getrennte Testfälle
Fehlerursachenur eine Änderung gleichzeitig, vorher/nachher dokumentieren
Offset oder roboterspezifische Funktionversionsabhängige Hilfe und Testprojekt

Wer einen Vorschlag übernimmt, muss dessen Zweck, Ein- und Ausgänge, Bedingungen sowie mögliche Fehler erklären können. Eine funktionierende Copy-and-Paste-Lösung ohne Verständnis ist kein ausreichender Nachweis.

Dateien und Zusammenarbeit

Aktuellen Projektstand sichern und Aufgabenbereiche wechseln

SRS-Projekte werden lokal bearbeitet. Die gemeinsame Sicherung liegt auf dem persönlichen Schulnetz-Laufwerk eines Teammitglieds.

lokal arbeiten..\Documents\Staubli\SRS
zurücksichernam Ende jeder Stunde
vertretbar bleibenLehrkraft kann Kopie übertragen
Schulnetzaktuellen Teamordner finden
Kopierennach lokalem SRS-Ordner
Bearbeitennur lokale Kopie öffnen
SchließenProjekt vollständig beenden
Zurücksichernvollständigen Ordner kopieren
Abwesenheit
Fehlt in der nächsten Stunde die Person, auf deren Laufwerk der aktuelle Teamordner liegt, kann die Lehrkraft den Ordner auf das Laufwerk eines anderen Teammitglieds kopieren.

Alle Teammitglieder verfügen über einen eigenen PC. Aufgaben können parallel bearbeitet werden. Trotzdem soll nicht dieselbe Person dauerhaft nur programmieren oder nur dokumentieren. Plant Wechsel so, dass jede Person unterschiedliche Arbeitsbereiche kennenlernt und die gemeinsame Lösung erklären kann.

Abgabecheck

Vor jedem Upload Vollständigkeit und Lesbarkeit prüfen

Die Checkliste gilt für individuelle und gemeinsame Dokumente. Projektspezifische Anforderungen der jeweiligen Meilensteine kommen hinzu.

aktuellrichtiger Versionsstand
lesbarbeschriftete Belege
prüfbarQuellen und Ergebnisse