KRC1 DeviceNet analog Beckhoff

    Hallo und guten Abend,
    ich bin neu hier und ein Kuka unerfahrener Anfänger.
    Befinde mich gerade auf Montage und habe folgendes Problem:
    Ich muß 4 analoge Eingänge und 4 analoge Ausgänge an eine KRC1/150 anknüpfen. Softwareversion ist die 4.1.7SP08. Die Hardware die ich mit habe besteht aus: Beckhoff BK5220 (Koppler), KL3464 (4 analoge Eingänge 2-leiter), KL4404 (4 analoge Ausgänge 2-Leiter), KL9010 (Endklemme). Koppler und Powerkontakte sind Spannungsversorgt. Verbindungskabel hat an beiden Enden 121 Ohm Widerstände (einer hat 122,4 Ohm; Toleranz i.O.). Das DeviceNet Kabel habe ich über die X11.1 (24V) und X11.15 (0V) vom Roboter versorgt.
    In der Devnet.ini steht:
    [krc]
    debug=0
    bautrate=500


    [1]
    macid=5
    Den Koppler habe ich auch so eingestellt (Pin 1,3,8 on Rest off).
    In der iosys.ini habe ich das Semikolon entfernt um den Treiber zu aktivieren.
    In der iosys habe ich in die Devnet folgendes geschrieben:
    [DEVNET]
    ANIN1=0,16,1
    ANOUT1=0,16,1
    ANIN2=2,16,1
    ANOUT2=2,16,1
    ANIN3=4,16,1
    ANOUT3=4,16,1
    ANIN4=6,16,1
    ANOUT4=6,16,1


    Da bin ich mir aber unsicher, Weil ich nicht weiß wofür die 3 Positionen stehen.
    An dem Koppler leuchtet die RUN LED konstant grün. Status o.k. (laut Beckhoff)
    Weiterhin leuchtet die I/O RUN LED konstant. Busklemmen arbeiten einwandfrei ( auch laut Beckhoff).
    Aber die LED BUS OFF ist aus, das heißt es findt kein Datenaustausch statt.
    Habe auch am Teachpanel den analogen Ausgang1 auf 10V gesetzt und an der Klemme im externen Schaltschrank nachgemmessen. Da kommt nichts an.
    Meine nun endlich folgende Frage, was habe ich falsch gemacht, das der Datenaustausch nicht funktioniert?
    Bin für jede Idee dankbar. Nächste Woche muß das Ding mit 2 FU´s und nem Widerstandswegmesssytem laufen und ich möchte auch schnell wieder nach Deutschland. :zwink:

    Was nicht passt, wird passend gehämmert.

    • Schritt für Schritt zum Roboterprofi!
    Zitat von MaikJ.


    macid=5
    Den Koppler habe ich auch so eingestellt (Pin 1,3,8 on Rest off).


    Hallo MaikJ,


    Die MACID stellt die Adresse im Netzwerk dar. Jeder Teilnehmer muß eine andere besitzen. Also, wenn der Roboter bereits die Adresse 5 hat, mußt Du am Buskoppler von Beckhoff eine andere einstellen. Sonst funktioniert gar nichts.


    Zitat von MaikJ.


    ich möchte auch schnell wieder nach Deutschland


    Na, dann viel Erfolg!


    Tilman

    Einmal editiert, zuletzt von Tilman ()

    Morgen Tilman,
    werde ich gleich mal ausprobieren.
    Aber, ich sehe gerade in den Softwarekonfigurationsunterlagen von Kuka unter Punkt 3.2:
    "Die MAC-ID der KR C1-Steuerung ist als Vorgabe "0" und brauch nicht in die Datei DEVNET.INI eingetragen werden."
    Zitat Ende.
    Ich glaube es liegt an den 3 Positionen die ich definieren soll. Daraus werde ich aber nicht schlau.
    Wenn mir die einer aus der IOSYS erklären könnte.
    Danke für alle Anregungen. :merci:

    Was nicht passt, wird passend gehämmert.

    Zitat von Tilman


    Also, wenn der Roboter bereits die Adresse 5 hat, mußt Du am Buskoppler von Beckhoff eine andere einstellen.


    Hallo MaikJ,


    Da habe ich eindeutig zu schnell geantwortet. Seit einer Stunde sitze ich jetzt selbst über der Dokumentation... und bekomme immer mehr Zweifel an meiner Antwort. Sorry!


    Tilman

    <<[krc]
    debug=0
    bautrate=500


    [1]
    macid=5>>


    Bei meinem jetzigen Wissensstand: das ist richtig. [1]...[63] nennt sich Scanliste. Hier werden die Adressen der Teilnehmer aufgeführt, macid=5 ist der Buskoppler von Beckhoff.


    <<Die MAC-ID der KR C1-Steuerung ist als Vorgabe "0" und brauch nicht in die Datei DEVNET.INI eingetragen werden.>>


    Bei meinem jetzigen Wissensstand: richtig! MFC-DeviceNet ist immer Master mit MACID 0. Die benutzt Du doch, die MFC Karte, oder?


    <<(Pin 1,3,8 on Rest off)>>
    7 off, 8 on, das bedeutet 250 kBit/s. Im "devnet.ini" jedoch 500. Das scheint mir komisch zu sein (... ich bin vorsichtig geworden, bei meinen Antworten :->)
    Beckhoff 500kBits/s ist 7 on, 8 off


    [EDIT] Ja, schon wieder daneben... 7on 8off ist für den BK5120, 7off 8on für den BK5220, war also auch richtig!


    <<
    ANIN1=0,16,1
    ANOUT1=0,16,1
    ...
    >>
    Seltsam finde ich, daß die Devicenet- Adresse nicht angebeben wird. Also so was wie
    ANIN1=5,0,16,1. Das steht bei mir so in der Doku für eine KR C2 Ed 2005. Aber vielleicht hat sich da was geändert.


    [EDIT] Habe noch fogendes gefunden: <<Beim "neuen" Treiber (dn2drv.o) muss die MACID des Devices angegeben werden>>
    Liegt also am verwendeten Treiber.


    Ouff... Erst einmal frühstücken,
    Tilman

    Einmal editiert, zuletzt von Tilman ()

    Nachdem ich nun nach und nach festgestellt habe, daß Deine Konfiguration soweit richtig scheint, kann ich mich heute kaum noch lächerlicher machen :uglyhammer_2:.


    In der Anleitung von Beckhoff steht:


    LED "BUS OFF"


    - Die grüne LED leuchtet konstant: Buskoppler ist dem Master zugeordnet, Datenaustausch findet statt.
    - Die rote LED blinkt: I/O Verbindung im Timeout
    - Die rote LED leuchtet konstant: BUS OFF: CAN Fehler, Teilnehmer mit gleicher Knotenadresse.


    Was macht denn die grüne LED "Connect"?


    Hast Du mal nachgemessen, ob die 24V aus dem Devicenet-Kabel auch bei dem Koppler ankommen? Die scheinen nämlich den Transceiver des Buskopplers zu versorgen.


    Tilman

    Einmal editiert, zuletzt von Tilman ()

    Hi,
    ich würde zum Test mal die E/A's als digitale konfigurieren:
    Also die ANIN / ANOUT rauswerfen und 'normale' Einträge wie


    OUTW0 = 0 usw. hernehmen (Achtung bei dn2drv: OUTW0 = 5,0)


    Man glaubt's vielleicht nicht, aber analoge Baugruppen können so auch angesprochen werden.
    Dann in der $config.dat sowas wie:
    Signal testana $OUT[1] to $OUT[16]


    und auf testana einen Wert ausgeben.


    Wenn das funktioniert die Sache mit den ANIN weiterverfolgen. Oder gleich mit den digitalen arbeiten und die Umrechnung selber machen.

    So bin vom Kunden zurück in meiner Pension.
    Habe beim Kunden keinen Internetzugang, deshalb hab ich jetzt erst alles lesen können.
    Also Bauteile sind schonmal alle in Ordnung. Habe eine zweite Baugleiche Anlage fast fertig aufgebaut und da ist es das selbe Problem.
    Die BUS OFF LED und die CONNECT LED sind wie im ersten Text geschrieben aus. Es findet also kein Datenaustausch statt.
    Habe auch die DEVNET mehrmals umgeschrieben.
    z. B. ANIN1=0,12,1 weil die Beckhoff Klemme eine 12 Bit Auflösung hat.
    oder ANIN1=0,12,0 oder ANIN1=0,16,0 weil ich das mit der 3. Position nicht verstehe.
    Zu Hermann:
    Bestimmt ein sehr guter Ansatz, jedoch bin ich dafür viel zu unerfahren. Stehe praktisch das 2. Mal vor einem Kuka. Bin sonst eher der Schlosser (ich-hau-mal-mit-dem-Hammer-davor-)Typ. Das scheint mir hier aber nicht richtig zu sein.
    Danke für alle Gedankenansätze. Bin morgen früh wieder an der Anlage und dann werde ich ein paar Sachen ausprobieren.
    Viele Grüße aus CZ bei -15°C

    Was nicht passt, wird passend gehämmert.

    Liegen an. Hab sie einmal vom X11 des Roboters benutzt und auch mal die 24V vom externen Schaltschrank aufgelegt. Beidesmal 24V, aber dasselbe Fehlerbild.

    Was nicht passt, wird passend gehämmert.

    Ich habe den Fehler!


    Zitat von MaikJ.


    Viele Grüße aus CZ bei -15°C


    Da würde ich auch nicht funktionieren!


    Ich überlege morgen mal weiter... Es gibt noch Tests, die Du am Roboter machen kannst. Mit telnet 192.0.1.1. Habe ich unter anderem hier gelesen.


    http://www.roboterforum.de/rob…am_devicenet-t3793.0.html


    Das habe ich allerdings noch nicht selber gemacht, da will ich Dir keinen Unsinn erzählen.. Sollte mal jemand mit Erfahrung ein paar Tips geben.


    Ich habe nach den 24V gefragt, da ja weder die grüne (CONNECT) noch die rote Led (BUS OFF) leuchten. Das sieht wie ein Fehler auf unterster Kommunikation-Ebene aus.


    Welchen Driver benutzt Du eigentlich, den dn2drv (steht oben im iosys.ini).


    Hier ist die Erklärung, die wohl für den dn2drv gilt.


    ANIN/ANOUT INDEX = DeviceNet Adresse, Byte-offset, Exponent 2, Typ, Cal-Faktor



    DeviceNet Adresse Die DeviceNet Adresse (1...63) wird auf jeder DeviceNet Baugruppe eingestellt.


    Byteoffset Der Byteoffset bezeichnet die Lage der E/As im Speicher des DeviceNet Teilnehmers und wird einmal für alle Eingänge und einmal für alle Ausgänge durchgezählt (0...127).


    Exponent 2 Dieser Parameter gibt die Anzahl der Bits an, die zur Darstellung des Zahlenwertes eines Analogwerts verwendet
    werden (8...16).


    Typ Mit diesem Parameter wird angegeben, wie die Bits im Parameter Exponent 2 ausgerichtet sind und ob das führende Bit als Vorzeichen des Zahlenwerts gedeutet werden soll.
    Den möglichen Parameterwerten sind folgende Bedeutungen zugeordnet:
    0 : rechtsbündig ohne Vorzeichen
    1 : rechtsbündig mit Vorzeichen
    2 : linksbündig ohne Vorzeichen
    3 : linksbündig mit Vorzeichen


    Cal-Faktor Der Cal-Faktor gibt den Wert an, bei dem ein Analog-Ausgang seinen Nennwert ausgibt (z. B. 10V). Bei einem Analog-Eingang entspricht der Wert des Cal-Faktors dem Nenn-Eingangswert.


    Bei dem älteren dndrv.o wird wohl keine Devicenet-Adresse angegeben.



    Ich hoffe, das hilft Dir weiter.
    Tilman

    Hier mal ein Auszug aus einer funktionierenden iosys.ini,
    ebenfalls mit Beckhoff-Klemme:

    Code
    [DRIVERS]
DEVNET=2,dnInit,dn2drv.o    ;DeviceNet
....
[DEVNET] ;DeviceNet


;ANALOGMODUL
ANIN1=10,1,12,3,CAL4095  ;Analogeingang 1
;+1Byte IN dazuadieren da Beckhoff
....


    Ausserdem gibt es da vermutlich Fehlermeldungen beim E/A-Rekonfigurieren?
    Und es gibt noch diverse Log-Dateien, die man durchsehen kann:
    iosys.log
    devnet.log

    Einmal editiert, zuletzt von Hermann ()

    Hallo Maik,


    Noch ein kleiner Hinweis für den heutigen Tag. Schreibe ich Dir, da Du ja noch nicht so viel mit Kukas gearbeitet hast.


    Das Echtzeitsystem bekommt nicht unbedingt mit, wenn Du (besonders mit einem externen Editor) die Konfigurationsdateien änderst. Daher zwei Tips von LindePaul: Cold Boot tut Guut, bzw. Aufrufen der IO-Rekonfiguration über Menü.


    Viel Erfolg heute,
    Tilman

    So, heute war ein erfolgreicher (Sonn-)Tag (+6-+8°C).
    Habe erstmal die Spannungsversorgung aufgeteilt. Wie in einem anderen Beitrag beschrieben. 1. Kabel, 2. Koppler, 3. Powerkontakte. Hatte die alle 3 gebrückt. Da war ich wohl zu ungeduldig und dumm.
    Dann die DEVNET wieder umgeschrieben. Die Auflösung der Beckhoffklemme ist 12 Bit, die Breite im Prozessbild ist aber 16 Bit. Also ANIN1=0,16,1 usw.. Dann E/A Rekonfiguriert (das hatte ich im Eifer des Gefechts auch schon mal vergessen). Jetzt leuchtete die CONNECT LED konstant
    Und dann herausgefunden, dass die Beckhoff Beschreibung falsch ist. Erstens ist die für die Koppler BK5200, BK5210 und LC5200. Der BK5220 ist da irgendwie nicht aufgeführt. Dann steht auf Seite 25: LED BUS OFF 3 Zeilen zu hoch. Die ist nämlich rot (und zwar nur rot). Die Erklärung dahinter gilt für die Grüne CONNECT LED und die leuchtete bei mir ja jetzt dauerhaft.
    Hab dann die 4 analogen Ausgänge gesetzt (2V,4V,6V,8V usw.) und nachgemessen. Alles Top.
    Hab aus Spaß mal die DEVNET mit 12 Bit geschrieben und 10V am Ausgang gesetzt, dann kommen da 1,2xxV raus. Das wäre ja auch noch ein Fehlerbild gewesen.
    Um zum Ende zu kommen.
    Ein riesiges Dankeschön an alle die mir so schnell geholfen und den Thread gelesen haben. :merci:
    Morgen noch schnell die 4 FU´s parametrieren und dann Dienstag schnell nach Hause.
    Nochmals :danke:

    Was nicht passt, wird passend gehämmert.

    Zitat

    So, heute war ein erfolgreicher (Sonn-)Tag (+6-+8°C).

    Siehste, war meine Diagnose gar nicht so falsch :) Es lag am Wetter :genau:!


    Zitat

    Und dann herausgefunden, dass die Beckhoff Beschreibung falsch ist.

    Damit hatte ich auch Schwierigkeiten.... deswegen mein Irrtum mit den DIP Schaltern, und deshalb auch meine Frage zum Connect LED.


    Zitat

    Ein riesiges Dankeschön an alle die mir so schnell geholfen und den Thread gelesen haben.

    Danke auch für Deine Rückmeldung. Ich habe dieses Wochenende jedenfalls unheimlich viel gelernt. Und Danke auch an Hermann, der uns "Anfänger" unterstützt hat.


    Gute Heimreise,
    Tilman

    Einmal editiert, zuletzt von Tilman ()

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden