Legosortiermaschine gesamte Anlage

Dies ist ein Unterartikel von der Legoteil Zählmaschine, wo Aufgaben bezogen auf die ganze Anlage beschrieben werden.

Anforderungen

Spezifikations-ID	Anforderungs-ID	Anforderungstitel	Beschreibung der Spezifikation	Arbeitsergebnis
0057	REQ10.2041	Sicherheit/ Gefährdungsbeurteilung	Schaltschrank verdrahten	Inbetriebnahmeprotokoll
0010	REQ10.2000	Eigenständige Funktionsweise der Sortiermaschine	Funktionsfähig ohne Verbindung zu einem anderen System und ohne menschliche Eingriffe	Inbetriebnahmeprotokoll
0052	REQ10.2040	Sicherheit / Gefährdungsbeurteilung	Mechanische Sicherheit (Einklemmschutz)	Inbetriebnahmeprotokoll
0053	REQ10.2040	Sicherheit/ Gefährdungsbeurteilung	Erstellen einer Gebrauchsanleitung im Wiki	Wiki-Artikel
0054	REQ10.2040	Sicherheit / Gefährdungsbeurteilung	Erstellen einer Schritt-für-Schritt Anleitung im Wiki	Wiki-Artikel
0300	REQ10.3200	Projektplanung	MS Project verwenden	Dokument
0310	REQ10.3210	Versionsverwaltung	Alle Daten in SVN hinterlegen	SVN
0410	REQ10.3250	Modellierung der System- und Softwarearchitektur	Geeignete Software für System- und Softwarearchitektur verwenden (zb. MS Visio)	Wiki Artikel
0420	REQ10.3260	Tools für Softwareentwicklung	Geeignete Werkzeuge für Softwareentwicklung	Dokument
0430	REQ10.3270	Nachhaltigkeit	Alle wichtigen Software-Stände werden gut dokumentiert, d. h. ausführlich kommentiert und per SVN versioniert	Dokument
0431	REQ10.3271	Nachhaltigkeit	Softwarestände dokumentieren	Dokument
0432	REQ10.3272	Nachhaltigkeit	Software ausführlich kommentieren	Dokument
0432.1	REQ10.3272	Nachhaltigkeit	SVN - Nachhaltigkeit	Dokument
0510	REQ10.3290	Integrationstests	Für die entwickelte Software bzw. die Steuer- und Regelungsalgorithmen muss ein Integrationstest durchgeführt werden.	Integrations_Tests
0500	REQ10.3280	Komponententests	Für die entwickelte Software bzw. die Steuer- und Regelungsalgorithmen müssen geeignete Komponententests durchgeführt und geeignet dokumentiert werden	Unit_Tests
0070.2	REQ10.2060	Verarbeitungszeit	> 120 Legoteile in 10min	Protokoll Verarbeitungsrate
0320	REQ10.3220	Ablagestruktur für Versionsverwaltung	Geeignete Struktur für SVN definieren und einrichten
0330	REQ10.3231	Dokumentation	Projektergebnisse nachvollziehbar und nachbaubar darstellen für fachversierte Nutzer	Übersicht Dokumentationen
0520.1	REQ10.3300	Coding Guidelines	Code Reviews	MATLAB Arduino
0520.3	REQ10.3300	Coding Guidelines	Leitfaden überarbeiten (Arduino-C, Matlab)	Programmierrichtlinien
0521	REQ10.3300	Coding Guidelines	Untersuchung und Überarbeitung des bisherigen Codes bezüglich Einhaltung der Coding Guidelines	Analyse MATLAB
0530	REQ10.3310	Dokumentation von Software	Geeignete Software zur Dokumentation des Quellcodes (zb LaTeX oder Doxygen)	MATLAB mit m2html Arduino mit PapDesigner
0531	REQ10.3311	Dokumentation von Software	Video zur Bedienung von m2html	Videoanleitung

Schnittstellen

Die Legosortiermaschiene ist in drei Arbeitsbereiche eingeteilt. Dies hat den Vorteil, dass aus dem gesamten Team kleine Gruppen gebildet werden können, welche für ihren Maschinenteil verantwortlich sind. Dadurch wird vermieden, dass Aufgaben doppelt oder gar nicht erledigt werden. Es bringt allerdings den Nachteil mit sich, dass es Schnittstellen zwischen den Gruppen gibt. Diese müssen genau definiert werden, damit eine reibungslose Zusammenarbeit gewährleistet ist.

Separierung - Bildverarbeitung

Die Separierung vereinzelt die Legoteile, damit die Bildverarbeitung diese verarbeiten kann. Dafür sind folgende Vereinbarungen getroffen worden:

Hardware

• Es darf immer nur ein Teil von der Separierung an die Bildverarbeitung übergeben werden
• Das Förderband und der Eingang der Bildverarbeitungsbox liegen auf einer Höhe, damit kein Teil vom Förderband fällt. Damit alle Teile in die Box fallen, ist diese schräg angebracht.
• Die Anlage wird über einen Schaltschrank gesteuert. Dort werden die Komponenten der Separierung und der Bildverarbeitung gesteuert.

Software

Beide Anlagenteile können nicht gleichzeitig durch zwei getrennt Programme gesteuert werden. Deshalb muss eine Hauptfunktion die Laufzeiten steuern. Nötige Vereinbarungen:

• Sobald ein Teil in der Bildbox erkannt wird, bleibt die Separierung stehen
• Kalibrierungen der Kameras wird in der Hauptfunktion durchgeführt
• Die Teilprogramme dürfen keine Dauerschleifen haben
• Die graphische Ausgabe für beide Funktionen ist in einer Figur

Bildverarbeitung - Sortierung

Das Teil aus der Bildverarbeitung muss in die Sortierung gelangen, damit es richtig einsortiert wird. Dafür sind folgende Vereinbarungen getroffen worden:

Hardware

• Die Bildverarbeitung hat den Ausgang zur Seite
• Das Teil wird mit einer Luftdüse herausgeschossen
• Die Anlage wird über einen Schaltschrank gesteuert.

Software

• Hat die Bildverarbeitung ein Teil erkannt, so wird die Fachnummer an den Mikrocontroler gesendet. Dazu fragt die Bildverarbeitung die Fachnummer aus der Datenbank ab
• Der Mikrocontroler steuert dann die die Klappen der Sortierung an

Neuverdrahtung des Schaltschranks

Nach der Übernahme des Projekts wurden folgende Mängel bei der Verdrahtung im Schaltschrank festgestellt:

• Fehlen von Aderendhülsen auf flexiblen Leitungen
• Aderendhülsen auf starren Leitungen
• Signalleitungen mit starren Leitungen (Leitungsbruch bei geringem Bewegen dieser Leitungen)
• Leitungen wurden vor dem Anschluss nicht auf Länge gebracht und lagen aufgerollt hinter dem Schaltschrank
• Fehlende Beschriftung von Bauteilen, Leitungen und Adern
• Dokumentation und Verdrahtung stimmen nicht überein

Aufgrund dieser Mängel wurde entschieden, den Schaltschrank komplett neu zu verdrahten und dabei eine aktuelle Dokumentation zu erstellen.

Die nachfolgenden Bilder zeigen einen Vorher/Nachher-Vergleich der Verdrahtung im Schaltschrank.

• 

  Schaltschrank vor der Neuverdrahtung

• 

  Schaltschrank nach der Neuverdrahtung

Die aktuelle Verdrahtung ist durch einen Klemmenbelegungsplan dokumentiert.

Richtlinien zur Codegestaltung

Übersicht über die Richtlinien

Die Softwarekomponenten der Legoteil-Zählmaschine wurden in MATLAB und Arduino C implementiert. Um den Entwicklungsprozess zu vereinfachen mussten zunächst formalen Guidelines überarbeitet werden. Diese legen die formelle und syntaktische Gestaltung des im Rahmen des Praktikums erzeugten Codes fest.

Insbesondere Liegt der Fokus hier auf:

• Gestaltung von Headern
• Benennung von Funktionen und Variablen
• Umfang von Kommentaren

Die Guidelines beziehen sich in erster Linie auf Code in C/C++ und Matlab, können jedoch auch leicht auf andere Sprachen übertragen werden. Sie wurden im Verlaufe des Semesters mehrfach überarbeitet und angepasst. Dies Erfolgte zuletzt in Zusammenarbeit mit Stephan Marks aus der Gruppe des Autonomen Fahrzeuges. Die entsprechenden Dokumente liegen im SVN oder sind hier im Wiki zu finden und werden auch im weiteren Praktikumsverlauf falls nötig noch erweitert und verbessert werden.

Konkret wurden hierbei folgende Änderungen vorgenommen:

• Die C Richtlinien wurden auf MATLAB erweitert
• Variablenbenennung soll auf Deutsch erfolgen
• Es wurden Anforderungen an Kommentare hinzugefügt, laut denen allein anhand dieser der Programmablauf klar werden muss
• Das Header Format wurde wie Folgt spezifiziert:

Sprache	Modul	Funktion
C/C++	/************************************************************\ * * Modul  : ModulName.c * * Datum  : 04. Oktober 2013 * * Beschreibung  : Zweck dieses Moduls * * Implementierung : Visual Studio 2012 Professional * * Autor  : Mustermann, Max * * Bemerkung  : Demo für den ersten Meilenstein * * Letzte Änderung : 04. Mai 2018 * \************************************************************/	/***********************************************************\ * * Funktion  : MD_FunktionsName * * Datum  : 04. Oktober 2013 * * Beschreibung  : Zweck dieser Funktion * * Implementierung  : Visual Studio 2012 Professional * * Autor  : Mustermann, Max * * Bemerkung  : Code-Review noch ausstehend * * Letzte Änderung  : 04. Mai 2018 * * Übergebeparameter : * Typ Name Beschreibung * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * int n Anzahl Elemente des Arrays * double[] a Array mit double-Werten * * Rückgabeparameter : * Typ Beschreibung * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * int Rückgabe eines Fehlercodes * \***********************************************************/
MATLAB	% ***********************************************************\ % % Modul  : ModulName.m % % Datum  : 04. Oktober 2013 % % Implementierung : MATLAB R2013a % % Toolbox  : Example Toolbox % % Autor  : Mustermann, Max % % Bemerkung  : Code-Review noch ausstehend % % Letzte Änderung : 04. Mai 2018 % %************************************************************/	%************************************************************\ % % Funktion  : Funktion.m % % Datum  : 14. Mai 2018 % % Implementierung  : MATLAB R2017a % % Toolbox  : - % % Autor  : Marks, Stephan % % Bemerkung  : Beispiel eines Funktions-Headers % % Letzte Änderung  : 04. Mai 2018 % % ***********************************************************/

• Im Falle des MATLAB Headers soll nach Möglichkeit zudem eine via help Funktionsname aufrufbare Hilfe eingebaut werden. Bei MATLAB wird hierfür stets der erste zusammenhängende Kommentar verwendet, daher sollte sich vor dem eigentlichen Header ein Block folgender Form befinden:

function result = Math_Add_A2B(a, b)
% MATH_ADD_A2B addiert zwei Zahlen   
%
% Syntax:
%   ergebnis = MATH_ADD_A2B(a, b)
%  
% Beschreibung:
%   Es werden die zwei Zahlen 'a' und 'b' 
%   beliebigen Datentyps addiert.
%   result = a + b
%
% Eingangswerte:
%   a: erster Summand
%   b: zweiter Summand
%
% Rückgabewerte:
%   result: Ergebnis der Addition von 'a' und 'b'
%  
% Beispiel:
%   ergebnis = MATH_ADD_A2B(7, 12.583)

Nach der ersten Überarbeitung der Guidelines wurde dann der gesamte bisherige Matlab Code bezüglich der Konformität überprüft und entsprechend überarbeitet. Dabei wurden die Benennungen und Formatierungen in Absprache mit Professor Göbel angepasst, um einen aufgeräumten und einheitlichen Ausgangszustand zu erzeugen, auf dem im Folgesemester weiter aufgebaut werden kann. Dazu wurde jede Datei des Programms analysiert und auf Header, Kommentare, Variablen und Funktionsbenennung untersucht und die Ergebnisse in einer Tabelle festgehalten. Zudem wurde überprüft, ob die einzelnen Funktionen im aktuellsten Programm überhaupt noch Verwendung fanden. Alle nicht verwendeten Programmteile wurden anschließend entfernt. Ein Ausschnitt der erstellten Tabelle ist im Folgenden dargestellt:

Abbildung 1: Ausschnitt aus der Analysetabelle

Eine komplette Liste mit allen überarbeiteten und gelöschten Dateien sowie Informationen zu den Umbenennungen sind im SVN zu finden. Eine erneute Überarbeitung aller Header aufgrund wiederholter Anpassungen steht noch aus. Die tatsächlich bearbeiteten Dateien wurden im Verlaufe des Projektes entsprechend angepasst.

Code Reviews

Abbildung 2: Beispiel eines Code-Reviews mit neuem Template

Gegen Ende des Projektzeitraums wurden für alle nennenswert veränderten Dateien des Projektes Code-Reviews durchgeführt. Dabei wurde in Anlehnung an ein vorhandenes Hella-Template ein neues, für den Umfang des Projektes besser geeignetes, neues Template erstellt. In diesem befindet sich neben den allgemeinen Projektdaten und dem Ergebnis der Analyse eine Checkliste, mit welcher Schritt für Schritt die einzelnen Dateien und Funktionen untersucht werden können.

Die Code Reviews wurden für folgende Quelldateien erstellt:

Dateiname	Link
Anlernen.m	SVN Link
AutomatischesZaehlen.m	SVN Link
BaukastenBearbeiten.m	SVN Link
Bildverarbeitung_Teach_In.m	SVN Link
Datenbankabgleich.m	SVN Link
ExcelOeffnen.m	SVN Link
FarberkennungMaske.m	SVN Link
Fehlteilliste.m	SVN Link
Inventurliste.m	SVN Link
Merkmalsberechnung.m	SVN Link
Separierung.m	SVN Link
StartSortiermaschine.m	SVN Link
TeachIn2.m	SVN Link
Serielle_Steuerung.ino	SVN Link

SVN

Die Ordnerstruktur im SVN wurde größtenteils von den Vorsemestern übernommen. In dem Bereich Dokumentation wurden einige Teilbeeiche hinzugefügt um neu entstandene Dokumente sinnvoll abzuspeichern.

Die Nachhaltigkeit des SVN Ordners wurde durch verschiedene Maßnamen verbessert:

• Entfernen ungenutzter Dateien
  • Im Ordner SRC wurden alte, ungenutzte Dateien entfernt
• Löschen temporärer Dateien wie Matlab .asv Dateien oder ~$ Dateien von Office Programmen
• Ignorierliste erweitert
  • .asv Dateien
  • Inventurliste.xls
• Umbenennungen
  • FARBERKENNUNG_V2 --> Farberkennung
  • createBinary_V3 --> createBinary
• Manuelle Versionierung behoben
• Doppelte Dateien gelöscht

Verlauf der Verarbeitungsrate

Die Verarbeitungsrate der Maschine ist ein gutes Maß, um den Fortschritt des Projekts sichtbar zu machen oder den Erfolg einzelner Maßnahmen zu überprüfen. Dazu wird nach jeder großen Änderung und zu jedem Meilenstein ein Sortierprozess gestartet und für eine gewisse Zeit beobachtet. Anschließend wird aus der Anzahl der erfolgreich sortierten Teile und der dabei benötigten Zeit die Verarbeitungsrate in Teile pro 10 Minuten ermittelt. Zusätzlich wird über die Differenz der zugeführten und im ersten Durchlauf richtig sortierten Teile die Sortierung in Prozent berechnet. Dabei ist zu beachten, dass seit dem 11.01.2019 zum Zweck der Vereinzelung Teile aus dem Prozess genommen werden, bevor sie die Bildverarbeitung erreichen. Die Sortierung in Prozent ist daher kein Gütekriterium der Bildverarbeitung.

Die folgende Tabelle zeigt eine Auswahl von ermittelten Verarbeitungsraten, um den Verlauf des Projekts zu verdeutlichen.

Datum	Anzahl zugeführte Teile	Anzahl erfolgreich sortierte Teile	Dauer	Verarbeitungsrate Teile/10min	Sortierung in %	Kommentar
23.04.18	50	13	10 Minuten	13,0	26	Ausgangssituation nach Übernahme des Projekts
25.06.18	81	54	9,5 Minuten	56,84	66,67	Ergebnis des SS18
11.01.19	326	270	23,3 Minuten	115,88	82,82209	Umbau der Separierung und Integration der Sortiereinheit
17.01.19	175	122	10 Minuten	122,00	69,71429	Programmtechnische Optimierung

Wie der Tabelle zu entnehmen ist, konnte die Verarbeitungsrate seit Übernahme des Projekts signifikant gesteigert werden. Der im Pflichtenheft vereinbarte Mindestwert der Verarbeitungsrate von 120 Teilen in 10 Minuten ist zu Meilenstein 4 erreicht worden. Das Projekt kann also als erfolgreich bearbeitet angesehen werden.

Inbetriebnahmeprotokoll

In einem Inbetriebnahmeprotokoll wurde die Legosortiermaschine im Juni 2018 in Betrieb genommen. Folgende Requirements wurden in diesem Protokoll bearbeitet und als Ergebnis in SVN festgehalten:

Spezifikations-ID	Anforderungs-ID	Anforderungstitel	Beschreibung der Spezifikation
0020	REQ10.2010	Antriebe	Elektrischer Antrieb muss vorhanden sein
0030	REQ10.2020	Energieversorgung	Per 230V AC Schukostecker
0040	REQ10.2030	Abmessung	2,5m x 1m x 1,5m Grundplattenmontage
0056	REQ10.2040	Sicherheit/ Gefährdungsbeurteilung	Drucken und Anbringen von Warnhinweisen

Das Inbetriebnahmeprotokoll ist unter folgendem Link zu finden: Inbetriebnahmeprotokoll

Der Systemtest der elektrischen Antriebe wurde zudem in einem Protokoll festgehalten und ist unter folgendem Link zu finden: Systemtest elektrische Antriebe

Gefährdungsbeurteilung

Eine Gefährdungsbeurteilung wurde im Juni 2018 erstellt.

Die Gefährdungsbeurteilung wurde in tabellarischer Form angelegt und listet mögliche Gefahren der Legosortiermaschine auf. Von der Grundausstattung über elektrische und mechanische Gefährdungen, wurden auch Gefahrstoffe und Brandgefährdungen kontrolliert.

Mögliche Gefahren wurden dabei in folgende Risikostufen eingeteilt:

• Kein Risiko
• Geringes Risiko
• Großes Risiko

Anhand der Risikostufe werden desweiteren Lösungsmaßnahmen sowie Termine zur Fehlerbehebung festgelegt.

Es wurden die folgenden drei Risiken erkannt:

1.) Eine Betriebsanweisung ist erstellt worden?

Das Risiko wurde als gering eingeschätzt und es wurde die Pflicht aufgenommen, eine Betriebsanweisung zum Meilenstein 4 zu erstellen.

2.) Bewegte Transportmittel, bewegte Arbeitsmittel

Für das Förderband gibt es momentan lediglich einen Warnhinweis und keinen materiellen Einklemmschutz. Dieses Risiko wurde als gering eingeschätzt und zum Meilenstein 3 wird ein Schutz angebracht werden.

3.) Unkontrollierte bewegte Teile

Nach der Bildverarbeitung werden die Legoteile "ausgeschossen". Dieses Risiko wurde ebenfalls als gering eingestuft. Als Maßnahme gilt der Zusammenbau der Sortiereinheit, welcher anschließend vor der Bildverarbeitung positioniert wird.

Die gesamte Gefährdungsbeurteilung wurde in SVN abgelegt und ist unter folgendem Link zu finden: Gefährdungsbeurteilung

Software Dokumentation

Allgemeine Informationen

Abbildung 3: Beispiel PAP

Spezifikations-ID	Anforderungs-ID	Anforderungstitel	Beschreibung der Spezifikation
410	REQ10.2320	Modellierung der System- und Softwarearchitektur	Geeignete Software für System- und Softwarearchitektur verwenden (zb. MS Visio)

Eine Softwarearchitektur beschreibt die grundlegenden Komponenten und deren Zusammenspiel innerhalb eines Softwaresystems.

Eine Systemarchitektur wird nach dem V-Modell XT im Rahmen des Systementwurfs erstellt und umfasst die Dekomposition des Systems, die Schnittstellenübersicht und den übergreifenden Datenkatalog (Daten, die Systeme und Systemelemente austauschen).

Zu Beginn der Systemarchitekturarbeiten werden, durch Analyse der Gesamtsystemspezifikation und weiterer vorhandener Informationen, Architekturtreiber identifiziert und Bewertungskriterien festgelegt. Funktionale und nicht-funktionale Anforderungen beeinflussen den Entwurf der Systemarchitektur, die in Architektursichten dokumentiert wird.

Für die System- und Softwarearchitektur müssen Programme verwendet werden die kostenfrei sind oder durch die Hochschule zur Verfügung gestellt werden.

Beipielhaft können folgende Programme verwendet werden:

• PapDesigner
• MS Visio
• Clickcharts
• Dia
• XMind
• FreeeMind

Für den Ablauf der Legosortiermaschine wurde mit der Software PAP-Designer ein Ablaufplan erstellt. In der neben stehenden Abbildung 3 ist ein Auszug zu sehen.

Das Dokument ist unter folgendem Link abrufbar:

Ablaufplan

Dateien sollten nicht als PDF oder Bilder gespeichert werden um nachfolgenden Gruppen die Weiterbearbeitung und Ergänzung zu ermöglichen.

MATLAB Dokumentation

Spezifikations-ID	Anforderungs-ID	Anforderungstitel	Beschreibung der Spezifikation	Arbeitsergebnis
0530	REQ10.3310	Dokumentation von Software	Geeignete Software zur Dokumentation des Quellcodes (zb LaTeX oder Doxygen)	MATLAB mit m2html
0531	REQ10.3311	Dokumentation von Software	Video zur Bedienung von m2html	Videoanleitung

Abbildung 4: m2html Übersicht

Abbildung 5: m2html Funktionsbeispiel

Die MATLAB Dokumentation wurde mit m2html erstellt. Es handelt sich dabei um ein doxygen-ähnliches Werkzeug, welches die Quelldateien eines Projektes automatisch analysiert und eine im Webbrowser benutzbare Dokumentation erstellt. Hierbei werden für jede Quelldatei Funktionsname, Kopf, Eingabe- und Ausgabeparameter, sowie Zugriffe von und auf andere Funktionen im Projekt untersucht und übersichtlich dargestellt. Zu den Funktionszugriffen wird optional auch ein Graph erstellt, wie in ABB gezeigt. Da das Tool für eine sehr alte MATLAB-Version geschrieben wurde, sind einige Funktionen, unter anderem die Benutzeroberfläche zur einfachen Bedienung nicht mehr vollständig benutzbar. Zudem musste der Algorithmus zur Code-Analyse an einigen Stellen leicht abgeändert werden, um mit den neu erstellten Richtlinien zur Codegestaltung zu funktionieren. Weitere Änderungen können falls nötig in mfileparse.m vorgenommen werden. Die Anleitung sowie ein kurzes Bedienungs- und Demovideo sind im SVN zu finden.

Nach der Erstellung der Dokumentation kann diese mit dem öffnen der index.html im Dokumentationsordner eingesehen werden. Die Übersicht sowie eine beispielhafte Funktionsinformation sind im folgenden in Abbildung 4 bzw. 5 dargestellt.

Arduino Dokumentation

Abbildung 6: PAP der Seriellen Steuerung

Spezifikations-ID	Anforderungs-ID	Anforderungstitel	Beschreibung der Spezifikation	Arbeitsergebnis
0530	REQ10.3310	Dokumentation von Software	Geeignete Software zur Dokumentation des Quellcodes (zb LaTeX oder Doxygen)	Arduino mit PapDesigner

Die Arduino Dokumentation beschränkt sich auf eine einzelne Datei, welche die via USB empfangenen seriellen Daten auswertet und die jeweiligen Elemente der Maschine entsprechend ansteuert. Da sich somit keine komplexen Zusammenhänge zwischen verschiedenen Dateien im Programm ergeben, wurde für den Code mithilfe von PapDesigner ein genauer Ablaufplan in PapDesigner erstellt. Das Ergebnis ist in Abbildung 6 zu sehen.

Dokumentation

Die Ergebnisse des Projektes wurden, wie in Spezifikation 0330 gefordert, nachvollziehbar und nachbaubar dokumentiert. Die gesamten Dateien und Unterlagen zur Dokumentation sind strukturiert in SVN gesichert und versioniert. Abbildung 7 zeigt eine Übersicht der Dokumentationen, die im WS18/19 anzufertigen waren. Mit Hilfe der dort dargestellten Tabelle wurde die Vollständigkeit sowie der Fortschritt der Dokumentation überprüft.

Abbildung 7: Übersicht der Dokumentationen

Zusammenfassung

Dieser Artikel beschreibt Punkte zur Hardware und Software, die auf die gesamte Anlage bezogen sind. Umgesetzte Punkte sind die folgenden:

Liste offener Punkte (LoP)

• Separate Absicherung der 5V und 24V Stromkreise (Benötigte Materialien bereits in BOM eingetragen, Bestellung war zum Jahresende nicht mehr möglich)
• Provisorischen Vorwiderstand der Vibrationsförderrinne durch Potentiometer ersetzen (Benötigte Materialien bereits in BOM eingetragen, Bestellung war zum Jahresende nicht mehr möglich)

Autoren

Dies ist ein Unterartikel von der Legoteil_Zählmaschine, welcher die Zusammenführung der einzelnen Teile zu einer Einheit beschrieben.