$SR_OV_RED in KRL-Programm setzen

Hallo,

$SR_OV_RED kann nicht im Programm beschrieben werden und dient der automatischen Reduzierung in Verbindung mit SafeOperation. Für das was du wahrscheinlich machen willst, solltest du $OV_PRO verwenden.

Fubini

Hallo zusammen,

also ich beschreib $SR_OV_RED im SPS.SUB und hatte keine Probleme

Gruß Loipe

Moin zusammen,
$OV_PRO aus dem Submit oder aus dem Programm zu schreiben, halte ich generell für keine gute Idee. Ich hatte wegen solchem S....ß fast einen Crash.
Irgendein Starprogrammierer hatte ein (Unter)Programm mit $OV_PRO = 100 ergänzt, geile Sache wenn man den Ablauf aus anderen Gründen testen muss!
Wenn ich als Bediener am KCP/SmartPad den Programmoverride auf einen Wert setze, hat der da gefälligst zu bleiben.
Ist die Geschwindigkeit prozessrelevant, so muss man halt eine entsprechende Meldung absetzen. Die richtige Reaktion des Bedieners setzt natürlich eine gewisse Kompetenz desjenigen voraus. Aber jetzt schweife ich ab...

Grüße

Hallo Otto,

1. Voll deiner Meinung. Sauerei sowas im sub oder im Programm ohne Warnung hochzuschalten.
2. $SR_OV_RED ist nicht $OV_PRO.

Zitat

> [size=2]Die Variable $SR_OV_RED gibt den Reduzierfaktor für die Override-Reduzierung in Prozent an. Die Geschwindigkeit wird auf folgenden Wert reduziert: Kleinste Geschwindigkeitsgrenze * Reduzierfaktor
[/size]

Wenn $SR_VEL_RED = TRUE ist kannst du nicht mehr schneller als die eingestellten Prozent fahren.
hast du [size=2]$SR_OV_RED=[/size][size=2]50 dann sind [/size]$OV_PRO=100 im Grunde nur 100% von den eingestellten 50%. $OV_PRO bleibt auf
eingestellten Wert.

Hallo,

habe jetzt noch mal im Code nachgesehen: Ja $SR_OV_RED kann bei aktueller Implementierung in der Steuerung im Programm gesetzt werden. Das war aber nie so beabsichtigt, sondern ist eher ein Implementierungsfehler, d.h. es wurde vergessen das zu verbieten. Konsequenz beim ändern von $SR_OV_RED aus dem Programm heraus ist ein Vorlaufstopp, was man bedenken sollte. Ferner können nur Werte zwischen 10 und 95 zugewiesen werden. Alles andere produziert eine "Unzulässige Wertzuweisung". zuletzt sollte man bedenken $SR_OV_RED wirkt nur auf Grenzen, die aus der Sicherheitssteuerung(SafeOperation) kommen und nicht auf Grenzen der nicht sicheren Steuerung, wie z.B. $SPEED_LIMIT_TEACH_MODE.
Zugegeben $OV_PRO war vielleicht etwas unüberlegt, aber $RED_VEL passt vielleicht besser.

Fubini

Hallo Experten,

bezüglich der Thematik, dass der $OV_PRO im sps.sub gesetzt wird hätte ich nochmal eine Frage.
Wir benutzen dieses Vorgehen aktuell, um den Override vom HMI direkt beim Roboter einzustellen.
Dies passiert nur, wenn der Roboter im EXT-Mode ist.
Welches Vorgehen wird da im Normalfall genutzt? Normalerweise wird bei uns das KCP von Bedienern gar nicht in die Hand genommen, sondern nur von der Wartung, die entsprechenden Qualifikation mitbringen.
Gruß Denis

Moin,
prinzipiell kann ja jeder machen , wie er das will.
Nur, wie schon vorher gesagt, sollte ein _bedingungsloses_ Überschreiben des $OV_PRO unbedingt verhindert werden. Wenn also auf der HMI der übergeordneten Steuerung eine Möglichkeit des Steuerns besteht, sollte dieses nur bei expliziter Anforderung des Bedieners stattfinden. In SPS gesprochen: Eingabewert plus Flanke der Anforderung gehen zum Roboter und der kann dann den Wert mit der Flanke mittels sps.sub EINMALIG einlesen. Das ist dann sauber und das Smartpad/KCP brauchst dann nur noch für den Notaus. Das Überschreiben _ausschliesslich_ von der Betriebsart EXT/AUT abhängig zu machen, ist gleichermassen gefährlich. Im Regelfall braucht es das ja auch für den Testlauf.

Grüße

$OV_PRO=100 zu programmieren gilt in unserem Haus als Todsünde.

Hier heißt es
WAIT FOR $OV_PRO==100
Ggf. auch mit Meldung an die SPS:
IF ($OV_PRO < 100) THEN
$OUT[out_Override_an_SPS]=true
WAIT FOR $OV_PRO==100
$OUT[out_Override_an_SPS]=FALSE
ENDIF