R Parameter im CNC Programm, R-Parameter zählen nicht hoch

Hallo,
Habe folgendes Programm


Warum sehe ich in den R-Parametern R15 und R10 immer mit dem Wert10 vorbelegt und nicht langsam hoch hochzählen?
Bei R20 funktioniert es aber

Der Beitrag wurde von tonkelz bearbeitet: 18.05.2021, 12:27 Uhr

Weil der Wert bis er 10 ist, immer zu Satz N100 kommt, danach in N90 aber weiter springt. Und damit auf Wert 10 bleibt.

Und warum zählt der nicht hoch bis 10?
Wenn ich z.B.25 eingebe dann ist immer 10 vorbelegt und dann sehe ich dass er hochzählt

Der Beitrag wurde von tonkelz bearbeitet: 18.05.2021, 13:31 Uhr

Gib' den Wert doch an verschiedenen Stellen mal mit message aus.

Hallo,

ich würde mal vorm bescheiben (R15=R15+1) ein STOPRE einbauen, könnte was mit dem Satzvorlauf zu tun haben...

LG

Ein falsches, leider nicht auszurottendes Gerücht.

STOPRE braucht man glaub nur, wenn irgendwelche Zustände ausgelesen werden (Achspositionen oder so), richtig?

Aber ich hab das bestimmt auch 20 Mal öfter genutzt als es notwendig war

OK
also wird ein R-Parameter nicht schon im Satzvorlauf beschrieben, wenn man kein DO davor setzt?
leider kann ich mir nicht immer alles erklären, und wenn du mir helfen könntest, zumindest bei mir, dieses Gerücht auszurotten, wäre zumindest ich dir sehr Dankbar

LG

Ich kann's ja mal versuchen:
Die Programmverarbeitung läuft folgendermaßen ab:
Aus dem Programm wird ein Satz gelesen und und in einer ersten Station, dem sogenannten Interpreter bearbeitet. In dieser Station werden z.B. die Endpunkte des Satzes berechnet (u. a. abhängig von G90 / G91 oder inch / metrisch), es wird erkannt ob ein Kreis, eine Gerade gefahren werden soll und etliches mehr. An dieser Stelle werden auch reine Berechnungen mit R-Parametern oder eigenen Variablen ausgeführt.
So wird z.B. in dem NC-Satz
R2 = 10 * R1
der zu diesem Zeitpunkt in R1 stehende Wert mit 10 multipliziert und in R1 geschrieben.

Nach dem Interpreter kommt der sogenannte Vorlauf, der aus etlichen Stationen besteht, die jeweils bestimmte Aufgaben erfüllen, z.B. Nullpunktverschiebungen berücksichtigen, Werkzeugkorrekturen einrechnen, Softwarelimits überwachen, Geschwindigkeitsprofil berechnen und noch etliches mehr. Für viele dieser Aufgaben müssen die Stationen auf mehrere NC-Sätze gleichzeitig zugreifen können z.B. für die Splineberechnung oder die Werkzeugradiuskorrektur.
Wenn ein Satz sämtliche Stationen des Vorlaufs durchlaufen hat, ist er bereit, um ausgeführt zu werden. Der jeweils gerade aktive Satz, wird aber in der Regel nicht exakt zu dem Zeitpunkt fertig sein, wenn der nächste Satz am Ende des Vorlaufs angekommen ist. Deshalb wird ein solcher Satz in einem als Ipobuffer bezeichneten Pufferspeicher zwischengelagert bis er gebraucht wird. Dieser Pufferspeicher kann sehr groß sein (z.B. 100 Sätze oder auch mehr).
Zwischen dem Satz, der ganz vorne in der Verarbeitungskette gerade aus dem Programm gelesen wird und dem aktuell ausgeführten Satz können also sehr viele Sätze liegen, die entweder irgendwo im Vorlauf oder oder im Ipobuffer stecken.
Wenn man nun bereits in einem Satz Informationen braucht, die erst zu dem Zeitpunkt bekannt sind, an dem der Vorgängersatz beendet wurde, muss der gesamte Vorlauf und der gesamte Ipobuffer leer sein.
Ein Beispiel wäre z.B. Messen mit Restweglöschen. Die exakte Position, an der der Messtaster auslöst, kennt man erst wenn der Satz ausgeführt wurde. Das gesamte Folgeprogramm baut aber evtl. auf dieser zunächst unbekannten Position auf. Man muss deshalb mit der Verarbeitung warten, bis die Messung ausgeführt wurde. Das erzwingt man durch einen Vorlaufstop. Der Vorlaufstop liest solange keine neuen Sätze mehr aus dem NC-Programm, bis der gesamte Vorlauf und der Ipobuffer leergelaufen sind.
Wenn man mit Systemvariablen arbeitet, die auf Echtzeitwerte zugreifen, wird der Vorlaufstop automatisch ausgelöst, die Variablen sind in der Doku auch entsprechend gekennzeichnet.

Und um jetzt auf das Ausgangsproblem zurück zu kommen: R-Parameter und auch selbst definierte Variablen werden im Vorlauf, im Ipobuffer und im Hauptlauf nicht verändert, wenn man sie nicht mit Synchronaktionen beschreibt. Das bedeutet, das zu dem Zeitpunkt, zu dem ein NC-Satz mit Berechnungen gelesen wird, alle notwendigen Werte gültig sind, egal wie viele Sätze aktuell gerade im Vorlauf und im Ipobuffer stecken.
In diesen Fällen unterbricht ein STOPRE nur unnötigerweise die normale Programmverarbeitung, was im einfachsten Fall zu geringfügig verlängerten Programmlaufzeiten führen kann.

Das verstehe ich soweit, jetzt habe ich nur noch 1 Problem, unter Parameter ==> R-Parameter sehe ich immer den letzten Wert bei z.B.:
R1=1
M0
R1=2
M0
R1=3

wenn ich den dazwischen mit einem MSG("R1="<<R1) ausgebe, sehe ich wie der hochzählt, breche ich dazwischen ab, bei R1=1 und gebe mir den Wert als MSG aus, steht eine 3 drinnen.

warum sehe ich beim ersten Start eine 3 und warum bleibt die 3 erhalten obwohl sie noch nicht geschrieben sein sollte?

ich hoffe, da hast du eine Erklärung dafür, da dies auch das Problem vom Themenstarter lösen sollte

Danke!

Angenommen ich füge nach dem Satz mit R1=2 eine MSG ein, also z.B. so:
R1=1
M0
R1=2
MSG("Aktueller Wert von R2 = " << R2
M0
R1=3

dann wird in dem MSG-Satz der aktuelle Wert von R2, nämlich der Wert 2 gelesen. Damit wird der auszugebende Text gebildet, also der String "Aktueller Wert von R2 = 2". Dieser Textstring wird im Satz mitgeführt und wandert durch den Vorlauf und den Ipobuffer, bis er irgendwann im Hauptlauf ankommt und dann ausgegeben wird. Der R-Parameter wird zum Zeitpunkt, zu dem der Satz im Hauptlauf ausgegeben wird, nicht neu gelesen, d.h. der aktuell im R-Parameter abgespeicherte Wert kann ein völlig anderer sein.
Während der MSG-Satz diesen ganzen Weg durchläuft, werden in der Regel ständig weitere Sätze aus dem NC-Programm gelesen und interpretiert.
Das bedeutet in unserem Beispiel, dass der R-Parameter selbst im übernächsten Satz auf den Wert 3 gesetzt wird und dieser Wert erhalten bleibt, wenn er im Programm nicht mehr weiter verändert wird. Da in diesem Beispiel der Satz mit R1=3 meistens wenige Millisekunden nach dem MSG-Satz gelesen und verarbeitet wird, siehst du nach dem Abbrechen praktisch immer die 3.
Die 2 würdest du nur sehen, wenn es dir gelänge, das Programm zu unterbrechen, nachdem der MSG-Ssatz aber bevor der Satz mit der Zuweisung R1=3 interpretiert wurde.

Danke!
das kann ich verstehen
manchmal komme ich in eine Situation, wo ich nicht will das eine Variable schon vorher interpretiert wurde, somit helfe ich mir mit einem STOPRE ab, bzw. mit Syn-Guds oder R-Parameter mit DO Anweisung.
wenn du da einen besseren Ansatz hast, wäre ich natürlich auch sehr froh

zum Themenstarter, sein Ablauf funktioniert prinzipiell, nur in der Anzeige wurde der R-Parameter schon bis zur 10 "interpretiert".
beim R20 funktionierts, (in der Anzeige) weil beim Zählvorgang der Parameter noch nicht interpretiert wurde (wegen UP Aufruf vermute ich mal).

@tonkelz
funktioniert dein Programm und dir gefällt die Vorbelegung nicht?

LG

Genau für solche Situationen ist ein explizites STOPRE ja auch vorgesehen.
Gleiches gilt auch für Synchronaktionen (was du als DO-Anweisung bezeichnest).
Allerdings sind beide Möglichkeiten ja nicht identisch, sondern die beiden haben ja ziemlich verschieden Anwendungsfelder.

Danke aufjedenfall fürs Gespräch
habe für meinen Teil, aufjedenfall wieder was gelernt, sprich das "falsche, nicht auszurottende Gerücht" verstehe ich jetzt besser!
zu meinem Ziel bin ich immer noch gekommen, leider hab ichs nicht immer verstanden

schönes Wochenende

LG