STOPRE, alternative Befehle

Hey Leute,

Bei uns geht es um Zykluszeit-optimierung.

Gibt es vielleicht Leute, die damit Erfahrung haben ?

Im NC Programm wird öfters der Befehl "STOPRE" aufgerufen, bevor R-Parameter wieder beschrieben werden.
Macht ja auch Sinn und ist gut so.

Meine Frage, jedes STOPRE im Programm kostet ja Zeit und die Summe machts. Gibt es alternativen, die auf die Summe nicht so viel Zeit kosten und
trotzdem Sichergestellt ist, dass die Parameter sicher beschrieben/gelesen werden.


Eventuell anstatt STOPRE, G04 S1 verwenden oder so etwas ????????


Gruße

Hallo,

das ist nicht so einfach zu Beantworten
wenns "nur" ums Parameter beschreiben geht, würde ich das so drinnen lassen, da leider sehr viele Parameter schon im Satzvorlauf beschrieben werden.
kann sein, das dieses "Problem" bei neueren Versionen nicht mehr besteht.... weiß ich leider nicht....
aber beim Taktzeit optimieren, kommt es nicht nur auf die "STOPRE`s" an, sondern viel mehr um unnützige Bewegungen, Verschleifen, usw ....

LG

Meistens macht es keinen Sinn.
Wenn man mit Variablen rechnet (z.B. mit R-Parametern) und verwendet sie nur im Vorlauf, z.B. um Endpunkte usw. zu berechnen, gibt es keinen Grund, beim Schreiben oder Lesen Vorlaufstops (STOPRE) einzufügen.
Anders sieht es aus, wenn man Echtzeitergebnisse verarbeiten will. Dann muss wissen was man tut. Mit einem STOPRE ist man dann eher auf der sicheren Seite.

Den Satz von SeanClaud

"wenns "nur" ums Parameter beschreiben geht, würde ich das so drinnen lassen, da leider sehr viele Parameter schon im Satzvorlauf beschrieben werden."

verstehe ich nicht. Wo sonst, wenn nicht im Vorlauf sollte man einen R-Parameter denn beschreiben, wenn man ihn im Vorlauf braucht? Im Hauptlauf lassen sich R-Parameter ohnehin nur mittels Synchronaktion schreiben bzw. lesen. Das ist ja aber eine ganz andere Baustelle.

Macht schon Sinn, dass Verschwendung reduziert wird in Form von Verfahrwegen die unnötig sind oder mit Verschleifen arbeiten.
Aber, wenn man das schon alles angewendet hat, seine Technologie-Werte bis Ende gedreht hat, alles Verfahrwege raus hat und sonst alles anderen Tricks schon angewendet hat, bleibt nicht mehr viel, wenn man Sekunde oder sogar 1/10 Sekunden sucht

Deshalb hab ich gefragt. Aber, dann werde ich wohl das komplette Programm umstellen müssen.

Danke trotzdem Jungs








Der Beitrag wurde von FANUCFRANZ bearbeitet: 23.07.2018, 20:59 Uhr

Danke
manchmal verstehe ich selbst meine Sätze nicht
ist nur schwer zu sagen "nimm das STOPRE raus" wenn man den Code nicht kennt....
kommt immer auf die Anwendung drauf an....

LG

STOPRE wird sehr oft unnötig eingesetzt.
STOPRE sollte im Falle der Auslesen der Positionen im IPO Takt verwendet werden.
Sprich ich lese Positionen in R Parameter und bring danach ein STOPRE. Damit gehe ich sicher, dass die letzte erreichte Position geschrieben wird.

Zum berechnen der R Parameter ist es absolut nicht notwendig

Ein Lesestop muß ja nicht zwangsläufig zur Bremse werden. Wenn sowiso schon die Bewegung gestoppt ist, ist der Lesestop das kleinere Übel.
In einigen Situationen kommt man an einem STOPRE eben nicht vorbei.
Oft sind aber ganz andere Ursachen für einen Bewegungsstop programmiert.
Wie CNCFr schon geschrieben hat, sollte man schon wissen, was man da tut.
Wenn man um die Taktzeit kämpft, muß man die Bewegungen im Fluß halten und unnötige Bewegungsstops zu vermeiden suchen.

ne muss es nicht
Siemens bietet ein Paar tricks, wie man Stopre faken kann

Da hätte ich doch gerne mal Beispiele

Ein lesen der Achspositonen im TP (Teileprogramm ) hat immer einen STPORE zur folge,( implizierter STOPRE)
außer in SA (Synchronaktion)
nachzulesen im Listenhandbuch Systemvariablen.

Ja, die Hauptlaufvariablen haben alle einen impliziten Vorlaufstop, so dass ein zusätzliches STOPRE nichts bringt, außer einer (allerdings sehr geringen) weiteren Zeitverzögerung Aber wenn man um Millisekunden kämpft, sollte man sich natürlich auch solche Stellen anschauen..

etwas mehr Fantasie bitte



So in etwa kannst dir das STOPRE sparen.

Der Beitrag wurde von Hexogen bearbeitet: 30.07.2018, 05:56 Uhr

Steht im Handbuch ...
Bedenk, Du hast noch ne Maschinen Dynamik.
Probiere mal mit MEAS auf ne Position zu fahren und den Messwert einmal ohne STOPRE und einmal mit STOPRE schreiben.
Hast 2 Verschiedene Ergebnisse, bedinkt der Dynamik.
Ohne STOPRE sind die Ergebnisse zudem jedesmal anders.

Der Beitrag wurde von Hexogen bearbeitet: 30.07.2018, 06:07 Uhr

Was ich oft in Zyklen erlebe:

STOPRE
R101=_OVR[4]
STOPRE

Je nach Softwarestand, ist sowas eine enorme Verzögerung.
Zum Schluss auch noch M17 und wir haben alle Bremsen am Auto angezogen.

Der Beitrag wurde von Hexogen bearbeitet: 30.07.2018, 06:10 Uhr

Hallo zusammen,

ich kann zwar zu dem Thema STOPRE nichts sagen, aber was Zykluszeitoptimierungen angeht gibt es eine Möglichkeit
mit der ich ca.2-3 sec pro Teil einspare, Vorausgesetzt die Teile werden von Stange gefertigt.

In meinem Fall vergehen zwischen dem Programmende M30 und dem Neustart des Programms wie oben schon geschrieben 2-3sec.
Laut Maschinenhersteller ist das darauf zurückzuführen, dass die PLC nach Programmende den Status mehrere Systeme abfragt.
Unter anderem Füllstand KSS, Zentralschmierung usw.
Aus meiner Sicht ist das bei Zykluszeiten <2 min nicht nach jedem Teil notwendig.
Diese paar Sekunden fallen auch kaum auf, da sie vom Internen Zykluszeitzähler nicht erfasst werden und meines Wissens nach
keine Zähler existiert der über den M30 hinaus mitzählt.
Außer die Maschinenzeit, wobei ich bezweifle das jemand so seine Zeiten erfasst.

Aufgrund dessen Laufen bei mir alle meine Programme in einer Dauerschleife. Unterbrochen wird diese nur durch die unten noch folgenden
Gründe.

Beispiel:

-----Start-----
DEF ....
DEF ....
DEF ....
$AC_TIMER[3]=0
******************
Sonstige Programm Vorbereitungen
(Nullpunkt laden, Sichere Positionen anfahren etc.)
******************
Stangenwechsel (Wenn erforderlich)
******************
ANFANG: (Sprungmarke)
******************
Eigentliche Teilebearbeitung

******************
IF ($A_IN[7]==0) AND ($A_IN[20]==0) AND $AC_TIMER[3]<1800
GOTOB ANFANG:
ENDIF

M30 M32
--------------------------------

Als Unterbrecher in der IF-Abfrage habe ich die Systemvariablen

$A_IN[7]==0 ;Stangenende (kommt vom Stangenlader)
$A_IN[20]==0 ;1x-Taste (Der Bediener sollte das Programm ja auch ohne RESET stoppen können )
$AC_TIMER[3]<1800 ; Zeit (in meinem Fall nach ca. 30 min. da es bei mir schon mal vorkommen kann
das eine 3000mm Stange 4 Std braucht bis sie verarbeitet ist )

kommt eine der genannten Variablen zu keinem positiven Ergebnis
wird ganz normal das Programm mit M30 beendet und die PLC kann tun was auch immer sie tun will.

Auf diese weise spare ich in der Fertigung jedes Jahr ca. 4000 Fertigungsstunden ein.

Ich hoffe mit meinem Optimierungsansatz kann ich FANUCFRANZ oder auch jemand anderem Helfen.

Gruß Karesus