falsch klingt bisshen zu hart...
Ich halte KRC für eine Autorität auf diesem Gebiet... Wehn es funcktioniert, alles ist in Ordnung. Einziege Problem ist das es kein LEhrzeichen gibt zwischen X und 0.
So gehts auch:
DECL POS xP1={x 0}
und xP1 Wert wird Touchup geändert... danach gibts Werte fuer ganze Struktur - auch S und T
SPS hat keine Moeglichkeit Programanwahl auf der KRC vreilassen/unterdrucken.
Muss etwas auf KRC sing (Submit). Versuche ein PRogram per hand anwaehlen weil Submit angehalten/deselektiert ist.
keine Dokus sind noetig da BAS.SRC ist lesbar:
Go to the KUKA Xpert portal and look up KSS 8.7 for example. There you can see the list of all supported tech options and their versions.
So clicking on option will lead you to its own info page. That also applies to SafeOperation. Manual for it is where safety signals are defined.
You can do the same steps for any other KSS (such as 8.6) and compare the documents yourself.
alles falsch....
zB.
BAS(#VEL_PTP,100) ; hat NICHTS mit DAT zu tun...
BAS(#ACC_PTP,100) ; hat NICHTS mit DAT zu tun...weil
BAS(#PTP_PARAMS,100.0)ist in BAS.SRC zu sehen:
CASE #PTP_PARAMS
PTP_DAT ( ) ; nicht daselbe... nutzt DAT Datei
FRAMES ( ) ; nicht daselbe...
VEL_PTP (REAL_PAR ) ; daselbe wie BAS(#VEL_PTP,REAL_PAR)
TQMDETECTION ( ) ; nicht daselbe...STRUC QUAD_TYPE POS Stelle, BOOL edited, teil_da
DECL QUAD_TYPE QUAD[5,4]
DECL INT x,y
DECL REAL dX,dY
dX=127;mm
dY=150;mm
FOR x=1 to 5
FOR y=1to 4
QUAD[x,y].Stelle = xReferenzPunkt
QUAD[x,y].X = xReferenzPunkt.X + dX*(x-1)
QUAD[x,y].Y = xReferenzPunkt.Y + dY*(y-1)
QUAD[x,y].edited = FALSE
QUAD[x,y].teil_da= FALSE
ENDFOR ;y
ENDFOR ; x$POS_ACT ist aktuelle TCP Position (bewegt sich immer mit Roboter)
$POS_FOR ist der naechste Punkt
$POS_BACK ist vorhige Punkt
daselbe ist mit Achsen moeglich
$AXIS_ACT
$AXIS_FOR
$AXIS_BACK
ja... solange roboter von AFC mit richtige Versogung gewaelt ist.
Meistends SV400 fuer 400V Versorgung...
Nur in Americas was anderes zu finden ist (440V, 480V...)
Alles anzeigenFragen:
zu Punkt 2 - Warum kann ich die Zelle nicht finden?
zu Punkt 3 - Wie kann man den Roboter LBR iiwa finden oder einbinden?
- Bei Werner im Video ist der Roboter + Steuerung enthalten (siehe Bild 6)
- Bei mir ist der Roboter LBR iiwa aber nicht vorhanden - nur die Steuerung (siehe Bild 5)
Vielen Dank für die Hilfe!
Gehts nicht... Sunrise Steuerung ist kein KRC4.
Video von Werner zeigt Umgang mit KRC4 - nicht mit Sunrise Steuerung...
Wehn es um Sunrise OS geht, Workvisual ist nur fuer EA anpasung benutzt.
Alles andere ist mit Workbench gemacht - einschlieslich Roboter wahl, Medienflansch wahl, Sicherheit, Programmierung, Optionpakete usw. Wirklich alles...!
Bedeutet auch das alles was du von KRC4 gelernt hast, kanst du vergessen...
ich habe eine KRC4 Steuerung mit dem Roboter (LBR iiwa)
Nein, KRC4 und LBR passen nicht zusammen. Das ist Sunrise Steuerung.
ich konnte über Workbench das hinterlegte Sunrise Projekt von der Robotersteuerung (KRC4)
importieren. Dann habe ich über Workbench die IO-Configuration geöffnet (siehe Bild 1)
Das stimmt... Mann nutzt Workbench fuer alles ... (Projekt eunrichten, uebertragen, programieren...)
Nur fuer IO configuration ist WorkVisual noetig. Kommunikation mit Steuerung finded stat in Workbench - nicht Workvisual.
Achtung:
1. Benoetigte Workvisual Version ist von SunriseOS Version abhaengig - nicht jede Worvisual ist einsaetzbar (kann nicht freigewaehlt sein)
2. Sunrie.kop muss ins Workvisual integriert sein (Sunrise IO einrichtung ist nicht daselbe wie bei KRC4)
3. Es ist emphfehlungswert backup erstellen... Projekt oder Zumindest IOConfiguration.wvs.
4. Nachdem IO configuration angepasst ist, muss auch exportiert sein.
5. Sunrise Projekt ist dann mit Workbench (nich Workvisual) auf Steurung uebertragen....
genau....
und da Bus zyklus 4ms ist, schneller schreiben von Ausgang in Programm wird nicht hilfreich da Bus ist Flashenhalls und so werden Pulses verlohren.
Aber mit 5ms warte instruktionen, Zeitschlitz fuer Submit ist immer ueberschritten und damit 12ms IPO wirkt als Flashenhalls. Das bedeuted Ein/Aus Zeit ist 24ms oder laenger.
Und wehn Drehung ist kurzer als 24ms, wirds ruckelig mit mehrere Umdrehungen.
Die Schleife läuft die vorher gewünschten Schritte ab und stoppt dann, je nach zu bewegender Distanz sind es mehr oder weniger Schritte.
So gehts... aber mag zu langsam sein. Die Frage is wie lange so was wirklich dauert und ob Drehungen kontinuirlich order zerstueckelt sind... Mit PTO Klemme gehts immer schneller. 1000 oder 10000 pulse in ein paar ms ist kein Problem
macht kein Sin... 0,005s ist 5ms. Pulse jede 2ms geht einfach nicht. auch nicht mit SPS staat KRC da Ausgang wird immer TRUE (5ms>2ms).
auch 5ms geht nicht. Submit lauft auftretend jede 12ms und Zeitschlitz ist sehr eng.
und wehn jede 12ms Ausgang is ein und ausgeschaltet, bedeuted ein Zeitraum ist 24ms und max 1000ms/24ms=41.67Hz
so was ist einsaetzbar fuer zehr langsame dinge... kanst vergessen alles <24ms.
solche Dinge loest mann mit specialle Klemmen wie EL2521. weiss nicht ob die von KUKA untertuetzt sind.
Wie gesagt schlägt bei dem Roboter der Bremsentest fehl.
kanst du bitte details erwahnen? roboter hat mehrere Achsen, vieleicht auch zusatz achsen. sind alle achsen betroffen?
falls test bremsprogram falsch ist, A3 bremsfehler ist absichtlich gesetzt - auch wehn Bremse in ordnung ist. so ueber welchen test wird geredet?
und was fuer bremstestparameter benutzt sind? was ist MaxSafetyFactor? muss mehr als 1 sein, aber untershied zwischen 1.01 , 1.10 order 1.25 ist ziemlich bedeutsam.
bremsausfall in einem Jahr ist ... merkwurdig (sehr). auch fuer roboter that funzt 24/7 und Nothalt 10x per Tag ausgeloest ist.
was ist der Fehler? was ist "kapput"? Was ist the Meldung genau? wie alt ist der Roboter?
das war nur ein Fehler...
Andere Problem hat mit Scope zu tun...
da ENUM in SRC deklariert ist, es ist nur inerhalb dieser routine bekant. Funktion BEST_MOVE() hat keine Ahnung von FILED_TYPE.
Da mehr als eine Routine/Funktion mit FIELD_TYPE umgehen, relevante deklarierungen mussen von SRC nach DAT verschiebt sein:
ENUM FIELD_TYPE empty, cross, circle
DECL FIELD_TYPE field_status[3,3]robeter arm typ, steurung typ usw haben kein einfluss auf smartPad mousezeiger.
passende info ist kss version, smartPad firmware version usw.
wilde mauszeiger gab es by altere firmware... einfach by KUKA nachfragen
