25. Mai 2019, 03:01:38
Roboterforum.de - Die Industrieroboter- Anwender und Experten Community

 Strukturiertes Programmieren


normal_post Autor Thema:  Strukturiertes Programmieren  (Gelesen 856 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

20. Februar 2019, 09:41:25
Gelesen 856 mal
Offline

Krayzzee


Guten Tag Forum Mitglieder,

ich habe vor kurzem angefangen als Kuka-Programmierer zu arbeiten. Alle nötigen Schulungen und etwas Praxiserfahrung kann ich vorweisen, aber das war es leider auch schon. Ich bin 22 und frisch von der Technikerschule und dementsprechend noch sehr unerfahren. Eine, wahrscheinlich nicht vermeidbare, Erfahrung durfte ich schon machen. Wenn Programme unstrukturiert und schlecht leserlich sind, erschwert es einem die Arbeit ungemein. Dies durfte ich an eigenem Leib erfahren als ich Probleme bei einem Kunden Vorort lösen sollte und das Programm meines Vorgängers recht "Wild" aussah.

Nun zu meiner Frage: Gibt es ungeschriebene Gesetze, an die man sich halten sollte? Bzw. Tipps und Vorgehensweisen eurer seits, auf die man von vorne rein achten kann um Wartungsarbeiten und eventuelle Ergänzungen zu vereinfachen? Natürlich möchte ich das jeder der damit zu tun haben wird, leicht nachvollziehen kann, was ich programmiert habe.
Über die Suchanfrage konnte ich leider nicht wirklich was zufriedenstellendes finden..

Danke schon mal im vorraus.  :mrgreen:

Mit freundlichen Grüßen

  • gefällt mir    Danke

Heute um 03:01:38
Antwort #1

Werbung

Gast

20. Februar 2019, 10:41:28
Antwort #1
Offline

Joern_E

ROBTEC Mitarbeiter
Moin Krayzzee,

vorweg sei gesagt, daß alleine Einrückungen und die Wahl sinnvoller Variablen- und Unterprogrammnamen schon die halbe Miete sind. :)

Auf dieser Seite (1) ist das Thema insgesamt relativ ausführlich behandelt. Die meisten Programmierer haben Vorlieben und werden das eine oder andere im Detail sicherlich anders machen. Wie Du es ganz am Ende machst bleibt natürlich auch Dir überlassen. Aber es ist eine gute Basis.   ;)

Nachtrag:
Gerade bei größeren Projekten finde ich Programmablaufpläne sehr sinnvoll. Für Windows kann ich den PAPDesigner empfehlen. Klein, schlank und für Privatpersonen kostenlos. ;)

Gruß
Jörn


(1) https://de.wikibooks.org/wiki/Strukturierte_Programmierung
« Letzte Änderung: 09. April 2019, 09:35:38 von Joern_E »
  • gefällt mir x 1    Danke x 1 (Details | 3 Danke)
In der Theorie sind Theorie und Praxis identisch. In der Praxis nicht.

20. Februar 2019, 13:02:03
Antwort #2
Offline

Krayzzee


Auf dieser Seite[/url]



Dankeschön! Ich hab mir nun den Artikel durchgelesen und werde denke ich einiges davon übernehmen.  :mrgreen:


Hilft aufjedenfall einen guten Überblick zu bewahren. Ich werde es beim nächsten Auftrag der reinkommt direkt ausprobieren  :D


Eine weitere Frage die mich beschäftigt: Wie gehe ich am besten vor wenn ich ein Projekt in angriff nehme?
Zuerst die sicherheitsrelevanten Sachen oder doch zuerst die gewünschte Funktion und dann den Rest außen rum?
In welcher Reihenfolge ist es am sinnvollsten zu arbeiten?


Grüße Krayzzee
  • gefällt mir    Danke

20. Februar 2019, 14:27:44
Antwort #3
Offline

Joern_E

ROBTEC Mitarbeiter

Das hängt von den genauen Umständen ab. I.d.R. richte ich anfangs eine SafeZone in SaveMove ein (bei KUKA SafeOperation!?), die der Größe der Zelle, d.h. dem Schutzzaun drumherum, entspricht und die der Roboter nicht verlassen darf. Dann kommt der eigentliche Programmablauf und zuletzt - wenn ich weiß wo der Roboter wann hin muss - grenze ich die SafeZone entsprechend ein. Sonst musst Du während des Programmierens da schlimmstenfalls mehrfach drin rumpulen. Je nach Projekt kommt u.U. auch eine Achsbegrenzung hinzu.

Auf größeren Baustellen mit viel Publikumsverkehr ist das Einrichten einer NOT-Aus-Verkettung und/oder eines Bedienerschutzes (wie Schutztüren, Lichtgitter, ...) vor dem Umschalten auf den Automatikbetrieb auf jeden Fall dringend anzuraten (1), da sich immer mal wieder "plötzlich" irgendwelche Leute ohne weiteren Kommentar in die Roboterzelle verirren! :angry:

Gruß
Jörn

(1) Ehrlich gesagt weiß ich nicht, wie die rechtliche Lage dazu ist. Da kann vielleicht jemand anderes etwas detaillierter drauf eingehen?
  • gefällt mir    Danke
In der Theorie sind Theorie und Praxis identisch. In der Praxis nicht.

20. Februar 2019, 15:13:29
Antwort #4
Offline

Iceberg



Mit den Thema kannst du Bücher füllen. Aber der Link "Strukturierte_Programmierung" von Jörn sollte schon mal ein sehr guter Anfang sein. Von Robert Martin kann ich das Buch Clean Code empfehlen, das geht aber sehr in Richtung objektorientierte Sprachen. Für prozedurale Sprachen würde ich das aber auch mal empfehlen.
Ganz wichtig ist meiner Meinung nach aber auch Erfahrung im Programmieren an sich. Sauberer Code entsteht auch, in dem man sein Vorgehen immer wieder hinterfragt und versucht alte Fehler zu vermeiden. Noch dazu wird man die Vorteile einiger Vorschläge auch erst verstehen, wenn man mal so programmiert hat.

Meiner Meinung nach stehen einem aber auch die Programmiersprachen auf den Robotern oft im Weg, saubere Programme zu schreiben. Und wenns nicht der Roboter ist, dann der Kunde mit Programmvorgaben jehnseits von Gut und Böse.

Grüße
Reinhard
  • gefällt mir    Danke

Heute um 03:01:38
Antwort #5

Werbung

Gast

21. Februar 2019, 11:10:42
Antwort #5
Offline

Programmiersklave



Ich mach's inzwischen lieber rückwärts: alles programmieren, was außenrum schief gehen kann, und abfangen. Das, was übrigbleibt, ist dann die gewünschte Funktion.
Klar, das kann man nicht immer durchhalten, weil es oft zu viel wird, und manchmal fehlt einem schlicht die Phantasie, sich bestimmte Fehlfunktionen vorstellen zu können. Aber dann hat man im Programm wenigstens schon die Infrastruktur geschaffen, die das nachträgliche Einbinden solcher Mechanismen erlaubt. Erfahrungsgemäß ist das oft deutlich mehr Code als die Erschaffung der "eigentlichen" Funktion.

"Leicht wartbar" und "übersichtlich" beißt sich leider manchmal. Häufiges und ernstzunehmendes Beispiel ist die Produktinflation, wenn auf einer Anlage mehrere laufen sollen. Wenn mir einer sagt: "auf der Anlage laufen später zwei Produkte!", dann multipliziere ich gedanklich mit 50. Was bei zwei vielleicht noch übersichtlich ist, wird bei 7 (kommt immer was dazu) unerträglich. Lege ich im Vorhinein Arrays und Switches an, um das bis dahin fiktive Problem einzugrenzen, ist das Programm nicht mehr ganz so übersichtlich, lässt sich aber einfach erweitern.

Eine Buchempfehlung habe ich auch noch, die hat mir jedenfalls geholfen (Disclaimer: ob ein externer Beobachter das auch so sieht, ist nicht Gegenstand der vorhergehenden Aussage):
https://www.oreilly.de/buecher/120174/9783897215672-weniger-schlecht-programmieren.html

Grüße,
Michael
  • gefällt mir    Danke

21. Februar 2019, 16:52:31
Antwort #6
Offline

Joern_E

ROBTEC Mitarbeiter
Sehe ich genauso. Mit steigender Erfahrung kristallisiert sich das irgendwann heraus. Besonders im Hinblick darauf:


Ich programmiere auch lieber mit Variablen. Bei wenigen Verwendungsstellen mag das übertrieben erscheinen, aber wenn man das erste mal mehrere Positionen ändern muss, die dutzendfach im Code verwendet werden, lernt man es zu schätzen, obwohl es etwas Mehraufwand ist. ;)

Bei Vergleichen hat sich bei mir gut bewährt: Bis 2 Vergleiche verwende ich IF, für alles darüber hinaus CASE. Und, ganz wichtig, falsche Wertebereiche immer mit ELSE bzw. DEFAULT abfangen! Sonst macht das Programm u.U. ziemlich merkwürdige Sachen. Schlimmstenfalls bewegt sich der Roboter irgendwo hin, wo schon was anderes ist. Und da fängt dann der lustige Teil an. Interessanterweise haben Bediener für sowas ein geradezu magisches Händchen. :mrgreen:

Gruß
Jörn
  • gefällt mir    Danke
In der Theorie sind Theorie und Praxis identisch. In der Praxis nicht.

25. Februar 2019, 08:53:30
Antwort #7
Offline

Krayzzee


Danke für eure Antworten :) ich werd es mir zu Herzen nehmen!


Dass Buch werd ich mal auf jedenfalls anschauen.

Grüße Krayzzee
« Letzte Änderung: 25. Februar 2019, 13:33:52 von Krayzzee »
  • gefällt mir    Danke


Teile per facebook Teile per linkedin Teile per pinterest Teile per reddit Teile per twitter
 

über das Roboterforum

Nutzungsbedingungen Impressum Datenschutzerklärung

Sponsoren des Roboterforums

ROBTEC GmbH