QUOTE (Keule0 @ 17.02.2013, 14:44 Uhr)
... Ich finde man sollte sich da garnicht so an der Definition "real Programmer" und "Whop" festbeißen. Die Übergänge sind ja fließend.
CAM fängt ja streng genommen auch schon fast bei Macros und Variablenprogrammierung an.
http://www.cnc-arena.com/forum/index.php?a...&pid=385604Mit Marcos und Variablen fangen die strukturierte Programmierung und die Abstraktion an....
QUOTE
Und dieser Trend, dass Fertigkeiten die früher fast mystische Ausstrahlung hatten nun von Maschinen genauso oder besser erledingt werden ist wohl auch nicht mehr umkehrbar. Wenn ein Dreher früher eben als halbgott angesehen wurde wenn er die 1/100 mm Passungen immer getroffen hat,
"Real Programmer"
QUOTE
so erntet der
CNC dreher mit vernünftigen Werkzeugen heute dafür nur ein müdes lächeln. Da kann man nix machen. Dadurch entstehen ja immer auch wieder neue Aufgabenfelder. Der der früher ein sehr guter Dreher geworden wäre geht heute in die AV und schraubt da am CAM rum. Arbeit ist immer genug da.
Eben....
QUOTE
Ich finde es macht auch keinen Unterschied ob man quasi als "Real Programmer" schön tief im Code steckt und jede Werkzeugbahn optimiert weil man die ja eh komplett definieren muss, oder ob man am CAM sitzt und da die ganzen häckchen und Einstellungen sucht um das optimal ablaufen zu lassen. Ok der eine sitzt im Büro der andere an der Maschine, aber wenn das CAM vernünftig auf die Maschine angepasst ist, d.h. die Simulation entspricht fast 100 % dem Ablauf an der Maschine, dann frickeln beide doch einfach nur an einem Programm. Der eine drückt Knöpfe der andere tippt Text. Also quasi nur 2 verschiedene Arten der Maschine zu sagen was sie machen soll.
CAM wird sich immer mit einer Abstraktion beschäftigen und beschreiben, was was ist.... Schwerpunkt liegt also auf
deskriptivem Programmieren.
For Ort, bzw. textbasiert, programmiert man, wie etwas gemacht wird... Schwerpunkt liegt also auf
imperativem Programmieren.
QUOTE
Die Kollision zwischen diesen beiden herangehensweisen gibt es natürlich dann wenn das CAM programm wirklich auf der Maschine laufen soll. Das wurde ja schon angesprochen. Nen schönes Programm im CAm system ist auf der MAschine manchmal Sch***e. So das der Bediener bzw. ein "Real Programmer" (wenn der noch einer ist) eingreifen muss z.B. wegen:
- blöde An- und Abfahrstrategien
- Falsche Schnittwerte
- Kollisionen
- Spankontrolle
(mehr fällt mir grad nicht ein, was müsst ihr denn meistens händisch anpassen?)
Das weiß man aber. Allein Grafisch-Interaktive Programmiersysteme konnten bis heute nicht überzeugen, und die Computerprogrammierer haben damit jetzt 30 Jahre Erfahrung.
QUOTE
Dieses nachträgliche Anpassen der Cam Programme würde aber dann entfallen wenn das CAM System die Maschine bzw. besser gesagt, den Prozess, wirklich 100% abbilden würde. Weil dann könnte der Mensch am CAM das ebenso optimieren (oder optimieren lassen) wie der Real Programmer. Ich setzte dabei mal vorraus, dass das CAM dies zulässt bzw. selbst erledigt.
Das wird klassisch nie funktionieren. Inwieweit andere Ansätze das leisten können.... Da bin ich sehr vorsichtig....
QUOTE
Wenn das CAM den Prozess also deutlich besser abbilden würde als es heute üblich ist, inkl. Kollisionen, Kräfte, Momente, Spankontrolle usw. Dann bräuchte man keine Real Programmer mehr. Dann wären die Programme am CAM soweit optimiert das es läuft. Ansätze dazu gibt es ja bereits --> z.B. iMashining von SolidCAM.
Ich denke irgendwann wird es soweit sein, das der ganze Prozess mathematisch abgebildet werden kann und dann von einem Rechner absolut optimiert werden kann. Also quasi 3 mal klicken und da ist das fertige Programm. Dem Bediener bleiben dann nur noch die Potis und die Einstellung der Kühlmitterldüsen.
Wir sind schon froh, wenn (falls?) wir es schaffen werden, Objekte, welche durch Zeichnungen repräsentiert werden, auf Code(-Blöcke) abzubilden, die dann ausgeführt werden können. ... Das wäre CAM, der deskriptive Ansatz ganz oben, aus dem eben Zwischen-Code abgeleitet werden kann... Wie dieser dann optimal auf einer realen Maschine ausgeführt werden kann, müssen dann schon Low-Level-Leute implementieren. Das ist aber bei normalen Computern genauso...
QUOTE
Also ich würde mir sowas wünschen. Aber bis dahin brauchts den Real Programmer wohl noch.
Gibt prinzipiell Bedenken, ob das mit endlichem Aufwand überhaupt umgesetzt werden kann....
QUOTE
Und da ist auch der Unterschied zur allgemeinen Softwareentwicklung. Unsere Zerspanungsprozesse können eben mit endlich vielen Variablen beschrieben werden (rein theoretisch könnte man da aber auch unendlich viele einbeziehen--> siehe unten, aufspannung MAterial usw.). Die Aufgaben der Softwareentwicklung können aber natürlich nie irgendwo begrenzt werden( woher soll der "ProgrammiersprachenHersteller" wissen was der Programmierer programmieren will). Also es ist schon ein krass unterschiedlicher Grad an komplexität. Das es in der allgemeinen Softwarentwicklung irgendwann keine Real Programmer mehr gibt ist für mich ausgeschlossen, bei der Zerspanung werde ich dies hoffentlich aber noch erleben.
... und das ist gnadenlos falsch. Sehr viel Code geht in Steuerungen. Im gesetzlich geregelten Bereich muss man nachweisen, dass ein Programm nur eine bestimmte Anzahl von Variablen hat, und damit nur eine endliche, unterschiedliche Anzahl von Zustandsänderungen....
QUOTE
Und Arbeit bleibt ja genug. Z.B. das Rohmaterial auswählen, die Aufspannung das Werkzeug usw. bleiben ja noch. Wenn dies der Rechner auch noch alles auswählen soll dann werden das ganz schnell zu viele Variablen. Das wird auch in Zukunft sehr schwer sein automatisch optimieren zu lassen.
Das kriegt man noch relativ einfach mit wissensbasierten Systemen in den Griff.....Sicher einfacher als die Abbildung von geometrischen Objekten in Programmstücke.....
HA