Sto lavorando con il bus CAN e ho bisogno di aiuto con la decodifica dei dati dei messaggi.
Ecco un campione dei dati che vedo sul bus 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#
Non riesco a capire come risalire ai dati su un particolare CAN messaggio bus.
Il mio dispositivo ha un ID nodo 101 (base 10) ed è un motore passo-passo StepIM. Ecco un riferimento al manuale: http://servotronix.com/wp-content/uploads/dlm_uploads/2015/05/stepIM_CANopen_fw0.0.2.85_Rev.1.3.pdf . Quindi proviamo a decodificare lultimo messaggio dallalto. Sarebbe “ can0 665 8 40 6C 60 00 00 00 00 00 “
Non riesco” a capire come tradurre la stringa esadecimale “* 40 6C 60 ..” in un comando che il documento per il motore passo-passo conosce …
Commenti
- gli stepIM sono con protocollo CANopen che è un protocollo superiore basato su CAN bus. Si prega di scambiare il tag CAN con CANopen.
Risposta
Ad eccezione del primo messaggio, questo è tipico SDO traffico ( CANopen ), con coppie richiesta / risposta:
0x665 SDO request (range 0x600 - 0x67F, depending on the node ID) 0x5E5 SDO response (range 0x580 - 0x5FF, depending on the node ID)
Per la prima coppia, un regalo morto è lo 0x4B nel primo byte della risposta. Ciò indica che i dati restituiti hanno una dimensione di due byte (per un byte e quattro byte, sono rispettivamente 0x4F e 0x43). Lo 0x40 nel primo byte della richiesta indica che si tratta di una richiesta di lettura (lo standard utilizza un termine diverso, ” Carica “, con il significato opposto rispetto a Internet (download) – è dal punto di vista del dispositivo indirizzato).
LID CAN della richiesta è 0x600 + ID nodo. La risposta CAN ID è 0x580 + ID nodo. Quindi:
665 A read request to the device with node ID 0x65 5E5 A read response from the device with node ID 0x65
Per gli SDO, lindice e il sottoindice CANopen si trovano nel secondo, terzo e quarto byte (primo byte meno significativo per lindice CANopen). Quindi per la prima coppia, 40 78 60 00, il richiedente dice: ” Dispositivo allID nodo 0x65 (101), dammi il tuo valore memorizzato su 6078sub0 ” .
In questo caso linformazione fluisce dal dispositivo indirizzato a chi ha fatto la richiesta (il richiedente non può essere visto dal registro del bus CAN, ma di solito è un controller centrale nel sistema o uno strumento di servizio in esecuzione su un PC (solitamente un adattatore da USB a CAN)).
Pertanto, per il traffico mostrato, vengono effettuate richieste di lettura per (il la risposta per lultimo non è inclusa nel log del bus CAN pubblicato):
6078sub0 (2 bytes, 0xDB00 = 219) 6064sub0 (4 bytes, 0x005E7DE4 - 6,192,612) 6041sub0 (2 bytes, 0x0227 - 551) 6041sub0 (2 bytes, 0x0227 - 551) 606Csub0 (?? bytes)
Stranamente, la richiesta per 6041sub0 viene ripetuta.
Inoltre, anche se gli SDO di solito servono solo per informazioni di configurazione, lintervallo di indice CANopen da 0x6000 a 0x6FFF viene solitamente utilizzato per informazioni non di configurazione, come le quantità misurate o lo stato.
Immergersi nel manuale
Gli indici / sottoindici SDO possono essere consultati nel manuale (I h ave incluso i valori effettivi dal registro del bus CAN di esempio):
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.
Il primo messaggio
Supponendo che anche il primo messaggio sia CANopen, 4E5 F0 16 00 00: per tutti i messaggi CAN CANopen lID è un codice funzione a quattro bit (0-15) seguito da un ID nodo a sette bit. In questo caso, 0x4E5 = 1001 1100101b. Pertanto il codice della funzione è 1001b = 9, che significa ” PDO4, trasmissione “. La direzione del flusso di informazioni per i PDO (nonostante, in questo caso, ” trasmissione “) è una questione di definizione (dipende dallapplicazione ). LID del nodo è 1100101b = 0x65.
LID del nodo per il PDO è lo stesso degli SDO.
Le informazioni in questo PDO, ” Transmit PDO 4 “, è contenuto in SDO 0x1A03, ” Transmit PDO Mapping Parameter 4 “. Se non è stato modificato dal valore predefinito, i dati nel PDO sono gli stessi di SDO 0x60FAsub0, un intero con segno a 32 bit:
il controllo sforzo come uscita dellanello di controllo della posizione. Nella funzione di controllo della posizione, la notazione dello sforzo di controllo dipende dalla modalità e quindi non è specificata.
Conclusione
Il dispositivo motore con ID nodo 0x65 invia lo sforzo di controllo (probabilmente a intervalli di tempo regolari) utilizzando un PDO .
Un controller o una finestra di monitoraggio in tempo reale in uno strumento di servizio legge e visualizza altre grandezze / stati misurati dallo stesso dispositivo motore utilizzando SDO .
Commenti
- Lavoro con questo tipo di CAN dati del bus su base giornaliera, quindi è facilmente riconoscibile. Tuttavia, linterpretazione / significato preciso dipende dalle informazioni sul particolare sistema. Ho pensato che questa domanda meritasse una risposta esauriente.
Risposta
Non hai “spiegato cosa mostra esattamente la tua scheda, ma potrebbe essere lID del messaggio, seguito dal numero di byte di dati tra parentesi, seguito dai byte di dati effettivi. Niente sembra indicare esplicitamente se gli ID sono 11 o 29 bit. Forse solo usando 3 cifre HEX per lID this lelenco indica ID a 11 bit. In tal caso, mostrerebbe 8 cifre HEX per ID a 29 bit.
Ciò che ogni riga è quindi (sembra) mostrandoti è un messaggio CAN. Non cè più niente da decodificare capire il messaggio CAN. Ti viene mostrato esplicitamente.
Ad esempio, lultima riga dice che è stato visto un messaggio con ID 665h (1637 decimale), che questo messaggio aveva 8 byte di dati e che il byte di dati erano (in HEX) 40, 6C, 60, 0, 0, 0, 0 e 0. I primi tre sarebbero 64, 108 e 96 in decimale.
Per quanto riguarda il il significato di quel messaggio è per qualunque dispositivo lo abbia originato o sia inteso ad agire su di esso, è qualcosa devi cercare nella documentazione dei dispositivi specifici. Quel “è un livello sopra CAN.
Il mio dispositivo ha un ID nodo 101
Non ci sono nodi ID in CAN, solo ID messaggio. Se i tuoi dispositivi utilizzano il concetto di ID nodo, questo è qualcosa di particolare per un livello di protocollo sopra CAN. Lo standard CAN non può aiutarti in questo. È necessario consultare la documentazione specifica del dispositivo, che potrebbe fare riferimento al protocollo di livello superiore che utilizza sopra CAN, possibilmente in un documento separato.
Commenti
- ‘ non è CAN di base, è CANopen, come mostrato nel manuale.
- Lho elaborato in la mia risposta .
Risposta
Il dispositivo utilizza un protocollo CANopen . CANopen è un sistema di comunicazione basato su CAN. Comprende protocolli di livello superiore e specifiche del profilo.
Viene utilizzato nellautomazione. Ci sono diversi analizzatori di protocollo per capire lintera comunicazione. Il sistema di automazione che utilizza CANopen è unarchitettura master / slave. Troverai alcune informazioni su CANopen su wikipedia, ma non è così banale come lo stesso CAN orientato ai messaggi.
Commenti
- Sì, è corretto. È CANopen.
Risposta
Per decodificare la comunicazione, è necessario conoscere il dizionario degli oggetti CANopen del motore. Sembra che i TPDO e il loro contenuto dipenda dalla comunicazione e dalla mappatura degli oggetti.
Dovresti studiare i seguenti termini da CANopen per comprendere il protocollo. – Dizionario degli oggetti – Process Data Objects (PDO) – Parametri di comunicazione – Parametri di mappatura