Beiträge von Hermann

Hallo,
glaube nicht, dass da eine neue Instanz erzeugt wird.

Ich würde da den bequemen Weg gehen und das Modul kopieren, und
aus dem SPS.SUB die Kopie aufrufen. Dann hat man halt zwei Protokolle.
Sehe da keine halbwegs vernünftige Möglichkeit das anderweitig in den Griff zu bekommen.

Wird das Modul aus dem SPS.SUB aufgerufen, dann kann es unterbrochen
werden (u.U. mehrmals) so dass es dann aus dem Hauptprogramm während
dieser Zeit nochmal aufgerufen wird (u.U. mehrmals).

Man könnte höchstens was mit einer Art Semaphoren versuchen, also im SPS.SUB
eine Variable setzen, bevor das Modul aufgerufen wird, danach diese wieder
zurücksetzen.
Im Hauptprogramm vor dem Aufruf des Moduls warten, bis die Variable zurückgesetzt ist,
dann eine andere Variable setzen, Modul aufrufen, Variable wieder zurücksetzen.
Jetzt kommt die Ergänzung im SPS.SUB: Das Modul nicht aufrufen, wenn diese vom
Hauptprogramm gesetzte Variable gesetzt ist.

Hört sich schon nicht so übersichtlich an, ist dann im SPS.SUB nicht so schön zu
realisieren da man nicht einfach warten sollte, bis das Modul frei ist.

Gruss Hermann

Hallo,
nur mal so eine Idee:
Je nach Prozessortyp wird im Gerätemanager unter 'Computer' ein unterschiedlicher
Typ angezeigt: ACPI-PC, Standard-PC usw. vielleicht da mal rumspielen und auf
Standard-PC setzen. Da hatte ich auch schon diverse Erfolge, könnte aber sein,
dass da dann andere Programme nicht mehr laufen.

Also am Besten vorher ein Image erstellen!

Hermann

Hallo,
ja glaubt es ihm doch endlich, das mit ServicePack 1/2 ist Geschichte.
Zitat von der Homepage:

Zitat

KUKA.OfficeLite KR C V4.1.7
30-Tage-Demo-Version für Windows 2000 SP04 und Windows XP SP02. (Hinweis: Windows Vista oder 64 Bit Betriebssysteme werden nicht unterstützt!)

Aber da steht Demo-Version, und nix von Shareware oder Freeware!

Hermann

Hallo,
der Programmauszug ist jetzt mal nicht allzu erhellend, da fehlen die Interruptdeklaration,
der Aufruf des Unterprogramms, die Bewegungsbefehle ...

Aber: Interrupts können ja zu unterschiedlichen Zeiten auftauchen, also sind die Bedingungen
auch unterschiedlich, daher kann es schon sein, dass die Geschichte eine Zeit lang gut geht.

Entscheidend ist (wie schon gesagt wurde), dass der Vorlaufzeiger zum Zeitpunkt des Auftretens
des Interrupts nicht in der Ebene steht, in der der Interrupt deklariert wurde.
Daher ist meiner Meinung nach das $Advance=0 im Beispiel von Soma nicht ganz richtig. Das Beispiel
funktioniert trotzdem, da VOR dem Rücksprung aus DoSomething() ein Vorlaufstop ausgelöst wird,
dadurch wird sichergestellt, dass der Interrupt nur solange auftreten kann, wie der Vorlaufzeiger
noch im DoSomething steht.

Würde da eher zu sowas raten (oder falls vertretbar $advance in DoSomething gleich auf 0 setzen):

DEF MAIN()
    INTERRUPT DECL 10 WHEN XYZ DO Abbruch()
    DoSomething()
END
------------------------------------------------------------
DEF Abbruch()
    INTERRUPT OFF 10
    BRAKE
    $ADVANCE=0
    RESUME
END
-----------------------------------------
DEF DoSomething()
    INTERRUPT ON 10;
    $ADVANCE=1
    ;Anweisung
    ;Anweisung...
    ;[VorlaufStopRoutine]!!!!
    wait sec 0.1
INTERRUPT OFF 10
END

Hermann

Hi,
das Problem scheint nicht unbekannt zu sein:
Schau doch mal hier:
http://www.roboterforum.de/rob…tartet_nicht-t4219.0.html

Hermann

Hallo,
die Relativbewegungen sind beim Anfahren eines Punktes eh nicht
zu gebrauchen.
Das ginge nur beim Wegfahren vom Punkt, das 'Zum Punkt Hinfahren'
muss auf jeden Fall berechnet werden.
LIN_Rel bezieht sich immer auf die aktuelle Position, und nie auf die,
die noch kommen soll.

Hermann

Hi,
die Benutzerumschaltung hängt soweit ich weiss nicht von der Betriebssystemversion ab,
sondern davon ob SafeRobot installiert ist oder nicht.

Hermann

Naja,
hab's nachgesehen, Bytetausch direkt geht nu wirklich nicht.
Bei zeitunkritischen Werten und wenn's nicht für irgend eine Option, in der
unbedingt AI gefordert sind könnte ich mir folgende Lösung vorstellen:

Zwei GI's mit jeweils 8 Bit (bzw. einmal 8 und einmal 4 Bit bei 12Bit-Wandler) definieren.
Und den Wert ausrechnen:
R[1]=(GI[1]*256+GI[2]);
oder so ähnlich.

Hermann
PS: Zu dem Thema 'einzige wirkliche Schwäche' sag ich nichts.

Hallo,
habe jetzt keine praktische Erfahrung mit Fanuc und ET200.
Ich würde mal versuchen die Baugruppe als GI[] zu konfigurieren. Da sollte der Bytetausch problemlos
machbar sein.
Die eingelesenen Werte dann halt selber umrechnen.
Kommt auch ein wenig darauf an, was man mit den Werten anstellen möchte.

Hermann

Hallo,
mit der Swap-Funktion werden alle words getauscht, evtl ist es sinnvoller
die Bytes in der ISYS.INI einzeln zu deklarieren und dann nur ein Wort zu tauschen.
In etwa so:

INB0=2,0,x1
INB1=2,1,x1
INB2=2,3,x1 ; getauscht
INB3=2,2,x1 ; getauscht
INB4=2,4,x1

Hermann

Sodele,
hab's jetzt in einer stillen Stunde selber rausgefunden:

Die Steuerungen haben alle dieses schöne bunte Panel, in dem man den
Bildschirm in max. 3 Fenster aufteilen kann. Das benutze ich auch sehr
intensiv.
Das Problem ist nur, dass man die Payload-Einstellungen nur im 'Hauptfenster',
also dem linken ändern kann (Wenn man ein Programm starten möchte,
während eines der anderen Fenster aktiv ist bekommt man einen Hinweis)
Oder man schaltet ebend auf nur ein Fenster um.

Hermann

Ja klar,
da kommt keine Fehlermeldung und nix, aber die Daten werden nicht übernommen!
Genau so ist es, wenn ich die Daten von Hand eintrage.

Ich trage den Wert ein, nach Enter steht da wieder der alte Wert.

Hermann

Hallo,

Zitat

haben vielleicht nicht alle deine roboter die option payload ident geladen?

Das kann schon sein,
habe ich noch nicht überprüft, aber an einem der Roboter habe ich die
Lastdatenermittlung erfolgreich durchgeführt, zumindest wurden Lastdaten
angezeigt, aber sie wurden ebenfalls nicht in die Tabelle mit den Lastdaten
übernommen. Da stehen nach wie vor die Standard-Daten drin:
165 kg und ansonsten lauter Nullen.

Hermann

Hallo,
nein, der Befehl Lockreg wird nicht verwendet.

Ich meine nicht die Änderunge der aktuellen Werkzeuglast mittels des Befehls
Payload im Programm, sondern ich kann schon die einzelnen
Lastdaten in der Konfiguration unter 'System' - 'Motion'

Hermann

Hallo,
hat hier jemand eine Ahnung, warum sich die Payload-Parameter nicht einstellen lassen?

Habe hier 8 Roboter (R2000-IB) bei einigen lassen sich die Daten eintragen, bei anderen
werden die Änderungen sofort wieder auf den alten Wert gesetzt ?

Danke schon mal für eventuelle Hinweise.

Hermann

Hallo,
ja der Hilfspunkt liegt genau auf dem Kreisbogen, anders ist das doch gar nicht machbar.
Erst durch die 3 Punkte (Anfangs-, Hilfs- und Endpunkt) ist der Kreisbogen genau definiert.

Hermann

Selbst wenn man sie weitergeben darf:
bringt nichts, denn auch für die Demo musste man sich einen
Freischaltcode besorgen, der dann nur auf einem PC läuft.
Wenn KUKA diese Version nicht mehr unterstützt, dann war es
das wohl.

Hermann

Hallo,
das sieht nach dem alten S- und T-Problem aus.
Der Roboter verfährt bei PTP-Bewegung die Achse nicht nur auf den Achswert
(im Beispiel -120), sondern wertet auch noch S und T des zugehörigen Punktes aus.

Dementsprechend müsstest Du auch noch S und T (eigentlich nur T soweit ich das
noch im Hirn habe) anpassen, so dass die Achse 6 in den negativen Bereich fährt.

Such' mal hier im Forum nach 'Status' und 'Turn', irgendwo war da mal eine genauere
Erklärung, oder schau in der Roboterdoku nach, da war das eingermassen erklärt.

Hermann

Also ich hab nichts anderes,
hätte ich es, dann hätte ich es Dir schon längst zukommen lassen.

Hermann

Lang, lang ist's her,
kann mich wirklich nicht mehr zu 100% erinnern,

S2 ist's auf keinen Fall,
S1 wird's wohl auch nicht sein.
Der obere Hebel ist ein Ausdrückhebel für das 'Kuchenblech', wenn man die Halteschraube
daneben gelöst hat.

Wenn kein weiterer Schalter zu sehen ist, dann muss er wohl doch auf der Platine
direkt vorhanden sein.

Hermann