CAN-Bus-Reverse-Engineering

Ich kämpfe mit dem CAN-Bus-Reverse-Engineering. Es mag eine dumme Frage sein, aber sie irritiert mich.

Geben Sie hier die Bildbeschreibung ein

Dies sind Verkehre, die durch das Drücken der Tasten A und B entstehen, wodurch am Ende die 1. Achse des Roboters angehoben wird.

Durch Drücken der Taste A ändert sich der Wert „09“ in 181h-Knoten und Taste B ändert den Wert „C8“ in 281h.

Wenn ich mich nicht irre, muss ich RPDOs füttern, um die Hebeaktion zu replizieren, anstatt die Nachrichten "0A 00 09 00 00 00 00 FF" an 181h und "00 00 00 C8 6F BD 00 FF" an 281h zu senden. Im Grunde sende ich die Nachrichten von RPDOs zurück an RPDOs.

Geben Sie hier die Bildbeschreibung ein

Ist bis jetzt irgendetwas falsch? (Es muss sein ... sonst hätte es funktioniert.)

Wie Sie auf dem obigen Screenshot sehen können, habe ich die Nachrichten manuell gesendet, indem ich jede Zeile mit der Leertaste gedrückt habe. Und es scheint so, dass zwischen meinen Tx-Nachrichten viele Rx-Nachrichten auftauchen. Ist das vielleicht der Grund, warum der Roboter keine Reaktion zeigt?

Geben Sie hier die Bildbeschreibung ein

AKTUALISIEREN :

Die TPDO-Nachricht "0A 00 09 00 00 00 00 FF", die durch das Drücken von Taste A entsteht, wird ignoriert, denn immer wenn ich eine TPDO-Nachricht 0A 00 09 00 00 00 00 FF schreibe, wird sie mit ihrem Standardwert 0A 00 0A 00 überschrieben 00 00 00 FF so schnell, dass meine Nachricht überhaupt wie "nicht angekommen" ist.

Die Übertragungsart von TPDO ist derzeit asynchron mit einem Event-Timer von 50 ms. Dies führt dazu, dass mein TPDO alle 50 ms irgendwie mit dem Standardwert 0A 00 0A überschrieben wird. Wie gehe ich mit diesem Problem um? Ich dachte, diese asynchrone Übertragungsart mit 50 ms bedeutet, dass das TPDO alle 50 ms überprüft werden muss und ob es eine Änderung gab -> Übertragung. Aber woher kommt dann dieser 0A 00 0A 00 00 00 00 FF Default-Wert?

Eine andere Frage: Ich dachte die ganze Zeit, dass ich den RPDOs-Wert zurück in RPDO schreiben muss, um die Aktion zu replizieren. Aber es scheint so, dass sich die RPDOs erst ab dem Drücken der Taste A überhaupt nicht ändern. Wie kann ich dann die Aktion des Drückens der Taste A überhaupt replizieren?

UPDATE 2 : Die Bitrate beträgt 125 kbit/s. Ich verwende CANopen, damit ich den Roboter mit meinem Computer steuern kann, anstatt die Fernbedienung zu verwenden. Der Roboter, den ich verwende, ist Brokk 170. Unten finden Sie eine Excel-Datei, in der sich die aufgezeichneten CAN-Nachrichten befinden. Diese CAN-Meldungen entstanden, als ich den Roboter mit der Robotersteuerung einschaltete.

Ich habe die Nachrichten bis zur Nachricht mit der Nummer 107 übertragen, da der Wert 0A 00 0A 00 00 00 00 FF anzeigt, dass der Roboter jetzt hochgefahren ist. Aber irgendwie schaltet die übertragene Sequenz den Roboter nicht ein. Jetzt versuche ich, einen Weg zu finden, um die Nachrichten von der Fernbedienung zu blockieren.

https://drive.google.com/open?id=1Du4J27KykzrTtCquFt29uMa_qhpZP4Ov

Können Sie weitere Informationen zum System bereitstellen (indem Sie die Frage bearbeiten)? ZB Bitrate auf dem CAN-Bus und wie viele Geräte sich auf dem CAN-Bus befinden. Wofür wird der CAN-Bus verwendet? - Soll nur zum/vom Roboter kommuniziert werden oder sind einzelne Gelenke am CAN-Bus? Gibt es eine Art zentrale Steuerung, die auf dem CAN-Bus ist? Nachzuvollziehen, wo die CAN-Bus-Kabel angeschlossen sind, könnte einen Hinweis geben. Wie lautet der Hersteller und die Modellbezeichnung/-nummer des Roboters?
Können Sie eine vollständige CAN-Bus-Protokolldatei über die gesamte Zeit bereitstellen (in der Sie keine Nachrichten senden, sondern den Roboter mit den Tasten bedienen)? Aufgrund der Größe ist ein externer Ort erforderlich (z. B. durch eine direkte URL (öffentlich) auf Dropbox). Später, wenn wir dieses Problem eingegrenzt haben, können wir eine reduzierte Version in dieser Frage posten).

Antworten (1)

Dies sieht aus wie CANopen- Verkehr (RPDO wird auch in der Frage erwähnt). 0x80 ist SYNC, und es scheint, dass es in regelmäßigen Abständen gesendet wird (etwa alle 26 ms, 38-39 Hz). Und einige Geräte reagieren auf die SYNC-Nachrichten, indem sie Nachrichten mit den IDs 0x181 und 0x281 senden. Aber das ist an dieser Stelle nur eine Vermutung.

Es könnte auch sein, dass der Inhalt von ID 0x181 und 0x281 Sollwerte zu einem Servo sind (das gleiche Gerät sendet also 0x80, 0x181 und 0x281 aus) und dass die Positionsrückmeldung in den 0x301-Nachrichten enthalten ist.

Es sollte möglich sein, physische Positionen des Roboters mit den Nachrichten zu korrelieren. Es wird (wahrscheinlich) sofort ein Sollwert gesetzt und die Ist-Positionen hinken hinterher.

Hinweis: 181h ist kein Knoten, und Sie senden keine Nachrichten an ihn. 181h ist eine CAN-Nachrichten-ID. Da es sich wahrscheinlich um CANopen handelt, ist 0x181 die Nachricht „PDO1, send“ für das Gerät mit der ID 1. Beachten Sie, dass nicht immer klar ist, ob die Geräte-ID angibt, welches Gerät sie sendet, oder ob das Gerät das Ziel ist.

Type            Function code: Device ID range:
                Binary Decimal ID in  Hex             Decimal
                               CAN ID
--------------------------------------------------------------------
NMT             0000   0       No     0 - 0             0 -    0
SYNC            0001   1       No     0x80  -  0x80   128 -  128
Emergency       0001   1       Yes    0x81  -  0xFF   129 -  255
Time stamp      0010   2       No     0x100 - 0x100   256 -  256
PDO1, transmit  0011   3       Yes    0x181 - 0x1FF   385 -  511
PDO1, receive   0100   4       Yes    0x201 - 0x27F   513 -  639
PDO2, transmit  0101   5       Yes    0x281 - 0x2FF   641 -  767
PDO2, receive   0110   6       Yes    0x301 - 0x37F   769 -  895
PDO3, transmit  0111   7       Yes    0x381 - 0x3FF   897 - 1023
PDO3, receive   1000   8       Yes    0x401 - 0x47F  1025 - 1151
PDO4, transmit  1001   9       Yes    0x481 - 0x4FF  1153 - 1279
PDO4, receive   1010  10       Yes    0x501 - 0x57F  1281 - 1407
SDO, transmit   1011  11       Yes    0x581 - 0x5FF  1409 - 1535
SDO, receive    1100  12       Yes    0x601 - 0x67F  1537 - 1663
NMT error ctrl  1110  14       Yes    0x701 - 0x77F  1793 - 1919
"Es sollte möglich sein, physische Positionen des Roboters mit den Nachrichten zu korrelieren" Ja, das versuche ich zu erreichen. Ihre Vermutung, dass 0x281 ein Sollwert für ein Servo ist, klingt vernünftig, da sich der Wert nur ändert, wenn ich tatsächlich versuche, die physische Position zu ändern. 0x181 könnte etwas anderes sein, da es seinen Wert ändert, wenn ich den Motor hochdrehe und andere Tasten drücke, die nicht mit der physischen Position des Roboters korrelieren.
So nun zurück zur Frage, jetzt habe ich die Nachrichten in einem bestimmten Intervall (50ms ) immer wieder verschickt. Aber der Roboter bewegt sich überhaupt nicht und es gibt diese Warnung, dass der Bus jetzt beschäftigt ist. Es ist, als ob etwas blockiert, dass der Roboter durch Nachrichten bewegt wird. Irgendeine Idee, wie man einen solchen Fall behandelt, debuggt oder analysiert?
@Joe: Es ist keine gute Idee, zwei Geräte eine CAN-Nachricht mit derselben CAN-ID senden zu lassen. Dies führt zu CAN-Frame-Fehlern. Die Häufigkeit dieser CAN-Frame-Fehler hängt von vielen Faktoren ab, einschließlich der Buslast. Da die CAN-Frame-Fehler während der Übertragung auftreten, dauert es nur 16-32 CAN-Frame-Fehler, bevor beide Geräte in den Bus-Off-Zustand wechseln. Einige Geräte weigern sich sehr hartnäckig, aus dem Busoff herauszukommen, es sei denn, sie werden aus- und wieder eingeschaltet (ich denke, dies ist eine Fehlinterpretation des CAN-Standards, aber das ist eine andere Geschichte).
Ich glaube, ich habe den Grund gefunden, warum meine Nachricht die ganze Zeit ignoriert wird. Für den Roboter gibt es eine Fernbedienung. Der Roboter brokk170, den ich verwende, wurde entwickelt, um mit dieser Fernbedienung gesteuert zu werden. Also muss ich den Roboter über die Fernbedienung einschalten. Und diese Fernbedienung sendete ihren Wert an den Roboter. Das war der Grund, warum meine Nachrichten die ganze Zeit überschrieben werden.
Ich sehe hier also zwei Möglichkeiten: 1) Ich finde einen Weg, dass die Nachrichten der Fernbedienung vom Roboter ignoriert werden. 2) Ich schalte den Roboter mit der Fernbedienung ein und erfasse die CAN-Nachricht. Für die erste Option habe ich keine Ahnung, wie es geht (obwohl es "eleganter" wäre als die andere). Für die zweite Option habe ich die Reihenfolge der Nachrichten erfasst. Dann habe ich jede CAN-Nachricht manuell eingetippt und gesendet, aber irgendwie springt der Roboter nicht an.
CAN-Bus-Reverse-Engineering
AntwortenHierDatenschutz-Bestimmungen1y, 0v