Beiträge von dust2

    Hallo Roland,


    hier die Motivation für meine Weihnachtswünsche:


    1. Programm-Module:
    Iststand: der Compiler bestimmt die oeffentliche (globale) Hauptprozedur(/-funktion?) eines Moduls anhand der Uebereinstimmung des Prozedurnamens mit dem Dateinamen.
    Wunsch: beliebig viele öffentliche Prozeduren(Funktionen) mit modulweit bekannten Variablen (die gibts ja schon)
    Damit könnte man Prozeduren funktional prima zusammenfassen, z.B. alles was mit Greifer zu tun hat, z.B. in einem .src-Modul!
    Wenn man nun noch öffentliche Zugriffsfunktionen für modulweite Variablen (Properties) schreibt, erreicht man fast schon eine Kappselung wie bei OOP!


    2. kein Windows mehr auf der Steuerung!!
    hab lange überlegt, ob ich das hier schreibe, denn dieses Forderung ist hochpolitisch und ne abolute Grundsatzfrage! Aber ich sehe das einfach so und bin für Gegenargumente offen:


    Der Endanwender (und nur um den geht es ja letzendlich) hat in der Produktion keinen funktionalen Nutzen von Windows!
    Ich als Systemintegrator kann es nicht nutzen, darf ja keine weiteren Programme installieren. Windows nutzt mir also gar nichts, außer das ich keinen Laptop zum Programmieren brauche. Ich fahre aber lieber mit nen Laptop zum Kunden, auf dem eine komplette Entwicklungsumgebung inkl. Simulation und Netzwerkzugriff installiert ist und mit der ich jedes Robotersystem mit ein paar Schlüsseln in fünf Minuten nacherzeugen kann, als mit einer Tastatur und ner Maus und nen Stapel CDs untern Arm!
    Ich erbe also vom Windows nur die bekannten Probleme (such mal hier im Forum nach Registry und achte auf den Robotertyp in den Beiträgen, dann weißt Du was ich u.A. meine).



    3. keine Festplatten mehr:
    Ich hatte neulich eine Plattenausfall(fehlerhafte Sektoren) von einem Roboter Lieferjahr 2004, wenn man da kein Image hat, wirds ne lange Nacht! (Fernwartung ist ja dann auch nicht mehr)
    Wäre echt mal interessant, was Großanwender (die Automobillisten mit Ihren 500 Robotern oder die harten Jungs aus der Schmiede mit extremen Umgebungsbedingungen für Ausfallraten haben?)


    4. Socket Messaging aus dem Echtzeitsystem heraus:
    macht sich gut, wenn man Positions- oder Sensorwerte schnell und ohne Umstände an einen externen PC oder Robi zur Auswertung schicken möchte oder mit intelligenten Kameras kommunizieren will


    5. CODESYS als Soft-SPS:
    ist halt mehr verbreitet als PROCONOS und super zu programmieren


    Dem Endanwender sind solche Dinge schnuppe, der will nur, das der Robi robotet und das tun die KUKAs dann ja auch fast immer!

    Mal sehen was der Weihnachtsmann bringt.....


    Grüße dust2

    Hallo Matu,


    rufst Du WAIT SEC in der Synchronbewegung auf, bewegt sich der Roboter synchron, so wie von Robotix beschrieben. Laut KUKA gibt es keine Möglichkeit, die Bandgeschwindigkeit am Conveyor abzugreifen!
    Musst Du Dir von der SPS geben lassen!


    Grüße dust2

    Wenn Du beim KUKA eine HMI-Schnittstelle suchst, die Du über mehrere Jahre benutzen möchtest, bleibt meiner Meinung nach aus jetziger Sicht nur OPC. Seit Version 2.1 ist der KUKA OPC Server sauber implementiert und läuft ohne Probleme.


    Vorteile:
    1. Deine HMI kann nicht nur lokal sondern auch remote laufen
    2. standardisiert und dokumentiert
    3. durch OPC UA absolut zukunftssicher (muss KUKA noch implementieren!)
    4. stets gleicher Zugriff egal ob von Deinem eigenen Client oder mächtigen Fremdsystemen wie WinCC oder InTouch


    Natürlich ist das Alles nicht kostenlos aber dafür professionell und macht in Summe vielleicht 0,5-1,5% der Gesamtkosten der Roboterzelle aus??


    Grüße Dust2

    Hallo,


    hatte wirklich lange überlegt, ob ich das mal so in aller Deutlichkeit sage! Habe bisher auch immer Fragen beantwortet ohne ein Wertung abzugeben! Aber irgendwie musste das an dem Abend mal raus!
    War vielleicht zu brachial, wollte niemanden persönlich angreifen-was ich meines Ermessens auch nicht habe( im Gegensatz zu Anderen hier!) Ich stehe aber nachwievor zu dem was ich gesagt habe! Werde aber in Zukunft wieder neutral antworten! Letzendlich muss jeder selbst wissen, was er tut!


    Wegen des Überlaufs hatte ich im technischen Referenzhandbuch beim datentyp num geschaut:



    Der Datentyp num kann folgende Werte haben:
    • eine Ganzzahl, z. B. -5,
    • eine Dezimalzahl, z. B. 3,45.
    Er lässt sich auch in Exponentialschreibweise ausdrücken, z. B. 2E3 (= 2*10^3 = 2000), 2,5E-
    2 (= 0,025).
    Ganzzahlen zwischen -8388607 und +8388608 werden immer als exakte Ganzzahlen
    gespeichert.


    Ich hatte auch im RAPID-Überblick keine weitere Angabe über die Datenbreite eines num gefunden, deshalb hielt ich es für sinvoll, dort zu begrenzen.
    Die Frage, wo den nun counter im Listing von robprog das erste Mal auf 0 initialisiert werden soll, ist immer noch nicht beantwortet!!?? Wo würdet Ihr das tun, um auch über PZtoMain hinwegzählen zu können?


    Hoffe-Alles wieder gut


    dust2

    Also roboprog, wennschon dann


    PERS num Counter;


    damit auch nach Stromausfall/Ausschalten der Zähler erhalten bleibt!


    Gute Programmierer initialisieren Variablen, bevor sie sie das erste Mal benutzen!
    Die Frage wo und vor allen wann Counter initialisiert wird, ist tatsächlich nicht trivial wenn du über PZtoMain drüberzählen willst!!!



    Gute Programmierer achten beim Hochzählen auf Überlauf:


    IF counter<8388628 THEN
    counter:=counter+1;
    ELSE
    ! Fehler Überlauf geht schneller als man denkt! siehe WINDOWS....
    ENDIF


    Wenn es wirklich ein Tageszähler sein soll, kannst Du aut. um Mitternacht resetten ( mit CDate()-Funktion vergleichen ob neuer Tag)


    Meiner Meinung nach sollte aber die SPS zählen auf einer Flanke eines Eingangs der vom Robi bei jedem Teil gesetzt wird. Vorteil die SPS läuft zyklisch, kann den Wert auch gleich aufs Panel schreiben und beim Umrüsten oder Tastedruck im Bedienpult resetten. Damit bist Du auch unabh. davon, wie oft der Robi zwischenzeitlich neu gestartet oder abgeschalten wurde und musst nicht stur über Produktwechsel hinwegzählen, nur weil jemand den Resetknopf nicht gedrückt hat.
    Außerdem hat die SPS meist die Anbindung ans ERP und da Reporting immer wichtiger wird, kann der Wert ggf. einfach hochgegeben werden!


    Aber mal grundsätzlich zu Marvyn123456:


    1. Aus Der Forumüberschrift geht Dein Problen überhaupt nicht hervor!
    2. Du programmierst Schweißroboter und weißt nicht, wie man eine num-Variable deklariert, initialisiert und inkrementiert? Das macht mir schon Angst!!! Ich mein wir sind hier nicht bei Roboterselbstbau .de sondern reden von Industrierobotern! Schon mal was von der neuen Maschinenrichtlinie gehört?
    Bist Du sicher das Du entsprechend qualifiziert bist? Glaubst DU es hilft Dir, wenn Du nun das Listing von roboprog in Deinen Robi reinoperierst?


    Falls Du Praktikant bist, lass Dir bitte von Deinem Betreuer eine Dokumentation über Roboter und Steuerung geben!
    Falls Du kein Praktikant bist, fordere Deinen Chef auf, Dich dringend zum Grundlagenlehrgang nach Friedberg zu schicken!!



    Grüße dust2

    Remotedesktop alla NSM kann bei ABB nicht funktionieren, da auf der IRC5 kein Windows läuft!
    Du musst dafür sorgen, das Du die IRC-5 über Ethernet erreichen kannst. Dann benutzt Du RobotStudio (Online-Ribbon), damit kannst Du alles machen was notwendig ist. Ist genau so, als ob Du mit dem Laptop davor sitzt, nur das das Kabel halt etwas länger(Internet) ist.
    Direktverbindung mit ModemRouter (ich kann z.B den MoRoS von INSYS empfehlen, gibts für analog, ISDN GPRS und VPN). Der hat noch einen 4-fach-Switch mit drin, das sollte für kleine Anlagen reichen! Hab damit mal zwei FANUCS gemacht, müsste für ABB auch gehen!


    http://www.insys-tec.de/conten…uter-switch/moros-lanpro/


    Moderne Konzepte vernetzen alle SPS und Robotersteuerungen der Anlage per Ethernet zu einem Maschinennetz, dort hängt ein NAT-Router mit drin, der als Bridge ins Kundennetz fungiert. Einwahl ins Kundennetz per VPN und von dort über NAT auf die Steuerungen!
    Muss halt nur mit der IT des Kunden sauber abgeklärt werden wegen Freischaltung von Ports und Konfiguration der KundenFirewall!
    Machinenetzwerk an der IRC-5 am freien Ethernet-Port des Rechners, Serviceport am Schaltschrank bleibt wie er ist für den ABB-Monteur!
    Hängst Du Dich bei der IB mit deinem Laptop ins Maschinennetz, erreichst Du alle Robotersteureungen gleichzeitig und kannst sehr leicht Programme zwischen den Roboter kopieren!


    Wenn Du Dich einmal mit VPN auf eine Maschine eingewählt hast, willst Du nie wieder was mit Modem machen- glaubs mir!!




    Grüße dust2

    Nach Warmstart sind die Änderungen in der eio.cfg aktiv!
    Hats Du Profibus FA oder eine PCI-Profibuskarte?



    Zu Deiner zweiten Frage:


    Definition des virtuellen Bus:
    EIO_BUS:


    -Name "Virtual1" -ConnectorID "SIM1"


    Definition der virtuellen Unit-Types:
    EIO_UNIT_TYPE:


    -Name "Virtual" -VendorName "ABB" -ProductName "Virtual unit"

    Definition der virtuellen Unit:
    EIO_UNIT:


    -Name "virt_unit_1" -UnitType "Virtual" -Bus "Virtual1"

    Definition eines virtuellen Signals für die semistatische Task:
    EIO_SIGNAL:


    -Name "voGripAction" -SignalType "DO" -Unit "virt_unit_1" -UnitMap "0"\
    -Access "ALL"


    dust2

    Ja hast Recht! Hab mal 1% eingetragen, nun sehe ich, das der Roboter tatsächlich langsamer läuft, die Anzeige bleibt auf 100%! Da mein Roboter noch nicht verdübelt ist, kann ich nur im Bereich 0-25% fahren, da war der Unterschied zwischen 10 und 20% kaum zu sehen und ich hatte erwartet, das die Anzeige auch die programmierte Geschwindigkeit anzeigt!


    Bleiben folgende Fragen:
    1. Wie macht man beim ABB Suchfahrten mit stets konstanter Geschwindigkeit unabhängig des eingestellten Override am FlexPendant?
    2. Wie ist das bei Conveyortracking, wenn das Band mit 30m/min läuft und der Bediener am Flexpendant 10% einstellt? Wenn es keine Möglichkeit gibt, die Geschwindigkeit wenigstens in der Synchronphase hochzusetzen, fährt der Roboter jedesmal in die Achs-Begrenzung?

    Hallo,


    ich habe versucht, den Programmoverride OP-Mode abhängig zu setzen:



    ! ########### Overide setzen ######################
    ! Speedrefresh setzt nur wenn Wert < als am Flexpendant!!!!!!!
    PROC rSetOverRide(NUM nNewOverride, \switch Set | switch Restore )
    IF Present(Set) AND (NOT Present(Restore)) THEN
    ! aktuellen Override speichern
    nAcOverride:= CSpeedOverride();
    ! Override nur im AUTOMATIK-Betrieb setzen
    TEST OpMode()
    CASE OP_AUTO:
    SpeedRefresh nNewOverride;
    ! in TRAP Speedrefresh wird Speed zeitzyklisch auf gesetzt nAckSPEED gestetzt!
    nAckSPEED:=nNewOverride;
    CASE OP_MAN_PROG: ! Einrichtbetrieb max. 250mm/sec
    SpeedRefresh 100;
    ! in TRAP Speedrefresh wird Speed zeitzyklisch auf gesetzt nAckSPEED gestetzt!
    nAckSPEED:=100;
    CASE OP_MAN_TEST: ! Einrichtbetrieb 100%
    SpeedRefresh 25;
    ! in TRAP Speedrefresh wird Speed zeitzyklisch auf gesetzt nAckSPEED gestetzt!
    nAckSPEED:=25;
    ENDTest


    ENDIF


    IF Present(Restore) AND (NOT Present(Set)) THEN
    SpeedRefresh nAcOverride;
    ENDIF
    ENDPROC



    Die Prozedur wird bei Programmstart im Initialisierungsteil aufgerufen. Setze ich den Roboter am Flexpendat auf 100% und startet das Programm, bleibt der Override auf 100%, auch wenn per Programm auf 25% gesetzt wird.


    Nun habe ich eine Zeitinterrupt definiert, der alle 2 Sekunden folgende TRAP-Routine aufruft:


    TRAP speed_refresh


    SpeedRefresh nAckSPEED;
    TPWRITE " Refreshed oder was??" \Num:=nAckSPEED;


    ENDTRAP


    Der TRAP läuft zyklisch, den Override beeinflusst das in keinster Weise, weder Anzeige am Pendant noch die Geschwindigkeit am Robo! Die Anweisung SpeedRefresh scheint ohne Wirkung zu sein??????? (IRC5 RW 5.12)


    Mir ist klar, das ich die vom Flexpendant vorgegebene Geschwindigkleit dominiert!
    Wie macht man beim ABB mit dieser Einschränkung Suchfahrten mit stets konstanter Geschwindigkeit ??


    Habe eine Bewegungstask, eine NoMotion-Task(NORMAL) und eine zykl. Task (SEMISTATIC) im System!
    Den Speedrefresh mach ich in der Motion-Task!



    Danke für Eure Hilfe


    dust2

    Hallo Titan72,


    Danke für den Tip! Es funktioniert!
    Das Feld im Flexpendat anzulegen ist viel kompfortabler und vor allem sicherer als in RobotStudio,wie ich es versucht hatte! Dort hat man den Stress mit den vielen eckigen Klammern und Kommas, was bei solchen Ausmaßen kaum noch zu beherrschen ist!
    Wieder was gelernt!


    Danke......

    Hallo,


    ich benötige in meinem Programm ein 3-dimensionales Feld von robtarget-Variaben.
    Also TASK PERS robtarget rZwPos{6,6,2}
    Laut Doku sind 3 Dimensionen erlaubt. Ich bekomme die Deklaration nicht hin.
    Habe nun zur Vereinfachung mal mit einen num-Feld Versuche gemacht, meiner Meinung nach müsste die Deklaration so aussehen:

    TASK PERS num rr{6,6,2}:=[[
    [1,2,3,4,5,6],
    [1,2,3,4,5,6],
    [1,2,3,4,5,6],
    [1,2,3,4,5,6],
    [1,2,3,4,5,6],
    [1,2,3,4,5,6]
    ],
    [
    [1,2,3,4,5,6],
    [1,2,3,4,5,6],
    [1,2,3,4,5,6],
    [1,2,3,4,5,6],
    [1,2,3,4,5,6],
    [1,2,3,4,5,6]
    ]] ;


    Das bringt Fehler 4045 "Unterschiedliche Dimension von Datenfeldern"
    Hat jemand ein Beispiel für solch eine Deklaration? 2D Felder auch mit robtraget funktionieren ohne Probleme!


    Danke für Eure Hilfe


    dust2

    Hallo,


    hab das jetzt so gelöst (Voraussetzung ist MULTITASKING)


    1. neue Task T_ZYK angelegt-TYP NORMAL, noMotion
    2. einen digitalen Ausgang voGripOf angelegt auf virtueller UNIT
    3. Funktionstaste 1 so konfigiriert, das diese Ausgang voGripOf setzt
    4. in TASK T_ZYK eine Prozedur wie folgt:



    PROC main()
    TEST OpMode()
    CASE OP_AUTO:

    CASE OP_MAN_TEST: ! Einrichtbetrieb 100%

    CASE OP_MAN_PROG: ! Einrichtbetrieb 250mm/sec
    ! voGripOf wird mit Funktionstaste I auf True gesetzt
    ! damit wird hier Greiferaktion gestartet
    IF DOutput(voGripOf)=1 THEN
    RESET voGripOf;
    !Palettenklauen öffnen
    SET doPalGr_ROp;
    SET doPalGr_LOp;
    RESET doPalGr_RCl;
    RESET doPalGr_LCl;
    ...........


    ENDIF



    ENDTEST
    WAITTIME 1.0;
    ENDPROC


    5. Nachdem alles funktioniert, T_ZYK auf Typ SEMISTATIC setzen, dann läuft diese permanet im Hintergrund


    Verbesserung: man könnte noch die Zustimmtaste als Bedingung mit reinnehmen,
    man könnte mit einem zweiten virtuellen Ausgang ein STOP in der permaneten Task auslösen, dann hält die Task mit einer Fehlermeldung an und man kann ändern ohne jedesmal den Tasktyp wechseln und Warmstart machen zu müssen


    Dust2

    Hallo,


    gibt es einen Systemausgang, mit der man der SPS mitteilen kann, das der Operater den Roboter resettet hat, also PZ to Main. Ich hab IRC5 mit Multitasking, da kann man schon was machen, Problem: die SPS muss es mitbekommen, bevor!! der Roboter wieder gestartet wird!
    Der Systemausgang muss als vom Roboter nicht von einem Roboterprogramm aus gesetzt werden oder in einer Hintergrundtask die immer läuft(so wie submit-interpreter beim KUKA)


    Danke


    dust2

    Hallo,


    wenn Du mehr als zwei Ablageorientierungen benötigst, empfehle ich Dir, die Ablagepos in ein Werkobjekt zu legen und die Position und Orientierungen nicht zu teachen, sondern in einem Feld fix zu hinterlegen oder in das Feld hineinzuteachen. Hier ein Beispiel mit 4 Abladepositionen auf einer Palette, Position 1 und 3 gegenüber 2 und 4 um 180Grad gedreht!



    TASK PERS pose EmptyTrayPos{4} := [
    [[850,170,0],[0,0,0,1]],
    [[850,590,0],[1,0,0,0]],
    [[340,580,0],[0,0,0,1]],
    [[268,180,0],[1,0,0,0]]
    ];

    Vorteil: Da kannst Du jederzeit beliebig erweitern und
    geht auch bei asymetrischer Last, wenn sich bei der A6-Drehung die x/y-Werte verschieben und wenn Du oft zwischen den Positionen hin- und herschalten mußt!
    Z.B Bauen von vier gleich hohen Stapeln auf der Palette, brauchst Du nur den Index pro Lage bis 4 zählen, dann von vorn.
    Im Programm dann in einem Test/ Case die jeweilige Position aus dem Feld in Deine akt. Bewegungsposition umladen:


    ZPos.trans:=EmptyTrayPos{nTrayIndex}.trans;
    ZPos.rot:=EmptyTrayPos{nTrayIndex}.rot;


    Die entsprechenden Vorpositionen einfach mit offset aus Zielpositionen bilden


    dst2