Die Sache ist, je länger das Programm ist, desto länger ist die Verarbeitungszeit, während die Lesbarkeit geringer ist. Jeder Vergleich ist eine andere Anweisung und unnötige Vergleiche sind verschwenderisch.
Wenn man wirklich jeden Tick (aus Sicht der CPU-Ressourcen) genau betrachtet, gibt es auch Gründe, Vergleiche zu minimieren, da sie ineffizient sind (Auswirkungen auf die Verzweigungsvorhersage), obwohl der Compiler die Unterschiede ausgleichen kann.
so... warum nicht
IF EINGANG THEN
AUSGANG=TRUE
ENDIFWarum nicht einfacher:
$AUSGANG=$EINGANG
Warum nicht einfacher:
$AUSGANG=$EINGANG
nicht dasselbe... das aendert Ausgang auch wehn Eingang ist FALSE. original laest Ausgang unvreraendert (egal ob TRUE oder FALSE) wehn Eingang ist FALSE
Servus zusammen,
öffne dieses Thema hier nochmal da ich auch eine Frage zum SPS.SUB habe.
Es geht um folgendes:
Beim Automatischen Sitzverbau verwenden wir verschiedene Greifer Signale für verschiedene Sitz-Typen via Gripper-Tech.
Beispiel: LU-Greifen = Ausgang xy (Grippertech Taste 1)
LGIS-Greifen = Ausgang xy (Grippertech Taste 2)
MPA-Greifen = Ausgang xy (Grippertech Taste 3)
( Da der Greifer auf verschiedene öffnungs/schließ werte fährt )
Bei Störungen muss die Instandhaltung mit dem KCP in die Anlage und schauen welcher Sitztyp am Greifer hängt / oder hing, und mit der richtigen Gripper-Tech Taste den Greifer öffnen/schließen um den Roboter/Sitz frei zu fahren. Da kam die Beschwerde das es blöd wäre darauf achten zu müssen, denn wenn im Automatikablauf das LU-Signal schließen gesetzt wurde und die mit der Gripper-Tech Taste2 z.b LGIS öffnen drücken, der Greifer sich nicht bewegt, was logisch ist, Signal LU schließen steht ja noch an, wenn ich dann LGIS öffnen drücke, macht der Greifer nix da ja noch das LU schließen ansteht. Kann natürlich im Stress mal passieren und man weis nicht mehr welche Taste gedrückt wurde & schwups stehen gleich mal 2 verschieden öffnen & schließen an.
Gefordert wird nun ein einziges Signal das den Greifer komplett öffnen und komplett schließen lässt, damit man nicht mehr drauf achten muss welcher Sitztyp etc am Greifer hängt/hing. Habe hierzu die Tasten 1-3 gelöscht und auf die Taste 1 ein komplettes öffnen/schließen gelegt. Damit das funktioniert habe ich in der SPS.SUB alle anderen Signale abgelöscht, wollte jetzt fragen ob das so funktioniert und so richtig ist ?
Hoffe konnte es einigermaßen verständlich erklären 
;--------------------------------------------------------------------------------------------
IF (T1) AND (O_Komplett_schliessen) OR (O_Komplett_oeffnen) THEN
O_GRF_oeffnen = FALSE
O_Nachsetzen = FALSE
O_GRF_schliessen_Pruef = FALSE
O_GRF_schliessen_LGIS = FALSE
O_GRF_schliessen_MPA = FALSE
O_GRF_schliessen_LU = FALSE
;---------------------------------------------------------------------------------------------
Nun sollte bei einem Störungsfall ganz einfach mit der Gripper-Tech Taste 1 das öffnen/schließen vom Greifer angesteuert werden können, da er ja alle anderen Signale ablöscht. Richtig ? 
Sorry falls es ne dumme frage ist, habe noch nie mit einer SPS.SUB gearbeitet, vorhanden ist die SPS.SUB bereits, hab nur diesen Text dazu gefügt.
Gruß Tobias
Hoffe konnte es einigermaßen verständlich erklären
Nach den Reaktionen hier geht es wohl vielen gleich wie mir. Nix verstanden.
die logischen Zusammenhänge / Verriegelungen der Ausgänge sind nicht bekannt/ eindeutig klar.
Ein Muss zum Dir eine Aussage zu machen, ob Dein "7-Zeiler" passt.
Weiter die aktuelle Konfiguration von Grippertech und Signaldeklarationen.
(T1) AND (O_Komplett_schliessen) OR (O_Komplett_oeffnen)
AND hat höhere Priorität wie OR !!
Logik wirklich so gewollt??
Betreffend Lesbarkeit würde ich hier 2tes Klammerpaar verwenden.
Gruss SJX
Das wird so nicht klappen, abgesehen von den von SjX vorgebrachten Argumenten, denn was passiert, denn nach dem Wechsel von Automatik nach Hand, wenn noch eines des Signale O_Komplett_schliessen oder O_Komplett_oeffnen gesetzt ist? Der Greifer bewegt sich ganz automatisch, nur durch das Umschalten auf T1. Da müsste man schon noch etwas optimieren.
Aber Kuka hat dafür eine elegante Lösung vorgesehen: Man kann sich eigene Greifertypen programmieren, das macht man in den Dateien User_grp.src und User_grp.dat.
Alles anzeigenNach den Reaktionen hier geht es wohl vielen gleich wie mir. Nix verstanden.
die logischen Zusammenhänge / Verriegelungen der Ausgänge sind nicht bekannt/ eindeutig klar.
Ein Muss zum Dir eine Aussage zu machen, ob Dein "7-Zeiler" passt.
Weiter die aktuelle Konfiguration von Grippertech und Signaldeklarationen.
AND hat höhere Priorität wie OR !!
Logik wirklich so gewollt??
Betreffend Lesbarkeit würde ich hier 2tes Klammerpaar verwenden.
Gruss SJX
Danke dir für deine Antwort. Hätte gedacht habs verständlich genug erklärt, konnte nicht noch weiter ausholen da es einfach ein riesiges Projekt ist. Dachte reicht nen kleinen ausschnitt davon zu erklären, da ich ja nur wissen wollte ob es in der SPS.SUB so richtig aufgeführt ist, da ich zuvor noch nie in der SPS.SUB änderungen machen musste. Die Änderung hat funktioniert. Habs wie folgt im SPS.SUB
;--------------------------------------------------------------------------------------------
IF ($T1 AND O_Komplett_schliessen OR O_Komplett_oeffnen) THEN
O_GRF_oeffnen = FALSE
O_Nachsetzen = FALSE
O_GRF_schliessen_Pruef = FALSE
O_GRF_schliessen_LGIS = FALSE
O_GRF_schliessen_MPA = FALSE
O_GRF_schliessen_LU = FALSE
ENDIF
IF NOT $T1 THEN
O_Komplett_oeffnen = FALSE
O_Komplett_schliessen = FALSE
ENDIF
;---------------------------------------------------------------------------------------------
Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können
