kleines NC-Analysetool, Anforderungsliste?

Hi Leute,

wie wärs denn mit einem KLEINEN Analysetool für G-Code!? Falls es sowas hier schon gibt und ich es nur übersehen habe so lasst mich das doch einfach kurz wissen.
Ansonsten wollte ich demnächst mal ein paar Studenten an so ein Tool setzen. Vielleicht können wir ja hier schon mal eine Anforderungsliste sammeln!? Ein paar Analyseanforderungen gab es ja schon bei dem Editor. (Soll zunächst mal kein absolutes HIGH-TECH Tool sein - dafür gibts ja genug teure CAM Software - sondern nur das Pendant zu dem NC-Editor)
Eine echte 3D-Darstellung sollte schon drin sein denke ich. Diese würde dann auf OpenCascade (OpenGL) basieren. Weiss nicht wie schnell eure Rechner sind und wie Hardwarehungrig die 3D Darstellung bei großen Programmen (60000 G-Sätze) würde. Müsste man dann halt mal testen.
Also: Was für Funktionen zur Anzeige/Analyse würdet ihr euch wünschen?

Gruß Mirco

klingt nicht schlecht was du vorhast

Eine Fräserwechsel / Operationswechsel sollte auf jedenfall dabei sein, wenn möglich farblich unterschieden


was alles möglich ist weis ich nicht da ich in dieser sache eine totale null bin aber dafür gibt es ja dich und andere

Moin,

wie wäre es mit:

- Zeitberechnung

- Werkzeugliste

- maximal/minimal-Koordinaten in X Y Z

Soweit die nicht-grafische Analyse.

Wenn Ihr dann irgendwann auf das Problem stossen werdet, Radiuskorrektur zu simulieren, können wir gern weitere Gedanken dazu austauschen.

Viel Spaß bei der Programmierung

Thorsten

Hallo,
gute Idee,
mir fällt dazu ein:
Darstellung von Fräszyklen (Taschenfräsen, Bohren, usw)

Anzeige der Anfahrwege, Eilgänge farblich

Ich denke mit ein paar Stunden wirst du da nicht hinkommen.

Falls du Unterstützung beim programmieren brauchst.
Vielleicht kann ich helfen.

Mit Grafik kenn ich mich allerdings gar nicht aus.

Ich Programmiere mit VB.Net.

Hi,

ok - also zunächst schonmal vielen Dank für die Antworten.
Mit den "paar Stunden" werden wir erstmal anfangen - mal sehen was draus wird. Vielen Dank auch für das Angebot zur Unterstützung - vielleicht komm ich drauf zurück
Zu der Zyklen Anzeige: Was genau soll denn da angezeigt werden - die Werkzeugbahn oder nur wo ein Zyklus aufgerufen wird?
Eilgänge farblich hervorgehoben ist kein Problem.
Zeitberechnung: Diese würde dann zunächst mal nur unter idealisierten Bedingungen erfolgen, da keine Maschinendynamik hinterlegt wäre - ist aber dann kein Problem
Hmm... Werzeugliste heisst im Detail? Alle Werkzeugwechsel in eine Liste aufnehmen?
Was genau ist mit Operationswechsel gemeint?

So far...
Mirco

Hallo Mikro,

Am besten wäre, so wie es bei der Maschinengraphik auch dargestellt wird, nämlich das Ergebniss der gefrästen Tasche oder Bohrung. Dies kann bei einer Draufsicht eine Kontur der Tasche oder Bohrung sein.
Das Werkzeug selbst darzustellen ist nicht erforderlich.
Dazu ist natürlich wichtig, daß alle Werkzeuge vorher durchmesserbezogen definiert werden, sonst stimmt das Ergebniss der Bearbeitung nicht.

Als Beispiel

Operation 01: Mit einem Werkzeug parallel fräsen
Operation 02: mit dem selben Werkzeug Konturfräsen. usw

Hi Camly,

hmm... das ist machbar, wird aber sicherlich erst eine der weiteren Funktionen werden (kann ein klein wenig dauern). Für welche Steuerung sollen das denn die Zyklen sein. Das Problem dabei ist, dass dann ja für jeden Steuerungshersteller die spezifischen Zyklen quasi "nachprogrammiert" werden müssen. Zumindest müssen für jeden Hersteller die entsprechenden Parameter in die Taschengeometrie umgerechnet werden.

Mirco

Hi UliCam,

stehen diese Operationswechsel denn bereits als Kommentare in der Datei drin? Weiss sonst nicht so recht wie ich aus einer Masse G01,G02,G03 die Art der Operation bestimmen soll!?

Gruß Mirco

ja, das könnte aufwendig werden.
Allerdings bei Bohrungen wäre es in der Draufsicht egal, da ist nur der Werkzeugdurchmesser maßgebend.
bei Kreistaschen ist es auch wurst wie ausgeräumt wird.
bei Rechtecktaschen müsste man jedoch die Eckenradien noch mit einbeziehen.

Hi,

ich schreibe momentan gerade ein Zeitberechnungsprog. in VB6. Es liest die Fahrwege, Bohrzyklen etc. ein und berechnet daraus eine Zeit. Mein Problem ist, dass ich aus der Inforamtik komme. Habe also nicht wirklich viel Ahnung von nc-Programmen gehabt...
Das hat sich mittlerweile geändert! Trotzdem stimmen die Zeiten noch nicht alle.
Ich habe eine Frage bezüglich der Fahrwege. Da es sich ja um ein 3d Koordinatensystem handelt habe ich folgende Berechnugen angestellt:

G0 X-15 Y-15 --> 1,4 s
G0 Z2 --> 1,88 s
G1 Z-10 --> 7,2 s
G1 Y0 --> 12,72 s
G1 X120 --> 114,55
G1 Y60 --> 4,24
G1 X115 Y65 --> 66
G1 X5 --> 4,24
G1 Y0 --> 50,91
G1 Z2 --> 14,4
G0 Z150 --> 2,076
G0 X150 Y150 --> 1,27

Meine Ergebnisse habe ich mit --> gekennzeichnet.
G0 = 36000 mm/min
G1 = 100 mm/min.

Ges.Erg.= 5min42s

Kommt ihr auf die selben? Ist das so richtig?
Die Werte sind natürlich erfunden... Es ist ja auch nur ein einfaches Prog..

Ich hoffe ihr helft mir.

Gruß Andi

Hi Andy,
Bei der Eilganggeschwindigkeit, solltest du eine Variable für den Programmierer machen.
Ich arbeite mit Maschinen, deren Eilganggeschwindigkeiten zwischen
7000 und 15000 mm/min liegt.
Auch achsabhängig differentiert.
Auch sollte eine Variable geschaffen sein, für die Werkzeugwechselzeit.

Habe da Span zu Span Zeiten von 3 bis 15 sek.

Gruß Rolf

Du brauchst auf jeden Fall eine .INI in der du die max. Achsgeschwindigkeiten hinterlegst. Bekannterweise kann nur die langsamste Achse die Geschwindigkeit vorgeben(bei z.B. der Mehr-Achsenprogrammierung, was ja eigentlich dem Normalfall entspricht).

Wichtig wäre auch die Abfrage auf welchen Durchmesser bei circularen Achsen gearbeitet wird damit man z.B. vom Einheitskreis zurück auf den echten Vorschub rechnen kann.

Bei vielen Achsbewegungen wäre noch die Start bzw. Bremsrampe zu beachten(Kommt bei besonders großen Maschinen zum tragen).

Genau Halt ist natürlich auch ein Thema da die Maschine hier immer zum absoluten Stop und dann wieder zur Beschleunigung kommt.

Werkzeugwechselzeiten mit und ohne Werkzeugvorwahl sollte natürlich auch berücksichtigt werden.

Noch ein paar Kleinigkeiten.....
1.) äquidistante Linie oder Echtkontur bzw. kompensiert oder nicht.
2.) Unterprogramme
3.) Hersteller-Zyklen
4.) Anwenderdefinierte Zyklen
5.) Verweilzeiten
6.) Kopfwechsel
7.) Technologiewechsel (Drehen,Fräsen, Bohren usw...)
8.) Werkstückwechselzeit
9.) Nebenzeitberechnung
10.) Verteilzeitberechnung
11.) Hauptzeiteberechnung
12.) Werkzeugbestimmung(es gibt ja nicht nur rotationssymetrische Werkzeuge)
12.) da wär bestimmt noch was...auf die schnelle fällt mir aber nichts mehr ein.......

Nicht entmutigen lassen....wollte nur darauf Aufmerksam machen das man eine Zeitberechnung NUR für eine spezielle Maschine und einen speziellen Betrieb sicherlich in ein paar Tagen(ca. 5-10Tagen) programiert bekommt.

Allerdings, eine allgemein gültige Software zur Zeitberechnung wird mit Sicherheit nicht weniger als 3 bis 6 Monate(Drehen, Fräsen, Bohren....unterschiedliche Steuerungen...unterschiedliche Strategien..unterschiedliche Zyklen...usw...) in Anspruch nehmen.

Dann hat man allerdings erst das Grundgerüst programmiert. Soll heissen, wenn man hier schon das falsche Konzept entwickelt hat , wird man nach ein paar Monaten wieder von vorne Anfangen.

Seit also bitte ein wenig vorsichtiger mit euren Aussage das ein Programm in ein paar Stunden...bzw. wenigen Tagen fertig sein kann...

Selbst die Aussage das zumindest das Grundgerüst in einigen Stunden programmiert ist und das danach selbstverständlich noch weitere Detailarbeit reingesteckt werden muß verfälscht das Gesamtbild der NICHTPROGRAMMIERER dermaßen, so das es aussieht als wenn selbst komplexeste Zusammenhänge, in wenigen Tagen programmiert und die Problematiken somit alle erledigt wären.

Wenn wir Programmierer ein wenig unser Ego zurücknehmen würden, dann wären publizierte Entwicklungszeiten für ein bestimmte Software wahrscheinlich um den Faktor 10 bis 50 höher.

Es ist bis jetzt kein NC-Editor, NC-Simulation, NC-Zeitberechnung, 3D-Simulation usw...usw...usw... mal soeben nebenbei geschrieben worden.


Gruß
- Spieler -

Ich denke das VB6 für eine derartige Anwendung performancekritisch wird .
Ich meine wirklich interessant werden solche Zeitberechnungen doch erst für Cam-generierte 3D Programme mit ein paar tausend NC Sätzen (und dort ist meist so etwas schon dabei).

"
G0 X-15 Y-15 --> 1,4 s
G0 Z2 --> 1,88 s // diesen Wert mit den unten
G1 Z-10 --> 7,2 s
G1 Y0 --> 12,72 s
G1 X120 --> 114,55
G1 Y60 --> 4,24
G1 X115 Y65 --> 66
G1 X5 --> 4,24
G1 Y0 --> 50,91
G1 Z2 --> 14,4
G0 Z150 --> 2,076 // ins Verhältnis gesetzt, wäre doch fehlerhaft berechnet oder?
G0 X150 Y150 --> 1,27
"

vielleicht habe ich dein Beispiel aber auch nicht richtig verstanden

Hi,

erstmal danke für die vielen Antworten.
Also ich programmiere schon sei ca. 2 Wochen an dem Programm rum, wobei VB nicht wirklich die Programmiersprache ist, bei der ich mich richtig gut auskenne... Ich muss sie halt verwenden.
Mein Prog. berücksichtigt bisher: WKZ, Tischdrehungen, Bohrzyklen, Stops im Programm, dazu die Hauptwerteermittlung (G0, G1, G3, G4).
Natürlich ist dies alles sehr maschinenabhängig. Daher lese ich die maschinenabhängigen Daten später aus einer DB ein. Gerade läuft das noch über eine Excel-Tabelle, wo die Daten (G0, WKZ,...) drinstehen.
Mein momentanes Problem: Irgendwie stimmen die Grundberechnungen der Wege nicht so ganz (G0, G1). Mein Programm hat momentan eine Abweichung von +1:30 min (von einer handgestoppten Zeit) bei 600 Zeilen nc-Code.
Daher möchte ich nochmals ganz an den Anfang zurück... Die Grundberechnungen der Wege (G0, G1). Wäre toll, wenn ihr mir da helfen könntet. Der Tipp mit dem G0-Z ist schon mal nicht schlecht. Werde das gleich mal überprüfen...
Natürlich wird es schwierig werden ein allgemeingültiges Programm zu implementieren, was alles kann. Da ich die Einschätzung von ein paar Monaten fast noch zu niedrig...
Oder es arbeitet dann ein ganzes Team an so einem Projekt...

Gruß Andi

G0 X-15 Y-15 --> 1,4 s
G0 Z2 --> 1,88 s
G1 Z-10 --> 7,2 s
G1 Y0 --> 12,72 s
G1 X120 --> 114,55
G1 Y60 --> 4,24
G1 X115 Y65 --> 66
G1 X5 --> 4,24
G1 Y0 --> 50,91
G1 Z2 --> 14,4
G0 Z150 --> 2,076
G0 X150 Y150 --> 1,27

Meine Ergebnisse habe ich mit --> gekennzeichnet.
G0 = 36000 mm/min
G1 = 100 mm/min.

------------------------------------------------------------------------------




habe nicht nachgerechnet, aber auf den ersten Blick stimmt hier fast kein einziger Wert. Oder hab ich was falsch verstanden ????

G1 X120 --> 114,55 ------- 81



G1 X115 Y65 --> 66 --------- 3


G1 X5 --> 4,24 ------ 66


G1 Y0 --> 50,91 -------- 39


usw....

Hi,

wie hast du die Werte berechnet?
Wäre nett, wenn du mich teilhaben lassen könntest?

Meine Berechnung (aus Prog.):
erg_x ist der alte Wert - neuer Wert von X...
bei erg_y ist es wie bei X...
Dann so:
erg_xy = Sqr((erg_x ^ 2) + (erg_y ^ 2))
End If
'zeit
zeit_G1_xy = erg_xy / geschw_G1 * 60

Habe also mit Pythagoras gerechnet.

Gruß Andi

Hi,

hat sich erledigt, habe den Fehler gefunden!

Gruß Andi

Hi,

gibt es denn irgendwo (Inet) ein Freewaretool? Oder ne Testversion? Bräuchte das zur Kontrolle.

Gruß Andi

Genau daran hab ich mir Tagelang die Zähne ausgebissen...und wirklich helfen konnten mir auch nicht gerade viele Leute.

Das ist ziemlich hohe Mathematik...jedenfalls für mich.

Für mich ist das auch der falsche Mathe-Level.
Problem Radiuskorrektur fängt aber mit wesentlich einfacherer Mathematik an: Du müsstest ja eine Äquidistante zum NC-Prog rechnen, nicht ? Es steht aber wahrscheinlich nirgends der Werkzeugdurchmesser in Nc_Programm geschrieben (normalerweise).
Da kanns schon schon zu großen Abweichungen kommen, wenn man nur eine scharfe Ecke im NC-Prog hat, der Fräser aber kreisförmig an der dieser Ecke abwälzt.

Wie weit ist das Projekt gediehen ?

Gruß,
Thorsten

Naja, wenn im Prog. der Fräserdurchmesser nicht steht kann man ihn ja vom Bediener abfragen. Das ist nicht das Problem. Aber sonst sind deine Ausführungen schon richtig. Das mit der Werkzeigbahnberechnung ist nicht soooo einfach wie man sich das vielleicht vorstellt.

Wenn du mein Projekt meinst...dem geht's soweit ganz gut...nur kostet es mich immerwieder Jahre meines Lebens.

Hast Du auch schon mal drann gedacht das z.B. bei einem G0 die Achse nicht gleich mit 35m/min losfährt sondern erst noch beschleunigt werden muß. Mit dem Auto kann man ja auch nicht gleich aus dem Stand mit 100km/h fahren. Man muß ja auch erst einmal Beschleunigen. Dazu kommt dann wieder das Bremsen. Bei kurzen Wegen kommt man oft gar nicht auf die volle Eilganggeschwindigkeit. Bei G1/G2/G3 verhält sich das fast genauso.

Der Beitrag wurde von Armageddon bearbeitet: 07.06.2007, 14:46 Uhr