Lucrez cu magistrala CAN și am nevoie de ajutor pentru decodarea datelor mesajelor.
Iată un eșantion de date pe care „le văd pe magistrala CAN.
root@petalinux:/var/volatile/tmp# /tmp/candump -n 10 can0 can0 4E5 [4] F0 16 00 00 can0 665 [8] 40 78 60 00 00 00 00 00 can0 5E5 [8] 4B 78 60 00 DB 00 00 00 can0 665 [8] 40 64 60 00 00 00 00 00 can0 5E5 [8] 43 64 60 00 E4 7D 5E 00 can0 665 [8] 40 41 60 00 00 00 00 00 can0 5E5 [8] 4B 41 60 00 27 02 00 00 can0 665 [8] 40 41 60 00 00 00 00 00 can0 5E5 [8] 4B 41 60 00 27 02 00 00 can0 665 [8] 40 6C 60 00 00 00 00 00 root@petalinux:/var/volatile/tmp# Nu pot afla cum să trasez datele înapoi la un anumit CAN mesaj de magistrală.
Dispozitivul meu are un ID de nod 101 (baza 10) și este un motor StepIM stepper. Iată o referință la manual – http://servotronix.com/wp-content/uploads/dlm_uploads/2015/05/stepIM_CANopen_fw0.0.2.85_Rev.1.3.pdf . Deci, să încercăm să decodificăm ultimul mesaj de sus. Acesta ar fi „ can0 665 8 40 6C 60 00 00 00 00 00 „
Nu pot să îmi dau seama cum să traduc șirul hexagonal” * 40 6C 60 .. „într-o comandă despre care știe documentul pentru motorul pas cu pas …
Comentarii
- stepIM sunt cu protocolul CANopen, care este un protocol mai înalt bazat pe magistrala CAN. Vă rugăm să schimbați eticheta CAN cu CANopen.
Răspuns
Cu excepția primului mesaj, acest lucru este tipic trafic SDO ( CANopen ), cu perechi cerere / răspuns:
0x665 SDO request (range 0x600 - 0x67F, depending on the node ID) 0x5E5 SDO response (range 0x580 - 0x5FF, depending on the node ID) Pentru prima pereche, un cadou mort este 0x4B în primul octet al răspunsului. Acest lucru indică faptul că datele returnate au o dimensiune de doi octeți (pentru un octet și patru octeți, este 0x4F și, respectiv, 0x43). 0x40 din primul octet al cererii indică faptul că este o cerere citită (standardul folosește un termen diferit, ” Încărcare „, cu sensul opus ca pe Internet (descărcare) – este din perspectiva dispozitivului adresat).
ID-ul CAN al cererii este 0x600 + ID nod. Răspunsul CAN ID este 0x580 + ID nod. Astfel:
665 A read request to the device with node ID 0x65 5E5 A read response from the device with node ID 0x65 Pentru SDO, indicele și subindexul CANopen se află în al doilea, al treilea și al patrulea octet (cel mai puțin semnificativ octet primul pentru indicele CANopen). Deci, pentru prima pereche, 40 78 60 00, solicitantul spune: ” Dispozitiv la ID-ul nodului 0x65 (101), dați-mi valoarea stocată la 6078sub0 ” .
În acest caz, informațiile curg de la dispozitivul adresat către oricine a făcut cererea (solicitantul nu poate fi văzut din jurnalul de autobuz CAN, dar este de obicei un controler central în sistem sau un instrument de service care rulează pe un PC (de obicei un adaptor USB-CAN-CAN)).
Astfel, pentru traficul afișat, se fac cereri de citire pentru ( răspunsul pentru ultimul nu este inclus în jurnalul de autobuz CAN afișat):
6078sub0 (2 bytes, 0xDB00 = 219) 6064sub0 (4 bytes, 0x005E7DE4 - 6,192,612) 6041sub0 (2 bytes, 0x0227 - 551) 6041sub0 (2 bytes, 0x0227 - 551) 606Csub0 (?? bytes) În mod ciudat, solicitarea pentru 6041sub0 se repetă.
În plus, chiar dacă SDO-urile sunt de obicei numai pentru informații de configurare, intervalul de indice CANopen de la 0x6000 la 0x6FFF este de obicei utilizat pentru informații care nu sunt de configurare, cum ar fi cantitățile măsurate sau starea.
Indicii / subindexele SDO pot fi căutați în manual (I h au inclus valorile reale din jurnalul magistralei CAN):
6078sub0 Motor current, 219 mA 6064sub0 "Position Actual Internal Value" is 6,192,612 6041sub0 Statusword, 0x0227 = 0000 0010 0010 0111, meaning: "ready to switch on", "switched on", "operation enabled", "quick stop" "remote" 606Csub0 "Velocity Actual Value". The value is not included, but it is a 32-bit signed integer. Primul mesaj
Presupunând că primul mesaj este și CANopen, 4E5 F0 16 00 00: Pentru toate mesajele CANopen CAN, ID-ul este un cod de funcție de patru biți (0-15) urmat de un ID de nod de șapte biți. În acest caz, 0x4E5 = 1001 1100101b. Astfel, codul funcției este 1001b = 9, adică ” PDO4, transmite „. Direcția fluxului de informații pentru PDO-uri (în ciuda, în acest caz, ” transmiterea „) este o chestiune de definiție (depinde de aplicație ). ID-ul nodului este 1100101b = 0x65.
ID-ul nodului pentru PDO este același ca și pentru SDO-urile.
Informațiile din acest PDO, ” Transmit PDO 4 „, este conținut în SDO 0x1A03, ” Transmit PDO Mapping Parameter 4 „. Dacă nu a fost modificată din valoarea implicită, datele din PDO sunt aceleași ca SDO 0x60FAsub0, un număr întreg pe 32 de biți semnat:
controlul efort ca ieșire a buclei de control a poziției. În funcția de control al poziției, notarea efortului de control depinde de mod și, prin urmare, nu este specificată.
Concluzie
Dispozitivul motor cu ID nod 0x65 trimite efortul de control (probabil la intervale regulate de timp) folosind un PDO .
Un controler sau o fereastră de monitorizare în timp real într-un instrument de service citește și afișează alte cantități măsurate / stare de la același dispozitiv motor folosind SDOs .
Comentarii
- Lucrez cu acest tip de CAN date de autobuz zilnic, deci acest lucru este ușor de recunoscut. Cu toate acestea, interpretarea / semnificația precisă depinde de informații despre sistemul particular. Am crezut că această întrebare merită un răspuns cuprinzător.
Răspuns
Nu ați explicat exact ce arată înregistrarea dvs., dar ar putea fi ID-ul mesajului, urmat de numărul de octeți de date între paranteze, urmat de octeții de date reali. Nimic nu pare să precizeze în mod explicit dacă ID-urile sunt de 11 sau 29 de biți. Poate doar folosind 3 cifre HEX pentru ID listarea indică ID-uri de 11 biți. Dacă da, ar afișa 8 cifre HEX pentru ID-urile de 29 de biți.
Prin urmare, ceea ce vă arată fiecare linie (se pare) este un mesaj CAN. Nu mai este nimic de decodat în înțelegeți mesajul CAN. Vi se arată explicit.
De exemplu, ultima linie spune că un mesaj a fost văzut cu ID 665h (1637 zecimal), că acest mesaj avea 8 octeți de date și că octeții de date au fost (în HEX) 40, 6C, 60, 0, 0, 0, 0 și 0. Primii trei ar fi 64, 108 și 96 în zecimal.
În ceea ce privește ceea ce sensul acelui mesaj este pentru orice dispozitiv l-a inițiat sau este destinat să acționeze în legătură cu acesta, asta este ceva trebuie să căutați în documentația dispozitivelor specifice. Acel „strat de deasupra CAN.
Dispozitivul meu are un ID de nod 101
Nu există nod ID-urile din CAN, numai ID-urile mesajelor. Dacă dispozitivele dvs. utilizează conceptul de ID nod, atunci acesta este ceva special pentru un strat de protocol deasupra CAN. Standardul CAN nu vă poate ajuta în acest sens. Trebuie să consultați documentația specifică a dispozitivului, care ar putea face referire la protocolul de nivel superior pe care îl folosește mai sus de CAN, posibil într-un document separat.
Comentarii
- ‘ nu este CAN de bază, este CANopen, așa cum se vede în Manual.
- Am elaborat-o în răspunsul meu .
Răspuns
Dispozitivul utilizează un Protocol CANopen . CANopen este un sistem de comunicare bazat pe CAN. Acesta cuprinde protocoale de nivel superior și specificații de profil.
Este utilizat în automatizare. Există mai mulți analizatori de protocol pentru a afla întreaga comunicare. Sistemul de automatizare care utilizează CANopen este o arhitectură master / slave. Veți găsi câteva informații pe Wikipedia despre CANopen, dar nu sunt atât de banale precum CAN-ul orientat către mesaj.
Comentarii
- Da, este corect. Este CANopen.
Răspuns
Pentru a decoda comunicarea, trebuie să cunoașteți motorul CANopen Object Dictionary. Se pare că TPDO-urile și conținutul lor depind de obiecte de comunicare și cartografiere.
Ar trebui să studiați următorii termeni de la CANopen pentru a înțelege protocolul. – Dicționar de obiecte – Obiecte de date de proces (PDO) – Parametri de comunicare – Parametri de mapare