CAN-Bus mit Beckhoff EL6751 (CAN2.0B)

[Froehlich56]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,
vorab erst einmal ich bin SPS-Umsteiger und habe noch nicht viel Erfahrung mit der TC3-Umgebung.
Ich habe Probleme dabei mittels der EL6751 als Master eine aktive Verbindung zu einem Slave aufzubauen. Das Beispiel-Projekt von wollvieh (vielen Dank an dieser Stelle) habe ich mir bereits zur Hilfe genommen und mich an der Anleitung entlanggehangelt. Daher denke ich die Schnittstellen und POD´s richtig miteinander verbunden zuhaben.

Deshalb habe ich mir den Aufbau der Nachrichten angeguckt und festgestellt, dass die COB ID in dem Beispiel-Projekt für einen 11 Bit Identifier ausgelegt ist.
Zur Kommunikation mit dem Slave bräuchte ich allerdings einen 29 Bit Identifier. Allerdings verstehe ich nicht wie ich diesen richtig zusammen baue, dass dieser auch vom CANMaster genutzt werden kann. Wie der 29-Bit-identifiere aussieht habe ich der Doku entnommen.

11-Bit	29-Bit
Bit 0-3: Länge der Daten (0…8) • Bit 4: RTR • Bit 5-15: 11 Bit-Identifier	• Bit 0-28: 29 Bit Identifier • Bit 30: RTR • Bit 31: ◦ 0: 11 Bit-Identifier, ◦ 1: 29 Bit Identifier

Es ist durchaus Möglich, dass mein Problem wo anders liegt, daher bin ich um jede Hilfe dankbar irgendwie voran zukommen.

Als Referenz hier der Link worauf ich mich beziehe.
CAN-Kommunikation mit Beckhoff EL6751

Fröhliche Grüße

 

[Guga]

..entlanggehangelt. Daher denke ich die Schnittstellen und POD´s richtig miteinander verbunden zuhaben.

Wenn du so denkst dann ist ja gut... Die Screenshots sind nicht wirklich informativ.


Ich frage aber doch nach: Auf einem CANMaster ein CANInterface eingefügt und 28-Bit identifier eingefügt. Wie groß sind die Queues (in der SPS musst du in der Schleife drüberlaufen. Ich wiederum glaube du hast als Wert 10 definiert, in deinem (nicht passenden da auf 11-Bit identifier ausgereichteten Codebeispiel sind es aber 32).
Das EA-Interface für eine Message ist mit der Default-Config wie folgt


Hier ein Beispiel wie es aussehen könnte.

CobID: 0x 83000804 (Wichtig: Bit 31 must be set to 1).
Length: 4
Data : D4 00 01 00 (Byte Swapping zur Auswertung notwendig). Es sind 4 Bytes auszuwerten entsprechend der Length

Du musst im SPS Code also über die Anzahl der neuen Messages (im EA-Interface verfügbar - musst du auswerten) das Array von Messages auswerten bzw. schreiben (je nachdem ob du empfängst oder sendest.

 

[Froehlich56]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du so denkst dann ist ja gut... Die Screenshots sind nicht wirklich informativ.

Welche Information kann ich zur Verfügung stellen um zu zeigen das die Verknüpfungen richtig eingerichtet sind?

Was mich auch etwas durcheinander bringt ist das ich aus meiner Dokumentation über das anzusteuernde Gerät nur eine 32 Bit CAN-ID entnehmen kann. Ist bei der CAN-ID die COB-ID schon enthalten? Also ist die CAN-ID das komplette Frame? 29 Bit Identifier + RTR + SRR + IDE = 32 Bit?

Für eine Start Request der an den Slaves gesendet werden soll, habe ich der Doku die Information so entnommen, dass die CAN-ID als COB-ID interpretiert wird.

CAN-ID: 0x 14 00 00 90
length: 1
data: 80

Muss die Länge der Data immer 8 Byte sein?

 

[Guga]

Dann schreib mal zyklisch.

CobID: 0x 9400_0090. Also deine Nummer und dann setzt du noch das Bit 31 (mit 0 angefangen zu zählen).
Length: 1
Data : 80


CAN erlaubt max 8 Byte zu schicken. Es sind aber auch weniger Daten möglich.

 

[Froehlich56]

Danke schon mal für die Hilfe.

Ich habe jetzt vom Hersteller eine dbc-File bekommen und im CAN-Master als CAN Schicht2 Knoten importiert. Mir wird dann auch dem entsprechen die BOX erstellt. Wenn ich jetzt einen Scan am Master durchführe, sagt er mir das der Slave 1 fehlt.
Sollte dem entsprechend der Slave mit dem importieren schon erreichbar sein?
Heißt im Endeffekt, dass ich ein Hardware-Fehler habe?

 

[Guga]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das kann ich dir nicht sagen. Die Messagebox sagt das ein Slave mit der NodeID 1 fehlt. Vermutlich hast du den MiscPCB als NodeID 1 eingefügt und er kann nicht gefunden werden.

DBC dient dazu das die Konfiguration und Interpretation der Daten zum Gerät vereinfacht werden. Hier ist z.B. für einen 2 -Byte werte der Datentyp und auch die Skalierung ... integriert/lesbar.
Wenn du auf Basis des DBC-Imports arbeitest brauchst du eine Lizenz (Trial oder kostenpflichtig) der TF6550.

 

[Froehlich56]

Im Umkehrschluss bedeutet das ich mittels der DBC-Datei und der damit angelegten Variablen, diese direkt beschreiben ohne mir Gedanken über die COB-ID und das zuweisen der PDO´s etc. machen zu müssen?

Sonst verstehe ich nicht wie ich sonst mit der angelegten Struktur arbeiten soll.



Meine CAN-Bus-Leitung habe ich überprüft und 59Ohm gemessen.

 

[Guga]

Wenn du dbc kennst/kannst dann macht es die Sache einfacher.
Ich bin da nur Laie aber immerhin weiss ich z.B. das es beim Import eine ECU-Checkbox gibt für Rx-Messages. Ic hglaube nicht dass du das entsprechend durchgeführt hast.
Und auch mit 29-Bit identifier beschäftige ich mich nicht so häufig.

Da ich kein ausgewiesener Experte hier bin kann und will ich dir auch nicht die Absolution geben - auch wenn du das gerne hören würdest.

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Stimmt denn die Baudrate?

 

[Froehlich56]

z.B. das es beim Import eine ECU-Checkbox gibt für Rx-Messages. Ich glaube nicht dass du das entsprechend durchgeführt hast.

Also die ECU-Checkbox für die Nachrichten habe ich schon angeklickt allerdings gibt es für die Rx-Nachrichten keine separate Box.

Stimmt denn die Baudrate?

Ja die Baudrate habe ich auf 250kbit gestellt, sowie der Slave es gerne haben möchte.

 

[Froehlich56]

Um das ganze einmal zu Abschluss zu bringen.

Durch das importieren einer DBC-File werden bereits alle Knotenpunkte und COB ID richtig übernommen.


Nach einigen herum Probieren mit dem Support von Beckhoff hat sich heraus gestellt, dass es eine Fehler in der TC3-Version (v3.1.4024.25) gab. Dabei lag der Fehler darin dass ein Gerät über mehrere Knoten angesprochen wurde. Ein ähnliches Fehlverhalten gab es anscheinend auch bei der Modbus Kommunikation.

Das Problem ist in der neusten Version allerdings bereits behoben.

Und nochmal Danke für die Hilfe von allen Beteiligten