Posts by SJX

    ich habe eben mal in einem Projekt bei mir nachgeschaut.

    Hättest Du noch die Infos der Step 7 Projekte, wie diese Konfiguriert wurden.

    Alleine die Einträge der .ini's nützen nicht viel.

    Müssen passen zu den Step7 Hardwarekonfigurationen.

    Gegenüber der Doku ist auch die Steckplatzkonfiguration des Device der Roboterkonfiguration komplett anders.


    Hast Du die Doku zu Deiner ProfinetIO-Version ?

    Kannst Du mal noch Printscreens der Projekte posten mit den getätigten Einstellungen.

    Nicht jeder hat Zugriff zu Siemens Software und kann Deine Projekte anschauen.

    Wenn ich sehe, dass Du Geschwindigkeiten mit Nachkommastellen verwendest, würde ich eher vorschlagen, dass Du mit einem Trace Deine Achsbewegungen aufzeichnest und daraus die Beschleunigung bestimmst.


    Dann hast Du Echtzeitdaten und das dynamische Modell wird berücksichtigt.

    Wie kann man denn sichergehen, dass der Stift nicht weiter in Z zugestellt wird. Damit meine ich warum ist man sich sicher dass hier kein Crash in die
    Tischplatte gefahren wird.

    Erfahrung.

    Werner programmiert die Punkte mit relativ wenigen Achswinkelumorientierungen in den Achsen 4-6.

    Mit den Achswinkelstellungen 2 + 3 kann man etwa Abschätzen, ob die Bewegung eher nach oben geht oder durch den Tisch.

    Es ist doch immer das gleiche vorgehen bei Abweichungen von Punkten.


    Zuerst mal Mechanik überprüfen. Am einfachsten via Justage-Prüfung mit EMT.

    Brenner und Brennerhalterung überprüfen. Mit Lehre oder Referenzposition.

    Position der Schweissvorrichtung Kontrollieren via Referenzpunkte.


    Mit diesen Steps sollte dann eigentlich erkennbar sein, ob Du mechanisches Problem hast oder Software.

    Verdrahtung:

    Laut Bild von Post #1 sind die Anschlüsse an der Busklemme falsch aufgelegt

    Ist: schwarz-orange, orange- schwarz

    soll: schwarz-schwarz, orange-orange

    (notfalls Anpassung an der PC Karte notwendig)

    Bist Du Dir wirklich sicher ?

    Meinte es zuerst eben auch.

    Verbindest ja "2x Sender mit Empfänger". Dann würde es doch passen?

    Man, einfach zu lange her. Und irgendwie sympathisch war mir Interbus nie.

    Zum Thema Interbus:


    Wenn ich dies richtig sehe, hast Du einfach 8 Ausgänge an diesem Modul. Mehr nicht vorhanden.

    Gemappt ist in der IOSYS.INI aber folgendes: (auskommentierte Zeilen entfernt)

    Code
    [DRIVERS]
    INTERBUS=1,ibusInit,ibusdrv.o
    
    [INTERBUS]
    INB0=1 ;$IN[1-8]Eingaenge
    INB0=1 ;$IN[129-144]
    OUTB0=0 ;$OUT[1-8]Ausgaenge
    OUTB0=1 ;$IN[129-144]    Folgenanwahl + Systemeingaenge

    Wäre ja eigentlich nur:

    OUTB0=0 ;$OUT[1-8]Ausgaenge


    Im geposteten Archiv hat die IOSYS.INI ein uraltes Datum. Warum ?


    Was für Meldungen stehen nach EA-Rekonfiguration an ?

    Diagnose-LED's der IBS-Karte zeigen was an ?


    DIP-Switch Einstellungen, IO-Adresse stimmt mit der Adresse in der interbus.ini überein ? ( 0x390)


    In der Interbus.ini hast Du noch folgendes scharf:

    LOCALMASTEROK=9

    wirklich gewollt, dass Ausgang 9 Dir den Status weitergeben soll ? Wenn ja, wohin ? Aktuell hardwaretechnisch ja nicht vorhanden.

    Zu Punkt 1: Umbau VKRC => KRC:


    Was für KSS hast Du installiert ?

    Was steht als Wert der Version in der progress.ini ? Wert 5 ?

    Prinzipiell sollte damit möglich sein, KSS Version mit "Sicherheitskonzept VW" zu betreiben.

    Kennt ja 2 Betriebsarten am KCP, Test und "Automatik extern".

    Mit E2 / E7 Schliessung (Schlüsselschalter) sollten dann die entsprechenden Modis SSTEP T1 ODER SSTEP T2 verbunden mit Bedienerschutz wählbar sein in Test.


    Tabelle der verschiedenen Status habe ich nur von einer KRC2, sind vermutlich aber die gleichen.

    Habe im Segment 2 Ausgänge Buchse 0-3 und Segment 3 Eingänge Buchse 4-7

    Nach Herstellerbeschrieb Murr passt dies für Dein Modul.


    Zur Auswahl stehen noch Ausgänge Pin 2 oder Ausgänge Pin4, wenn es diese sind, wieviele Segmente belegen sie ?

    Wären angedacht für Murr-Module, wo Du auf allen Buchsen Pin2 z.B. Ausgang hast. Oder auf allen Buchsen auf Pin 4 einen Ausgang hast. Reservieren je ein Byte. Ist bei Deinem Modul und Deiner Belegung ja nicht der Fall.


    Haben ja getrennte Spannungen UA und US.

    Aktor-Spannung UA steht an ?

    DIGIN-Anweisungen wurden 1:1 so nicht ersetzt mit allen Möglichkeiten.


    Warum verwendest Du nicht gleich direkt die Signalvereinbarung als Regelglied?

    Evtl. musst Du einfach auf 32Bit gehen, wenn es ein Problem von +-Werten wäre.

    $ANIN's wäre sicher auch eine Möglichkeit. Könnte man evtl. gleich so verschalten im WoV.

    BRAKE F stoppt nur die Bewegung, nicht den Programmablauf.

    Mach mal ins UP noch ein HALT. Dies stoppt den Programmablauf.


    Bei Schweissapplikationen ist ein Kollisionsschutz als "Brennersicherung" Standard.

    Da ist er in allen Betriebsarten aktiv.

    Sehr oft leidet der Brenner in T1, wenn die Bediener teachen, freifahren, oder was auch immer fummelt.

    Im Crashfall ist da normalerweise ein Taster da, wo Du kurzfristig das Signal des Kollisionsschutzes überbrücken kannst und sich resetet, wenn er wieder in "Normalstellung" ist.


    Wie er integriert wird ins System ist oft abhängig, wie schnell Du fährst und wie weit der Kollisionsschutz "nachgeben" kann. Dies über Interrupt zu lösen ist sicher eine schnelle Methode. Verlangt aber zwingend einen laufenden Interpreter. $Move_Enable ist eine gute Alternative, die sehr oft ausreicht.

    Typischerweise bei "normalem" Code würde ich mit 12 - 48 ms rechnen.

    Befehle wie "varstate", "Cwrite", etc, pushen das ganze aber gewaltig hoch.

    Praxis zeigt, dass es auch endlos sein kann. :mrgreen:

    Wenn ich allerdings den Bedienerschutz öffne, schließe und ihn quittiere, dann bleibe ich bei der Quittierung der $StopMess hängen (Schrittkette 90 in meinem Programm).

    Nach testweisem Einfügen von 2Sekunden Wartezeit, konnte ich beobachten, wie $ConfMess pulsiert aber $StopMess dauerhaft true ist.


    Wenn ich auf dem SmartPad manuell die Antriebe einschalte, läuft das Programm weiter.


    Ja, dies ist so. Wird Dir den ZK entladen und $PERI_RDY = FALSE sein.

    Durch dein manuelles Einschalten der Antriebe änderst Du diese auf True und voila.


    Im Ablauf hast Du $CONF_MESS doppelt drin.

    So wie ich auch. Ich mache aber nie Rücksprünge in der Kette und baue keinen "loop" ein.

    Ich habe die erste Quittierung nur Optional drin wegen möglichen allgemeinen Fehlern.

    Der Ablauf von KUKA sieht die Quittierung erst später vor.



    So würde er erstmal sicher weiterlaufen, Antriebe einschalten und danach in Schritt 120 Quittieren.


    Deine ELSE-Schritt Philosophie an diversen Orten haben die Tendenz, im Fehlerfall hängen zu bleiben in der Kette. Keine Resetfunktion vorsehen wollen für die Schrittkette ?


    Weiter sehe ich keine bewusste Start-Funktion für den Bediener.

    Je nach Konstellation flitzt der Roboter schon los nach Umschaltung der Betriebsart, Schliessen der Türe oder Anwahl des Programmes. Finde ich jetzt Sicherheitstechnisch Maschinenschutzbezogen nicht optimal. Ist Dir dies bewusst ?

    KSS < V8.x hatten eine "IMPORT...IS" Anweisung zur Übernahme von Daten aus anderen .dat's, die man leider entfernt hat mit Umstieg auf KRC4.


    Auch eine Möglichkeit wäre, die Positionen in Globalen Arrays zu handeln.

    Verwenden würde ich keine ILF's damit.

    Für's direkte Teachen bräuchtest Du Experttech.

    Mein Problem ist, ich weiß nicht, worauf bei dem Kauf eines Roboters zu achten ist

    - Vollständigkeit ( Länge Verbindungskabel, Software-Installationsmedien, Dokumentationen, etc.)

    - Mechanischer Zustand ( Getriebe, Getriebespiel, Lager ) / Arbeits- Lastbereich optimal für Anwendung.

    - Ersatzteilverfügbarkeit (Produkte sind länger schon abgekündet)

    - Externe Unterstützung bei grösseren Problemen / Hersteller machen z.T. nichts mehr.

    - Schnittstellen zur Anbindung / Integration Stromquelle ( Bussysteme )

    - Softwareoption für Schweissapplikation vorhanden / noch erhältlich

    - exakte Rechnerausstattungen


    Wenn Du das System noch über längere Zeit betreiben möchtest,

    würde ich Dir eher anraten, ein Produkt der beiden Hersteller eher ab 2005 anzuschauen.

    Hätten dann bei KUKA mind. eine KRC2ed05 Steuerung und bei ABB eine IRC5.

    Würden dann auch EN2006/42 entsprechen.

    Auch die gängigsten Bussysteme der Stromquellenhersteller sollten mit solchen Geräten unterstützt werden.

    Durch die Parameterübergabe in meinem Beispiel werden die Koordinaten ja verschiedenen Punktnamen zugeschrieben mit :OUT Parameter im übergeordnetem Programm.

    Der Aufruf wäre dann halt mit Deinen Punktnamen:

    POS_KOR_MOVE(60_mess)

    POS_KOR_MOVE(30_mess)


    Oder wir verstehen uns wirklich nicht.