Automatische Generierung von NC-Programmen, "Titel ist Programm"

Hallo Programmiergemeinde!
Ich bin es leid: abgebrochene Gewindebohrer wegen falscher Steigung, Gewinde zu tief angesenkt, oder Konturfase zu groß ..... . Das könnte ich unendlich erweitern, das Ergebnis ist immer das selbe: Ausschuß und Ärger mit dem Chef.
In unserem Betrieb wird vorwiegend einzeln produziert -> selbst programmiert und gefertigt. Das bedeutet jeden Tag hunderte Tastenanschläge und natürlich sind da Fehler vorprogramiert.
Ansatzpunkt zur Lösung:
CNC-Programme automatisch generieren und dem Programmierer/ Bediener nur ein Minimum an Eingaben überlassen.
Die Lösung:
Excel-Tabellen mit gespeicherten Angaben über Durchmesser, Steigung von Gewinden auslesen und eine komplette Datei mit vorgefertigten Zyklen und Labeln generieren. Anschließend die Label mit den Koordinaten der Bohrungen, Konturzug, u.s.w. vervollständigen und fertig!

Ich mach mich schon mal ran und bin über eure Meinung dazu gespannt!

Der Gedankengang ist gut.
Ich selber arbeite seit mehreren Jahren bei normalen Bearbeitungen wie dem Bohren, Gewindeschneiden, Senkungen oder Passungen mit Standardprogrammen die ich selber erstellt habe. Ich kopiere mir dann nur noch den Programmkopf und ändere ggf. die Bohrtiefen oder Senktiefen.
Scheinbar hat dies gut funktioniert und bei meiner Ex-Firma wird immer noch mit meinen alten Programmen gearbeitet.
Wichtig sind dann allerdings passenden Schnittwerte, ein funktionierendes System der Werkzeugvermessung und natürlich Ko9llegen die sich auch drauf einlassen.
Arbeitsanweisungen auf Papier kenne ich auch. Allerdings sind diese nur bei etwas exotischeren Dingen nötig für die ich keine Programme abspeichern will.
Das liegt aber nur an mir...

Hallo DerLanz!
Danke für`s feedback.
Teilweise arbeiten wir auch so. Es ist schwierig, eine Art Norm im Programmieren einzuführen, jeder bevorzugt seine eigenen Zyklen und der schreibt cycl call, ich bevorzuge M89 M99 der nächste bohrt mit Zyklus 203 ein anderer mit 205, jedesmal muß man umdenken und die Flexibilität fehlt dann meist. Konturzug ist bei einigen Mitarbeitern noch ein rotes Tuch. Die Generierung eines CNC-Programms stellt kein Problem dar. Das habe ich mit MS Excel schon gemacht. Sicherheit kommt dazu, da meinetwegen die Steigungswerte von Gewinden automatisch aus einer Tabelle ausgelesen werden und in das vorgefertigte Programm inklusive Tiefe, wenn man möchte, eingetragen werden. Das generierte Programm ist binnen Sekunden fertig. Nach meiner Vorstellung sind nur noch Koordinaten in Vorgefassten Labeln nach M30 einzutragen. Der Bediener wählt nur vor der Generation aus: z.B. M6 15 tief, M6 10 tief auf Stufe Z-100 , M8 20 tief, Bohrung D20H7 30 tief Kopf 90GRD. geschwenkt, PG7 5 tief, Kontur (Aussenkontur)120 tief u.s.w.
Nach M30 stehen die vorgefertigeten Label für Gewinde, Bohrungen Konturzug zur Eingabe der Koordinaten bereit und selbst das Freifahren ist schon programiert, selbst da ist es schon zum crash gekommen!
Sicher eine Zukunftsvision, aber in Schritten sicher machbar. So werden die Programme mitarbeiterunabhängig normiert und irgendwann für jeden nachvollziehbar und anpassbar (flexibel), und sicherer.

Ich freue ich auf weiter Meinungen, oder vielleicht möchte sich jemand dem Projekt anschließen!

Wie wäre es denn mit Programmaufrufen, in denen dann die Senkungen, Bohrungen, Steigungen und alles drinnensteht, z.B.

Begin Haupt PGM
Q10 = 25 (Gewindetiefe)
Sel Pattern BohrpositionenM6.pnt
Call PGM M6
End Haupt PGM

Begin PGM M6
Tool Call NC-Anbohrer
Cycl 240 mit Senktiefe, Vorschübe etc.
Cycl Call Pat
Tool Call Bohrer
Cycl 200 mit Bohrtiefe Vorschübe etc.
Cycl Call Pat
Tool Call Gewindebohrer
Cycl 207 mit Gewindetiefe Steigung etc.
Cycl Call Pat
End PGM M6

Das wäre jetzt für Gewinde, für Konturen könntest Du mit Sel Contur oder Zyklus 14 weitermachen.

Hallo,

also Excel-Tabellen brauchst du für dafür nicht. Wir haben sowas mit sogenannten "Entstehungen" gelöst. Dort werden Programmteile abgelegt, die immer wieder gebraucht werden (z.b. Kernloch M6, ansenken und Gewindeschneiden) und mit einem Programmnamen versehen, der die Bearbeitung erklärt (z.B. M6_Sack_17_12_4301) Wenn jetzt in einem Werkstück aus rostfreiem Material Sacklöcher M6 BT 17 und GT 12 benötigt werden wird einfach dieses PGM mit PGM Call aufgerufen.

Ja das Problem kenne ich. Für sowas habe ich Cimco. Dort kann ich mir Makros erstellen wo alles hinterlegt ist. Zum Beispiel klicke ich auf das Makro:

Bohrer 5,55mm für Gefo M6 dann kommt automatisch das was ich hinterlegt habe:

* - T56 Bohrer 5,55
TOOL CALL 56 Z S2273.642 F159.154
TOOL DEF 706
CYCL DEF 200 BOHREN ~
Q200=+1 ;SICHERHEITS-ABST. ~
Q201=-12.0 ;TIEFE ~
Q206= AUTO ;VORSCHUB TIEFENZ. ~
Q202=+4 ;ZUSTELL-TIEFE ~
Q210=+0 ;VERWEILZEIT OBEN ~
Q203=+0 ;KOOR. OBERFLAECHE ~
Q204=+50 ;2. SICHERHEITS-ABST. ~
Q211=+0 ;VERWEILZEIT UNTEN
CALL LBL 706

Hier ändere ich nur noch die Tiefe und die Zustellung, falls nötig. Und dann kann ich auf das nächste Makro klicken usw.

Das schöne daran ist ich kann mir soviele Makros erstellen wie ich will und eine DXF Zeichnung kann ich dort auch öffnen und mir z.B. Konturen oder mehrere Bohrungen rausholen und die dann ins Programm mit einbauen.

Natürlich braucht man dazu einen PC und eine Verbindung zur Maschine.

Hallo!

Ich finde das, was du dort vorschlägst, schrecklich. Sollte ich so arbeiten müssen, käme ich mir nicht ernstgenommen und bevormundet vor.
Klar passieren Fehler in der Einzelteilfertigung, ich schließe mich da auch nicht von aus, aber das ginge mir persönlich zu weit.

Bei deiner Idee kann man das ganze fast noch ausweiten und komplett per CAM programmieren und die Fachkräfte an der Maschine
zu "Teileaufspannern und Nullpunktsetzern" machen.

Erfahrungsgemäß ist es sinnvoller doch den Menschen an der Maschine die Verantwortung zu überlassen.

Wenn sich allerdings solche wie von dir beschriebene Fehler häufen, würde ich ich eher über die Qualifikation der Mitarbeiter nachdenken, bzw über deren evtl nötige Weiterbildung.

Gruß, Stefan..

Hallo alle zusammen!
Ich freue mich über die rege Beteiligung an dem Thema. Ich bin grad auf Arbeit und hab einen Moment Verschnaufpause. Die Ideen von euch habe ich mal kurz überflogen. Wie ich sehe kennt jeder das Problem und hat sich schon so seine Gedanken darüber gemacht.
Die Ideen sind alle toll, bauen aber meist auf dem Prinzip einmal gemacht -> gespeichert und wieder aufgerufen. Da muß man sich erst mal ein Sammelsorium zusammenstellen.
Meine Idee ist:
Programmierer / Arbeitsvorbereiter oder sonstwer sitzt am PC mit der Zeichnung in der Hand und in ruhiger Umgebung.
Hochkonzentriert liest er alle nötigen Bearbeitungen aus der Zeichnung, also
M6 12 tief , M8 20 tief Aussenkontur von oben.
M10 M20 Rechtecktasche von hinten u.s.w.

In einer Maske wird abgefragt:
1. Gewinde? wie tief ? -> Senken automatisch mit vorgegeben WP-Senker
2. Konturzug? wie tief? ->Fase automatisch mit WP-Senker
3. Bohrung? wie tief? ->Senken automatisch mit WP-Senker
Hier wird alles aingetragen.

Dann wird ein Musterprogramm ausgegeben (vom Excel oder sonstwem) mit allen WKZ-Aufrufen (eventuell nach Werkstoff vorgegebenen Schnittgeschwindigkeiten und Vorschüben) sortiert nach Bohrer Fräser Senker Gewindebohrer Reibahle..... und denm Aufruf der entsprechenden Label.
Nach dem M30 in diesem Programm werden Musterlabel ohne Koordinaten mit Kommentar, alle nötigen Schwenklabel, Konturlabel, Freifahrlabel u.s.w. geschrieben.
Anschliessend können die Koordinaten eingeben und das Programm sofort gestartet werden.
So habe ich alles Nötige in einem Programm und kann dieses Sichern, oder auf eine andere Maschine übertragen.
Excel ist hier nicht zwingend notwendig, mir geht es nur um die Verabeitung einer Datenbank z.B. für alle möglichen Gewinde, Werkstoffe und Schnittgeschwindigkeiten.
Der Vorteil ist: Die Programme sehen immer gleich aus, nur die Koordinaten unterscheiden sich. Falsch eingegeben Steigungen gibt`s nicht mehr und zu geringe Bohrtiefen für`s Gewinde auch nicht (werden dann automatisch berechnet)
Die Tabelle für alle möglichen Gewinde mit Kernlochdurchmesser und Steigung ist schon in arbeit.
Dann geht`s an`s Eingemachte.
Vielleicht hat jemand Erfahrung mit Excel und hat was ähnliches schonmal gemacht?
Ich freue mich über jede Hilfe und wenn`s nur ein Kommentar ist!

Ich hoffe ihr erkennt hier, welche Absicht ich verfolge.
Ich freue mich aber gern über anderweitige Anregungen oder Lösungsansätze.

Hallo WarFish!

Du hast recht vielleicht lehne ich mich doch ein bisschen zuweit hinaus mit meinem Vorhaben und muß es dann wohl doch als Spinnerei abtun. Ich möchte hier dem Maschinenbediener eigentlich nicht die Arbeit abnehmen, die soll er ja selbst machen. Ich will ihm nur ein Hilfsmittel zur Fehlerminimierung in die Hand geben und die Programmierung umfangreicher Programme erleichtern. Ich denke da andas ewige "tool call cycl def" Eingeben werden doch nur die Finger wund. CAM-Programmierung ist mir auch geläufig, ich arbeite mit Mastercam. Die Mängel an diesen Systemen sind eben das, was du gemeint hast (Nullpunktsetzer und so), weil der Bediener nicht viel ändern kann und dazu verdammt ist dem nächsten Crash gelassen oder ängstlich zuzsehen. Ich gebe lieber eine fertige Kontur mittels Mastecam aus und der Bediener darf damit machen was er will und versteht auch noch nebehr, was passiert und ist in der Lage, etwas zu ändern oder den Gegebenheiten anzupassen. Cam-Systeme sind toll aber wenig flexibel. Ich würde mich da z.B. über eine bessere Zusammenarbeit zwischen Cam-System und Heidenhain wünschen.

Vielen Dank für die Kritik

Hallo

ich mache das meinstens bei einzelteile so das ich alle gleiche löcher z.b. m6 anzentriere dann mach ich ein andere bohrzy. und bohre die löcher in der zeit bediene die meine restlichen maschienen so mach ich das auch mit ner kontur dann kann da eigentlich nicht viel passiren und ich bediene normal 3 maschinen
2 einzelteile und eine maschiene serien teile was heist serien mehr wie 20bis 30 teilen haben wir nie. . da habe ich für mich ein rezept entwickelt und da bekomme ich richtig was runter.
ein cam programm haben wir nicht da kann ich nicht mitreden wie man da am besten rangeht.
ich habe schon oft bewerber gehabt die sagten sie können vieles programieren mich mit cheff besprochen eingestellt.
1 abeitstag dann fin das elend an konnten die einfachsten konturen nicht programieren denke mahl kommt von dem das die betriebe progamirer
einstellen die alles über cam oder so etwas programieren egal ob es wenig aufwendig oder aufwendiger ist die brauchen nur so ein dummen der das teil anfährt und start drückt wie oben schon angesprochen das währe auch nichts für mich. Wenn alles zu einfach währe währe es doch langweilig und ein bißchen kann man sich anstrengen und konzentrieren.

grüsse
andy

Unsere Probleme, kurz zusammengefasst: http://www.cnc-arena.com/forum/index.php?a...&pid=382531

Also bestens bekannt. Wobei wir am Anfang nicht zwischen Maschinenfehlern, Fehlern in der PLC, Übertragungsfehlern und Programmierfehlern unterscheiden konnten.... In der Softwareversion -1 gibt es ja nur Q-Parameter, also letztendlich nur globale Variablen... Die -1 war niemals wirklich geeignet, für komponentenorientiertes bzw. strukturiertes Programmieren...

Mit der -7 führte HH mit QL-Parametern lokale Variablen ein, mit QR-Parametern persistente....Sicher ein Schritt in die richtige Richtung, ABER auch nicht zu Ende gedacht. Will man eine höhere Programmeiersprache schaffen, ohne die Eignung des Problems wirklich verstanden zu haben, oder zu was sollen diese angehefteten Flicken ansonsten nützen?




Ist letztendlich ein Problem aus dem Softwareengineering und kann daher mit seit ca. 1980 bewährten Methoden auch gelöst werden.

Abriß unseres Lösungsvorschlag: http://www.cnc-arena.com/forum/index.php?a...&pid=373581

Niemand sagt, dass man in einem Programm jedesmal jedes Detail selbst formulieren muss. Wieviele Leute schieben heute noch große Programme komplett in Assembler???????




Joa, wir, Klaus Raddatz und ich (ich natürlich wesentlich mehr) haben uns mit dem Problem auseinandergesetzt..... und es hilft auch nichts, eine grundlegende Programmiersprache immer mehr aufblähen.....

Hier steht HH an einem Scheideweg....

• Soll alles in CAM generiert werden, praktisch als eine Visuelle Entwicklungsumgebung, Visual Studio lässt grüßen,
• oder lässt man handgeschriebenen Code zu. Dann muss man aber einen entsprechenden Entwicklugnsstapel anbieten können, wie das andere Anbieter von Softwarenentsiclungswerkzeugen so seit dreissig bis fünfzig Jahren (!) beherrschen...

Gruß, HA

...und Senktiefe, Vorschub1, Vorschub2, Senktiefe, Bohrtiefe, Gewindetiefe, Steigung sind Konstanten(1) oder Variablen(2)?

1. Falls es Konstanten sind, brauchst Du für jede geänderte Größe ein eigenes Unterprogramm. Wer soll da den Überblick behalten, welches Programm M6* welche Größen hat, also wie tief bohrt, senkt, Gewinnde schneidet, usw?
2. Falls es Variablen sind, bleiben ja nur Q-Parameter (QL haben nur lokale Bedeutung, QR sind persistent, macht auch keinen Sinn). Wer behält den Überblick, welcher Q-Parameter welche Bedeutung in einem großen Programm hat? Wann darf welcher Q-Parameter zur Übergabe von Werten an Unterprogramme genutzt werden? Wer stellt sicher, dass diese Parameter nicht versehentlich wo anders genutzt werden,und dann spätestens für die Werteübergabe an das Unterprogramm überschrieben werden usw. usw?.... Das Problem hier ist, dass Werte nur in globalen Variablen an Unterprogramme übergeben werden können. Genau das war ein Problem in FORTRAN mit den COMMON-Blöcken. Die sind genau aus dem Grund abgeschafft worden, da sie als eine Ursache für (extrem) schlechte Softwarequalität erkannt worden waren.

Ein paar Bemerkungen aus einem meiner anderen Leben, Gruß HA

http://catb.org/jargon/html/R/Real-Programmer.html

HA

Hallo Homerq,

zwischen Euch beiden öffnet sich genau der gleiche kulturelle Graben, der bei den (Computer-)Programmieren "Real Programmers" und "Whimps" trennt.

"Warship" ist ein echter "Real Programmer", während Du wohl sicher zu den "Whimps" gezählt würdest. Waren die "Real Programmer" unschlagbar, auf unzureichenden Systemen kleine, trotzdem kritische Programme ans Laufen zu kriegen, haben sich die "Whimps" in der heutigen Softwareentwicklung vollkommen durchgesetzt.

Kennzeichnend für "Whimps" war stets,

• dass sie Probleme hierarchisch gliederten (Flansch -> Lochkreis -> Mutterngewinde -> Senken, Kernloch, Gewinde schneiden),
• dass sie automatisierte Systeme nutzen, um ihre Lösungen zu formulieren (Integrierte Entwicklungsumgebungen),
• dass sie autmatiisierte Systeme nutzen, um ihre Lösungen zu versionieren und den Lebensdauerzyklus abzubilden,
• dass sie auf automatische Verfahren zurückgreifen, um ausführbaren Code generieren zu lassen ("Höhere Programmiersprachen", Compiler),
• dass sie auf automatisierte Verfahren vertrauen, um Fehler zu minimieren, ([statische] Codeanalyse)
• dass sie automatisierte Verfahren nutzen, um Fehler zu finden. (Simulation und Debugger)

Damit haben die "Whimps" im Mittel die Fehlerraten drastisch reduziert.

Gruß,

Hallo ,

Ich kann hier WarFish nur zustimmen ....

Ob ich einen Cyclus mit M99 oder Cycl. Call aufrufe ist ja grad mal sch... egal .
Wenn ein Fräser kein Gewinde herstellen kann , hat er an einer CNC nix zu suchen.
Jeder Fräser hat so seinen eigenen Stil , wäre ja schlimm , wenns nicht so wäre . Solange das Bauteil am Ende passt , ist das vollkommen egal .
Da über Programmdetails zu diskutieren = Kindergarten .
Dein Vorhaben halte ich für den totalen Krampf . einen AV mit ner Zeichnung alles ins Excel hakken zu lassen finde ich lachhaft - daraus ein Progi zu generieren entspricht der Neuerfindung des Rades = CAM

Sorry aber das ist ein Witz funktioniert niemals .

Gut wir haben eine CAD/CAM Komplettausstattung und jeder Fräser kann auch am CAD/CAM programmieren. Einfachere Bearbeitungen programmieren wir auch an der Steuerung ...... , da hat auch jeder so seine eigenen Vorlagen und Strategien - das Ergebnis ist das Gleiche .

Bitte nicht persönlich nehmen , aber die " mach ich schnell mit Excel " Menschen , kennt man reichlich , die machen sich manchmal aus purem Aktionismus ganz viel Mühe und am Ende nutzt es keine Sau .

M kbG Matz

Deine Lösung mit Excel ist schwachsinn. Das was du suchst nennt sich CAM!!!



Dafür gibt es CAM oder Cimco!!

Hallo!

Damit fühle ich mich, als von dir so genannter "real programmer", in meiner Wertschätzigkeit herab gesetzt..Gerade
wegen deiner Auflistung..
Wer sagt denn das es nicht möglich ist sich solche Dinge einfach mal zu merken und mit diesen Erfahrungswerten zu arbeiten?

Gerade DAS macht doch den guten Mitarbeiter aus. Ich denke nicht das sich der "whimp" durchgesetzt hat, aus eigener Erfahrung heraus
ist doch der "whimp" immer noch auf den "Real programmer" angewiesen. Der sagt doch ob ein CAM-generiertes Programm
gut läuft oder nicht. Die software kann noch so oft sagen wie sie will:"läuft!"

In der Realität, speziell in der Einzelteilfertigung, sind Theorie und Praxis echt zwei verschiedene Dinge..

Gruß, Stefan..

Hallo!

Danke für die Antwort. Cam kostet für mein Vorhaben zu viel Geld und wird am Ende zu wenig genutzt. Richtig ist, ein Teil des CAM, nähmlich der Postprozessor, ist genau der Teil, den ich zum generieren brauche, der Rest ist dem Programmierer überlassen, der dann eben nicht nur Nullpunktsetzer ist!
Klammert euch bitte nicht an Excel fest. Wenn ich es könnte, würde ich ein Programm für Windows schreiben (das hat ja jeder und kostet nicht extra). Da ich der Computersprache nicht mächtig bin suche ich nach einer Schnittstelle (z.B. Excel, hat ja fast jeder), die ich halbwegs beherrsche.
Und bitte haltet euch mit Aussagen "Das ist absoluter Quatsch" zurück. Es geht hier um die Lösung eines Problems. Meinungen sind durchaus erwünscht, aber nur dann, wenn sie auch begründet werden. Alles andere drumherum interessiert mich nicht. Bitte nicht persönlich nehmen!

Weiter So! Ich freue mich über jeden Beitrag!

Zitat: Alles was man sich Vorstellen kann, geht auch zu verwirklichen, es muß auf alle Fälle einen logisch nachvolltiehbaren Hintergrund haben!
(Verfasser nicht bekannt)

Hallo!

Mit deiner Einstellung "ist alles egal" kommen in unserer Firma nur die durch, die sich dann auch um alle komplizierten Aufgaben herummogeln und auch sonst so alles bestens finden, wie es ist. Nach meiner Meinung sind aber gerade DIE fehl am Platze, die sind dann halt wirklich nur Knöpfchendrücker, die immer wieder das selbe tun und keine Leidenschaft im Beruf an den Tag legen. Sie lehnen alles Neue ab und werden auch noch in 10 Jahren Zyklus 1 verwenden, wenn er bis dahin nicht endlich ganz verschwunden ist, warum auch, funktioniert doch. Dann hätte die Menschheit auch nach der Dampfmaschine das selbe sagen können.
Aber auch deine Kritk hilft, da begründet und einen weiteren Aspekt über die Nützlichkeit einer solchen Programierhilfe, so will ich es mal bezeichnen.

Vielen Dank dafür!

Die meisten hier dürften einige Zehntausend Zeilen Code geschrieben haben, egal in welcher Programmiersprache. Die/unsere Probleme liegen wo ganz wo anders, als in mangelnden intellektuellen Fähigkeiten oder mangelnder praktischer Erfahrung. Nochmals die Argumente zusammengefasst:

• Die Größe der CNC-Programme lässt uns in die klassischen Probleme des Softwareengineerings laufen.Diese Probleme hatten die Jungs und Mädels aus dem Bankenbereich und Buchhaltung ("DATEV", "SAP") schon ab 1970. Die sind also alles andere als neu.
• Um diese Probleme herum brachen Glaubenskriege aus, Entwicklungen blockierend und Feindschaften stiftend.
• Dabei waren die Grundlagen einer sachzentrienten Diskussion ab ca. 1960 gegeben, Assembler waren Standard, FORTRAN von Backus mit allen Mängel, letztendlich unstrukturiert, , ALGOL als strukturierte Programmiersprache und LISP (siehe AutoLISP, MacCarthy) als Programmiersprache, die ALLE Verarbeitungsmodelle unterstützt.... (Bemerkung: Mittels LISP wurden beretis rein funktionale Ansätze ausprobiert, die Backus zehn Jahre später selbst übernommen hatte, aber vorher vehement bekämpfte...)
• Am Werdegang von Backus sieht man, wie gefochten worden war. War Backus die treibende Kraft hinter FORTRAN, und war für die Entwicklung von FORTRAN hochgeehrt worden, so zeigte er 1978 (!) die fundamentalen Mängel seiner eigenen Entwicklung auf, einen alternativen Ansatz, und wurde dafür nochmals hochgeehrt. (Einfach in Google suchen "Backus FORTRAN", "Backus Functional Programming")
• Die Ergebnisse im Softwareengineering explodierten, und wir können und sollten (!) uns deren Ergebnisse zu eigen machen. Wir haben seit ca. dreißig Jahren Standardmethoden, um unsere Probleme zu lösen.
  Warum sollten wir geschlagene Schlachten nachstellen, vielleicht als Kommödiantengruppe? Das überlassen wir doch gerne den Leuten auf den mittelalterlichen Weihnachtsmärkten und Burgspielen.
  Die Doyen der Programmiersprachen (Backus, Wirth,, MacCarthy[?]) und deren Mitarbeiter haben sich ja schon im letzten Jahrhundert als Gurkentruppe im Kindergarten aufgeführt. Warum sollten wir es ihnen gleichtun?
• In einer textbasierten Programmierung fehlen uns die Abstraktionsebenen, seien es Methoden, Variableninhalte zu übergeben, Geltungsbereich von Variablen vernünftig zu beschränken, ablaufunabhängig Beziehungen von Größen untereinander zu definieren usw. usw. usw, überhaupt
  (Fertigungs-)Vorgänge über komplexe Strukturen definieren zu können und zu gliedern, widerspruchsfrei und konsistent!
  Beispiel: Aufgabe "MutternGewinde.fertigen(Mxx, Tiefe yy, Fase z)".... Müssen wir einmal festlegen als (Bohrung.fertigen(Kernloch.Tiefe( yy, Kernloch.Durchmesser(Mxx), Fase.Fasen(z, Mxx), Mxx.Gewindeschneiden(Tiefe yy))...
  Bohrung.fertigen, Fase.Fasen,Mxx.Gewindeschneiden, sind Teilaufgaben, Kernloch.Tiefe und Kernloch.Durchmesser sind Funktionen, die eben aus bekannten Größen unbekannte Größen berechnen (auch nur in einer Tabelle nachgucken...)
  Da uns diese Abstraktionsebenen fehlen, können wir eben nicht realen Komponenten ihre entsprechenden Programmteile einfach zuordnen. Dabei gibt es Methoden (Mathematik:Kategorientheorie), genau Programm-Objekten Objekte aus der realen (Zeichnungs-)Welt mit ihren Eigenschaften(!) zuzuordnen. Die Mathematik dahinter müsst Ihr nicht verstehen. Diese Methoden haben uns aber die Anbieter der Programmiersysteme zur Verfügung zu stellen....Das Methoden sind Standardwissen. Punkt. Aus.Basta.
• Gegen eine alleinige Verwendung von grafisch-interaktiven Systemen zur Codeerzeugung sprechen bei CAM die gleichen Argumente wie sie gegen Visual Studio sprechen... Diese Systeme können grafisch interaktiv immer nur Gerüste vernünftig erzeugen.. Code muss praktisch immer händisch nachgeführt werden und/oder verbessert werden.
  Haben wir ein CAM-System, das nach DIN-ISO übersetzt, so nutzt diese CAM nicht die vielleicht wesentlich mächtigeren Befehle der jeweiligen Steuerung. Vielleicht kriegt das CAM noch einen Werkzeugwechsel vernünftig hin, aber wie ist es bei Spänebruch, Messzylus etc. etc??? Da wird man meistens händisch/textuell nachbessern müssen, wie beim Code aus Visual Studio.
• Dementsprechend gehe ich davon aus, dass man beide Methoden der Programmierung wird beibehalten müssen.... Bei den Computerprogrammen war es bisher ja auch so.

Dass der Ansatz von "homerq" über Excel unzureichend ist, ist unstrittig. Aber der teil-funktionale Ansatz, wenigstens aus bekannten Größen die (meisten) unbekannten zu berechnen, ist richtig. "Homerq" ist mutmaßlich Zerspaner, und kein (promovierter) Informatiker. Obengenanntes betrifft aber genau zwei Teilbereiche der Informatik, Softwareengineering/Programmierung und Grundlagen der Informatik/Kategorientheorie. Darum sollen sich dementsprechend Informatiker kümmern.

Wir sollten "homerq" nicht vorwerfen, dass er zuwenig Kenntnisse in der Informatik hat. Bereits sein Ansatz über Excel ist besser, als mancher implementierter Ansatz in Programmiersystemen..

Bittere Grüße, HA

Hallo!

Die Einteilung in whimps und realprogrammer trifft hier glaube ich nicht so zu, weil dabei, wenn ich es richtig verstanden habe, der realprogrammer mehr Grundwissen besitzt. Also ich bin der Programmiersprache heidenhain durchaus mächtig und habe schon zig Prigramme mit Parameterberechnungen geschrieben. Eigentlich würde ich mich selbst mehr als realprogrammer bezeichnen. Da ich vielleicht 1 mal in der Woche am Rechner sitze, um etwas zu programmieren. Leider setzt heidenhain ziemlich viele Einschränkungen und ist leider nicht bereit, wie bei meinem letzten Porjekt "Kopfschwenken", oder nicht in der Lage, Unterstützung zu bieten. Die sagen "geht nicht", jetzt läuft`s bei uns!
Trotzdem auch ein interessanter Aspekt!
Danke und weiter so!

Keine persönliche Wertung, sondern genau die Aufgabenteilung, die ich oben angegeben habe. Für kleine Programmieraufgaben und Wegwerf-Programme in der Einzelfertigung ist der Ansatz des "Real Programmers" durchaus zu vertreten, soweit nicht die notwendige QS dagegen spricht.



Je größer und komplexer Programmieraufgaben werden, desto weniger ist der Ansatz des "Real Programmers" geeignet, hochwertige Software zu erzeugen.

Dieser Umstand wurde gerade von IBM intensivst untersucht, denn viele Programme auf IBM-Maschinen stammten aus 1960 bis 1970 und waren notwendigerweise alle von "Real Programmer" geschrieben, da wegen mangelnder Ressourcen das letzte aus den Rechnern herauskitzelt werden musste und der Programmierstil störte auch nicht, da die Programme auf Grund mangelnder Ressourcen einfach klein waren.

Je leistungsfähiger die Systeme wurden, desto weniger wurden die Ansätze von "Real Programmer" benötigt, sondern dann als kontraproduktiv erkannt, da mit größeren Programmen die Fehlerwahrscheinlichkeit explodierte, man aber trotzdem stabile und wartbare Programme benötigte....

Gruß, HA

Es sind natürlich zwei Pole, wobei sich der Code von sog. "Whimps" tatsächlich durchgesetzt hat....

Dass man diese Einteilung mit einem Augenzwinkern betrachten muss, dafür bin ich selbst das beste Beispiel.... Habe ich sehr häufig Programmiersprachen höchster Abstraktionsstufe genutzt (Maxima/MacSyma, R, Octave etc. etc.), so habe ich auch jahrelang Assembler auf MC68020 geschrieben, und sogar Microcode für Spezialsteuerungen. (Das ist einer meiner Hintergründe, jetzt wisst Ihr das einmal...)

Die beschränkten Möglichkeiten und Fähigkeiten einer Heidenhain-Steuerung erfordern den "Real Programmer". Dessen Ansätze verursachen aber auch zwingend eine erhöhte Fehlerwahrscheinlichkeit gg. den Ansätzen der "Whimps". Für diese erhöhte Fehlerwahrscheinlichkeit kann aber niemand persönlich, sie ist eben gerade nicht eigenem, persönlichem Versagen geschuldet.

In einem neuen Anlauf möchte man aber genau diese Probleme vermeiden, oder habe ich da etwas falsch verstanden?

Gruß und Grinsen, HA

Der Beitrag wurde von adamsh bearbeitet: 16.02.2013, 12:27 Uhr

Hier mal ein Auszug aus deinem ersten Beitrag:



Und dann schreibst du das:



Weißt du eigentlich selber was du willst???

Wieviel Ahnung hast du von Excel??? Kannst du überhaupt Makros, Variablen usw. über Excel proggen??

Das ist genau das, was Informatiker Codegenerator oder Compiler-Backend nennen. Damit dieser "vernünftigen" Code erzeugen kann, benötigt er eine komplexere Infrastruktur und komplexere Eingaben, als Du sie im so liefern kannst.



Da wir uns darin zumindest ein bisschen unterscheiden, haben wir/ich den Vorschlag mit "Scala" (vgl. http://www.scala-lang.org/ ) gemacht. Nach meiner Kenntnis ist zu erwarten, dass das so funktionieren würde, vgl.: https://de.industryarena.com/forum/index.ph...amp;#entry37358. Pikantermaßen orientiert sich Siemens bereits in diese Richtung.

Die Schnittstelle bzw. das gegenseitige Einbetten könnte funktionieren wie hier angegeben http://www.cnc-arena.com/forum/index.php?a...&pid=373581.




Gruß, HA