- Beiträge
- 15.559
- Reaktionspunkte
- 4.188
-> Hier kostenlos registrieren
Na ja, wenn du also weißt, worum die Frage geht, warum antwortest du dann nicht auf die Frage. Würde ja sicher alle interessieren.
G-Code: Wo sinnvoll und wo nicht?
- Ersteller Pippen
- Erstellt am
-> Hier kostenlos registrieren
Peter Gedöns
Level-2
- Beiträge
- 953
- Reaktionspunkte
- 327
Für mich ist es ganz klar einen Anwendung für eine CNC Steuerung,
die kann jede x beliebige Kontur abfahren , die Kontur kann in einer genormten Sprache allgemeingültig beschrieben werden G-Code .
die Kontur wird in X,Y,Z Koordinaten System beschrieben , die NC setzt das intern auf die Kinematik des Roboters um .
dann wird das ganze System noch bewegt , in X oder der Y Achse Linear also noch eine Transformation.
Aber die Diskussion PLC oder G-Code ist für mich befremdlich, was ich so gelesen habe was sich die Leute vorstellen unter G-CODE.
hat mich erstaunt,
die kann jede x beliebige Kontur abfahren , die Kontur kann in einer genormten Sprache allgemeingültig beschrieben werden G-Code .
die Kontur wird in X,Y,Z Koordinaten System beschrieben , die NC setzt das intern auf die Kinematik des Roboters um .
dann wird das ganze System noch bewegt , in X oder der Y Achse Linear also noch eine Transformation.
Aber die Diskussion PLC oder G-Code ist für mich befremdlich, was ich so gelesen habe was sich die Leute vorstellen unter G-CODE.
hat mich erstaunt,
-> Hier kostenlos registrieren
Nein, es geht tatsächlich um die "Programmiersprache G-Code". Es geht darum, in diesem Bereich möglichst viel in den Hochsprachenbereich zu verlagern: Vor allem das Generieren des G-Code.
Und genau da habe ich meine Bedenken, da ich G-Code überhaupt nicht kenne. Ich denke, wir verlieren dadurch viel Flexibilität. Wir müssen ja reagieren können.
Genau das ist das Ziel. Der G-Code soll generisch erzeugt werden. Vielleicht von einem Programm, das wir einkaufen. Die PLC soll sich um alles andere kümmern, nur nicht darum.
Und was verstehst Du an dieser Diskussion nun nicht?
-> Hier kostenlos registrieren
Da gibts noch was zu Siemens Hochsprachen...
Genau so machen wir das heute auch. Die Idee ist nun, das wie beschrieben zu ändern. Deshalb meine Frage: Ist die neue Überlegung sinnvoll. Ich bin da noch sehr skeptisch. Wenn diese Idee aber von vielen geteilt wird, lasse ich mich gerne eines Besseren belehren.
-> Hier kostenlos registrieren
@Pippen Danke für die Bestätigung, dass eure Anlage zumindest ähnlich zu unserer ist.
Ich habe mir das Thema vor ein paar Jahren auch mal aus deiner vorgeschlagenen Richtung betrachtet.
Was mich aber am Ende davon abgebracht hat, war die Überlegung was man am Ende will oder braucht.
Der aktuelle Stand ist so ausgelegt, dass möglichst viele Parameter konstant bleiben und man trotzdem hochflexibel lackieren kann.
Was ist der grundsätzliche Hintergrund deiner Überlegung?
Zusätzlich steigt aus meiner Sicht die Möglichkeit der Fehler, wenn möglichst viel variabel abläuft. Und um eine gewünschte konstante Auftragsmenge zu applizieren musst Du entweder sehr viel rechnen, um den Vorschub variabel anzupassen je nach Breite des Materials (mit einem Rattenschwanz bei verketteten Anlagen) oder die Auftragsmenge über den Pumpendruck aktiv regeln, da wird dir der Prozess selbst aber einen Strich durch die Rechnung machen.
Was noch dazukommt ist die Auswirkung eines Mini-Fehlers: das ganze Werkstück ist fehlerhaft, was aber nur schwer automatisch zu detektieren ist...
Ich habe mir das Thema vor ein paar Jahren auch mal aus deiner vorgeschlagenen Richtung betrachtet.
Was mich aber am Ende davon abgebracht hat, war die Überlegung was man am Ende will oder braucht.
Der aktuelle Stand ist so ausgelegt, dass möglichst viele Parameter konstant bleiben und man trotzdem hochflexibel lackieren kann.
Was ist der grundsätzliche Hintergrund deiner Überlegung?
Zusätzlich steigt aus meiner Sicht die Möglichkeit der Fehler, wenn möglichst viel variabel abläuft. Und um eine gewünschte konstante Auftragsmenge zu applizieren musst Du entweder sehr viel rechnen, um den Vorschub variabel anzupassen je nach Breite des Materials (mit einem Rattenschwanz bei verketteten Anlagen) oder die Auftragsmenge über den Pumpendruck aktiv regeln, da wird dir der Prozess selbst aber einen Strich durch die Rechnung machen.
Was noch dazukommt ist die Auswirkung eines Mini-Fehlers: das ganze Werkstück ist fehlerhaft, was aber nur schwer automatisch zu detektieren ist...
Das ist nicht meine Überlegung. Sondern die Überlegung der SW Architekten, die sich bereits jetzt mit der Architektur unserer neuen Software beschäftigt haben. Ich bin derjenige, der die ganze Sache kritisch hinterfragt.
Die Überlegung war, dass wir alle diese aufwendigen Berechnungen auslagern und vielleicht auch extern geben können. Die Schnittstelle zu diesen Programmen wäre dann nur noch ein File mit diesem G-Code.
Gerhard Bäurle
Schreibender Ingenieur
- Beiträge
- 7.088
- Reaktionspunkte
- 2.625
Vielleicht liegt es einfach an Deiner Fragestellung?
Eine Pseudo-Diskussion starten, dann die Katze halb aus dem Sack lassen – und sich nun wundern, dass die Diskussion ein Gestocher ist ...
-> Hier kostenlos registrieren
Ich finde die Diskussion hochinteressant und spannend. Ausserdem finde ich die Steuerung überhaupt nicht relevant. Deshalb habe ich sie nicht erwähnt.Vielleicht liegt es einfach an Deiner Fragestellung?
Eine Pseudo-Diskussion starten, dann die Katze halb aus dem Sack lassen – und sich nun wundern, dass die Diskussion ein Gestocher ist ...
Naja der Ansatz zum erzeugen des G-Codes ist doch nicht völlig falsch.
Am Ende ist es doch wie der Slicer für den 3D Druck. Das 3D Teil wird in G-Code überführt und die Achsen fahren danach.
Ihr Scannt das Teil (3D Teil) erzeugt daraus den G-Code mit den jeweiligen M-Befehlen und "gut" ist.
Der PLC Entwickler hat nur "noch" die Aufgabe auf die jeweiligen M-Befehle richtig zu reagieren (Mxx = Ventil Auf, Mxy = Ventil Zu usw).
Am Ende ist es doch wie der Slicer für den 3D Druck. Das 3D Teil wird in G-Code überführt und die Achsen fahren danach.
Ihr Scannt das Teil (3D Teil) erzeugt daraus den G-Code mit den jeweiligen M-Befehlen und "gut" ist.
Der PLC Entwickler hat nur "noch" die Aufgabe auf die jeweiligen M-Befehle richtig zu reagieren (Mxx = Ventil Auf, Mxy = Ventil Zu usw).
- Beiträge
- 12.318
- Reaktionspunkte
- 4.500
Die Steuerung wird dann aber schon interessant, wenn es nachher um die Datei geht.
Der Aufwand um eine ASCII-Datei auf einer SPS auszuwerten ist nicht unerheblich.
Da gibt es deutlich einfachere Lösungen.
Ganz besonders wenn man sowieso ein eigenes PC-Programm erstellt.
-> Hier kostenlos registrieren
Bei Beckhoff gibt es dafür eine fix fertige NC Library. Da gibt es einen FB für das Laden und Ausführen einer G-Code-Datei. 1-2 Zeilen Code also.
Zuletzt bearbeitet:
Gerhard Bäurle
Schreibender Ingenieur
- Beiträge
- 7.088
- Reaktionspunkte
- 2.625
Ich verstehe diese Frage nicht. Ist der Förderer nicht eine der NC-Achsen?
-> Hier kostenlos registrieren
Das kann ich Dir nicht sicher sagen. Der Förderer kommt nicht von uns. Wir bekommen einfach ein Drehgebersignal vom Förderer.
Ginge das auch als virtuelle Achse?
Similar threads
