Gcode mit R-Parameter steuern, R-Parameter als Bedingung

Hallo an alle,

ich bin neu in der CNC-Programmierung und teste zurzeit mehrere Codes in einer Sinumerik 840Dsl Steuerung. Leider hab ich jedoch keinen großen Erfolg.

Ich habe eine While Schleife programmiert, mit der ich eine vordefinierte Anzahl an Fräsbahnen durchführen möchte. Hierfür benutze ich R-Paramter als Bedingung.
Im folgenden hab ich den kurzen Code reinkopiert. Ich möchte insgesamt drei Bahnen verfahren, alle im Abstand von 5mm.
Leider stoppt er aber nicht den Prozess und endet in einer Endlosschleife. Der R-Paramter 303 ändert auch stehts seinen Wert manchmal bis zu 350 etc. also weit über R304 =2, dennoch endet der Versuch nicht.
Ich verstehe wirklich nicht, was ich falsch mache. Ich denke mir fehlt erstmal generell basic Wissen zur CNC-Programmierung.

Fragen:
1) Werden R-Parameter im G-Code gecheckt und auf ihren Wert untersucht?
2) Wenn ja, in welchem Takt?
3) Hat die While Schleife eine Besonderheit bzw. fällt euch ein Fehler auf?
4) Können R-Parameter synchron verändert werden? also kann ich während eines G-Code-Ablauf im HMI den R-Wert manuell setzen, der dann widerrum im Code berücksichtigt wird?
5) Benötige ich hierfür eine Synchronaktion
6) Kennt ihr gute Handbücher/Beispiel G-Code für die Sinumerik 840Dsl?

---nur drei mal verfahren
N10 G17 G90 G94
N20 G510 ; individuelle Nullpunktverschiebung
N21 T="ED_M1" M6 D1 ;Werkzeugwechssel
M3 S500

R301=10
R303=0
R304=2

WHILE R303<=R304
G1 X=20+R301 Y-10 Z50 F1000 ; Sicherheitsposition anfahren
G1 Y260 Z0 F150 ; Nutfräsen
G1 Z50 F1000

R301 = R301+5 ; die nächste Bahn soll 5mm weiter anfangen
R303=R303+1 ; Anzahl Bahnen
ENDWHILE

M30

Ich würde mich sehr über eure Hilfe freuen!!!

R-Parameter werden im G-Code nicht direkt geprüft. Sie müssen in den Programmen als Teil der Logik verwendet werden, aber ihre Überprüfung und Manipulation erfolgen nicht automatisch in Echtzeit.

Die Schleife wird nicht gestoppt, weil der Wert von R303 nicht aktualisiert wird. Die While-Schleife prüft den Wert von R303 nur einmal pro Schleifeniteration, was zu einer Endlosschleife führen kann, wenn der Wert nicht korrekt aktualisiert wird.

Die While-Schleife hat keine spezifischen Fehler, aber sie endet nicht, weil R303 nicht korrekt erhöht wird. Es ist möglich, dass der R303-Wert nicht wie erwartet aktualisiert wird, oder der Code wird in einem Zustand ausgeführt, der nicht richtig auf die Schleifenbedingung reagiert.

R-Parameter können während der Programmausführung im HMI geändert werden, aber dies kann zu unerwarteten Ergebnissen führen, wenn die Schleife auf diesen Werten basiert.

Für die Synchronisation und die richtige Aktualisierung der R-Parameter in der Schleife sind keine speziellen Synchronaktionen erforderlich, aber eine genaue Steuerung und Prüfung der Werte ist wichtig.

Überprüfen Sie das Handbuch der Sinumerik 840Dsl für spezifische Programmieranweisungen und Beispielcodes. Siemens bietet detaillierte Dokumentation und Beispielprogramme für ihre Steuerungen an.

Zusammenfassend: Stellen Sie sicher, dass R303 und R301 korrekt erhöht werden und die Schleife unterbrochen wird, wenn die Bedingung erfüllt ist. Testen Sie die Werte außerhalb der Schleife, um sicherzustellen, dass sie korrekt aktualisiert werden.

Zu deinen Fragen:
1. und 2.: Die beiden Fragen verstehe ich nicht. Was meinst du mit "Checken des Wertes". Es wird nichts gecheckt. sondern die Variable wird gelesen, wenn sie gebraucht wird.
3. Ich sehe bei der while-Schleife keinen Fehler. Wenn der der Wert von R303 größer werden kann als 2 kann das eigentlich nur daran liegen, dass R304 irgendwo verändert wird. Du solltest deshalb den Wert dieser Variablen ebenfalls überprüfen, wenn der Fehler auftritt.
4. Was du beschreibst würde ich nicht als synchrone, sondern als asynchrone Veränderung bezeichnen. Wenn deine R-Parameter irgendwo verändert werden, sei es in einem aktiven Programm oder weil der Bediener die R-Parameter manipuliert, werden die geänderten Werte gelesen. Von den alten Werten (welche sollten das sein?) weiß die Steuerung nichts mehr. Das ist ein Grund, weshalb man für Fälle wie bei deinem NC-Programm keine R-Parameter verwenden sollte, sondern lokale, selbst definierte Variable (ein weiterer großer Vorteil ist, dass man den selbst definierten Variablen aussagekräftige Namen geben kann, so dass die Programme lesbarer werden).
5. Synchronaktionen brauchst du für dein Programm nicht.
6. Im Siemens-Handbuch "Arbeitsvorbereitung" steht eigentlich alles was man braucht, mit Beispielen.

Hey Rebecka,
zuerst einmal Welcome.
Zu den Fragen, wurde ja bereits beantwortet.
Geb meinen Senf auch noch kurz ab.

R-Parameter sind Rechenvariablen der Typs Real ... daher R.
Geprüft werden diese nur wenn du eine Abfrage machst und diese selbst prüfst.
Sprich in der Zeile wo du diese abfragst... IF Rxxx==2 oder so.
Du kannst einer R Variable keine Strings übergeben. Das führt zu einem Syntaxfehler.
Boolische True False gehen auch nicht.
R-Paramter sind von Siemens vordefiniert und jeder Maschinenhersteller kann die Anzahl bestimmen.

Das geht nur in einer Synchronaktion


WHILE Schleife startet eine nicht Statische Synchronaktion im Siemens, daher jeder IPO Takt (je nach System ca. 2-8ms) prüft diese Bedienung solange das Programm läuft.
Die Abfrage würde zum Fehler führen. WHILE Schleifen und R Parameter müssen mit $R[xxx] "Bedienung" angesprochen werden.
Für die Art der Programmierung eignet sich FOR Schleife.


Ja das geht.
Du kannst auch eigen Variablen erstellen und diese in der HMI ändern.
Man kann auch HMI Masken machen die bestimmte Werte in der NC ändern.
Generell kannst alle NC Variablen im Systemlauf auch Synchron ändern.


Nicht zwangsläufig.
Der wert wird in diesem Augenblick geändert wenn du Eingabe drückst.



Welchen SW Stand hat die Maschine?

hier paar Links:
https://cache.industry.siemens.com/dl/files...15_de_de-DE.pdf
https://support.industry.siemens.com/cs/mdm...15&lc=de-DE

Was zu Synchronaktionen:
https://support.industry.siemens.com/cs/doc...=0&lc=de-DE

PS... dein code sollte so lauten:

Diese Sätze verstehe ich nicht.
Die While Schleife startet (selbstverständlich !) keine Synchronaktion. Da geschieht auch nichts im Ipotakt. Die ganze Schleife läuft vollständig im sogenannten Vorlauf ab.
R-Parameter müssen keineswegs mit $R[xxx] angesprochen werden. Das würde nur für Synchronaktionen gelten. Um die geht es hier aber nicht.
Ob man eine FOR- oder eine WHILE-Schleife verwendet, ist letztlich Geschmackssache.
Ich würde im konkreten Fall auch eher eine FOR-Schleife verwenden. Mit der WHILE-Schleife muss es aber genauso gut gehen.

Sorry mein Fehler, hast natürlich recht...
WHILE macht keine Synchronaktion.
War gestern Abend etwas hängen geblieben
Hab da irgenwie WHEN im Kopf ... zu viele Synchron-Aktionen am Abend

Sind die R-Parameter ab R100 nicht eigentlich für die Steuerung gedacht?
Ich arbeite in meinen Programmen viel mit R-Parametern und benutze laut Programmieranleitung deswegen auch nur R1 bis R99 .
Aber ist das nicht auch etwas über das Ziel hinausgeschossen für ein paar wiederholungen zu machen?

...
G1 Z50 F1000

STOPRE ; <--- verhindert das vorweg lesen der Maschine (stop read), der Parameter auch erst dann geschrieben wenn er dran ist

R301 = R301+5 ; die nächste Bahn soll 5mm weiter anfangen
...
Schreib das mal mit rein. Würde ich bei solchen Geschichten immer mit rein nehmen da die Steuerung unglaublich weit voraus liest und die R-Parameter dann auch schon schreibt.
Oder die Sache mit Sprüngen und Bedingung regeln

Schleife1: ; anstatt while / Sprungmarke= min. 3 Zeichen + ":"

...
...
...

STOPRE
IF R303==0 ; ein "=" den Parameter schreiben / zwei "=" abfrage ob er genau Null ist oder "<>" abfrage ob er nicht genau Null ist (also ungleich)
GOTOF Schleifenende ; ansprechen der Sprungmarke ohne ":"
ELSE
R301=R301+5
R303=R303-1
GOTOB Schleife1 ; GOTO = Sprungbefehl/B=Backward/F=Forward/nur Goto sucht erst in die eine dann in die andere (weis nicht mehr was zuerst)
ENDIF
Schleifenende:

Viel Spaß beim Probieren

Das ist ja lustig, ich habe keine Berechtigung meinen eigenen Beitrag zu editieren.
EDIT:

mit ungleich wäre sogar weniger zu schreiben

IF R303<>0 ; ist nicht Null
R301=R301+5
R303=R303-1
GOTOB Schleife1
ENDIF

Wenn die Bedingung erfüllt ist (R303 soll nicht Null sein) wird das gemacht was unter der Bedingung geschrieben ist.
Ist sie nicht erfüllt kann man mit ELSE sagen was anstatt dessen gemacht werden soll, muss man aber nicht. Das Programm würde dann einfach weiter laufen wenn die Bedingung nicht erfüllt ist, also eine Null drin steht.

Die CNC-Arena erlaubt die Korrektur eines Beitrags nur in einem Zeitraum von wenigen Minuten nachdem ein Beitrag abgeschickt wurde. Das hat Vor- und Nachteile, ist aber nun mal so.

Das STOPRE ist überflüssig. Der einzige Effekt ist, dass das NC_Programm unter Umständen ein paar MIllisekunden länger dauert.
Wenn du z.B. in einer Programmzeile X10 schreibst interessiert es dich auch nicht, ob diese Anweisung in 10 ms oder erst in einer halben Stunde verwendet wird.
Nicht anders ist es, wenn statt der fixen Zahl ein R-Parameter verwendet wird.
Wenn du allerdings die Befürchtung haben musst, dass im Zeitraum zwischen dem Zugriff auf den R-Parameter und der Ausführung der Programmzeile der Wert des R-Parameters noch verändert werden könnte (und der spätere Wert der "bessere" ist) ist das eher Lottospielen als programmieren.
Damit ich nicht missverstanden werde: STOPRE hat durchaus seine Berechtigung, z.B. bei Reaktionen auf Echtzeitereignisse. Bei schlichten NC-Programmen, bei denen einfach eine Programmzeile nach der anderen abgearbeitet wird, bringt ein STOPRE keinerlei Vorteile. In den meisten Fällen gibt es auch keine auffälligen Nachteile.

Sinnvoller wäre es an Stelle von R-Parametern aussagekräftige Variablennamen zu verwenden.

Weshalb sollte man selber unübersichtliche Schleifen basteln, wenn die Steuerung entsprechende Kontrollstrukturen zu Verfügung stellt?

Es mag am Alter meiner Steuerung (2002) oder vielleicht auch an einer falschen Implementation durch den Maschinenhersteller liegen, aber ohne STOPRE werden die R-Parameter bei mir bereits kurz nach dem Start des Programmes durch Rechenanweisungen ganz am Ende verändert.

Ja sicher ist das so. Und wo ist das Problem?
Nehmen wir an, deine Steuerung ist so konfiguriert, dass die Satzvorbereitung 40 Sätze aufnehmen kann, und dein Programm erzeugt 30 Sätze.
Dann ist nach einer Sekunde die Satzverarbeitung erledigt, auch wenn das Programm eine Stunde läuft.
Und die R-Parameter haben dann die Werte, die sie am Programmende haben müssen.

Das Problem ist schlicht und einfach: Der Parameter soll dann geändert werden, wenn ich es der Maschine vorschreibe - nicht zu einem beliebigen Zeitpunkt.
Das einfachste Beispiel ist ein Zähler. Wenn ich die gefertigten Stücke zählen möchte, dann zu dem Zeitpunkt, wenn das Programm durchgelaufen ist und das Teil fertig. Ich will keine halben Teile mitzählen, wenn der Bediener das Programm abbricht o.ä.

Dein Beispiel wiederum wirft ein anderes Problem auf: Wenn das Programm 60 Sätze lang ist und der Puffer nur 40 Sätze aufnehmen kann - dann ist nicht einmal gewährleistet, dass der Parameter von Anfang an im "Endzustand" ist. Aber das nur nebenbei.

Es ist also notwendig, STOPRE zu verwenden, um die R-Parameter im richtigen Moment zu ändern.

Das ist ein Teil von einem unserer Programme:

N330 M1
;EINSTICH RUND D12
N340 T="Einstich Rund D12" M6
N350 D1
...
...
...
N7330 G75 X0 Y0
N7340 G75 Z0
N7350 G0 G53 B0
N7360 M125
STOPRE
RG[1]=2
GROUP_END(0,1)
SP2:

Ich nutze die Parameter als Sprungmarke.
Wenn das STOPRE dort nicht steht ist der R-Parameter bereits neu geschrieben bevor das Werkzeug am Teil den ersten Span nehmen kann.
Jetzt hat der Werker z.B. vergessen die Platte zu wechseln, er stoppt und startet neu. Dann raucht das Folgewerkzeug als nächstes ins Volle weil die Bearbeitung noch garnicht beendet worden ist (läuft ca. 15min) aber die neue Sprungpunktnummer bereits gesetzt wurde.
In dem Beispiel Programm hier steht:

G1 X=20+R301 Y-10 Z50 F1000; Sicherheitsposition anfahren
G1 Y260 Z0 F150; Nutfräsen
G1 Z50 F1000

R301 = R301+5; die nächste Bahn soll 5mm weiter anfangen

Es kann also passieren das der Parameter bereits neu geschrieben wurde bevor die erste Bahn gefahren wird, ergo der erste Schnitt eventuell zu groß ist oder der letzte in der Aufspannung landet oder oder.
In meinem Beispiel könnte es passieren das man nicht auf Null landet sondern bei -1 und dann hat man auch eine endlosschleife weil immer weiter runter gezählt wird.

Ich sehe in deinem Beispiel nicht, wo der R-Parameter R301 initialisiert wird.
Ich würde erwarten, dass das ganz vorne im Programm geschieht. Dann kann der Werker das Programm so oft abbrechen wie er will und neu starten, ohne dass etwas passiert.
Woher kommt in deinem Beispiel der Startwert von R301?

Ich hatte weiter oben geschrieben, dass STOPRE durchaus seine Berechtigung hat. Nicht umsonst löst das Lesen vieler Systemvariabeln implizit ein STOPRE aus. Dein Beispiel mit dem Zähler ist ein solcher Fall. Wenn du einen Stückzähler implementieren willst und diesen Zähler jeweils am Ende der Bearbeitung inkrementieren willst, musst du mit einem STOPRE am Ende der Schleife machen.
Das ist aber ein ganz anderer Fall als die Definition einer Bahn mit Parametern.
In den Beispielen, die hier bisher genannt wurden, stand das STOPRE immer VOR der Schleife und nicht IN der Schleife. Das bedeutet, dass der ganze Programmteil vor dem STOPRE abgearbeitet bevor die nachfolgende Schleife verarbeitet wird. Wenn der Punkt erreicht ist, wird die Schleife und alles was danach kommt, sofort und ohne Echtzeitbezug abgearbeitet. Damit hat man dann trotz des STOPREs die Kontrolle darüber verloren, wann die Parameter verändert werden, was aber kein Problem ist. Ein solches STOPRE nutzt dir im Fall des Stückzählers also nichts.

Wie oben ebenfalls schon geschrieben: Die überflüssigen STOPREs, an denen ich mich hier hochziehe, machen in der Regel keinen Ärger und führen nur zu einer unnötigen Verlängerung der Programme um ein paar Millisekunden. Aber man sollte wissen, was man tut und weshalb man es tut.

Der Beitrag wurde von CNCFr bearbeitet: 15.08.2024, 13:04 Uhr

Es ist ein Ausszug aus dem Programm was Rebecka hier gepostet hat und für meine Argumetation brauchte ich auch nur den Teil vom benutzen des R301 bis zum neuschreiben des R301. Das ein Initialwert für einen Parameter vor der Schleife gesetzt werden muss war für mich erstmal selbstverständlich. Ausserdem hat Rebecca es in Ihrem Beispiel Programm auch getan. Nirgends habe ich geschrieben das STOPRE vor der Schleife stehen soll.

Für Ihr besseres Verständnis hier das ganze Programm:
N10 G17 G90 G94
N20 G510 ; individuelle Nullpunktverschiebung
N21 T="ED_M1" M6 D1 ;Werkzeugwechsel
M3 S500

R301=10 ; hier wird er gesetzt
R303=0
R304=2

WHILE R303<=R304 ; schleifen anfang
G1 X=20+R301 Y-10 Z50 F1000 ; hier verwendet
G1 Y260 Z0 F150 ; Nutfräsen
G1 Z50 F1000

STOPRE ; das befindet sich also außerhalb der schleife? Interessant!

R301 = R301+5 ; hier neu geschrieben
R303=R303+1 ;
ENDWHILE ; schleifen ende

M30

Ich habe vorher nichts anderes geschrieben außer das ich nur Auszüge aus dem Programm verwendet habe.

Ein paar Beispiele Ihrerseits wären hilfreich. Bis jetzt lese ich nur Kritik und das hilft niemandem weiter.

Ich versuche es nochmals:
Wenn man - aus welchen Gründen auch immer - dafür sorgen will / muss, das jeder Schleifendurchgang erst dan mit der Satzvorbereitung beginnt, wird man um STOPRE nicht herumkommen (wenn es nur um die Segmentierung der Bearbeitung gehen würde, wäre ein M0 mitunter ohnehin wohl die bessere Wahl).
Wenn das für deine (ich erlaube mir mal beim forenüblichen du zu bleiben) Arbeitsweise notwendig ist, so vorzugehen, ist das in Ordnung.
Aber ich behaupte mal, das das bei den meisten Programmen, die mit begegnet sind, nicht der Fall ist. Das nehme ich auch für das vorliegende Programm an. Das STOPRE in diesem Programm steht mit großer Sicherheit deswegen da, weil nun mal die (falsche) Meinung kursiert, dass irgendetwas schief gehen könnte, wenn die R-Parameter gelesen oder beschrieben werden, lange bevor die daraus resultierenden Bewegungen an der Maschine ausgeführt werden.
Das gleiche Programm, das jetzt mittels R-Parametern flexibel gestaltet ist, könnte man auch Zeile für Zeile ausprogrammieren. Dann käme kaum jemand auf den Gedanken, zwischen den einzelnen Programmteilen STOPREs einzufügen.
Die STOPREs werden häufig immer dann grundlos eingefügt, wenn mit R-Parametern gerechnet wir, weil Anwender die Funktionsweise der Steuerung nicht richtig verstehen, und sich nach dem Motto "besser fünf STOPREs zu viel, als eines zu wenig" auf der sicheren Seite wähnen.

Zum Vorwurf ich würde nur kritisieren und keine Beispiele bringen:
Mein Beispiel ist einfach (und zumindest implizit schon ein Dutzend mal genannt): Das STOPRE aus Rebeccas entfernen. Zwischen den beiden Varianten wird die Programmerstellerin kaum einen Unterschied bemerken.

Zu diesem Punkt bekenne ich mich ohne zu Zögern schuldig.



Nur, dass ich das richtig verstehe: Du sagst also, dass die Maschine trotzdem die Bewegungen mit den - inzwischen mehrfach überschriebenen - alten Werten ausführt, obwohl diese nicht mehr so in der Parameterliste stehen?

Ich versuche mal, das zu erklären. Angenommen wir haben in einer Schleife folgenden beiden Zeilen stehen und R1 sei anfangs gleich 0:

X=R1
R1 = R1 +1

Dann erzeugt die Satzvorbereitung intern die folgenden Sätze:
X0
X1
X2
X3
usw.

Diesen Sätzen sieht man nicht mehr an, dass die Werte aus Parametern kommen, sie "wissen" auch nichts mehr von Parametern. D.h. wenn sich der R-Parameter ändert hat das keinen Einfluss mehr auf diese Sätze.
Diese Sätze werden in einem Speicher aufgesammelt. Die Größe des Speichers ist konfigurierbar. Nehmen wir mal an er kann 20 Sätze aufnehmen.
Die Vorverarbeitung der Sätze stoppt, wenn der Speicher voll ist. In unserem Beispiel wird die Vorverarbeitung also gestoppt, wenn 20 Sätze bearbeitet sind, und noch keiner der Sätze abgearbeitet wird. Das könnte z.B. dann der Fall sein, wenn eine Achsfreigabe fehlt oder auch wenn das Vorschupoti auf Null steht.
Wenn es keine solchen Bedingungen gibt, die die Verabeitung der Sätze verhindern, wird der jeweils älteste Satz aus dem Speicher geholt und abgearbeitet, d.h die Maschine führt die programmierte Bewegung aus.
Wenn der Satz aus dem (vollen) Speicher geholt und abgearbeitet wird, wird im Speicher ein Platz frei und die Satzvorbereitung interpretiert deshalb den nächsten Satz und füllt damit den Speicher wieder.
Wenn es keine weiteren Sätze mehr gibt (Programmende) liefert die Satzvorbereitung natürlich auch keine Sätze mehr nach, und der Speicher leert sich. Aber erst wenn der letzte Satz aus dem Speicher geholt und abgearbeitet wurde, ist das Programm tatsächlich beendet.
Zwischen dem Ende der Vorverarbeitung und dem tatsächlichen Programmende kann eine beliebig lange Zeit liegen.
Die Parameter, die zur Steuerung der Vorverarbeitung verwendet wurden (Schleifenzähler, berechnete Positionen usw.) sind nur für die Vorverarbeitung relevant. Alles was danach kommt, weiß nichts von den Parametern und greift auch nicht auf sie zu.
Es ist deshalb völlig normal, und kann auch gar nicht anders sein, dass die verwendeten Parameter ihre Endwerte lange vor dem Programmende erreichen bzw. erreichen können.
Ein Vorlaufstop (STOPRE) bewirkt, dass die Vorverarbeitung den nächsten Satz erst dann bearbeitet, wenn der oben genannte Speicher leer gelaufen ist und der letzte aus dem Speicher abgeholte Satz abgearbeitet ist. Das führt dann in jedem Fall zu einer geringfügigen Verzögerung bis zur Abarbeitung des Satzes nach dem STOPRE, weil ja die Bearbeitung des nächsten Satzes erst erfolgen darf, wenn der Vorgängersatz vollständig abgearbeitet ist.
Das hat in vielen Fällen keine gravierenden Folgen (wie schon mehrfach erwähnt). Kritisch wird es z.B., wenn man ein STOPRE zwischen normalen Verfahrsätzen einfügt, weil die Steuerung dann zwangsweise nach jedem Satz anhalten und dann neu beschleunigen muss.
In Fällen, in denen die Vorverarbeitung mehrere Sätze überblicken muss um die Kontur zu berechnen, z.B. Werkzeugradiuskorrektur oder Splineinterpolation führt das zu Konturfehlern oder Fehlermeldungen.

Das war ausführlich. Vielen Dank, das bringt mich weiter.

Vielen Dank für die ausführliche Erklärung.