Hallo,
stimmt das was Dreiraumwohung sagt?
"Bei umschalten mit dem Schlüsselschalter von T1 auf Extern ist ja die Geschwindigkeitsoverride so eingestellt, wie beim verlassen
des Externen Modus."
Wenn ja, dann muss man den Zeitpunkt in dem von einer anderen Betriebsart auf $EXT geschaltet wird den $OV_PRO setzen
und nicht im Zeitpunkt in dem auf $T1 gewechselt wurde.
Gruß
Twister
Hi Toud,
keine Ursache.
Falls du noch Tasten suchst...
Ich habs so gemacht:
sps.sub
DECL INT II
FOR II = 1 TO 100
$OUT[II] = IS_KEY_PRESSED(II)
ENDFOR
Dann in Anzeige, Digitale Ausgänge ist einfach zu finden.
Am besten man macht das wenn noch nichts an den Ausgängen hängt... 
Gruß
Twister
Wolf(s)(burg)rahm(spinat) He(i)nkel
Hi Toud,
hier die fehlenden Tasten...
90 Program Override -
91 Program Override +
92 Hand Override -
93 Hand Override +
Gruß
Twister
Hi $CCTB,
hier noch ein Update, damit man nicht überrascht wird wieso der Override plötzlich von z.B. 0% auf 12% hoch geht.
Datei $config.dat
DECL MODE_OP tmpMODE_OP = #T1
DECL MODE_OP tmpOldMODE_OP = #T1
Datei sbs.sub
tmpMODE_OP = $MODE_OP
IF (tmpMODE_OP==#EXT) AND (tmpOldMODE_OP<>#EXT) AND ($OV_PRO>12) THEN
$OV_PRO = 12
ENDIF
tmpOldMODE_OP = tmpMODE_OP
Gruß
Twister
Hi $CCTB
wenn ich dich richtig verstanden habe willst du dass sobald man auf Automatik-Extern wechselt der Override auf 12% gesetzt werden soll.
Ich habe dies nicht getestet, sollte aber funktionieren.
Datei $config.dat
DECL MODE_OP tmpMODE_OP = #T1
DECL MODE_OP tmpOldMODE_OP = #T1
Datei sbs.sub
tmpMODE_OP = $MODE_OP
IF (tmpMODE_OP==#EXT) AND (tmpOldMODE_OP<>#EXT) THEN
$OV_PRO = 12
ENDIF
tmpOldMODE_OP = tmpMODE_OP
Gruß
Twister
I think it is a good idea to make short sentences....
Nobody will understand you and your problems...
...
Hi,
hab den Fehler gefunden
nicht:
<Message Number="2858" AllowConfInExt="True" />
sondern:
<Message Number="2858" AllowConfInExt="true" />
Du musst das "T" von "True" klein schreiben. Also "true", dann gehts bei mir. (Siemens S7 Profibus und KRC4 V8.2.x mit Beckhoff-Slave)
Gruß
Twister
Hallo fubini,
hast du auch eine Dokumentation über den "VectorMove"?
Gruß
Twister
Hallo,
ok, das hört sich ja schon mal gut an.
Da es ein Konus ist gehe ich davon aus dass die ersten ca. 120mm mit 1m/s gefahren werden können und erst bei den letzten 30mm gefühlvoll gefahren werden muss.
Ebenso gehe ich davon aus dass alles sehr stabil ist und dein Konus nicht beschädigt wird wenn der Roboter mal ein wenig kraft ausübt.
Könnte man die letzten 30mm in z.B. 30 überschliffene Bewegungen aufteilen und nach jedem Schritt die Momente/Ströme der einzelnen Achsen beobachten und
demensprechend die X/Y-Position für den nächsten Schritt korrigieren? Ist zwar keine "schöne" Lösung, aber würde wohl funktionieren.
Gruß
Twister
Hallo BastelNerd,
interessant wäre noch ob diese Fügebewegung sehr taktzeitkritisch ist.
Wie lange hätte er denn zusätzlich Zeit?
Gruß
Twister
Hallo,
hat mir jemand die Doku für den Funktionsgenerator V8.2.x KRC4?
Vielen Dank im Voraus.
Gruß
Twister
Hallo,
noch ein Nachtrag zum Thema Temperaturabweichung eines Roboters.
Heutzutage kann doch ein gutes CAD oder FEM - Tool Temperaturausdehnungen von komplexen Geometrieen berechnen.
Somit wäre es doch ein leichtes für jeden Roboterhersteller an markanten Stellen einen Temperatursensor einzubauen und
die Transformation mit diesen Temperaturwerten zu verrechnen ähnlich den Absolut vermessenen Robotern.
Somit wäre dieses Thema auch weitest gehend vom Tisch.
Wenn man sich überlegt dass sogar mit Lastdaten dynamisch korrigiert wird wäre dies doch ein Klacks.
Klar, wieso soll man sich die Mühe machen wenn sowieso keiner danach fragt... ausser mir!
Gruß
Twister
Hallo,
ok, das mit den Spline ist echt eine Verbesserung die irgendwie an mir durch gegangen ist. Vielen Dank für den Tip.
Thema Wärme ist auch nicht so ganz das Problem.
Zum Einen sind es sehr kleine Bereiche, kleiner 50x50x50mm, welche ich abfahre.
Des weiteren darf der Roboter natürlich nicht ins Wochenende und schafft brav durch. 
Ebenso kann ich mir noch überlegen wo ich den Arbeitsbereich (Achsstellung) hinlege damit ich geometrische Einflüsse
minimieren kann.
Die "offizielle" Aussage zum Toleranzschlauch... wo bekommt man denn sowas her? So "offiziell" hab ich das noch nirgends gelesen.
puck, dass du solche Normen kennst...
Das sagen mir meine Messungen auch.
Was sagen deine Messungen? Verhältnis Punktwiederholgenauigkeit zu Bahnwiederholgenauigkeit?
Hast ein Beispiel?
Gruß
Twister
Hallo fubini,
dann kann ich davon ausgehen dass der Roboter eine einzelne LIN-Bahn oder CIRC-Bahn egal ob KRL oder CNC räumlich gesehen gleich fährt?
Der Achsfilter müsste ja wohl auch bei der CNC-Option aktiv sein, da er erst nach der Transformation (Karthesisch->Achswinkel) zur Wirkung kommt
wie der Name schon sagt.
Der Durchmesserfehler der Kreise ist kein Problem. (den erwähnten Forumbeitrag habe ich gelesen). Diesen Parameter könnte ich
zur Not abändern. Mich stört dass die Kreise nicht rund sind.
Gruß
Twister
Hallo,
später die Bahngenauigkeit zu messen ist kein Problem, da der Roboter Laserschneiden soll.
Die Mechanik, Spiel usw. scheint auch richtig gut zu sein.
Fährt man aber einen kleinen Kreis (D<10mm) so ergibt dies mit einem Stift auf Papier schon ein sehr unrunden Kreis.
Ich vermute eher mal dass die Antriebsregler nicht steif genug eingestellt sind damit die mechanischen Bauteile nicht so
sehr belastet werden.
Zieht man z.B. ein bisschen am Antriebsriemen der Achse A5 so überschwingt dieser beim zurück positionieren/einregeln.
Ich werde mal bei KUKA um schärfere Regelparameter bitten.
Es gibt doch seit kurzem eine CNC-Option (G-Code) für KUKA, kann es sein dass hier die komplette Bahnplanung/Achsregelung anders/härter ist
oder wird nur einfach ein "G1 X100" durch ein "LIN {X 100}" getauscht?
Hat evtl. jemand diese Option schon im Einsatz und kann über Erfahrungen berichten?
Gruß
Twister
jetzt kann ich mein roboter endlich mit smartphone steuern:ylsuper:
... und jeder andere der ein Handy und deine Nummer hat somit auch... (Scherzle)
nein im Ernst, klingt interessant...
Hallo Urmel,
danke für die Ausführungen...
Ich habe aber nicht an so tiefe Eingriffe gedacht. Ebenso will ich nicht gleich einen eigenen Controller programmieren. 
Eher an sowas:
Anstatt:
LIN {X 0,Y 0,Z 0,A 0,B 0,C 0}
LIN {X 100}
Nun so:
LIN {X 0,Y 0,Z 0,A 0,B 0,C 0} C_DIS
LIN {X 10, Y 0.01 , Z 0.01} C_DIS
LIN {X 20, Y -0.01, Z 0.03} C_DIS
LIN {X 30, Y 0.03 , Z 0.02} C_DIS
LIN {X 40, Y 0.02 , Z 0.04} C_DIS
LIN {X 50, Y 0.05 , Z 0.02} C_DIS
LIN {X 60, Y 0.02 , Z -0.05} C_DIS
LIN {X 70, Y -0.04, Z 0.01} C_DIS
LIN {X 80, Y 0.03 , Z 0.03} C_DIS
LIN {X 90, Y -0.01, Z -0.01} C_DIS
LIN {X 100, Y 0.0 , Z 0.0}
Ist nur ein Beispiel...
Und dass er damit eine "perfekte" Gerade fährt.... jedes mal...
Gruß
Twister
Hallo Urmel,
ok, du hast also Erfahrung mit sowas.
Jetzt stellt sich nur noch die Frage von welchen Abweichungen sprechen wir denn bei der Bahnwiederholgenauigkeit?
Liegen die um ein vielfaches höher wie die reine Wiederholgenauigkeit?
Kann man hierzu ein paar Worte sagen oder sind das interne Ergebnisse die man nicht weitergeben kann?
Gruß
Twister
Hallo Urmel,
ja, das Thema Bahngenauigkeit ist das eine, mich würde aber eher die WIEDERHOLgenauigkeit der Bahn
interessieren.
Beispiel:
Ich will eine perfekte Gerade fahren
Weil der Roboter in einer LIN-Bewegung dies aufgrund von Geometriefehlern usw. nicht macht würde
ich die Geradenbewegung in viele kleine Geradenelemente aufteilen welche dann einzeln nachgebessert werden
können bis der Roboter eine perfekte Gerade (+-0.05mm) fährt.
Somit müsste der Roboter aber eine sehr gute BahnWIEDERHOLgenauigkeit haben.
Die Frage ist ob sich hiermit schon mal jemand beschäftigt hat.
Gruß
Twister
