Beiträge von Hinky

  • Verständnis-Problem bei der Berechnung von REAL Werten


    Im genannten Wikipedia-Artikel ist unter der Überschrift 'Dezimalbrüche' zu lesen:
    "Schon einfache Dezimalbrüche wie 0,1 können nicht exakt als binäre Gleitkommazahlen dargestellt werden, da jede rationale Zahl, deren gekürzter Nenner keine Zweierpotenz ist, im Binärsystem zu einer nicht abbrechenden, periodischen Darstellung führt."


    Die Zahl 179.6 gehört ebenso wie die 0.1 zu den Zahlen, die nicht exakt dargestellt werden können und bei denen es dann zu Rundungsfehlern in den letzten Nachkommastellen kommt.

  • Ablageposition im A Winkel manipulieren

    Hallo bluebird277,


    du hast nach der Manipulation des Winkels zwei Verfahrbewegungen im Programm. Welche macht denn die Probleme ?


    Falls es die zweite ist (in ';FOLD LIN CALCULATED...'):


    Wenn über das Inline-Formular eine LIN-Bewegung auf den Punkt 'CALCULATED' angelegt wird, dann werden die Zielkoordinaten in 'XCALCULATED' gespeichert.
    Folglich ist bei Berchnungen dann auch XCALCULATED als Berechnungsziel zu verwenden.

  • Beckhoff CX5020 über EL6692 an KRC4

    - Hast du es auf der Beckhoff-Seite einmal mit der Einstellung 'Sync master primary' versucht (falls die KRC das Sync-Telegramm nicht an die Sekundärseite der EL6692 verschickt) ?
    - Wenn ich es richtig interpretiere, hast du in WoV jeweils ein Byte in jeder Richtung als Prozessdaten gemappt, im TwinCAT Systemmanager aber jeweis zwei BOOL-Variable. Normalerweise sollte die Prozessdatenbelegung im Hinblick auf Datentyp und Anzahl in beiden Systemen identisch sein.

  • ConveyorTech für KR C4

    Ich stehe vor der Aufgabe, in naher Zukunft ConveyorTech erstmalig für die KR C4 (bisher KR C2) in Betrieb zu nehmen.
    Kann mir jemand die ConveyorTech-Doku für einen halbwegs aktuellen KSS-Stand der KR C4 zur Verfügung stellen ?
    Danke !
    Gruß Hinky

  • Offlineberechnung einer Linearbewegung

    Hallo Komkonza,
    du beschleunigst mit 2.3 m/s*s auf eine Endgeschwindigkeit von 0.25 m/s. Theoretisch dauert der Beschleunigungsvorgang 108.7 ms, das sind also 'nur' 9 Ipo-Takte. Hier dürfte der von fubini erwähnte $FILTER das Ergebnis stark beeinflussen, zumal die Datenaufnahme im Submit-Interpreter bei dessen Taktung (mal 12ms, dann auch mal 24ms) zusätzlich die Messgenauigkeit verschlechtert.
    Warum wählst du nicht stattdessen eine Endgeschwindigkeit von z.B. 1.2 m/s. Dann würde dein Beschleunigungsvorgang 521 ms bzw. etwa 44 Ipo-Takte dauern und theoretisch sollte der TCP in der Zeit ca. 310 mm zurücklegen. Bei deiner Gesamtfahrstrecke von 960 mm bedeutet das, dass sich in etwa eine Streckenaufteilung von 1/3 Beschleunigung, 1/3 Konstantfahrphase und 1/3 Verzögerung ergeben sollte. Ich bin mir ziemlich sicher, dass dabei dann die gemessene Beschleunigung dem Grenzwert von 2.3 m/s*s deutlich näher kommen dürfte.

  • PDAT_ACT.APO_DIST oder $APO.CPTP

    Zitat von dust2


    schau mir gerade die BAS an:
    d.h. also wenn zwischen den PDAT-Zuweisungen und der Bewegungsinstruktion kein BAS-Aufruf kommt, bleiben die Parameter unwirksam?


    Ja genau, erst mit der folgenden Zeile
    BAS (#PTP_DAT )
    werden die Daten in PDAT_ACT wirksam.
    Diese Zeile ist automatisch in einem Fold mit einem (PTP-)Bewegungsbefehl enthalten.

  • Flag mit sprechenden Namen

    Zitat von Toud


    Allgemein mal gefragt, gibt es irgenwelche Vorteile für die Systemflags, außer dass mann diese nicht selber deklarieren
    muss? Ich hab die noch nie hergenommen.


    Für die Systemflags gibt es einen eigenen Dialog bei der KRC im Menü Anzeige.
    Wenn die Flags z.B. zur Auswahl verwendet werden, welches Magazin beladen werden soll, ist es für die Bediener i.d.R.
    einfacher, das über den Flag-Dialog vorzugeben als im Programm etwas zu ändern.

  • KUKA Programmierer

    iVALUE ist mit dem Datentyp INT deklariert, die Division (iVALUE / 2) wird deshalb als Ganzzahldivision ausgeführt
    und es ergibt sich:


    ((1/2)*2) = (0)*2 = 0
    ((2/2)*2) = (1)*2 = 2
    ((3/2)*2) = (1)*2 = 2
    ((4/2)*2) = (2)*2 = 4
    ((5/2)*2) = (2)*2 = 4


    Gruß


    Hinky

  • KR C4 SmartHMI.exe startet mit Fehler

    Die Kombination der beiden Lösungsvorschläge von K(A)RL und notime hat das Problem gelöst:
    Zunächst wurde die Datei 'authentication.config' wiederhergestellt (sie fehlte komplett) und dann SetKrcUsers 512 ausgeführt. Danach lief die SmartHMI wieder fehlerfrei hoch.


    Danke an alle !


    Hinky

  • Quit Stellgröße A3 - Kein Achse verfahrbar

    Zitat


    Gibt es noch mehr die Schwierigkeiten mit der 4.1.7er SW haben?


    Ich habe bei einem Kunden aktuell das gleiche Problem mit einer KRC2 Version 4.1.4 SP02, an dem ein KR 30/1 betrieben wird (Steuerungstausch KRC1 -> KRC2, MaDA von KUKA erstellen lassen, trotzdem kommt Meldung 1104 bei Achse 3 und 5).

  • Variablen Deklaration

    Zitat von Hubrak


    IF ZOK OR ZGUT == 6 THEN -------> Operantentypen sind nicht vergleichbar (ZOK und ZGUT sind Integer)


    Welche Logik ist denn beabsichtigt?
    Der Zahlenwert ZOK ist 6 oder der Zahlenwert ZGUT ist 6 ==> dann 'IF (ZOK==6) OR (ZGUT==6) THEN'
    Die Summe der Zahlenwerte ist 6 ==> dann 'IF (ZOK+ZGUT)==6 THEN'


    Zitat von Hubrak


    IF ABS(ZREFF-ZMESS) <= 1,5 THEN ---------> "THEN" erwartet.... mein persöhnlicher Favorit


    Der Nackommaanteil wird bei Programmiersprachen immer mit dem Punkt '.' getrennt, als '1.5' stat '1,5',
    'Falsches Kontrollstrukturende etc.' werden dann Folgefehler sein.

  • RobRoot um 90° drehen

    Einiges ist dabei schon zu bedenken:
    - Nach der Umstellung des Roboters darf dann 'hinter' dem Roboter (A1 = +- 180°) keine Station sein, aber ich gehe davon aus, dass ihr das bei den Überlegungen berücksichtigt habt
    - Bei allen geteachten Punkten, die als AXIS definiert sind (dazu gehören z. B. die HOME-Positionen), muss der Wert für A1 um 90° korrigiert werden
    - Bei allen POS bzw. E6POS basierten Teachpunkten kann es Probleme mit dem TURN-Wert geben, da dieser nach der Umstellung anders sein kann als vorher (wenn im geteachten Punkt die Position von A1 vorher positiv und nachher negativ ist oder umgekehrt). In diesem Fall wird dann eine STOP-Meldung ausgelöst 'Unerreichbarer Punkt: Softwareendschalter +[-]A1'. Dies läßt sich i.d.R. durch eine manuelle Anpassung des TURN-Werts beheben: Die Stellung von A1 wird im letzten Bit des TURNS angegeben, d.h. eine Korrektur des TURN-Wertes um 1 in die richtige Richtung hilft hier weiter.


    In jedem Fall aber sollten alle geteachten Punkte und alle Bewegungen sorgfältig geprüft werden !


    Gruß Hinky