Dekoding av meldingsdata på denne CAN-bussen

Med unntak av den første meldingen, er dette typisk SDO trafikk ( CANopen ), med forespørsel / svarpar:

0x665 SDO request (range 0x600 - 0x67F, depending on the node ID) 0x5E5 SDO response (range 0x580 - 0x5FF, depending on the node ID) 

For det første paret er en død giveaway 0x4B i den første byten av svaret. Dette indikerer at de returnerte dataene er av størrelse to byte (for en byte og fire byte er den henholdsvis 0x4F og 0x43). 0x40 i forespørselens første byte indikerer at det er en lese forespørsel (standarden bruker et annet begrep, " Last opp ", med motsatt betydning som på Internett (nedlasting) – det er fra perspektivet til den adresserte enheten).

Forespørselen CAN ID er 0x600 + node-ID. Svaret CAN ID er 0x580 + node-ID. Dermed:

665 A read request to the device with node ID 0x65 5E5 A read response from the device with node ID 0x65 

For SDO-er er CANopen-indeksen og subindeksen i den andre, tredje og fjerde byten (minst signifikant byte først for CANopen-indeksen). Så for det første paret, 40 78 60 00, sier forespørselen: " Enhet ved node-ID 0x65 (101), gi meg den lagrede verdien din ved 6078sub0 " .

I dette tilfellet flyter informasjonen fra den adresserte enheten til den som sendte forespørselen (forespørselen kan ikke sees fra CAN-bussloggen, men det er vanligvis en sentral kontroller i systemet eller et serviceverktøy som kjører på en PC (vanligvis en USB-til-CAN-adapter)).

For den viste trafikken blir det derfor laget leseforespørsler for ( svaret for den siste er ikke inkludert i den utsendte CAN-bussloggen):

6078sub0 (2 bytes, 0xDB00 = 219) 6064sub0 (4 bytes, 0x005E7DE4 - 6,192,612) 6041sub0 (2 bytes, 0x0227 - 551) 6041sub0 (2 bytes, 0x0227 - 551) 606Csub0 (?? bytes) 

Merkelig nok, blir forespørselen om 6041sub0 gjentatt.

Videre, selv om SDO-er vanligvis bare er for konfigurasjonsinformasjon, brukes CANopen-indeksområdet 0x6000 til 0x6FFF vanligvis for ikke-konfigurasjonsinformasjon, som målte mengder eller status.

Dykking i manualen

SDO-indeksene / underindeksene kan slås opp i manualen (I h ave inkluderte de faktiske verdiene fra eksempel-CAN-bussloggen):

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. 

Den første meldingen

Forutsatt at den første meldingen også er CANopen, 4E5 F0 16 00 00: For alle CANopen CAN-meldinger er ID en fire-bits funksjonskode (0-15) etterfulgt av en syv-bit node-ID. I dette tilfellet 0x4E5 = 1001 1100101b. Dermed er funksjonskoden 1001b = 9, som betyr " PDO4, overfører ". Retningen for informasjonsflyt for PDOer (til tross for, i dette tilfellet " overfører ") er et spørsmål om definisjon (avhenger av applikasjonen ). Node-ID-en er 1100101b = 0x65.

Node-ID-en for PDO er den samme som for SDO-ene.

Informasjonen i denne PUDEN, " Overfør PDO 4 ", inngår i SDO 0x1A03, " Overfør PDO-kartleggingsparameter 4 ". Hvis det ikke er endret fra standard, er dataene i PDO de samme som SDO 0x60FAsub0, et signert 32-biters heltall:

kontrollen innsats som utgang fra posisjonskontrollsløyfen. I posisjonskontrollfunksjonen er notering av kontrollinnsatsen modusavhengig og derfor ikke spesifisert.

Konklusjon

Motorenheten med node ID 0x65 sender ut kontrollinnsatsen (sannsynligvis med jevne tidsintervaller) ved hjelp av en PDO .

En kontroller eller et sanntidsmonitorvindu i et serviceverktøy leser og viser andre målte størrelser / status fra samme motorenhet ved hjelp av SDOer .

Kommentarer

• Jeg jobber med denne typen CAN bussdata til daglig, så dette er lett gjenkjennelig. Den nøyaktige tolkningen / betydningen avhenger imidlertid av informasjon om det spesifikke systemet. Jeg syntes dette spørsmålet fortjente et omfattende svar.

Du har ikke forklart hva oppføringen din viser, men det kan være meldings-ID, etterfulgt av antall databytes i parentes, etterfulgt av de faktiske databytes. Ingenting ser ut til å eksplisitt si om ID-ene er 11 eller 29 bit. Kanskje bare ved å bruke 3 HEX-sifre for ID dette oppføring indikerer 11-bits ID-er. I så fall vil det vise 8 HEX-sifre for 29-bit-ID-er.

Hva hver linje derfor (ser ut til) viser deg er en CAN-melding. Det er ikke noe mer å dekode til forstå CAN-meldingen. Den vises eksplisitt til deg.

For eksempel sier den siste linjen at det ble sett en melding med ID 665h (1637 desimal), at denne meldingen hadde 8 databytes, og at databytes var (i HEX) 40, 6C, 60, 0, 0, 0, 0 og 0. De tre første ville være 64, 108 og 96 i desimal.

Når det gjelder hva i> mening av denne meldingen er uansett hvilken enhet den har eller har til hensikt å handle på, det er noe du må slå opp i dokumentasjonen til de spesifikke enhetene. Det «et laget over CAN.

Enheten min har en node-ID på 101

Det er ingen node ID-er i CAN, bare meldings-ID-er. Hvis enhetene dine bruker konseptet med en node-ID, er dette noe spesielt med et protokolllag over CAN. CAN-standarden kan ikke hjelpe deg med det. Du må konsultere den spesifikke enhetsdokumentasjonen, som kan referere til protokollen på høyere nivå den bruker ovenfor CAN, muligens i et eget dokument.

Kommentarer

• Det ' er ikke grunnleggende CAN, det er CANopen, som det fremgår av Manual.
• Jeg har utdypet det i mitt svar .

Enheten bruker en CANopen-protokoll . CANopen er et CAN-basert kommunikasjonssystem. Den inneholder protokoller med høyere lag og profilspesifikasjoner.

Den brukes i automatisering. Det er flere protokollanalysatorer for å finne ut hele kommunikasjonen. Automatiseringssystemet som bruker CANopen er en master / slave-arkitektur. Du finner litt informasjon på wikipedia om CANopen, men det er ikke så trivielt som meldingsorientert CAN selv.

Kommentarer

• Ja, det er riktig. Det er CANopen.

For å dekode kommunikasjonen, må du vite motor CANopen Object Dictionary. Det ser ut som TPDOer og innholdet deres avhenger av kommunikasjons- og kartleggingsobjekter.

Du bør studere følgende vilkår fra CANopen for å forstå protokollen. – Objektordbok – Prosessdataobjekter (PDO) – Kommunikasjonsparametere – Kartleggingsparametere