Standardmässig hat die KRC2 keine IO's.
Hängt man normalerweise Buskoppler mit IO-Modulen am DeviceNet (Master, Standardmässig auf MFC 2 vorhanden) ran.
Oft verwendet Produkte von Wago / Beckhoff (Devices).
Gibt diverse Posts hierzu im Forum.
Von KUKA selbst gab es als Ersatz für die MFC-IO's der KRC1 ein "X12-Board". Wurde aber höchst selten verwendet und war Option.
Bedienerschutz ist nur 1-kanalig gebrückt.
Hauptursache sollte dies aber nicht sein.
Roten LED's an KPS sehen ziemlich dunkel aus. Oder siehst Du da ein so leichtes "flimmern"?
Am ESC-Board, Stecker X6 , zwischen 3 und 4 hast Du definitiv 24V ?
Brennen irgendwelche LED's auf dem ESC-Board ?
Boah 4.1.7 das ist ja schon fast Museumsreif
Bit-Daten-Feld gab es bei der V4.1.7 noch nicht.
Es gibt da mehrere Stände vom KCP.(KRC2, KRC2ed, KRC2 mit Safe).
Mach mal ein Foto vom KCP Stecker...
Bei der KRC2 mit V4.1.x kannst Du das auch nehmen von der KRC2ed05 wie auch Safe.
Hörst Du die Relais "schalten", wenn Du den Reset drückst ?
Sicherungen auf dem ESC-Board wirklich alle ganz ?
Wie sehen die LED's des KPS aus ?
Ps: Wir sehen hier eigentlich wirklich gerne die Photos von Brückensteckern und nicht die Schaltpläne.
Der Stecker neigt dazu, dass man in der Belegung wirklich um eine Zeile verrutscht.
Trace auf verhalten Schleppfehler wäre hier wirklich interessant.
Haben wir wirklich auch eine Regelabweichung oder nicht. ( Wenn er sagt, es lief schon mit 100%)
Was für Lastdaten sind wirklich aktiv und wo stehen wir in KUKA-Load damit dito.
Hängt vor allem FE201 dran mit allen Sicherheitsverbindungen. Gehört das KCP auch dazu.
Zum Abgrenzen Problem intern / extern bei Sicherheiten kannst Du ja mal den X11 trennen.
hi, die 2. von unten im oberen 5 er Block 26.5 V also die Nr 6 ...
Eher die F5 als die Nr. 6, oder ?
Welche der beiden ging futsch ?
Bei den Standard KRC2 (auch ed05) startet das Mainboard, sobald das ATX-Netzteil an Pin 14 Spannung anstellt. Dies passiert ja nach einschalten der Steuerung. Das macht normalerweise ein Standard-PC nicht. Bei den Soyo Mainboards wissen wir, dass bei leerer Mainboard-Batterie dies exakt auch nicht mehr passiert. Da muss man ja über Kurzschluss der Pins (Power ON-Button) ihn so starten und im Mainboard-BIOS die Einstellungen ändern, dass dies wieder funktioniert (KUKA Defaults laden).
Beim Ausschalten über den Hauptschalter schaltet das KPS die USV, gibt Signal an die MFC, die das Herunterfahren einleitet. Nach herunterfahren schaltet das KPS die ATX-Netzteilspannung weg und an Pin 14 steht keine Spannung mehr an. Also startet das Mainboard auch nicht mehr (und hat ja auch keine Spannung mehr vom Netz.
Bei Dir stehen aber weiterhin an Pin 14 Spannung an. Das wird wohl der Grund sein, dass Mainboard gleich wieder starten will.
Wenn Du den Stecker ziehst, wartest, wieder einsteckst, startet der PC ohne betätigen des Power-On-Buttons ?
Möglich, dass im BIOS nicht alles einstellbar ist. Gab bei Siemens früher Tools zum Konfigurieren der BIOS Einstellungen. Aber ob die noch auffindbar sind, bezweifle ich.
Weiss nicht mehr auswendig, aber ich denke, Du musst dieses BIOS haben:
A26361-D900-Z410-1-19 (harlander.com)
Mal in Augsburg nachgefragt ?
Läuft das Programm noch (sprich ist "Statusanzeige" Grün für's Programm)
Normalerweise wartet er eher aud "Valid" Signal. Wie hast Du Auromatik extern konfiguriert?
Aber andere Signale, die in der selben machine.dat definiert sind, funktionieren ?
z.B. die Autoext- Signale, Betriebsarten, oder z.B. $SAFEGATE_OP, dass ja auch so "exotisch" ist.
$I_O_ACT ist TRUE ?
Es würde mich nicht überraschen, wenn sie nicht mehr funktionieren würden.
Dass es mal funkte, siehe hier. Da hatten sie Ärger damit:
Auch noch speziell Deine verschiedenen Namensbezeichnungen von Tool1 und Base17 in Deinem Programm. schon einiges Experimentiert daran......
Da die Kreise 90 Grad versetzt sind, würde sich ja anbieten,
mit fixer Base zu arbeiten,
POS statt E6POS zu verwenden,
und externe Achse über PTP E1 um 90 zu drehen / weiterdrehen.
Immer das gleiche UP ablaufen lassen an gleicher Ort und Stelle ( E1 einfach versetzt).
Meine Fragen:
- ist dieses Verhalten normal bzw. so gewollt? Verlässt der Roboter hier tatsächlich seine Bahn?
Verhalten ist normal.
$ON_PATH bezieht sich auf die Bahnplanung im Vorlauf und der abgefahrenen Bahn / IST-Position im Hauptlauf. Im UP des Interrupts weichst Du davon ab. Mit Resume brichst Du die durchgeführte Bahnplanung ab und "verwirfst" sie.
Das erlaubt Dir, direkt von der aktuellen Position, zum nächsten Punkt zu fahren, ohne er die letzte Bahn noch fertig fahren muss. Keine Bahnplanung => $ON_PATH = FALSE, Was korrekt ist.
Distanzhülse und "Wichser" für den Bolzen ziehen hast Du ?
Der Ersatz-GWA hat vorne die Distanzhülse drin und ist gefüllt ?
So wie Du es beschreibst ist es aktuell das "Standard-Verhalten", wie es bei der echten Steuerung verwendet wird. Da machen wir ja alles über die "Stromzufuhr" zum Netzteil und nicht über Power ON/OFF Button. So ist es auch in der Default Konfiguration des D1688 bei KUKA hinterlegt.
Kannst Du mal alle aktuellen Einstellungen des BIOS, Teil Powermanagement posten. Wenn es verstellbar sein sollte, müsste es da einstellbar sein.
Steuerung, Software ?
Standardmässig ist er auf 1025 vorbelegt. Testweise mal auf 1026 geändert ? Steht dann Not-Aus dauernd an ?
Andere Fehler noch anstehend ?
Nach der Änderung mal Kaltstart durchgeführt ?
Wird selten gebraucht, da nicht in sicherer Technik. Wieso willst Du Ihn verwenden ?
CWRITE($CMD,STAT,MODE,"RUN /R1/Program/Test2()")
Eigentlich geht dies. Programme können in Unterordner von R1 sein.
Was Du aber weglassen musst, ist im CWRITE die Angabe des Unterordners.
CWRITE($CMD,STAT,MODE,"RUN /R1/Test2()")
Und unbedingt so Ausprogrammieren, dass Befehl nur einmal ausgeführt wird.
Der Bediener meinte das wäre die CD1... scheinbar doch nicht
Versuch es eher mal mit VCD1 (V vorherstellen)
Struc von VCD1 müsste sein ( hängt von Softwarestand ab):
STRUC SRCH_TYP_2 INT OPT,BOOL CAL_MODE,SRCH_OK,REAL CAL_VAL,MES_VAL,OFFSET,REAL TCH_RESULT_A,TCH_RESULT_B,TCH_RESULT_C,TCH_RESULT_D,TCH_RESULT_E,TCH_RESULT_F,B_X,B_Y,B_Z,W_X,W_Y,W_Z,REF_X,REF_Y,REF_Z,MES_X,MES_Y,MES_Z
Schau mal, ob Du was gescheites hast in:
VCD1.MES_Z und VCD3.MES_Z
Kannst ja auch mal komplette Variable verfolgen unter Ansicht/Variable/einzeln und mal schauen, was sich wie ändert beim Suchen.
Ich habe das gerade auch ausprobiert.
Leider mit dem selben Ergebnis.
Es ist immer toll, wenn Ihr einfach schreibt, es geht nicht.
Welcher Code ging nicht und was passierte ? Fehlermeldung ? Verhalten ? Was hast Du erwartet ?
Was sicher nicht geht, ist einfach sowas wie: "RUN/R1/Programme/Werkzeug123()"
Wer kann helfen
Fanuc selbst wäre sicher Dein richtiger Ansprechpartner.
