Beiträge von Berrad

Mit der oben beschriebenen Code

SIGNAL ProgSpeed $anout[1]

ANOUT ON ProgSpeed = $VEL_act * rFactor DELAY= rDelay

lässt sich die aktuelle Geschwindigkeit auf eine Analogausgangsklemme (z.B. Beckhoff Ethercat) legen.

Ohne genauere Betrachtung könnte evtl. mit diesem Produkt direkt der Extruder betrieben werden:

BLDC & Schrittmotoren ansteuern | 4 Methoden | NANOTEC

Produktübersicht Nanotec: ✓Positoniersteuerung via Takt & Richtung ✓Digital- & Analogeingänge (I/O) ✓Feldbus ✓Stand-Alone-Betrieb o. verteilte Intelligenz

de.nanotec.com

Am Besten wäre natürlich gleich die direkte Feldbusversion...

Oder wenn dies als Anout-Modul konfiguriert werden könnte ?????

EtherCAT-Klemme, 1-Kanal-Motion-Interface, Schrittmotor, 48 V DC, 5 A

Die EtherCAT-Klemme EL7041-0052 ist für den direkten Anschluss von Schrittmotoren im mittleren Leistungsbereich bis 5 A und für einen Spannungsbereich ...

www.beckhoff.com

Wie gesagt, die KRC kann das immer nur als Analogsignal ausgeben: 12Bit/14Bit/16Bit mit/ohne Vorzeichen + Cal-Faktor

Ich geh mal davon aus das der Extruder Material in Abhängigkeit von Düsengeschwindigkeit liefern soll. Mit dem FSD können zwei Ausgänge wechselseitig konfigurierbaren weg-oder Zeitraster geschaltet. Damit könnte fast direkt ein Schrittmotor angesteuert werden. Alternativ in einem Splineblock die Punkte sehr eng setzen und im trigger-up die Ausgänge setzen. Am einfachsten $vel_act auf einen $anout mappen und damit den Stepper über zusatzhardware steuern.

Das Optionspaket FastSendDriver wird dir weiterhelfen.

Der Punktabstand ist viel zu gering, um auf Geschwindigkeit zu kommen. Abhilfe: $acc.ori1,ori2,cp auf Maximalwerte setzen oder besser einen Splineblock benutzen.

Hi,

das gibt es schon alles fertiges Techpaket und nennt sich TouchSense. Da kann verschoben und verdreht werden wie es gefällt.

Wenn es nur in einer Richtung sein soll, dann mal nach Suchfahrt (Interrupt, Resume) und Baseverschiebung (Doppelpunktoperator)

im Forum suchen.

Grüße

; dat

signal ao1 $anout[1]

;src

ANOUT ON ao1 = 1.0 * $VEL_ACT + 0.0 DELAY = 0

lin p1

lin p2 c_dis

..

Lin p100

anout off ao1

der Analogausgang 1 wird zyklisch im Hintergrund mit dem Wert von $vel_act * Skalierungsfaktor + Offset beschrieben, bis die Analogausgabe abgeschalten wird.

Vielleicht wäre die Technologie GlueTech schon das passende für deine Applikation

Grüße

Das Programm wird mit folgenden parametern aufgerufen:

GLOBAL DEF MsgQuit(sText[]:IN, sModul[]:IN, nNumPar:IN, sTextPar[]:IN, nMsgNr:IN,MsgOpt:IN)
DECL CHAR sText[], sModul[]; Meldungstext, Optional Verursacher
DECL CHAR sTextPar[] ; Optional Text-Parameter %1 ODER :
DECL INT nNumPar ; Optional Integer-Prameter %1
DECL INT nMsgNr ; Optional Meldungsnummer
DECL KrlMsgOpt_T MsgOpt ; Optional Log, Vorlaufstop, Meldung loeschen wenn Programm abgewählt wird

Bsp.:

DEF Haupt()
DECL KrlMsgOpt_T MsgOptLog

MsgOptLog={VL_Stop FALSE, Clear_P_Reset TRUE, Log_To_DB TRUE}
MsgQuit("Obacht ! Roboter nedd in Home","Cell", , , ,MsgOptLog)

So ganz klar ist mir Deine Applikation noch nicht. Aber mal so viel:
Am Conveyor ist ein Synchronisierungschalter angebracht. Wird dieser ausgelöst, zb. Vorderkante eines Pakets, wird $sen_prea_c[] auf 0 gesetzt. Von nun an wird die Base verschoben. In etwa so:
$base_c=base_data[11]:{x $sen_prea_c[1],y 0,z 0,a 0,b 0,c 0}. Deine bez. der base11 geteachten Punkte werden also mitverschoben. Der Roboter holt erst das Teil ab, nach dem das Band eine bestimmte Wegstrecke überschritten hat (Wait for $sen_prea_c[]>Bandfahrweg ; mm),
und stapelt es auf einer Palette.
Der Roboter fährt zum Band zurück und wartet auf erneutes Synchronisierung (nächstes Teil
unterbricht die Lichtschranke).

Soll der Roboter nur tätig werden, wenn eine bestimmte Anzahl von Teilen zum gleichzeitigen
greifen bereit liegen sollen, gibt es verschiedene Ansätze:

- Die Lichtschranke an einen elektronischen externen Zähler anschliessen, dessen Ausgang mit
$meas_pulse[] verbunden ist.

- Am Conveyorband werden in den gewünschten Abständen Markierungen angebracht.

- Nur KRL
Ich habe es noch nie getestet, aber ich glaube, das die Synchronsierung nur dann erfolgt, wenn
dies auch wirklich gewünscht wird: Inlineform "Warte auf Synchronisierung" (1. Teil kommt)

- anschliessend "wait for $sen_prea_c[]>=2000;mm". Roboter fährt zum Band, greift alle Teile
gleichzeitig und fährt wieder zurück zu Warteposition. Gestapelt wird erst mal nix, sondern
wieder "Warte auf Synchronisierung". Ist diese erneute Synchronisierung erfolgt, kann gestapelt
werden. Das Band rollt dabei weiter. Der Roboter fährt zurück und wartet jetzt nur noch bis
$sen_prea_c[]>=2000 -> greifen-> "Warte auf Synchronisierung" -> stapeln -> "wait for
$sen_prea_c[]>=2000" usw.
Fehler - z.B. der Roboter ist zu langsam - könnten wie folgt abgefangen werden:

DEF bsp()
IF teil_im_greifer THEN
stapeln() ; (Base=<10)
ENDIF
warte auf synchronisierung ; $sen_prea_c[]=0, (Base=<10)
LOOP
wait for $sen_prea_c[]>=2000 ; genügend Teile im Greifbereich, (Base=<10)
IF $sen_prea_c[]>=3999 Then ; letztes stapeln dauerte zu lang - Verzögerung nicht abfangbar
; Fehlerstategie: Teile einfach weiter laufen lassen, evtl. Fehlermeldung an sps
warte auf synchronisierung ; $sen_prea_c[]=0, (Base=<10)
ELSE ; normaler Zyklus, der Roboter war für die Bandgeschwindigkeit schnell genug
greifen() ; Warteposition->Teil auf Band greifen->Warteposition ; (Base>=11)
warte auf synchronisierung ; $sen_prea_c[]=0, (Base=<10)
stapeln() ; (Base=<10)
ENDIF
ENDLOOP
END

Das ist natürlich nur eine grobe Struktur ! Das ganze müsste noch auf Basis der ConveyorTech-
Programmstruktur umgesetzt werden.

Würde mich interessieren, wie Du es letztendlich gemacht hast.

Grüße

Berrad

Hallo,
so weit ich weiß, werden von kuka max. 3 Conveyor unterstützt: (Conv)Base11,12,13.
Abhängig von der Conveyortechversion kann auch zwischen diesen Basen hin- und hergeschalten
werden. Z.B.: von einem Conveyor entladen und den anderen beladen.
Sichworte dazu sind einsynchronisieren im Hintergrund und fliegendes Aufsynchronisieren.

Grüße

Berrad

Etwas einfacher ist vielleicht dieser Ansatz, habe ihn aber nicht getestet:

frame p1,p2
real dx,dy,dz,winkel

; vektor 1 aus p1 und p2
p1=$base:$pos_act:inv_pos($tool)
p2=p1:{x 0,y 0,z 1000,a 0,b 0,c 0}
dx=p2.x-p1.x
dy=p2.y-p1.y
dz=p2.z-p1.z

;vektor 2: x=y=0,z=1000 (willkürlich)
winkel=acos( (dz*1000) / (sqrt((dx*dx)+(dy*dy)+(dz*dz))*1000) )

Gruß

Berrad

Die Messgenauigkeit hängt von Größe und Form des zu vermessenden Objekts ab.
Ist es ein Skalpel oder ein Fleischmesser ? Aber auch die Genauigkeit des Semsors
spielt eine entscheidente Rolle.
Mit einem Kamerasystem oder vielleicht mit TouchSemse könnte eine automatisch Relativ-Korrektur durchgeführt werden.

Dieser Fehler tritt dann auf, wenn in einer Interrupt-Routine ein Bewegungsbefehl mit einem Inline-Formular ausgeführt werden soll.
In diesem Formular sind diverse Bas-Aufrufe. Bei der Initialisierung der Lastdatendaten wird die Fehlermeldung verursacht.
Kurz: In einer Interruptroutine Bewegungen keine Bewegungsformulare benutzen !

Berrad

Ich befürchte das für einen kr150 andere ksd's als für einen kr30 benötigt werden...

gruss

berrad

Man muß die Variable

$axis_home[1]=xhome1

setzen.

Berrad

Try this:

decl fold d_UserMessage[2]
d_UserMessage[1]="sSMUserMessage/[/] = "/"%fUserMessage /""
d_UserMessage[2]="Show_Message(0,sSMUserMessage/[/],TRUE)"

SW 5.5 requires xp embedded sp02. you need to install windows and the kss.
krl-programs and the configuration are compatible between the versions.

Berrad

Na dann vielleicht ein Tool- und/oder Lastdatenwechsel...

Es kann bei PTP-LIN bzw LIN-PTP Überschleifbewegung schon unter gewissen umständen
zu mehr oder weniger stark ausgeprägten "Bahnabweichungen" kommen.
In diesen Fällen ist etwas Einverfühlungsvermögen für den Übergang von Achsplanung auf
Bahnplanung erforderlich. Hauptaugenmerk gilt hier vor allem den Handachsen.
Wie stehen die Achsen am Ende der PTP-Bewegung, wie stehen sie am Anfang der LIN-Bewegung ?
In Deinem Fall denke ich, wird wohl Überschleifbewegung nahe der Singularität (A5=0)
durchgeführt werden.
Die Fehlermeldung "Sollgeschwindigkeit" - vermutlich A4 - deutet darauf hin.

man muss $pro_state1 auswerten. $pro_state bezieht sich immer auf den aktiven interpreter, in deinem fall dem submit. mit $pro_state0 kann der zustand des submit im roboterprogramm ausgelesen werden

berrad

StrLen wäre mit einer Dummy-Sread/Swrite-Anweisung ersetzbar:

int x
decl state_t st
char sDmy[470]

x=0
swrite(sDmy[],st,x,"%s",sEmpfang[])

in x bzw. st.length steht die anzahl der gelesenen Zeichen = StrLen(sEmpfang[])