Posts by fischertech

    Hallo WernerRob.


    Sichere Rückzugsstrategien sind begehrte Themen. Sieht man auch hier im Forum. Wäre mal eine Idee für KUKA hier was brauchbares im Grundsystem zu programmieren.


    Bei uns, werden alle Palettierer mit einer funktionierenden Rückzugsstrategie ausgeliefert.
    Es ist dann generell bei "Check HOME" angesiedelt. So dass bei einem Programm-Reset oder z.B. bei einem Stromausfall, nach einem Kaltstart wieder automatisch ein sicherer Weg zu HOME gefunden wird.
    Ich sage zu unseren Kunden immer spaßhaft: das Handlings-Programm braucht 10% der Programmzeilen. Der Rückzug 90%.

    Nun, bei unseren Palettierern ist es meist einfach. Ist $IN_HOME==false speichere ich die aktuelle Achs-Position in einer Variablen. Ich fahre dann ein wenig in Z nach oben (z.B. LIN_REL {Z -100} #TOOL), dann überschreibe ich die A2-Pos. mit einem absoluten Wert und fahre die Position an. Das mache ich ein paar Mal noch mit anderen Achsen. Wenn alles außer Bereich ist gehe ich in HOME.


    Bei unseren 6-Achsern, bin ich auch immer noch am herausfinden der besten Strategie. Mit Merkern setzten (wie schon oft beschrieben) bin ich nicht wirklich glücklich geworden. Dann habe ich versucht anhand der Act.-Pos. von A1 herauszufinden wo ich bin (vor allem ob ich noch in einem speziellen BASE bin). Funktioniert aber auch nicht immer so genau (vor allem wenn's eng wird).


    Meist habe ich für unterschiedliche Base's spezielle Stoßrichtungen des Tools. Also wäre es für mich schon eine Hilfe, wenn ich wüsste ob ich noch in einem BASE-Bereich bin und wenn ja in welchem. Dann könnte ich oft gegen die Stoßrichtung wieder weg fahren.

    Weg fahren am besten auch mit einem Absolutwert und nicht mit einem Relativwert (da man mit zwar vom Werkstück/Maschine wegkommt, aber nach hinten wieder anstößt oder an die Grenzen kommt)


    Aktuell mache ich das so:

    Ich bilde mir pro Base einen Kartesischen Arbeitsraum (mit KUKA Arbeitsraumüberwachung) und weiße diesem einen Ausgang (auch für die SPS) zu. Den Arbeitsraum bemesse ich nur im Bereich wo ich definiert rückziehen müsste.

    Wenn ich dann am Programm-Anfang nicht $IN_HOME bin, setzte ich ein TOOL aktiv.

    Dann prüfe ich die Ausgänge der Arbeitsraumüberwachungen. Ist einer TRUE, setzte ich das entsprechende Base aktiv und fahre mit einigen absoluten, kartesischen Positionen frei. Bin ich dann im ungefährlichen Bereich, geht's weiter gen HOMAE wie mit den Palettierern.


    Bei mir tut's so meistens ziemlich gut, ohne dass der Bediener eingreifen muss.

    Aber ich weiß, es gibt auch kompliziertere Anlagen, wo selbst das nicht hilt.


    Gruß Roland

    Hallo zentrumdermachtt.


    Ich habe auch schon festgestellt, dass wenn Du die XHOME numerisch in der config.dat änderst das Signal $IN_HOME nicht kommt.
    (zumindest bei bestimmten Softwareständen).
    Wenn Du die neue HOME jedoch teachen tust, kommt das Signal wieder korrekt.
    CU Roland

    Ist kein Hexenwerk:
    Erst Interrupt deklarieren. 16 für steigende Flanke, 17 für fallende Flanke.


    Code
    INTERRUPT DECL 16 WHEN $IN[1]==TRUE DO UP1( )
    INTERRUPT DECL 17 WHEN $IN[1]==FALSE DO UP2( )


    Dann Interrupt's scharf schalten


    Code
    INTERRUPT ON 16
    INTERRUPT ON 17


    Am Ende der sps.sub dann noch die Unterprogramme einfügen die Abgearbeitet werden sollen bei den Flanken.
    DEF UP1()

    Code
    DEF UP1()
    ;hier Code einfügen
    END
    DEF UP2()
    ;hier Code einfügen
    END


    Kannst ja einfach das bestehende sps.sub öffnen. Dort ist ja schon einer angelegt. Einfach noch Deine Sachen an den entsprechenden Stellen dazuschreiben.
    Reagiert astrein auf Flanken ohne erst Merker mit den alten Werten anzulegen.
    Gruß Roland

    Um versehentliche Touch-Up's zu sperren, verwenden wir gerne den Schreibschutz für's Programm.
    Programm markieren, dann [size=2][font="Calibri",sans-serif]Bearbeiten>Eigenschaften>schreibgeschützt[/font][/size]
    Ist nicht ganz das was Du willst, aber vielleicht hilft es trotzdem.


    Gruß Roland

    Hallo BastelNerd.


    Vielleicht kannst Du diese EtherCat-Schnittstelle mit TwinCat scannen und dann mit TwinCat die eingeholten Informationen als ESI (XML) exportieren.
    So ähnlich habe ich das schon mal mit CoDeSys gemacht, und konnte das dann in WoV importieren.
    Gruß Roland

    @ Loipe: ja bei ungefähr Profinet 20%.
    Ich nutzte Win10 auf meinem Notebook schon seit dem Windows-Update damals von Win8 auf 10. Bisher mit Erfolg! Alles tut gut (Siemens, WoV, CoDeSys, ...). Auch Software die nicht für Win10 gebaut wurde.
    Bei neuen Anlagen geben wir oft ein kleines, kostenloses (<200 EUR) Notebook mit, wo alle nötige Software installiert ist. So kommt man via TeamViewer auf alles aus der Ferne.
    Jedoch mit den neuen Notebooks mit Win10 tut WoV eben nicht mehr.
    Kleine Notebooks mit Win7 sind leider rar und teuer.
    Das zum Hintergrund.

    Hallo Ihr.
    WoV (V4.0.26 Build 0312) stürzt ab beim Aktiv setzten der Steuerung. Der "JIT-Debugger" wird als Fehler angegeben.
    Bei meinem älteren Notebook (auch Win10 Home, 64 bit, wie das erste) funktioniert alles, obwohl die selbe WoV mit den selben Optionspaketen und DTM's und das selbe Win10 aufgespielt ist.
    Hat jemand eine Lösung?
    Gruß Roand