Jeg arbejder med CAN-bussen og har brug for hjælp til afkodning af meddelelsesdata.
Her er et eksempel på de data, som jeg ser på CAN-bussen.
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#
Jeg kan ikke finde ud af, hvordan jeg kan spore dataene tilbage til en bestemt CAN busmeddelelse.
Min enhed har et node-id på 101 (base 10), og det er en StepIM-trinmotor. Her er en henvisning til manualen – http://servotronix.com/wp-content/uploads/dlm_uploads/2015/05/stepIM_CANopen_fw0.0.2.85_Rev.1.3.pdf . Så lad os prøve at afkode den sidste besked ovenfra. Det ville være “ can0 665 8 40 6C 60 00 00 00 00 00 “
Jeg kan ikke synes at finde ud af, hvordan man oversætter hexstrengen” * 40 6C 60 .. “til en kommando, som dokumentet til trinmotoren kender til …
Kommentarer
- stepIM er med CANopen-protokol, som er en højere protokol baseret på CAN-bus. Udskift tag CAN med CANopen.
Svar
Bortset fra den første besked er dette typisk SDO trafik ( CANopen ), med anmodning / 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 par er en død giveaway 0x4B i den første byte af svaret. Dette indikerer, at de returnerede data er af størrelse to byte (for en byte og fire byte er den henholdsvis 0x4F og 0x43). 0x40 i anmodningens første byte angiver, at det er en læs anmodning (standarden bruger et andet udtryk, " Upload ", med den modsatte betydning som på Internettet (download) – det er fra den adresserede enheds perspektiv).
CAN-ID-anmodningen er 0x600 + node-ID. Svaret CAN ID er 0x580 + node-ID. Således:
665 A read request to the device with node ID 0x65 5E5 A read response from the device with node ID 0x65
For SDOer er CANopen-indekset og subindex i den anden, tredje og fjerde byte (mindst signifikant byte først for CANopen-indekset). Så for det første par, 40 78 60 00, siger anmoderen: " Enhed ved node-ID 0x65 (101), giv mig din gemte værdi ved 6078sub0 " .
I dette tilfælde flyder informationen fra den adresserede enhed til den, der fremsatte anmodningen (anmoderen kan ikke ses fra CAN-busloggen, men det er normalt en central controller i systemet eller et serviceværktøj, der kører på en pc (normalt en USB-til-CAN-adapter).
Således, for den viste trafik, læses anmodninger om ( svar for den sidste er ikke inkluderet i den indsendte CAN-buslog):
6078sub0 (2 bytes, 0xDB00 = 219) 6064sub0 (4 bytes, 0x005E7DE4 - 6,192,612) 6041sub0 (2 bytes, 0x0227 - 551) 6041sub0 (2 bytes, 0x0227 - 551) 606Csub0 (?? bytes)
Underligt nok gentages anmodningen om 6041sub0.
Selvom SDOer normalt kun er til konfigurationsinformation, bruges CANopen-indeksområdet 0x6000 til 0x6FFF normalt til ikke-konfigurationsoplysninger, f.eks. Målte størrelser eller status.
Dykning i manualen
SDO-indekserne / underindekserne kan slås op i manualen (I h ave inkluderede de faktiske værdier fra eksempel-CAN-busloggen):
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 besked
Under forudsætning af at den første besked også er CANopen, 4E5 F0 16 00 00: For alle CANopen CAN-meddelelser er IDet en fire-bit funktionskode (0-15) efterfulgt af et syv-bit node-ID. I dette tilfælde 0x4E5 = 1001 1100101b. Funktionskoden er således 1001b = 9, hvilket betyder " PDO4, transmitterer ". Retningen af informationsstrømmen for PDOer (på trods af i dette tilfælde " transmitterer ") er et spørgsmål om definition (afhænger af applikationen ). Node-idet er 1100101b = 0x65.
Node-idet for PDOen er det samme som for SDOerne.
Oplysningerne i denne PDO, " Send PDO 4 ", er indeholdt i SDO 0x1A03, " Send PDO Mapping Parameter 4 ". Hvis det ikke er blevet ændret fra standardindstillingen, er dataene i PDO de samme som SDO 0x60FAsub0, et signeret 32-bit heltal:
kontrol indsats som output fra positionskontrolsløjfen. I positionskontrolfunktionen er notation af kontrolindsatsen tilstandsafhængig og derfor ikke specificeret.
Konklusion
Motorindretningen med node ID 0x65 sender kontrolindsatsen (sandsynligvis med regelmæssige tidsintervaller) ved hjælp af en PDO .
En controller eller et realtidsovervågningsvindue i et serviceværktøj læser og viser andre målte størrelser / status fra den samme motorenhed ved hjælp af SDOer .
Kommentarer
- Jeg arbejder med denne form for CAN busdata dagligt, så det er let at genkende. Den nøjagtige fortolkning / betydning afhænger dog af information om det specifikke system. Jeg troede, at dette spørgsmål fortjente et omfattende svar.
Svar
Du har ikke forklaret, hvad din fortegnelse nøjagtigt viser, men det måske være meddelelses-IDet, efterfulgt af antallet af databytes i parentes, efterfulgt af de faktiske data-bytes. Intet synes eksplicit at angive, om IDerne er 11 eller 29 bit. Måske bare ved at bruge 3 HEX-cifre til IDet dette Fortegnelse angiver 11 bit-ider. I så fald vil det vise 8 HEX-cifre til 29 bit-ider.
Hvad hver linje derfor (ser ud til) viser dig, er en CAN-besked. Der er ikke mere at afkode til forstå CAN-meddelelsen. Den vises eksplicit til dig.
For eksempel siger den sidste linje, at en meddelelse blev set med ID 665h (1637 decimal), at denne besked havde 8 databytes, og at databytes var (i HEX) 40, 6C, 60, 0, 0, 0, 0 og 0. De første tre ville være 64, 108 og 96 i decimal.
Hvad angår hvad betydning af denne meddelelse er uanset hvilken enhed der stammer fra den eller er beregnet til at handle på den, det er noget du skal slå op i dokumentationen til de specifikke enheder. Det “et lag over CAN.
Min enhed har en node-id på 101
Der er ingen node IDer i CAN, kun meddelelses-IDer. Hvis dine enheder bruger konceptet med et node-ID, så er dette noget særligt for et protokollag over CAN. CAN-standarden kan ikke hjælpe dig med det. Du skal konsultere den specifikke enhedsdokumentation, som muligvis henviser til den højere niveauprotokol, den bruger ovenfor CAN, muligvis i et separat dokument.
Kommentarer
- Det ' er ikke grundlæggende CAN, det er CANopen, som det fremgår af Manual.
- Jeg har uddybet det i mit svar .
Svar
Enheden bruger en CANopen-protokol . CANopen er et CAN-baseret kommunikationssystem. Den indeholder protokoller med højere lag og profilspecifikationer.
Den bruges i automatisering. Der er flere protokolanalysatorer for at finde ud af hele kommunikationen. Automatiseringssystemet, der bruger CANopen, er en master / slave-arkitektur. Du finder nogle oplysninger på wikipedia om CANopen, men det er ikke så trivielt som den meddelelsesorienterede CAN selv.
Kommentarer
- Ja, det er korrekt. Det er CANopen.
Svar
For at afkode kommunikationen skal du kende motor CANopen Object Dictionary. Det ser ud til, at TPDOer og deres indhold afhænger af kommunikations- og kortlægningsobjekter.
Du skal studere følgende vilkår fra CANopen for at forstå protokollen. – Objektordbog – Procesdataobjekter (PDO) – Kommunikationsparametre – Kortlægningsparametre